Network Mode of Operation (NMO)

Picture Source: Tektronix

The Network Mode of Operation (NMO) is also sometimes referred to as Network Operation Mode (NOM). The Network Modes have different values and interpretation in UTRAN and GERAN

In both the cases the Operation modes is decided based on the Gs interface between the CS CN (core network) a.k.a. MSC and the PS CN a.k.a. SGSN

In UTRAN:

Network Operation Mode I (NMO-I) is used when the Gs interface is present. In this case during the registration a Combined Attach (includes GPRS Attach & IMSI Attach procedures) procedure can be performed. A GMM Attach Request message with the attach type set to Combined Attach is used. Upon completion of this procedure, MM Status is IMSI Attached and GMM State is Attached.

In Network Operation Mode II (NMO-II) the GS Interface is not present. So the GMM attach procedure and the IMSI Attach (via Location Update) has to be performed seperately. This causes additional signalling.

Basic air interface signalling in case of NMO2 is shown here.

In GERAN:

Network operation mode 1. A network which has the Gs interface implemented is referred to as being in network operation mode 1. CS and PS paging is coordinated in this mode of operation on either the GPRS or the GSM paging channel. If the mobile device has been assigned a data traffic channel then CS paging will take place over this data channel rather than the paging channel (CS or PS).

Network operation mode 2. The Gs interface is not present and there is no GPRS paging channel present. In this case, paging for CS and PS devices will be transferred over the standard GSM common control channel (CCCH) paging channel. Even if the mobile device has been assigned a packet data channel, CS paging will continue to take place over the CCCH paging channel and thus monitoring of this channel is still required.

Network operation mode 3. The Gs interface is not present. CS paging will be transferred over the CCCH paging channel. PS paging will be transferred over the packet CCCH (PCCCH) paging channel, if it exists in the cell. In this case the mobile device needs to monitor both the paging channels.

The GERAN part above is extract from the book Convergence Technologies for 3G Networks.

From Martin Sauter's Blog:

The Gs interface, has a number of subtle but important advantages:

During an ongoing GPRS / EDGE data transfer (TBF established), mobiles can't detect incoming voice calls and SMS messages as they are focused on receiving packets and thus can not observe the paging channel. In NMO-1, the circuit switched part of the network forwards the paging message to the packet switched side of the network which then forwards the paging message between the user data blocks while a data transfer is ongoing. Mobiles can thus receive the paging message despite the ongoing data transfer, interrupt the session and accept the voice call or SMS.

Location/Routing area updates when moving to a cell in a different location/routing area are performed much faster as the mobile only communicates with the packet switched part of the network. The packet switched network (the SGSN) then forwards the location update to the circuit switched part of the network (to the MSC) which spares the mobile from doing it itself. This is especially important for ongoing data transfers as these are interrupted for a shorter period of time.

Cell reselections from UMTS to GPRS can be executed much faster due to the same effect as described in the previous bullet. Whithout NOM-1 an Inter RAT (Radio Access Technology) cell reselection with Location and Routing Area update requires around 10 to 12 seconds. With NOM-1 the time is reduced to around 5 to 6 seconds. An important difference as this reduces the chance to miss an incoming call during the change of the radio network. Also, ongoing data transfers are interrupted for a shorter time,an additional benefit that should not be underestimated.

ETWS detailed in LTE and UMTS

Its been couple of years since the introductory post on 3GPP Earthquake and Tsunami Warning service (ETWS). The following is more detailed post on ETWS from the NTT Docomo technical journal.

3GPP Release 8 accepted the standard technical specification for warning message distribution platform such as Area Mail, which adopts pioneering technology for faster distribution, in order to fulfil the requirements concerning the distribution of emergency information e.g. earthquakes, tsunamis and so on in LTE/EPC. The standard specifies the delivery of emergency information in two levels. The Primary Notification contains the minimum, most urgently required information such as “An earthquake occurred”; the Secondary Notification includes supplementary information not contained in the Primary Notification, such as seismic intensity, epicentre, and so on. This separation allows implementation of excellent information distribution platforms that can achieve the theoretically fastest speed of the warning distribution.

The purpose of the ETWS is to broadcast emergency information such as earthquake warnings provided by a local or national governments to many mobile terminals as quickly as possible by making use of the characteristic of the widespread mobile communication networks.

The ETWS, in the same way as Area Mail, detects the initial slight tremor of an earthquake, the Primary Wave (P wave - The first tremor of an earthquake to arrive at a location), and sends a warning message that an earthquake is about to happen to the mobile terminals in the affected area. ETWS can deliver the first notification to mobile terminals in the shortest theoretical time possible in a mobile communication system (about four seconds after receiving the emergency information from the local or national government), which is specified as a requirement by 3GPP.

The biggest difference between Area Mail and the ETWS is the disaster notification method (Figure 1). Earthquake warnings in Area Mail have a fixed-length message configuration that notifies of an earthquake. ETWS, on the other hand, achieves distribution of the highest priority information in the shortest time by separating out the minimum information that is needed with the most urgency, such as “Earthquake about to happen,” for the fastest possible distribution as a Primary Notification; other supplementary information (seismic intensity, epicentre, etc.) is then distributed in a Secondary Notification. This distinction thus implements a flexible information distribution platform that prioritizes information distribution according to urgency.

The Primary Notification contains only simple patterned disaster information, such as “Earthquake.” When a mobile terminal receives a Primary Notification, it produces a pre-set alert sound and displays pre-determined text on the screen according to the message content to notify users of the danger. The types of disaster that a Primary Notification can inform about are specified as “Earthquake,” “Tsunami,” “Tsunami + Earthquake,” “Test” and “Other,” regardless of the type of radio access.

The Secondary Notification contains the same kind of message as does the existing Area Mail service, which is, for example, textual information distributed from the network to the mobile terminal to inform of the epicentre, seismic intensity and other such information. That message also contains, in addition to text, a Message Identifier and Serial Number that identifies the type of disaster.

A major feature of the ETWS is compatibility with international roaming. Through standardization, mobile terminals that can receive ETWS can receive local emergency information when in other countries if the local network provides the ETWS service. These services are provided in a manner that is common to all types of radio access (3G, LTE, etc.).

Network Architecture

The ETWS platform is designed based on the Cell Broadcast Service (CBS). The ETWS network architecture is shown in Figure 2. Fig. 2 also shows the architecture for 3G network to highlight the features differences between LTE and 3G.

In the ETWS architecture for 3G, a Cell Broadcast Centre (CBC), which is the information distribution server, is directly connected to the 3G Radio Network Controller (RNC). The CBC is also connected to the Cell Broadcast Entity (CBE), which distributes information from the Meteorological Agency and other such sources.

In an LTE radio access network, however, the eNodeB (eNB) is directly connected to the core network, and eNB does not have a centralized radio control function as the one provided by the RNC of 3G. Accordingly, if the same network configuration as used for 3G were to be adopted, the number of eNB connected to the CBC would increase and add to the load on the CBC. To overcome that issue, ETWS for LTE adopts a hierarchical architecture in which the CBC is connected to a Mobility Management Entity (MME).

The MME, which acts as a concentrator node, is connected to a number of eNBs. This architecture gives advantages to the network, such as reducing the load in the CBC and reducing the processing time, and, thus preventing delay in distribution.

Message Distribution Area

In the 3G ETWS and Area Mail systems, the distribution area can be specified only in cell units, which creates the issue of huge distribution area database in CBC. In LTE ETWS, however, the distribution area is specified in three different granularities (Figure 3). This allows the operator to perform area planning according to the characteristic of the warning/emergency occasions, e.g. notice of an earthquake with a certain magnitude needs to be distributed in a certain width of area, thus allowing efficient and more flexible broadcast of the warning message.

1) Cell Level Distribution Area: The CBC designates the cell-level distribution areas by sending a list of cell IDs. The emergency information is broadcasted only to the designated cells. Although this area designation has the advantage of being able to pinpoint broadcast distribution to particular areas, it necessitates a large processing load in the network node (CBC, MME and eNB) especially when the list is long.

2) TA Level Distribution Area: In this case, the distribution area is designated as a list of Tracking Area Identities (TAIs). TAI is an identifier of a Tracking Area (TA), which is an LTE mobility management area. The warning message broadcast goes out to all of the cells in the TAIs. This area designation has the advantage of less processing load when the warning message has to be broadcast to relatively wide areas.

3) EA Level Distribution Area: The Emergency Area (EA) can be freely defined by the operator. An EA ID can be assigned to each cell, and the warning message can be broadcasted to the relevant EA only. The EA can be larger than a cell and is independent of the TA. EA is a unit of mobility management. EA thus allows flexible design for optimization of the distribution area for the affected area according to the type of disaster.

Message Distribution

The method of distributing emergency information to LTE radio networks is shown in Figure 4. When the CBC receives a request for emergency information distribution from CBE, it creates the text to be sent to the terminals and specifies the distribution area from the information in the request message (Fig. 4 (1) (2)).

Next, the CBC sends a Write-Replace Warning Request message to the MME of the specified area. This message contains information such as disaster type, warning message text, message distribution area, Primary Notification information, etc. (Fig. 4 (3)). When the MME receives this message, it sends a response message to the CBC to notify that the message was correctly received. The CBC then notifies the CBE that the distribution request was received and the processing has begun (Fig. 4 (4) (5)). At the same time, the MME checks the distribution area information in the received message (Fig. 4 (6)) and, if a TAI list is included, it sends the Write-Replace Warning Request message only to the eNB that belong to the TAI in the list (Fig. 4 (7)). If the TAI list is not included, the message is sent to all of the eNB to which the MME is connected.

When the eNB receives the Write-Replace Warning Request message from the MME, it determines the message distribution area based on the information included in the Write-Replace Warning Request message (Fig. 4 (8)) and starts the broadcast (Fig. 4 (9) (10)). The following describes how the eNB processes each of the specified information elements.

1) Disaster Type Information (Message Identifier/Serial Number): If an on-going broadcast of a warning message exists, this information is used by the eNB to decide whether it shall discard the newly received message or overwrite the ongoing warning message broadcast with the newly received one. Specifically, if the received request message has the same type as the message currently being broadcasted, the received request message is discarded. If the type is different from the message currently being broadcast, the received request message shall overwrite the ongoing broadcast message and the new warning message is immediately broadcasted.

2) Message Distribution Area (Warning Area List): When a list of cells has been specified as the distribution area, the eNB scans the list for cells that it serves and starts warning message broadcast to those cells. If the message distribution area is a list of TAIs, the eNB scans the list for TAIs that it serves and starts the broadcast to the cells included in those TAIs. In the same way, if the distribution area is specified as an EA (or list of EAs), the eNB scans the EA ID list for EA IDs that it serves and starts the broadcast to the cells included in the EA ID.

If the received Write-Replace Warning Request message does not contain distribution area information, the eNB broadcasts the warning message to all of the cells it serves.

3) Primary Notification Information: If Primary Notification information indication exists, that information is mapped to a radio channel that is defined for the broadcast of Primary Notification.

4) Message Text: The eNB determines whether or not there is message text and thus whether or not a Secondary Notification needs to be broadcasted. If message text exists, that text is mapped to a radio channel that is defined for the broadcast of Secondary Notification. The Secondary Notification is broadcast according to the transmission intervals and number of transmissions specified by the CBC. Upon the completion of a broadcast, the eNB returns the result to the MME (Fig. 4 (11)).

Radio Function Specifications

Overview : In the previous Area Mail service, only mobile terminals in the standby state (RRC_IDLE) could receive emergency information, but in ETWS, emergency information can be received also by mobile terminals in the connected state (RRC_CONNECTED), and hence the information can be delivered to a broader range of users. In LTE, when delivering emergency information to mobile terminals, the eNB sends a bit in the paging message to notify that emergency information is to be sent (ETWS indication), and sends the emergency information itself as system information broadcast. In 3G, on the other hand, the emergency information is sent through the paging message and CBS messages.

Message Distribution method for LTE: When the eNB begins transmission of the emergency information, a paging message in which the ETWS indication is set is sent to the mobile terminal. ETWS-compatible terminals, whether in standby or connected, try to receive a paging message at least once per default paging cycle, whose value is specified by the system information broadcast and can be set to 320 ms, 640 ms, 1.28 s or 2.56 s according to the 3GPP specifications. If a paging message that contains an ETWS indication is received, the terminal begins receiving the system information broadcast that contains the emergency information. The paging message that has the ETWS indication set is sent out repeatedly at every paging opportunity, thus increasing the reception probability at the mobile terminal.

The ETWS message itself is sent as system information broadcast. Specifically, the Primary Notification is sent as the Warning Type in System Information Block Type 10 (SIB10) and the Secondary Notification is sent as a Warning Message in SIB11. By repeated sending of SIB10 and SIB11 (at an interval that can be set to 80 ms, 160 ms, 320 ms, 640 ms, 1.28 s, 2.56 s, or 5.12 s according to the 3GPP specifications), the probability of the information being received at the residing mobile terminal can be increased. In addition, the SIB10 and SIB11 scheduling information is included in SIB1 issued at 80-ms intervals, so mobile terminals that receive the ETWS indication try to receive SIB10 and SIB11 after first having received the SIB1. By checking the disaster type information (Message Identifier and Serial Number) contained in SIB10 and SIB11, the mobile terminal can prevent the receiving of multiple messages that contain the same emergency information.

3G Message Distribution Method: For faster information delivery and increased range of target uers in 3G also, the CBS message distribution control used in Area Mail was enhanced. An overview of the 3G radio system is shown in Figure 5.

In the Area Mail system, a Common Traffic Channel (CTCH) logical channel is set up in the radio link, and emergency information distribution is implemented by sending CBS messages over that channel. To inform the mobile terminals that the CTCH logical channel has been set up, the RNC orders the base station (BTS) to set the CTCH Indicator information element in the system information broadcast to TRUE, and transmits the paging message indicating a change in the system information broadcast to the mobile terminals. When the mobile terminal receives the CTCH Indicator, it begins monitoring the CTCH logical channel and can receive CBS messages.

In ETWS, by including the Warning Type in the paging message indicating a change in the system information broadcast, processing for a pop-up display and alert sound processing (Primary Notification) at the mobile terminals according to the Warning Type can be executed in parallel to the processing at the mobile terminals to start receiving the CBS messages. This enhancement allows users whose terminals are in the connected state (RRC_CONNECTED) to also receive emergency information. In the previous system, it was not possible for these users to receive emergency information. Also including disaster type information (Message Identifier and Serial Number) in this paging message makes it possible to prevent receiving multiple messages containing the same emergency information at the mobile terminal.

More detailed information (Secondary Notification) is provided in CBS messages in the same way as in the conventional Area Mail system, thus achieving an architecture that is common to ETWS users and Area Mail users.

Temporary Identities in LTE/SAE - 2: RNTI's

Last year I covered some information on temporary identities but never got a chance to continue on it. Here is one on RNTI's

RNTI or Radio Network Temporary Identifier(s) are used primarily by eNB Physical Layer for scrambling the coded bits in each of the code words to be transmitted on the physical channel. This scrambling process in PHY happens before modulation. There is a sequence followed for scrambling, calculation of which depends on the RNTI(UE specific for channels like PDSCH,PUSCH) and cell specific (for broadcast channels like PBCH). Details could be found in [2].

The following table lists different kinds of RNTI's:

Lets look at some of these in slightly more detail:

P-RNTI (Paging RNTI): To receive paging messages from E-UTRAN, UEs in idle mode monitor the PDCCH channel for P-RNTI value used to indicate paging. If the terminal detects a group identity used for paging (the P-RNTI) when it wakes up, it will process the corresponding downlink paging message transmitted on the PCH.

SI-RNTI (System Information RNTI): The presence of system information on DL-SCH in a subframe is indicated by the transmission of a corresponding PDCCH marked with a special System Information RNTI (SI-RNTI). Similar to the PDCCH providing the scheduling assignment for ‘ normal ’ DL-SCH transmission, this PDCCH also indicates the transport format and physical resource (set of resource blocks) used for the system-information transmission.

M-RNTI (MBMS RNTI): Used in Rel-9 for MCCH Information change notification.

RA-RNTI (Random Access RNTI): The RA-RNTI is used on the PDCCH when Random Access Response (RAR) messages are transmitted. It unambiguously identifies which time-frequency resource was utilized by the UE to transmit the Random Access preamble. If multiple UEs had collided by selecting the same signature in the same preamble time-frequency resource, they would each receive the RAR.

C-RNTI (Cell RNTI): The C-RNTI to be used by a given UE while it is in a particular cell. C-RNTI allocation and details are too complex to explain in the blog so please refer to Nomor newsletter here.

TC-RNTI: When the UE does not have allocated C-RNTI then Temporaru C-RNTI is used. A temporary identity, the TC-RNTI, used for further communication between the terminal and the network. If the communication is successful then TC-RNTI is promoted eventually to C-RNTI in the case of UE not having a C-RNTI.

SPS-C-RNTI (Semi-Persistent Scheduling C-RNTI): For the configuration or reconfiguration of a persistent schedule, RRC signalling indicates the resource allocation interval at which the radio resources are periodically assigned. Specific transmission resource allocations in the frequency domain, and transmission attributes such as the modulation and coding scheme, are signalled using the PDCCH. The actual transmission timing of the PDCCH messages is used as the reference timing to which the resource allocation interval applies. When the PDCCH is used to configure or reconfigure a persistent schedule, it is necessary to distinguish the scheduling messages which apply to a persistent schedule from those used for dynamic scheduling. For this purpose, a special identity is used, known as the Semi-Persistent Scheduling C-RNTI (SPS-C-RNTI), which for each UE is different from C-RNTI used for dynamic scheduling messages. - Source: LTE, The UMTS Long Term Evolution: From Theory to Practice By Stefania Sesia, Issam Toufik, Matthew Baker

TPC-PUCCH-RNTI (Transmit Power Control-Physical Uplink Control Channel-RNTI) and TPC-PUSCH-RNTI (Transmit Power Control-Physical Uplink Shared Channel-RNTI): The power-control message is directed to a group of terminals using an RNTI specific for that group. Each terminal can be allocated two power-control RNTIs, one for PUCCH power control and the other for PUSCH power control. Although the power control RNTIs are common to a group of terminals, each terminal is informed through RRC signaling which bit(s) in the DCI message it should follow.

The following table lists the values that are assigned to different RNTI's in MAC:



[1] 3GPP TS 36.321 - Evolved Universal Terrestrial Radio Access (E-UTRA) Medium Access Control (MAC) protocol specification
[2] 3GPP TS 36.211 - Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation

Circuit Switched Fallback (CSFB): A Quick Primer

I have explained CSFB with basic signalling here and there is a very interesting Ericsson whitepaper explaining all Voice issues in LTE here.

The following CSFB details have been taken from NTT Docomo Technical Journal:

The basic concept of CS Fallback is shown in Figure 1. Given a mobile terminal camping on LTE, a mobile terminating voice call arrives at the terminal from the existing CS domain via EPC. On receiving a paging message, the mobile terminal recognises that the network is calling the mobile terminal for CS-based voice and therefore switches to 3G. The response confirming the acceptance of a call request is then sent from the mobile terminal to the 3G-CS system, and from that point on, all call control for the voice service is performed on the 3G side.

The CS Fallback consists of a function to notify a mobile terminal of a call request from the CS domain and combined mobility management functions between CS domain and EPC for that

purpose. The network architecture of CS Fallback is shown in Figure 2.

One of the remarkable characteristics of the EPC supporting CS Fallback is that it connects the Mobile Switching Center (MSC) and Visited Location Register (VLR) in the 3G CS domain

with the Mobility Management Entity (MME), which provides EPC mobility management functionality. The interface connecting MSC/VLR and MME is called an SGs reference point. This

interface is based on the concept of the Gs reference point that exchanges signalling with MSC, which connects to the Serving General Packet Radio Service Support Node (SGSN), a 3G

packet switch. The SGs provides nearly all the functions provided by the existing Gs.

The CS Fallback function uses this SGs reference point to transfer the mobile terminating call requests from the CS domain to LTE. It also provides combined mobility management

between the 3G CS domain and the EPC to enable this transfer to take place.

Combined Mobility Management between CS Domain and EPC Network:

A mobile communications network must always know where a mobile terminal is located to deliver mobile terminating service requests to the mobile user on the mobile terminating side. The procedure for determining terminal location is called “mobility management". As a basic function of mobile communications, 3G and LTE each provide a mobility management function.

To complete a call using the CS Fallback function, the CS domain needs to know which LTE location registration area the mobile terminal is currently camping on. To this end, the MME must correlate mobility management control of the CS domain with that of EPC and inform MSC/VLR that the mobile terminal is present in an LTE location registration area.

The 3G core network already incorporates a function for linking mobility management of the CS domain with that of the Packet Switched (PS) domain providing packet-switching functions. As described above, the CS domain and PS domain functions are provided via separate switches. Thus, if combined mobility management can be used, the mobility management procedure for the terminal only needs to be performed once, which has the effect of reducing signal traffic in the network. This concept of combined mobility management is appropriated by the CS Fallback function. Specifically, MSC/VLR uses the same logic for receiving a location registration request from SGSN as that for receiving a location registration request from MME. This achieves a more efficient combined mobility management between the CS domain and EPC while reducing the development impact on MSC.

As described above, a mobile terminal using LTE cannot use 3G at the same time. This implies that the MME, which contains the LTE location registration area (Tracking Area (TA)), is unable to identify which MSC/VLR it should send the mobility management messages to from the TA alone. To solve this problem, the mapping of TAs and 3G Location Areas (LA) within MME has been adopted. The concept behind TA/LA mapping is shown in Figure 3. Here, MME stores a database that manages the correspondence between physically overlapping TAs and LAs. This information is used to determine which MSC/VLR to target for location registration.

The combined TA/LA update procedure for CS fallback is shown in detail in Figure 4. First, the mobile terminal sends to the MME a Tracking Area Update (TAU) request message indicating a combined TAU and the current TA in which the mobile terminal is currently present (Fig. 4 (1)). The MME then performs a location update procedure towards Home Subscriber Server (HSS), which is a database used for managing subscriber profiles (Fig. 4 (2)). Next, the MME uses the TA/LA correspondence database to identify the corresponding LA and the MSC/VLR that is managing that area, and uses the SGs reference point to send a Location Area Update (LAU) request message to the MSC/VLR together with the LA so identified (Fig. 4 (3)). The MSC/VLR that receives the LAU request message stores the correspondence between the ID of the MME originating the request and an ID such as the International Mobile Subscriber Identity (IMSI) that identifies the subscriber (Fig. 4 (4)). This enables the MSC/VLR to know which MME the mobile terminal is currently connected to and that the mobile terminal is camping on LTE. Following this, the MSC/VLR performs a location registration procedure with the HSS (Fig. 4 (5)). Finally, the MSC/VLR informs the MME of temporary user identity (Temporary Mobile Subscriber Identity (TMSI)), which is used at the time of a mobile terminating call in the CS domain, and indicates that location registration has been completed. The MME then informs the mobile terminal of the TMSI and of the LA that the mobile terminal has been registered with thereby completing combined location registration (Fig. 4 (6) (7)).

CS Fallback Call Control Procedures - Mobile Originating Call:

To originate a voice call using the CS Fallback function, a mobile terminal in the LTE location registration area must first switch (fall back) to 3G. The mobile-originating voice call procedure is shown in Figure 5. To originate a call, the mobile terminal begins by sending a CS fallback service request message to the MME (Fig. 5 (1)). Since a packet-communications transmission path (bearer) must always exist in EPC for the purpose of providing an always-on connection, the bearer also has to be handed over to 3G. To accomplish this, the MME issues a handover command to the mobile terminal in LTE and initiates a handover procedure (Fig. 5 (2)). The mobile terminal changes its radio from LTE to 3G during this procedure (Fig. 5 (3)). On completion of handover, the mobile terminal issues an originating request for voice service to the MSC/VLR. A voice-call connection is then established using an existing calloriginating procedure on 3G and the CS Fallback procedure is completed (Fig. 5(4)).

CS Fallback Call Control Procedures - Mobile Terminating Call:

The mobile terminating voice call procedure using CS Fallback is shown in Figure 6. When the MSC/VLR receives a message indicating the occurrence of a mobile terminating call (Fig. 6 (1)), the MSC/VLR identifies the corresponding MME from the call information received (Fig. 6 (2)). Then, the MSC/VLR sends a paging message (Fig. 6 (3)) towards the MME. Next, the MME sends a paging message to the mobile terminal in LTE (Fig. 6 (4)). This paging message includes an indication that the call is a CS service, and on identifying the call as such, the mobile terminal sends a CS fallback service request signal to the MME (Fig. 6 (5)). Following this, a handover procedure to 3G as described above takes place (Fig. 6 (6), (7)). The mobile terminal that is now switched to 3G sends a paging response message to the MSC/VLR at which it is registered (Fig. 6 (8)). Finally, an existing mobile terminating call procedure on 3G is executed and the CS Fallback procedure is completed (Fig. 6 (9)).

Simplicity of LTE and its differences with UMTS RRC

LTE is gaining pace as the days pass by and everyday we hear some sort of milestone achieved by some company towards the ultimate aim of LTE product. RRC is one of the main components of Layer in the LTE protocol stack just as it was in UMTS. Certainly LTE RRC looks simpler in terms of the no of states and off course the length of the RRC document. Below are some of the important changes in LTE RRC and its difference with the UMTS system.

RRC State: In LTE there is only 2 RRC states i.e. RRC_IDLE and RRC_CONNECTED whereas in UMTS system RRC has a 5 state i.e. IDLE, CELL_FACH, CELL_DCH, CELL_PCH and URA_PCH. One of the reasons why we don’t have CELL_FACH and CELL_DCH state is because there is no concept of common and dedicated transport channel in LTE. In LTE the data transfer will be done through the defined shared transport channel. Therefore this will simplifies the RRC State machine handling and improves RRC performance. This will also simplify the RRM algorithm which decides RRC states.

Signalling Radio Bearers: In LTE there is only three SRB is defined i.e. SRB0, SRB1 and SRB2 whereas in UMTS system RRC has 4 SRBs i.e. SRB0, SRB1, SRB2 and SRB3 (optional).
SRB 0: In LTE SRB 0 use RLC TM entity over CCCH logical channel in DL whereas in UMTS system it SRB 0 is sent on RLC UM entity over CCCH logical channel in DL.

MAC entity: In LTE there is only one MAC entity which needs to configured whereas in UMTS system there is 4 different MAC entity based on different type of transport channel i.e MAC-d (DCH), MAC-c/sh (FACH, DSCH), MAC-hs (HS-DSCH) and MAC-e (E-DCH). In UMTS system the state machine which is handling MAC configuration is quite complex. During state transition from CELL_FACH to CELL_DCH or CELL_DCH to CELL_FACH lots of signalling was involved. In LTE, since there is only one MAC entity which is easier and simple to configure and thus have very simple State Machine.

Radio Bearer mapping: In LTE Radio bearer mapping would be much simpler than the UMTS system because of there is no common and transport channel defined in LTE.
In LTE there is no RRC connection mobility defined like cell update and URA update.

Domain Identity: In LTE, there is only one domain identity i.e. PS domain and which is implicit no need to specify anywhere in signalling unlike UMTS system which has CS domain and PS domain. Because of a single domain in LTE the signalling overhead and complexity in RRC design has been reduced.

System Broadcast Information: In LTE, MIB includes a limited number of most frequently transmitted parameters and SIB Type 1 containing the scheduling information that mainly indicates when the SI messages are transmitted where as in UMTS system, MIB includes the frequently transmitted parameters was well as scheduling information.

Channels: In LTE RRC there is no need to define the downlink transport channel configuration in the RRC Reconfiguration message as it uses only shared channel. This will reduce signalling message size effectively. All DL-SCH transport channel information is broadcasted in system information.

Power Consumption: The above point introduces another very critical feature of DRX calculation since all DL data is on the shared channel. E-NB can tell the UE when to decode/listen over the radio frame. This will optimize UE power consumption.

Paging Type: Since there is no CELL_FACH and CELL_DCH state in LTE there is only one type of paging required where as in UMTS system there is two type of paging defined.
Reconfiguration: In LTE there is only one reconfiguration message to reconfigure all logical, transport and physical channel where as in UMTS system there are number of reconfiguration message i.e. RB reconfiguration , TRCH configuration, PHY configuration. Thus there is less signalling message or overhead in LTE for the reconfiguration.

Reduced Latency: Since there is no RNC or NBAP protocol in LTE, this reduces the latency of the RRC connection establishment and RB management procedure.
Single UE identity: Since there is only one shared MAC entity, there is no need to define URNTI, ERNTI, HRNTI, SRNTI etc in LTE.

No Activation time: In LTE, there in no need to define activation time. Because of this there are lots of synchronizing complexity in 3G-RNC systems i.e. Synchronizing Radio link procedure based on activation time, synchronizing between the various MAC entity. This reduces significantly latency during establishment and reconfiguration of radio bearers.
RRC State: In LTE, there in no need to specify the RRC State in RRC message.

CQI Reporting: For network control mobility, there is one feature which become very important and critical i.e. CQI Reporting. As in LTE the CQI reporting should be fast and correct for taking decision for mobility.

Signalling connection release: There is no signalling connection release procedure in LTE, since there is only one domain i.e. PS domain. Also the UE context is shared between the MME and ENB and if UE is active in ENB then it should be active in MME also.

Paging Permission with Access Control (PPAC) Study in Release 8

A new feature that was studied part of 3GPP Release 8 was PPAC (Paging Permission with Access Control). The aim of this feature was that in an emergency situation, the network can get congested and as a result all access is barred except for emergency services. This can cause problem when the user requires to be contacted but is unreachable.

Lets take Case 1: Disaster risk management office in government calls to emergency responder within disaster areas in order to supply temporary service to the disaster areas.

This should not be a problem because the emergency responder is an authorised user with higher priority of access class and will be able to make and receive calls in the disaster area.



Case2: Ambulance attendant reaches a rescue site in the disaster area but cannot find the person who asked for help originally because of unexpected destruction. The attendant should be able to call him/her in order to make sure where he/she is.

Case3: Firefighter is at a scene of fire of high-rise apartment in the disaster area and calls to a person who asked for help in order to give out directives on the evacuation.

These scenarios as such are no problem except when there is congestion on the receiving side. In that case either the emergency attendant or the risk management office should be able to get in touch and establish the call.

In technical terms, the people like emergency attendants and disaster risk management office attendants are called authorised users and the ordinary people who need help are known as unauthorised users.

It should also be possible to make a small duration call between unauthorised users so people can check each others safety. This can be controlled by changing the permission of different access class for small durations so that people can trigger calls for small duration.

The study found that eMLPP (Enhanced Multi-Level Precedence and Pre-emption) that is already available since GSM days can resolve the problem of prioritisation in resource allocation. A new capability will be required to allow UEs with indications from the network to perform location registration and respond to a paging request even though it is under access class barring conditions to complete certain classes of calls or messages (e.g. calls from emergency personnel, …).

This new capability will be available probably when Release 9 is finalised in December this year.

As far as understanding this eMLPP is concerned, the following book has quite a lot of details on this topic. If you can get hold of it then do go through it.

Preferential Emergency Communications: From Telecommunications to the Internet (The Springer International Series in Engineering and Computer Science)

Here is the google books link for that.

A look at "Idle state Signalling Reduction" (ISR)

The following is from 3GPP TS 23.401, Annex J:

General description of the ISR concept

Idle state Signalling Reduction (or ISR) aims at reducing the frequency of Tracking Area Updates (TAU, in EUtran) and Routing Area Updates (RAU, in UTRAN/GERAN) procedures caused by UEs reselecting between E-UTRAN and GERAN/UTRAN which are operated together. Especially the update signalling between UE and network is reduced. But also network internal signalling is reduced. To some extent the reduction of network internal signalling is also available when ISR is not used or not activated by the network.

UMTS described already RAs containing GERAN and UTRAN cells, which also reduces update signalling between UE and network. The combination of GERAN and UTRAN into the same RAs implies however common scaling, dimensioning and configuration for GERAN and UTRAN (e.g. same RA coverage, same SGSN service area, no GERAN or UTRAN only access control, same physical node for GERAN and UTRAN). As an advantage it does not require special network interface functionality for the purpose of update signalling reduction.

ISR enables signalling reduction with separate SGSN and MME and also with independent TAs and RAs. Thereby the interdependency is drastically minimized compared with the GERAN/UTRAN RAs. This comes however with ISR specific node and interface functionality. SGSN and MME may be implemented together, which reduces some interface functions but results also in some dependencies.

ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for the network. ISR requires special functionality in both the UE and the network (i.e. in the SGSN, MME and Serving GW) to activate ISR for a UE. For this activation, the MME/SGSN detects whether S-GW supports ISR based on the configuration and activates ISR only if the S-GW supports the ISR. The network can decide for ISR activation individually for each UE. Gn/Gp SGSNs do not support ISR functionality. No specific HSS functionality is required to support ISR.

NOTE. A Release 7 HSS needs additional functionality to support the 'dual registration' of MME and SGSN. Without such an upgrade, at least PS domain MT Location Services and MT Short Messages are liable to fail.

It is inherent functionality of the MM procedures to enable ISR activation only when the UE is able to register via E-UTRAN and via GERAN/UTRAN. For example, when there is no E-UTRAN coverage there will be also no ISR activation. Once ISR is activated it remains active until one of the criteria for deactivation in the UE occurs, or until SGSN or MME indicate during an update procedure no more the activated ISR, i.e. the ISR status of the UE has to be refreshed with every update.

When ISR is activated this means the UE is registered with both MME and SGSN. Both the SGSN and the MME have a control connection with the Serving GW. MME and SGSN are both registered at HSS. The UE stores MM parameters from SGSN (e.g. P-TMSI and RA) and from MME (e.g. GUTI and TA(s)) and the UE stores session management (bearer) contexts that are common for E-UTRAN and GERAN/UTRAN accesses. In idle state the UE can reselect between E-UTRAN and GERAN/UTRAN (within the registered RA and TAs) without any need to perform TAU or RAU procedures with the network. SGSN and MME store each other's address when ISR is activated.

When ISR is activated and downlink data arrive, the Serving GW initiates paging processes on both SGSN and MME. In response to paging or for uplink data transfer the UE performs normal Service Request procedures on the currently camped-on RAT without any preceding update signalling (there are however existing scenarios that may require to perform a RAU procedure prior to the Service Request even with ISR is activated when GERAN/UTRAN RAs are used together, as specified in clause 6.13.1.3 of TS 23.060 [7]).

The UE and the network run independent periodic update timers for GERAN/UTRAN and for E-UTRAN. When the MME or SGSN do not receive periodic updates MME and SGSN may decide independently for implicit detach, which removes session management (bearer) contexts from the CN node performing the implicit detach and it removes also the related control connection from the Serving GW. Implicit detach by one CN node (either SGSN or MME) deactivates ISR in the network. It is deactivated in the UE when the UE cannot perform periodic updates in time. When ISR is activated and a periodic updating timer expires the UE starts a Deactivate ISR timer. When this timer expires and the UE was not able to perform the required update procedure the UE deactivates ISR.

Part of the ISR functionality is also available when ISR is not activated because the MM contexts are stored in UE, MME and SGSN also when ISR is not active. This results in some reduced network signalling, which is not available for Gn/Gp SGSNs. These SGSNs cannot handle MM and session management contexts separately. Therefore all contexts on Gn/Gp SGSNs are deleted when the UE changes to an MME. The MME can keep their MME contexts in all scenarios.

Note:

Gn = IP Based interface between SGSN and other SGSNs and (internal) GGSNs. DNS also shares this interface. Uses the GTP Protocol.

Gp = IP based interface between internal SGSN and external GGSNs. Between the SGSN and the external GGSN, there is the border gateway (which is essentially a firewall). Also uses the GTP Protocol.

"Temporary Identity used in Next update" (TIN)

The UE may have valid MM parameters both from MME and from SGSN. The "Temporary Identity used in Next update" (TIN) is a parameter of the UE's MM context, which identifies the UE identity to be indicated in the next RAU Request or TAU Request message. The TIN also identifies the status of ISR activation in the UE.

The TIN can take one of the three values, "P-TMSI", "GUTI" or "RAT-related TMSI". The UE sets the TIN when receiving an Attach Accept, a TAU Accept or RAU Accept message as specified in table 4.3.5.6-1.

"ISR Activated" indicated by the RAU/TAU Accept message but the UE not setting the TIN to "RAT-related TMSI" is a special situation. By maintaining the old TIN value the UE remembers to use the RAT TMSI indicated by the TIN when updating with the CN node of the other RAT.

Only if the TIN is set to "RAT-related TMSI" ISR behaviour is enabled for the UE, i.e. the UE can change between all registered areas and RATs without any update signalling and it listens for paging on the RAT it is camped on. If the TIN is set to "RAT-related TMSI", the UE's P-TMSI and RAI as well as its GUTI and TAI(s) remain registered with the network and valid in the UE.

When ISR is not active the TIN is always set to the temporary ID belonging to the currently used RAT. This guarantees that always the most recent context data are used, which means during inter-RAT changes there is always context transfer from the CN node serving the last used RAT. The UE identities, old GUTI IE and additional GUTI IE, indicated in the next TAU Request message, and old P-TMSI IE and additional P-TMSI/RAI IE, indicated in the next RAU Request message depend on the setting of TIN.

The UE indicates also information elements "additional GUTI" or "additional P-TMSI" in the Attach Request, TAU or RAU Request. These information elements permit the MME/SGSN to find the already existing UE contexts in the new MME or SGSN, when the "old GUTI" or "old P-TMSI" indicate values that are mapped from other identities.

ISR activation

The information flow in Figure below shows an example of ISR activation. For explanatory purposes the figure is simplified to show the MM parts only.

The process starts with an ordinary Attach procedure not requiring any special functionality for support of ISR. The Attach however deletes any existing old ISR state information stored in the UE. With the Attach request message, the UE sets its TIN to "GUTI". After attach with MME, the UE may perform any interactions via E-UTRAN without changing the ISR state. ISR remains deactivated. One or more bearer contexts are activated on MME, Serving GW and PDN GW, which is not shown in the figure.

The first time the UE reselects GERAN or UTRAN it initiates a Routing Area Update. This represents an occasion to activate ISR. The TIN indicates "GUTI" so the UE indicates a P-TMSI mapped from a GUTI in the RAU Request. The SGSN gets contexts from MME. When the MME sends the context to the SGSN, the MME includes the ISR supported indication only if the involved S-GW supports the ISR. After the ISR activated, both CN nodes keep these contexts because ISR is being activated. The SGSN establishes a control relation with the Serving GW, which is active in parallel to the control connection between MME and Serving GW (not shown in figure). The RAU Accept indicates ISR activation to the UE. The UE keeps GUTI and P-TMSI as registered, which the UE memorises by setting the TIN to "RAT-related TMSI". The MME and the SGSN are registered in parallel with the HSS.

After ISR activation, the UE may reselect between E-UTRAN and UTRAN/GERAN without any need for updating the network as long as the UE does not move out of the RA/TA(s) registered with the network.

The network is not required to activate ISR during a RAU or TAU. The network may activate ISR at any RAU or TAU that involves the context transfer between an SGSN and an MME. The RAU procedure for this is shown in Figure above. ISR activation for a UE, which is already attached to GERAN/UTRAN, with a TAU procedure from E-UTRAN works in a very similar way.

Reference: 3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

Temporary Identities in LTE/SAE - 1

An MS may be allocated three TMSIs, one for services provided through the MSC (TMSI), one for services provided through the SGSN (P-TMSI for short) and one for the services provided via the MME (M-TMSI part GUTI for short).

The purpose of the GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user's permanent identity in the Evolved Packet System (EPS). It also allows the identification of the MME and network. It can be used by the network and the UE to establish the UE's identity during signalling between them in the EPS.

The GUTI has two main components:

• one that uniquely identifies the MME which allocated the GUTI; and
• one that uniquely identifies the UE within the MME that allocated the GUTI.

Within the MME, the mobile shall be identified by the M-TMSI.

The Globally Unique MME Identifier (GUMMEI) shall be constructed from the MCC, MNC and MME Identifier (MMEI).

The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME Code (MMEC).

The GUTI shall be constructed from the GUMMEI and the M-TMSI.

For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from the MMEC and the M-TMSI.
S-TMSI = MMEC + M-TMSI

The operator shall need to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.

The GUTI shall be used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more efficient radio signalling procedures (e.g. paging and Service Request).


The format and size of the GUTI is therefore the following:
GUTI = GUMMEI + M-TMSI, where
GUMMEI = MCC + MNC + MME Identifier and
MME Identifier = MME Group ID + MME Code
MCC and MNC shall have the same field size as in earlier 3GPP systems.
M-TMSI shall be of 32 bits length.
MME Group ID shall be of 16 bits length.
MME Code shall be of 8 bits length.

During Handover to GERAN/UTRAN
RAI = MCC + MNC + LAC + RAC
E UTRAN "MCC" maps to GERAN/UTRAN "MCC"
E UTRAN "MNC" maps to GERAN/UTRAN "MNC"
E UTRAN "MME Group ID" maps to GERAN/UTRAN "LAC"
E UTRAN "MME Code" maps to GERAN/UTRAN "RAC" and is also copied into the 8 most significant bits of the NRI field within the P TMSI;

"P-TMSI" includes the mapped NRI
P TMSI shall be of 32 bits length where the two topmost bits are reserved and always set to 11.

E UTRAN "M-TMSI" maps as follows:
6 bits of the E UTRAN "M-TMSI" starting at bit 29 and down to bit 24 are mapped into bit 29 and down to bit 24 of the GERAN/UTRAN "P TMSI";
16 bits of the E UTRAN "M-TMSI" starting at bit 15 and down to bit 0 are mapped into bit 15 and down to bit 0 of the GERAN/UTRAN "P TMSI";
and the remaining 8 bits of the E UTRAN "M-TMSI" are mapped into the 8 MBS bits of the "P-TMSI signature" field.

Abbreviations Summary:
GUTI - Globally Unique Temporary UE Identity
GUMMEI - Globally Unique MME Identifier
MMEGI - MME Group ID
MMEC - MME Code
S-TMSI = SAE Temporary Mobile Subscriber Identity
M-TMSI = MME Temporary Mobile Subscriber Identity

Reference: 3GPP TS 23.003: Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 8) - Section 2.8

Low Latency Power Saving with Low Power-Wake Up Signal/Receiver (LP-WUS/LP-WUR)

Power-saving methodologies have been integral to all generations of 3GPP technologies, aimed at reducing the power consumption of user equipment (UEs) and other battery-dependent devices. Some of the stringent requirements of 5G, such as achieving a 10-year battery life for certain IoT devices, have necessitated further optimisation of power consumption. To address this, 3GPP Release 16 introduced the Wake-Up Signal (WUS) power-saving mechanism, designed to significantly reduce energy usage in UEs. For a detailed technical explanation, ShareTechnote provides an excellent overview.

The concept of wake-up radios has been explored for over a decade. In a 2017 blog post, Ericsson highlighted how researchers had been working on designing wake-up radios and receivers, initially aimed at IEEE 802.11 (Wi-Fi) technologies. This idea later gained traction in 3GPP discussions, culminating in a study conducted during Release 18. The findings are comprehensively documented in 3GPP TR 38.869: Study on low-power wake-up signal and receiver for NR (Release 18).

Quoting from the introduction of 3GPP 38.869:

5G systems are designed and developed targeting for both mobile telephony and vertical use cases. Besides latency, reliability, and availability, UE energy efficiency is also critical to 5G. Currently, 5G devices may have to be recharged per week or day, depending on individual's usage time. In general, 5G devices consume tens of milliwatts in RRC idle/inactive state and hundreds of milliwatts in RRC connected state. Designs to prolong battery life is a necessity for improving energy efficiency as well as for better user experience. 

Energy efficiency is even more critical for UEs without a continuous energy source, e.g., UEs using small rechargeable and single coin cell batteries. Among vertical use cases, sensors and actuators are deployed extensively for monitoring, measuring, charging, etc. Generally, their batteries are not rechargeable and expected to last at least few years as described in TR 38.875. Wearables include smart watches, rings, eHealth related devices, and medical monitoring devices. With typical battery capacity, it is challenging to sustain up to 1-2 weeks as required. 

The power consumption depends on the configured length of wake-up periods, e.g., paging cycle. To meet the battery life requirements above, eDRX cycle with large value is expected to be used, resulting in high latency, which is not suitable for such services with requirements of both long battery life and low latency. For example, in fire detection and extinguishment use case, fire shutters shall be closed and fire sprinklers shall be turned on by the actuators within 1 to 2 seconds from the time the fire is detected by sensors, long eDRX cycle cannot meet the delay requirements. eDRX is apparently not suitable for latency-critical use cases. Thus, the intention is to study ultra-low power mechanism that can support low latency in Rel-18, e.g. lower than eDRX latency.

Currently, UEs need to periodically wake up once per DRX cycle, which dominates the power consumption in periods with no signalling or data traffic. If UEs are able to wake up only when they are triggered, e.g., paging, power consumption could be dramatically reduced. This can be achieved by using a wake-up signal to trigger the main radio and a separate receiver which has the ability to monitor wake-up signal with ultra-low power consumption. Main radio works for data transmission and reception, which can be turned off or set to deep sleep unless it is turned on.

The power consumption for monitoring wake-up signal depends on the wake-up signal design and the hardware module of the wake-up receiver used for signal detecting and processing. 

The study should primarily target low-power WUS/WUR for power-sensitive, small form-factor devices including IoT use cases (such as industrial sensors, controllers) and wearables. Other use cases are not precluded, e.g.XR/smart glasses, smart phones. 

As opposed to the work on UE power savings in previous releases, this study will not require existing signals to be used as WUS. All WUS solutions identified shall be able to operate in a cell supporting legacy UEs. Solutions should target substantial gains compared to the existing Rel-15/16/17 UE power saving mechanisms. Other aspects such as detection performance, coverage, UE complexity, should be covered by the evaluation.

The Bridge Toward 6G: 5G-Advanced Evolution in 3GPP Release 19 by Xingqin Lin, @NVIDIA - https://t.co/O1d8jnB9MY#Free5Gtraining #3G4G5G #3GPP #5G #5GAdvanced #6G #AIML #NGRAN #XR #UAV #LPWUS #LPWUR #HighPerforming #LTM #SBFD #Femtocell #NTN #WAB #Relay pic.twitter.com/aSC9FuruC7

— Free 5G Training (@5Gtraining) January 2, 2024

Qualcomm's blog post looking at 'How will wireless innovations foster a greener, more sustainable future?' is also worth reading on this topic.

Related Posts: 

• The 3G4G Blog: 3GPP TSG RAN and TSG SA Release-19 Workshop Summary
• The 3G4G Blog: ETSI's Summit on Sustainability: ICT Standards for a Greener World
• The 3G4G Blog: Four Ways 5G Can Improve the Battery Life of User Equipment (UE)
• The 3G4G Blog: Energy Consumption in Mobile Networks and RAN Power Saving Schemes
• The 3G4G Blog: Reducing 5G Device Power Consumption Using Connected-mode Discontinuous Reception (C-DRX)
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System 

Home e-NodeB Architecture in Release 8

The Architecture of Home e-NodeB's (popularly known as Femtocells) is as shown above.

The E-UTRAN architecture may deploy a Home eNB Gateway (HeNB GW) to allow the S1 interface between the HeNB and the EPC to scale to support a large number of HeNBs. The HeNB GW serves as a concentrator for the C-Plane, specifically the S1-MME interface. The S1-U interface from the HeNB may be terminated at the HeNB GW, or a direct logical U-Plane connection between HeNB and S-GW may be used.

At present there is no support X2 connectivity of HeNBs.

The S1 interface is defined as the interface:

• Between the HeNB GW and the Core Network,
• Between the HeNB and the HeNB GW,
• Between the HeNB and the Core Network,
• Between the eNB and the Core Network.

The HeNB GW appears to the MME as an eNB. The HeNB GW appears to the HeNB as an MME. The S1 interface between the HeNB and the EPC is the same whether the HeNB is connected to the EPC via a HeNB GW or not.

The HeNB GW shall connect to the EPC in a way that inbound and outbound mobility to cells served by the HeNB GW shall not necessarily require inter MME handovers.

The functions supported by the HeNB shall be the same as those supported by an eNB (with the possible exception of NNSF - NAS Node Selection Function) and the procedures run between a HeNB and the EPC shall be the same as those between an eNB and the EPC.

The HeNB hosts the same functions as an eNB, with the following additional specifications in case of connection to the HeNB GW:

• Discovery of a suitable Serving HeNB GW
• A HeNB shall only connect to a single HeNB GW at one time, namely no S1 Flex function shall be used at the HeNB in case of connection to the HeNB GW.
• If the HeNB is connected to a HeNB GW, it will not simultaneously connect to another HeNB GW, or another MME.
• The TAC and PLMN ID used by the HeNB shall also be supported by the HeNB GW.
• When the HeNB connects to a HeNB GW, selection of an MME at UE attachment is hosted by the HeNB GW instead of the HeNB;
• HeNBs may be deployed without network planning. A HeNB may be moved from one geographical area to another and therefore it may need to connect to different HeNB GWs depending on its location.

The HeNB GW hosts the following functions:

• Relaying UE-associated S1 application part messages between the MME serving the UE and the HeNB serving the UE;
• Terminating non-UE associated S1 application part procedures towards the HeNB and towards the MME. Note that when a HeNB GW is deployed, non-UE associated procedures shall be run between HeNBs and the HeNB GW and between the HeNB GW and the MME.
• Optionally terminating S1-U interface with the HeNB and with the SGW.
• Supporting TAC and PLMN ID used by the HeNB

In addition the MME hosts the following functions:

• Access control for UEs that are members of Closed Subscriber Groups (CSG).

Mechanisms for filtering of paging messages, in order to avoid paging message distribution to HeNBs belonging to CSGs where the UE is not registered, is FFS.

Source: 3GPP TS 36.300 - E-UTRA and E-UTRAN Overall description; Stage 2 (Release 8)

3GPP Release 8 Features

Many people are surprised to hear that the Rel-8 of 3GPP is much more than just LTE/SAE. Here is a list of features:

1. Maintenance of TISPAN documentation
   
2. FS on 3G Home NodeB
   
3. FS on Multimedia Session Continuity
   
4. FS on CS Domain Services over evolved PS access
   
5. FS on Transferring of emergency call data – in-band modem solution
   
6. FS on Improved network controlled mobility between LTE and 3GPP2/mobile WiMAX radio technologies
   
7. FS on IMS Application Server Service Data Descriptions for AS interoperability
   
8. FS Restoration Procedures
   
9. Registration in Densely-populated area
   
10. Lawful Interception in the 3GPP Rel-8
    
11. IMS Enhancements for support of Packet Cable access
    
12. Study on Non 3GPP access NSP
    
13. Support of Service-Level Interworking for Messaging Services
    
14. Feasibility Study of Mobility between 3GPP-WLAN Interworking and 3GPP Systems
    
15. Study on Requirements for seamless roaming and service continuity between mobile and WLAN networks
    
16. Study on Stage 2 aspects of IMS Service Brokering
    
17. Study of Requirements of IP-Multimedia Subsystem (IMS) Convergent Multimedia Conferencing
    
18. Study on support of a Public Warning System (PWS)
    
19. Study of VCC support for Emergency Calls
    
20. Study on centralized IMS services
    
21. Study on centralised IMS service control
    
22. Consumer protection against spam and malware
    
23. 3G Long Term Evolution
    
24. GERAN support for GERAN - 3G Long Term Evolution interworking
    
25. Local Charging Zone Requirements
    
26. Enhancements to BS30 Bearer service for Videotelephony
    
27. IMS Enhancements Rel-8
    
28. NDS Authentication Framework Extension for TLS
    
29. Study on Value Added Services for Short Message Service
    
30. Value Added Services for Short Message Service
    
31. Study on Paging Permission with Access Control (PPAC)
    
32. Paging Permission with Access Control
    
33. GAN Enhancements
    
34. Earthquake and Tsunami Warning System
    
35. FS on Extended Support of IMS Emergency Calls
    
36. Study on System enhancements for the use of IMS services in local breakout
    
37. Study on Services Alignment and Migration
    
38. Study on A-interface over IP
    
39. Study on Multi-User Reusing-One-Slot
    
40. Study on Optimized Transmit Pulse Shape for Downlink EGPRS2-B
    
41. Study on InterWorking Function between MAP based and Diameter based interfaces
    
42. Study on Evaluation of the inclusion of Path Loss Based Technology in the UTRAN
    
43. LCS for 3GPP Interworking WLAN
    
44. All-IP Network (AIPN)
    
45. 3GPP System Architecture Evolution Specification
    
46. CT aspects of System Architecture Evolution
    
47. FBI Phase 2
    
48. Rel-8 Feasibility Studies
    
49. IMS Centralised Service Control
    
50. IMS Multimedia Telephony and Supplementary Services
    
51. MTSI Video - Dynamic Rate Adaptation/Signalling of Image Size
    
52. eCall data transfer Phase 2: Comparison of alternative in-band modem solutions and standardization of one in-band modem solution
    
53. Requirements and Test methods for Wideband Terminals
    
54. Extending PSS and MBMS User Services for optimized Mobile TV
    
55. IMS initiated and controlled PSS and MBMS User Service
    
56. Storage and easy access of ICE numbers on USIM
    
57. IP Interconnection of Services
    
58. Network Selection for non-3GPP Access
    
59. Charging for multi-phases services
    
60. Home NodeB / eNodeB
    
61. 3GPP2 Input to Common IMS
    
62. Rel-8 Improvements of the Radio Interface
    
63. OAM&P 8
    
64. OAM&P Rel-8 Studies
    
65. Study of Element Operations Systems Function (EOSF) definition
    
66. Study on SA5 MTOSI XML Harmonization
    
67. Study of Common Profile Storage (CPS) Framework of User Data for network services and management
    
68. Study of Management for LTE and SAE
    
69. Study on Charging Aspects of 3GPP System Evolution
    
70. Study of System Maintenance by Itf-N
    
71. Study of Self-Organizing Networks (SON) related OAM interfaces for Home NodeB
    
72. Study on Self-healing of Self-Organizing Networks (SON)
    
73. Personal Network Management (PNM)
    
74. eCall Data Transfer – Requirements
    
75. IMS System enhancements for corporate network access
    
76. IMS Service Brokering enhancements
    
77. Network Composition
    
78. FS on Scope of future HSPA Evolution for 1.28Mcps TDD
    
79. FS on Synchronised E-DCH for UTRA FDD
    
80. Study on Dual-Cell HSDPA operation
    
81. (FS on) Service continuity between mobile and WLAN networks
    
82. I-WLAN NSP
    
83. Interworking Wireless LAN Mobility
    
84. Multimedia Priority Service
    
85. Multimedia interworking between IMS and CS networks
    
86. Conferencing enhancements for Mp interface
    
87. Enhancements for VGCS Applications
    
88. Contact Manager for 3GPP UICC applications (formerly ""Enhanced USIM Phonebook"")
    
89. Charging Management small Enhancements
    
90. Harmonization of Gq'/Rx for Common IMS
    
91. IMS Service Continuity
    
92. Interworking between User-to-User Signaling (UUS) and SIP
    
93. Support of Overlap signalling
    
94. OSA Rel-8
    
95. Rel-8 RAN improvements
    
96. Combination of 64QAM and MIMO for HSDPA (FDD)
    
97. Security Enhancements for IMS
    
98. Generic Bootstrapping Architecture Push Function
    
99. Support of (G)MSC-S – (G)MSC-S Nc Interface based on the SIP-I protocol
    
100. IMS Stage-3 IETF Protocol Alignment
     
101. New multicarrier BTS class
     
102. Support of Customised Alerting Tone Service
     
103. Facilitating Machine to Machine Communication in GSM and UMTS (M2M)
     
104. SI on AS-MRFC media server control protocol
     
105. AS/MRFC stage 2 and 3 work
     
106. (Small) Technical Enhancements and Improvements for Rel-8