A Look into 5G Virtual/Open RAN - Part 4: Intra-gNB DU Handover

In the previous posts of this series I described O-RAN interfaces and protocols, connection establishment and connection release procedures. Now it is time to look at handovers.

As mentioned in one of the earlier posts the gNB-CU CP will be in charge of controlling hundreds of gNB-DUs in a similar way like the 3G RNC was in charge of controlling hundreds of UMTS NodeBs. As a result the most common 5G SA intra-system handovers will be intra-gNB handovers. These handovers can further be classified into intra-gNB-DU handovers (inter- as well as intra-frequency) and inter-gNB-DU handovers.

Due to the virtualization of RAN network functions we will also find another form of switching transmission path, which is a change of the gNB-CU UP during the call without mobility of the UE. This scenario I will discuss later in a separate blog post.

Today I want to focus on the intra-gNB DU handover. Here the UE moves from one cell to another one within the same distributed unit as shown in the figure below.

A prerequisite is the successful establishment of a NR RRC connection and a F1AP UE Context between the gNB-DU and the gNB-CU CP.

The F1AP transports all RRC messages between these two entities. Indeed, it transports the PDCP blocks and the gNB-DU is not aware that these PDCP blocks contain RRC messages. However, for better illustration I have not shown the PDPC part in the ladder diagram.

What we see in step 1 is a NR RRC Reconfiguration message that contains RRC measurement configurations to be enabled on the UE side. A typical trigger event for intra-frequency handovers is the A3 event that is already known from LTE RRC.

Once the UE detects a better neighbor cell meeting the A3 criteria it sends a RRC Measurement Report to the gNB-CU CP (step 2).

In step 3 the gNB-CU CP orders the gNB-DU to perform a F1AP UE Context Modification. The purpose is to allocate radio resources for the UE in the target cell and to prepare the cell change.

The gNB-DU replies with F1AP UE Context Modification Response. This messages contains the new C-RNTI and a large block of lower layer configuration parameters (e.g. for RLC and MAC layer) that need to be sent to the UE and thus, need to be transported to the gNB-CU CP before, because it is the only RAN function capable to communicate with the UE using the RRC protocol.

Hence, in step 5 we see another downlink RRC message transfer. This time it is used to transport the handover command towards the UE. The handover command is a NR RRC Reconfiguration message and it contains the new C-RNTI (new UE identity within the cell) as well as the physical cell ID of the target cell and the full set of lower layer configuration parameters previously provided by the gNB-DU.

When the gNB-CU CP receives the RRC Reconfiguration Complete message sent by the UE in step 6 the handover is successfully completed and the UE is now served by the cell with NR PCI 2.

As mentioned before there is neither XnAP (communication between two neighbor gNBs) nor NGAP (communication between gNB and AMF) involved in this handover procedure.

Related Posts:

• A Look into 5G Virtual/Open RAN - Part 5: Inter-gNB DU Handover
• 3G4G: Open RAN, OpenRAN and O-RAN

A Look into 5G Virtual/Open RAN - Part 1

Although it is understood in general that virtualization and increasing complexity are inherent characteristics of 5G networks many people are surprised when they realize the significant differences of 5G RAN architecture and signaling procedures compared to what they know from LTE or UTRAN.

In this blog post series I want to highlight some details that are not immediately visible when reading the 3GPP specs.

Figure 1 shows a virtualized gNB and the protocols it uses to communicate with its internal entities as well as with the UE and peer entities in neighbor network elements/functions.

Figure 1: Virtual Network Functions and Protocols in 5G RAN
(click on the image to see full size)

The core of the whole thing is the gNB-Central Unit for the Control Plane (gNB-CU CP). This function communicates directly with the UE using the NR RRC protocol. It also "talks" to the 5G Core Network represented by the AMF using the NGAP, a protocol very similar to the S1AP known from E-UTRAN. Neighboring 5G base stations are contacted using the XnAP, neighboring eNBs can be reached by using X2AP.

The other virtual functions of the gNB are the Central Units for User Plane (gNB-CU UP) and the Distributed Units (gNB-DU). While the gNB-CU UP is responsible for handling the transport of payload the gNB-DUs deal with all the allocation of radio resources, especially the scheduling. As a result the lower layer radio interface protocols, especially RLC and MAC terminate in the gNB-DUs.

For the RAN monitoring tools and the 3GPP Minimization of Drive Test (MDT) feature this means that RRC and Logged Measurement Reports sent by UEs will be available at gN-CU CP while all uplink radio quality measurements and call-related user plane metrics is only available at the gNB-DU - see figure 3.

Figure 2: Distribution of un-correlated RAN measurement tasks among different gNB virtual functions
(click on the image to see full size) 

And today, there is no 3GPP-standardized procedure to correlate this measurement information collected by different virtual gNB functions.

The full impact of the 5G RAN virtualization becomes even more evident when looking at Figure 3. It shows a single gNB-CU CP in charge of controlling several gNB-CU UPs and gNB-DUs.

In a live network deployment a single gNB-CU CP will control hundreds of gNB-DUs and maybe several gNB-CU UPs. This is why it is misleading to compare the connectivity of a gNB-CU CP with that of a LTE eNB. Rather it could be compared with a UTRAN RNC controlling a similar number of 3G base stations.

Figure 3: 5G RAN Connectivity
(click on the image to see full size)

Looking back into figure 1 we see that the F1AP is used for communication between gNB-CU CP and its gNB-DUs while the E1AP is the protocol that connects the gNB-CU CP with surrounding gNB-CU UPs.

Call-related control plane procedures of F1AP and E1AP are very similar to what is known from NGAP. There is a UE context established between the gNB-CU CP and the gNB-DU. On F1-U a GTP tunnel is established for user plane transport. At the same time an E1 Bearer Context in gNB-CU CP and gNB-CU UP keeps track of the most relevant user plane transport parameters.

All in all for setting up a single subscriber connection in the virtualized 5G RAN there are significantly more signaling transactions necessary than in E-UTRAN. Figure 4 shows a practical example.

Figure 4: 5G RAN Call Trace in NETSCOUT Session Analyzer
(click on the image to see full size)

The volume and complexity of signaling information is increasing when the UE moves or is redirected to virtual functions within one gNB e.g. due to load balancing.

The next blog post of this series will dive deeper into details of such call scenarios.

Stay tuned...

Related Posts:

• The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 2
• 3G4G: Open RAN, OpenRAN and O-RAN

Different flavours of SRVCC (Single Radio Voice Call Continuity)

Single Radio Voice Call Continuity (SRVCC) has been quietly evolving with the different 3GPP releases. Here is a quick summary of these different flavors

In its simplest form, SRVCC comes into picture when an IMS based VoLTE call is handed over to the existing 2G/3G network as a normal CS call. SRVCC is particularly important when LTE is rolled out in small islands and the operator decided to provide VoLTE based call when in LTE. An alternative (used widely in practice) is to use CS Fallback (CSFB) as the voice option until LTE is rolled out in a wider area. The main problem with CSFB is that the data rates would drop to the 2G/3G rates when the UE falls back to the 2G/3G network during the voice call.

The book "LTE-Advanced: A Practical Systems Approach to Understanding 3GPP LTE Releases 10 and 11 Radio Access Technologies" by Sassan Ahmadi has some detailed information on SRVCC, the following is an edited version from the book:

SRVCC is built on the IMS centralized services (ICS) framework for delivering voice and messaging services to the users regardless of the type of network to which they are attached, and for maintaining service continuity for moving terminals.

To support GSM and UMTS, some modifications in the MSC server are required. When the E-UTRAN selects a target cell for SRVCC handover, it needs to indicate to the MME that this handover procedure requires SRVCC. Upon receiving the handover request, the MME triggers the SRVCC procedure with the MSC server. The MSC then initiates the session transfer procedure to IMS and coordinates it with the circuit-switched handover procedure to the target cell.

Handling of any non-voice packet-switched bearer is by the packet-switched bearer splitting function in the MME. The handover of non-voice packet-switched bearers, if performed, is according to a regular inter-RAT packet-switched handover procedure.

When SRVCC is enacted, the downlink flow of voice packets is switched toward the target circuit-switched network. The call is moved from the packet-switched to the circuit-switched domain, and the UE switches from VoIP to circuit-switched voice.

3GPP Rel-10 architecture has been recommended by GSMA for SRVCC because it reduces both voice interruption time during handover and the dropped call rate compared to earlier configurations. The network controls and moves the UE from E-UTRAN to UTRAN/GERAN as the user moves out of the LTE network coverage area. The SRVCC handover mechanism is entirely network-controlled and calls remain under the control of the IMS core network, which maintains access to subscribed services implemented in the IMS service engine throughout the handover process. 3GPP Rel-10 configuration includes all components needed to manage the time-critical signaling between the user’s device and the network, and between network elements within the serving network, including visited networks during roaming. As a result, signaling follows the shortest possible path and is as robust as possible, minimizing voice interruption time caused by switching from the packet-switched core network to the circuit-switched core network, whether the UE is in its home network or roaming. With the industry aligned around the 3GPP standard and GSMA recommendations, SRVCC-enabled user devices and networks will be interoperable, ensuring that solutions work in many scenarios of interest.

Along with the introduction of the LTE radio access network, 3GPP also standardized SRVCC in Rel-8 specifications to provide seamless service continuity when a UE performs a handover from the E-UTRAN to UTRAN/GERAN. With SRVCC, calls are anchored in the IMS network while the UE is capable of transmitting/ receiving on only one of those access networks at a given time, where a call anchored in the IMS core can continue in UMTS/GSM networks and outside of the LTE coverage area. Since its introduction in Rel-8, the SRVCC has evolved with each new release, a brief summary of SRVCC capability and enhancements are noted below

3GPP Rel-8: Introduces SRVCC for voice calls that are anchored in the IMS core network from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN circuit-switched. To support this functionality, 3GPP introduced new protocol interface and procedures between MME and MSC for SRVCC from E-UTRAN to UTRAN/GERAN, between SGSN and MSC for SRVCC from UTRAN (HSPA) to UTRAN/GERAN, and between the MME and a 3GPP2-defined interworking function for SRVCC from E-UTRAN to CDMA 2000.

• 3GPP Rel-9: Introduces the SRVCC support for emergency calls that are anchored in the IMS core network. IMS emergency calls, placed via LTE access, need to continue when SRVCC handover occurs from the LTE network to GSM/UMTS/CDMA2000 networks. This evolution resolves a key regulatory exception. This enhancement supports IMS emergency call continuity from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/ GERAN circuit-switched network. Functional and interface evolution of EPS entities were needed to support IMS emergency calls with SRVCC.

• 3GPP Rel-10: Introduces procedures of enhanced SRVCC including support of mid-call feature during SRVCC handover (eSRVCC); support of SRVCC packet-switched to circuit-switched transfer of a call in alerting phase (aSRVCC); MSC server-assisted mid-call feature enables packet-switched/ circuit-switched access transfer for the UEs not using IMS centralized service capabilities, while preserving the provision of mid-call services (inactive sessions or sessions using the conference service). The SRVCC in alerting phase feature adds the ability to perform access transfer of media of an instant message session in packet-switched to circuit-switched direction in alerting phase for access transfers.

• 3GPP Rel-11: Introduces two new capabilities: single radio video call continuity for 3G-circuit-switched network (vSRVCC); and SRVCC from UTRAN/GERAN to E-UTRAN/HSPA (rSRVCC). The vSRVCC feature provides support of video call handover from E-UTRAN to UTRAN-circuitswitched network for service continuity when the video call is anchored in IMS and the UE is capable of transmitting/receiving on only one of those access networks at a given time. Service continuity from UTRAN/GERAN circuitswitched access to E-UTRAN/HSPA was not specified in 3GPP Rel-8/9/10. To overcome this drawback, 3GPP Rel-11 provided support of voice call continuity from UTRAN/GERAN to E-UTRAN/HSPA. To enable video call transfer from E-UTRAN to UTRAN-circuit-switched network, IMS/EPC is evolved to pass relevant information to the EPC side and S5/S11/Sv/Gx/Gxx interfaces are enhanced for video bearer-related information transfer. To support SRVCC from GERAN to E-UTRAN/HSPA, GERAN specifications are evolved to enable a mobile station and base station sub-system to support seamless service continuity when a mobile station hands over from GERAN circuit-switched access to EUTRAN/ HSPA for a voice call. To support SRVCC from UTRAN to EUTRAN/ HSPA, UTRAN specifications are evolved to enable the RNC to perform rSRVCC handover and to provide relative UE capability information to the RNC.

NTT Docomo has a presentation on SRVCC and eSRVCC which is embedded below:

Improvement of VoLTE Domain HO with Operators Vision from Zahid Ghadialy

Multipoint HSDPA / HSPA

The following is from 3GPP TR 25.872 - Technical Specification Group Radio Access Network; HSDPA Multipoint Transmission:

HSPA based mobile internet offerings are becoming very popular and data usage is increasing rapidly. Consequently, HSPA has begun to be deployed on more than one transmit antenna or more than one carrier. As an example, the single cell downlink MIMO (MIMO-Physical layer) feature was introduced in Release 7. This feature allowed a NodeB to transmit two transport blocks to a single UE from the same cell on a pair of transmit antennas thus improving data rates at high geometries and providing a beamforming advantage to the UE in low geometry conditions. Subsequently, in Release-8 and Release-9, the dual cell HSDPA (DC-HSDPA) and dual band DC-HSDPA features were introduced. Both these features allow the NodeB to serve one or more users by simultaneous operation of HSDPA on two different carrier frequencies in two geographically overlapping cells, thus improving the user experience across the entire cell coverage area. In Release 10 these concepts were extended so that simultaneous transmissions to a single UE could occur from four cells (4C-HSDPA).

When a UE falls into the softer or soft handover coverage region of two cells on the same carrier frequency, it would be beneficial for the non-serving cell to be able to schedule packets to this UE and thereby improving this particular user’s experience, especially when the non-serving cell is partially loaded. MultiPoint HSDPA allows two cells to transmit packets to the same UE, providing improved user experience and system load balancing. MultiPoint HSDPA can operate on one or two frequencies.

Click to enlarge

There is also an interesting Qualcomm Whitepaper on related topic that is available to view and download here. The following is from that whitepaper:

The simplest form of Multipoint HSPA, Single Frequency Dual Cell HSPA (SFDC-HSPA), can be seen as an extension to the existing DC-HSPA feature. While DC-HSPA allows scheduling of two independent transport blocks to the mobile device (UE) from one sector on two frequency carriers, SFDC-HSPA allows scheduling of two independent transport blocks to the UE from two different sectors on the same carrier. In other words, it allows for a primary and a secondary serving cell to simultaneously send different data to the UE. Therefore, the major difference between SFDC-HSPA and DC-HSPA operation is that the secondary transport block is scheduled to the UE from a different sector on the same frequency as the primary transport block. The UE also needs to have receive diversity (type 3i) to suppress interference from the other cell as it will receive data on the same frequecny from multiple serving cells.Figure 1 llustrates the high-level concept of SFDC-HSPA.

In the case where the two sectors involved in Multipoint HSPA transmission belong to the same NodeB (Intra-NodeB mode), as illustrated in Figure 2, there is only one transmission queue maintained at the NodeB and the RNC. The queue management and RLC layer operation is essentially the same as for DC-HSPA.

In the case where the two sectors belong to different NodeBs (Inter-NodeB mode), as illustrated in Figure 2, there is a separate transmission queue at each NodeB. RLC layer enhancements are needed at the RNC along with enhanced flow control on the Iub interface between RNC and NodeB in order to support Multipoint HSPA operation across NodeBs. These enhancements are discussed in more detail in Section 4. In both modes, combined feedback information (CQI and HARQ-ACK/ NAK) needs to be sent on the uplink for both data streams received from the serving cells. On the uplink, the UE sends CQIs seen on all sectors using the legacy channel structure, with timing aligned to the primary serving cell.

When two carriers are available in the network, there is an additional degree of freedom in the frequency domain. Dual Frequency Dual Cell HSPA (DFDC-HSPA) allows exploiting both frequency and spatial domains by scheduling two independent transport blocks to the UE from two different sectors on two different frequency carriers. For a DC-HSPA capable UE, this is equivalent to having independent serving cells on the two frequency carriers. In Figure 3, UE1 is in DC-HSPA mode, whereas UE2 is in DFDC-HSPA mode.

Dual Frequency Four-Cell HSPA (DF4C-HSPA) can be seen as a natural extension of DFDC-HSPA, suitable for networks with UEs having four receiver chains. DF4C-HSPA allows use of the four receiver chains by scheduling four independent transport blocks to the UE from two different sectors on two different frequency carriers. DF4C-HSPA is illustrated in Figure 4.

Like SFDC-HSPA; DFDC-HSPA and DF4C-HSPA can also be intra-NodeB or inter-NodeB, resulting in an impact on transmission queue management, Iub flow control and the RLC layer.

Advantages of Multipoint transmission:

* Cell Edge Performance Improvement

* Load balancing across sectors and frequency carriers

* Leveraging RRU and distributed NodeB technology

Multipoint HSPA improves the performance of cell edge users and helps balance the load disparity across neighboring cells. It leverages advanced receiver technology already available in mobile devices compatible with Release 8 and beyond to achieve this. The system impact of Multipoint HSPA on the network side is primarily limited to software upgrades affecting the upper layers (RLC and RRC).

See also: FS_HSDPA_MP_TX: Study on HSDPA Multipoint Transmission

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.

LTE to 3G Handover Procedure and Signalling

It may be worthwhile brushing up the LTE/SAE Interfaces and Architecture before proceeding.

1) Overview of Handover Operation

With EPC, continuous communication is possible, even while the terminal switches from one type of radio access system to another.

Specifically, in order to achieve the internal network path switching required to change radio access systems, the S-GW provides a mobility management anchor function for handover between 3GPP radio access systems, and the P-GW provides the function for handover between 3GPP and non-3GPP radio access systems. In this way, the IP address does not change when the terminal switches radio access systems, and communications can continue after handover.

In handover between the 3GPP radio access systems, LTE and 3G, handover preparation is done before changing systems, including tasks such as securing resources on the target radio access system, through cooperation between the radio access systems (Figure 3 (a)(A)). Then, when the actual switch occurs, only the network path needs to be switched, reducing handover processing time (Fig.3 (a)(B)). Also, loss of data packets that arrive at the pre-switch access point during handover can be avoided using a data forwarding function (Fig.3 (b)).

In this way, through interaction between radio access systems, fast handover without packet loss is possible, even between radio access systems such as LTE and 3G which cannot be used simultaneously.

2) Handover Preparation Procedure (Fig.3 (a)(A))

The handover preparation procedure for switching radio access from LTE to 3G is shown in Figure 4.

Step (1):The terminal sends a radio quality report containing the handover candidate base-stations and other information to the eNodeB. The eNodeB decides whether handover shall be performed based on the information in the report, identifies the base station and RNC to switch to, and begins handover preparation.

Steps (2) to (3): The eNodeB sends a handover required to the MME, sending the RNC identifier and transmission control information for the target radio access system. The MME identifies the SGSN connected to the target RNC based on the received RNC identifier and sends the communication control and other information it received from the eNodeB to the SGSN in a forward relocation request signal. The information required to configure the communications path between the S-GW and SGSN, which is used for data transmission after the MME has completed the handover, is sent at the same time.

Steps (4) to (5): The SGSN forwards the relocation request to the RNC, notifying it of the communications control information transmitted from the eNodeB. The RNC performs the required radio configuration processing based on the received information and sends a relocation response to the SGSN. Note that through this process, a 3G radio access bearer is prepared between the SGSN and RNC.

Step (6): The SGSN sends a forward relocation response to the MME in order to notify it that relocation procedure has completed. This signal also includes data issued by the SSGN and required to configure a communications path from the S-GW to the SGSN, to be used for data forwarding.

Steps (7) to (8): The MME sends a create indirect data forwarding tunnel request to the S-GW, informing it of the information issued by the SSGN that it just received. From the information that the S-GW receives, it establishes a communications path from the S-GW to the SGSN for data forwarding and sends a create indirect data forwarding tunnel response to the MME.

Through this handover preparation, target 3G radio-access resources are readied, the radio access bearer between the SGSN and RNC is configured, and the data forwarding path from the

S-GW to the SGSN configuration is completed.

3) Handover Procedure for Radio Access System Switching (Fig. 3(a)(B)):

The handover process after switching radio access system is shown in Figure 5.

Steps (1) to (2): When the handover preparation described in Fig.4 is completed, the MME sends a handover command to the eNodeB. When it receives this signal, the eNodeB sends a handover from LTE command for the terminal to switch radio systems. Note that when the eNodeB receives the handover command from the MME, it begins forwarding data packets received from the S-GW. Thereafter, packets for the terminal that arrive at the S-GW are forwarded to the terminal by the path: S-GW, eNodeB, S-GW, SGSN, RNC.

Steps (3) to (6): The terminal switches to 3G and when the radio link configuration is completed, notification that it has connected to the 3G radio access system is sent over each of the links through to the MME: from terminal to RNC, from RNC to SGSN, and from SGSN to MME. This way, the MME can perform Step (10) described below to release the eNodeB resources after a set period of time has elapsed.

Step (7): The MME sends a forward relocation complete acknowledgement to the SGSN. A set period of time after receiving this signal, the SGSN releases the resources related to data forwarding.

Step (8): The SGSN sends a modify bearer request to the S-GW to change from the communications path before the handover, between the S-GW and eNodeB, to one between the S-GW and SGSN. This signal contains information elements required to configure the path from S-GW to SGSN, including those issued by the SGSN. When the S-GW receives this signal, it configures a communications path from the S-GW to the SGSN. In this way, the communications path becomes: S-GW, SGSN, RNC, terminal; and data transmission to the target 3G radio access system begins.

Note that after this point, data forwarding is no longer needed, so the S-GW sends a packet to the eNodeB with an “End Marker” attached, and when the eNodeB receives this packet, it releases its resources related to data forwarding.

Steps (9) to (10): The S-GW sends a modify bearer response to the SGSN, indicating that handover procedure has completed. The MME also releases eNodeB resources that are no longer needed.

Through this handover procedure, data is forwarded during the handover, the switch of radio access bearer is completed, and the communications path from the P-GW to the terminal is updated.

In the examples above, we described the handover procedure between 3GPP radio access systems in which the S-GW did not change, but handovers with S-GW relocation are also possible. In these cases, the P-GW provides the anchor function for path switching, as with switches to non-3GPP access systems.

TERMS

Anchor function: A function which switches the communications path according to the area where the terminal is located, and forwards packets for the terminal to that area.

Relocation: Switching communications equipment such as area switches during communication.

Packet Flow in 2.5G, 3G, 3.5G and 4G

The 'LTE Signaling' is a very interesting book just being released that is a must have for people who are involved in design, development and testing. A book that explains the basic concepts from beginning till advanced concepts and explains how different components and interfaces fit together.

Though I havent yet read this book, I have read the earlier one titled UMTS Signaling, from the same authors that is an excellent reference for understanding Signalling in UMTS. I have no doubt that this book will be the same high quality.

The Excerpt on Wiley's website provides complete chapter 1 which is quite detailed and the Packet flow pictures and details below is extracted from this book.

The first stage of the General Packet Radio Service (GPRS), that is often referred to as the 2.5G network, was deployed in live networks starting after the year 2000. It was basically a system that offered a model of how radio resources (in this case, GSM time slots) that had not been used by Circuit Switched (CS) voice calls could be used for data transmission and, hence, profitability of the network could be enhanced. At the beginning there was no pre-emption for PS (Packet Switched) services, which meant that the packet data needed to wait to be transmitted until CS calls had been finished.

In contrast to the GSM CS calls that had a Dedicated Traffic Channel (DTCH) assigned on the radio interface, the PS data had no access to dedicated radio resources and PS signaling, and the payload was transmitted in unidirectional Temporary Block Flows (TBFs) as shown in Figure 1.2.

In Release 99, when a PDP (Packet Data Protocol) context is activated the UE is ordered by the RNC (Radio Network Controller) to enter the Radio Resource Control (RRC) CELL_DCH state. Dedicated resources are assigned by the Serving Radio Network Controller (SRNC): these are the dedicated physical channels established on the radio interface. Those channels are used for transmission of both IP payload and RRC signaling – see Figure 1.7. RRC signaling includes the exchange of Non-Access Stratum (NAS) messages between the UE and SGSN.

The spreading factor of the radio bearer (as the combination of several physical transport resources on the Air and Iub interfaces is called) depends on the expected UL/DL IP throughput. The expected data transfer rate can be found in the RANAP (Radio Access Network Application Part) part of the Radio Access Bearer (RAB) assignment request message that is used to establish the Iu bearer, a GPRS Tunneling Protocol (GTP) tunnel for transmission of a IP payload on the IuPS interface between SRNC and SGSN. While the spreading factor controls the bandwidth of the radio connection, a sophisticated power control algorithm guarantees the necessary quality of the radio transmission. For instance, this power control ensures that the number of retransmitted frames does not exceed a certain critical threshold.

Activation of PDP context results also in the establishment of another GTP tunnel on the Gn interface between SGSN and GGSN. In contrast to IuPS, where tunnel management is a task of RANAP, on the Gn interface – as in (E)GPRS – the GPRS Tunneling Protocol – Control (GTP-C) is responsible for context (or tunnel) activation, modification, and deletion.

However, in Release 99 the maximum possible bit rate is still limited to 384 kbps for a single connection and, more dramatically, the number of users per cell that can be served by this highest possible bit rate is very limited (only four simultaneous 384 kbps connections per cell are possible on the DL due to the shortness of DL spreading codes).

To increase the maximum possible bit rate per cell as well as for the individual user, HSPA was defined in Releases 5 and 6 of 3GPP.

In High-Speed Downlink Packet Access (HSDPA) the High-Speed Downlink Shared Channel (HSDSCH) which bundles several High-Speed Physical Downlink Shared Channels (HS-PDSCHs) is used by several UEs simultaneously – that is why it is called a shared channel.

A single UE using HSDPA works in the RRC CELL_DCH state. For DL payload transport the HSDSCH is used, that is, mapped onto the HS-PDSCH. The UL IP payload is still transferred using a dedicated physical data channel (and appropriate Iub transport bearer); in addition, the RRC signaling is exchanged between the UE and RNC using the dedicated channels – see Figure 1.8.

All these channels have to be set up and (re)configured during the call. In all these cases both parties of the radio connection, cell and UE, have to be informed about the required changes. While communication between NodeB (cell) and CRNC (Controlling Radio NetworkController) uses NBAP (Node B Application Part), the connection between the UE and SRNC (physically the same RNC unit, but different protocol entity) uses the RRC protocol.

The big advantage of using a shared channel is higher efficiency in the usage of available radio resources. There is no limitation due to the availability of codes and the individual data rate assigned to a UE can be adjusted quicker to the real needs. The only limitation is the availability of processing resources (represented by channel card elements) and buffer memory in the base station.

From the user plane QoS perspective the two major targets of LTE are:

• a further increase in the available bandwidth and maximum data rate per cell as well as for the individual subscriber;

• reducing the delays and interruptions in user data transfer to a minimum.

These are the reasons why LTE has an always-on concept in which the radio bearer is set up immediately when a subscriber is attached to the network. And all radio resources provided to subscribers by the E-UTRAN are shared resources, as shown in Figure 1.9. Here it is illustrated that the IP payload as well as RRC and NAS signaling are transmitted on the radio interfaces using unidirectional shared channels, the UL-SCH and the Downlink Shared Channel (DL-SCH). The payload part of this radio connection is called the radio bearer. The radio bearer is the bidirectional point-to-point connection for the user plane between the UE and eNodeB (eNB). The RAB is the user plane connection between the UE and the Serving Gateway (S-GW) and the S5 bearer is the user plane connection between the S-GW and public data network gateway (PDN-GW).

The end-to-end connection between the UE and PDN-GW, that is, the gateway to the IP world outside the operator’s network, is called a PDN connection in the E-UTRAN standard documents and a session in the core network standards. Regardless, the main characteristic of this PDN connection is that the IP payload is transparently tunneled through the core and the radio access network.

To control the tunnels and radio resources a set of control plane connections runs in parallel with the payload transport. On the radio interface RRC and NAS signaling messages are transmitted using the same shared channels and the same RLC transport layer that is used to transport the IP payload.

RRC signaling terminates in the eNB (different from 3G UTRAN where RRC was transparently routed by NodeB to the RNC). The NAS signaling information is – as in 3G UTRAN – simply forwarded to the Mobility Management Entity (MME) and/or UE by the eNB.

You can read in detail about all these things and much more from the Wiley's website here.

Minimization of Drive Tests (MDT) in 3GPP Release-10

Another one that came from the SON conference.

At present, the network optimisation after it is operational is generally done by drive testing. In this an equipment (test mobile) that collects measurements and location information collects all the required information while the equipment is being driven in a car on the roads and this information is used offline to analyse the coverage in different locations and based on that the parameters, power, antenna locations, antenna tilts, etc. are optimised. After the changes to any of the optimisation paramaters, drive test has to be undertaken again to make sure that the impact of these changes are positive.

One more thing that has to be taken account of is that the drive tests have to be carried out at di9ffert times to be able to predeict the behaviour at different loads.

Using drive tests for network optimization purposes is costly and causes also additional CO2 emissions, so it is desirable to develop automated solutions, including involving UEs in the field, in 3GPP to reduce the operator costs for network deployment and operation. The studies done as part of the study item phase [1] have shown that it is beneficial to collect UE measurements to enable a more efficient network optimisation and it is feasible to use control plane solutions to acquire the information from devices. This information, together with information available in the radio access network can be used for Coverage Optimization purposes.

It should be remembered that drive tests form a big part of the Network opex and Deutsche Telekom for example expects a 40% cost saving with SON (and MDT is a part of that)

Goal of MDT in 3GPP Rel.10

– Automatic UE measurements collection and data logging used to replace the manual drive testing that the operators have to perform in their networks

– Evaluation of network performance per physical location

– For both HSPA & LTE

There are two different types of MDT:

Immediate MDT: MDT functionality involving measurement performance by UE in CONNECTED state and reporting of the measurements to eNB/RNC available at the time of reporting condition.

Logged MDT: MDT functionality involving measurement performance by UE in IDLE state at points in time when configured conditions are satisfied, its storage in measurement log for reporting to eNB/RNC at a later point in time.

The solutions for MDT shall be able to work independently from SON support in the network. Relation between measurements/solution for MDT and UE side SON functions shall be established in a way that re-use of functions is achieved where possible.

• Use cases

– 3GPP R10: Coverage optimization : Prio1

– For 3GPP > R10 :Capacity optimization, Mobility optimization, Parameterization of common channels, QoS verification, no specific measurements

- In Release-11 MDT Enhancements and evaluation of other MDT use cases, such as ”Parameterization of common control channels” and Positioning enhancements will be explored.

• MDT and SON

– MDT is about UE measurement collection for off-line processing No automatic mechanism is defined MDT

– SON is aiming at instantaneous/automated reaction on short to middle term network issues

It should be noted that MDT is a wide area and some of the boundaries between MDT and SON are a bit fuzzy. One of the other ways for SON is to enable detected cell measurements in the handset. This will give the indication about the cells that are not in the monitored set but the UE is able to see.

The RRC (control plane) measurements for LTE are not advanced enough and there are no measurements for UE position. On the other hand for UMTS/HSPA the UE positioning measurements could be used to report the exact location at the point of measurements. There are some discussions for enhancing the LTE measurements to include the longitude, latitude, altitude, velocity and even direction (too ambitious?).

Finally it should be pointed out that UE based reporting based on the User Plane Measurements (typically done by the operator installing a small application on the handset) can be performed by the operator in case a user is reporting poor coverage or failure in an area. Since these are proprietary applications, the operator can collect variety of information including but not limited to, position information, crrent cell and neighbour cell power levels, etc.

With all the control plane measurements and user plane measurements, the battery life could be severely affected and it has to be made sure that these are done very seldomly or with users permission.

Some of the things mentioned above may not be exactly true and if you know better please feel free to correct me.

[1] 3GPP TR 36.805 - Study on Minimization of drive-tests in Next Generation Networks

[2] 3GPP TS 37.320 - Universal Terrestrial Radio Access (UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRA); Radio measurement collection for Minimization of Drive Tests (MDT); Overall description; Stage 2 (Release 10)

The 3GPP release 8 IMS Implementation, Deployment & Testing workshop

The 3GPP release 8 IMS Implementation, Deployment & Testing workshop took place in Sophia Antipolis on 24-25 November 2010.

The event was attended by 70 delegates actively participating to the discussions.

Presenting companies included: Tel : A1 Telekom Austria, Alcatel Lucent, Codenomicon, Conformiq, Eircom, Elvior, ETSI, France Telecom, GSMA, Huawei, Huawei, Mobitel, NTT DoCoMo, SFR, Telecom Italia, TestingTech, TU Berlin, Wind, Wipro, ZTE.

Here are the highlights from the ETSI document:

Goals and Outcome for this workshop

Share exprience from IMS implementation

Highlight areas for further specifications, for

Standards and Testing

Learn of issues and possible resolutions

Comments from The IMS Network Testing Group

Develop IMS core network test specifications based upon 3GPP, for:

• Interoperability

• conformance

• network integration

Hold interoperability events (IMS Plugtests)

Coordinate with other organisations such as OMA, MSF, GSMA

Implementations

• Beyond small islands, second wave to replace unscalable, unmaintenable early VoIP systems

• Implementation options - Hybrid CS-GW for transition from CS to LTE, which already has 2 million subscribers on IMS/CS-GW/RNC

• Auto provisioning - to simplify complexity

• IMS functions must be implemented in the core – not in any access network, such as LTE, and can be used for non-Voice as well

Implementing RCS (Rich Communication Suite)

• RCS trial feedback - Good feedback from 400 trial users on RCS but difficult to configure SBC

• RCS implementations should include aggregation with SNS (Social Network Services)– eg contact list from Facebook

• Most appreciated feature of RCS is: - cross-operator interworking and compatibility with ordinary phones, not just smartphones

Specific Issues and Resolutions

• FAX – Delay and Jitter issues - FTTH will solve long delays etc

• Emergency and Lawful Intercept with IMS -There are standards and developed solutions available but Currently still falls back to CS /TDM

• Data Provisioning speed is important, to achieve no service interruption.

• 3GPP II-NNI: Inter-IMS Network to Network Interface - Two levels: Solx (service with control function) and Coix (connection – a pipe for media).

• “PathFinder” Global ENUM – like DNS for phone number; It is a solution to number portability and can optimise routing

About Services

• Most issues are Beyond IMS - integrating OSS/BSS, existing systems, inter-vendors interfaces

• IMS and IN - Pity the Standards did not bring IN and IMS close together; Need iFC enhancements, like in IN; Need to support combining services

• OTT and SNS dominate growth - occupies the minds of commercial people, GSMA-like services have slowed down

• Service layer (Wipro) – Telcos want one SDP to serve all - include IMS and non-IMS services, human and non-humans on NAB, context based, and charge only what is ‘consumed’

Testing Methods, Tools and Test Beds

• Integrate Conformance checking with interoperability testing

• Automation of interoperability trace checking – it can reduce costs by more than 50 % compared to manual validation

• Independent Test Bed- available EPC playground for prototyping applications

• Protocol message customisation tool - allows changing the message and customise the flow

• Security testing tool - testing by ‘fuzzing’, 100% TTCN free – everything is already build in

• IMS is a multi vendor environment - Testing and validation must be an integral part of the deployment process

Memorable Quotes

“IMS is a Journey, not a destination” (ALU)

“SDP is almost anything” (Matjas Bericic, Mobitel)

“Voice as an app versus Voice as a Service” is a challenge (Manuel Vexler, Huawei)

“IMS is not a box, it is a network” (Matjas Bericic, Mobitel)

“global ENUM is DNS for phone numbers” (Adrian Dodd, GSMA)

“Kill with one SIP” (Ari Takanen, Codenomicon)

“ IOP is the red thread running through the entire ETSI standards development process “ (Milan Zoric, ETSI)

All documents from this workshop is available at: http://docbox.etsi.org/Workshop/2010/201011_IMSWORKSHOP/

Femtocells Standardization in 3GPP

Femtocells have been around since 2007. Before Femtocells, the smallest possible cell was the picocell that was designed to serve a small area, generally a office or a conference room. With Femtocells came the idea of having really small cells that can be used in houses and they were designed to serve just one home. Ofcourse in my past blogs you would have noticed me mentioning about Super Femtos and Femto++ that can cater for more users in a small confined space, typically a small office or a meeting room but as far as the most common definition is concerned they are designed for small confined spaces and are intended to serve less than 10 users simultaneously.

This blog post is based on IEEE paper on "Standardization of Femtocells in 3GPP" that appeared in IEEE Communications Magazine, September 2009 issue. This is not a copy paste article but is based on my understanding of Femtos and the research based on the IEEE paper. This post only focusses on 3GPP based femtocells, i.e., Femtocells that use UMTS HSDPA/HSPA based technology and an introduction to OFDM based LTE femtocells.

The reason attention is being paid to the Femtocells is because as I have blogged in the past, there are some interesting studies that suggest that majority of the calls and data browsing on mobiles originate in the home and the higher the frequency being used, the less its ability to penetrate walls. As a result to take advantage of the latest high speed technologies like HSDPA/HSUPA, it makes sense to have a small cell sitting in the home giving ability to the mobiles to have high speed error free transmission. In addition to this if some of the users that are experiencing poor signal quality are handed over to these femtocells, the overall data rate of the macro cell will increase thereby providing better experience to other users.

Each technology brings its own set of problems and femocells are no exception. There are three important problems that needs to be answered. They are as follows:

• Radio interference mitigation and management: Since femtocells would be deployed in adhoc manner by the users and for the cost to be kept down they should require no additional work from the operators point of view, they can create interference with other femtocells and in the worst possible scenario, with the macro cell. It may not be possible initially to configure everything correctly but once operational, it should be possible to adjust the parameters like power, scrambling codes, UARFCN dynamically to minimise the interference.

• Regulatory aspects: Since the mobiles work in licensed spectrum bands, it is required that they follow the regulatory laws and operate in a partcular area in a band it is licensed. This is not a problem in Europe where the operators are given bands for the whole country but in places like USA and India where there are physical boundaries within the country for the allocation of spectrum for a particular operator. This brings us to the next important point.

• Location detection: This is important from the regulatory aspect to verify that a Femtocell can use a particular band over an area and also useful for emergency case where location information is essential. It is important to make sure that the user does not move the device after initial setup and hence the detection should be made everytime the femto is started and also at regular intervals.

3GPP FEMTOCELLS STANDARDIZATION

Since the femtocells have been available for quite a while now, most of them do not comply to standards and they are proprietary solutions. This means that they are not interoperable and can only work with one particular operator. To combat this and to create economy of scale, it became necessary to standardise femtocells. Standardized interfaces from the core network to femtocell devices can potentially allow system operators to deploy femtocell devices from multiple vendors in a mix-and-match manner. Such interfaces can also allow femtocell devices to connect to gateways made by multiple vendors in the system operator’s core network (e.g., home NodeB gateway [HNB-GW] devices).

In 2008, Femto Forum was formed and it started discussion on the architecture. From 15 different proposals, consensus was reached in May over the Iuh interface as shown below.

There are two main standard development organizations (SDOs) shaping the standard for UMTS-related (UTRAN) femto technology: 3GPP and The Broadband Forum (BBF).
More about 3GPP here. BBF (http://www.broadbandforum.org) was called the DSL Forum until last year. As an SDO to meet the needs of fixed broadband technologies, it has created specifications mainly for DSL-related technologies. It consists of multiple Working Groups. The Broadband Home WG in particular is responsible for the specification of CPE device remote management. The specification is called CPE wide area network (WAN) Management Protocol (CWMP), which is commonly known by its document number, TR-069.

There are several other important organisations for femto technology. The two popular ones are the Femto Forum (www.femtoforum.org) and Next Generation Mobile Network (NGMN).

3GPP has different terminology for Femtocells and components related to that. They are as follows:

Generic term: Femtocell
3GPP Term: home NodeB (HNB)
Definition: The consumer premises equipment (CPE) device that functions as the small-scale nodeB by interfacing to the handset over the standard air interface (Uu) and connecting to the mobile network over the Iuh interface.

Generic term: FAP Gateway (FAP-GW) or Concentrator
3GPP Term: home NodeB gateway (HNB-GW)
Definition: The network element that directly terminates the Iuh interface with the HNB and the existing IuCS and IuPS interface with the CN. It effectively aggregates a large number of HNBs (i.e., Iuh interface) and presents it as a single IuCS/PS interface to the CN.

Generic term: Auto-Configuration Server (ACS)
3GPP Term: home NodeB management system (HMS)
Definition: The network element that terminates TR-069 with the HNB to handle the remote management of a large number of HNBs.

In addition, there is a security gateway (SeGW) that establishes IPsec tunnel to HNB. This ensures that all the Iuh traffic is securely protected from the devices in home to the HNB-GW.
The HNB-GW acts as a concentrator to aggregate a large number of HNBs which are logically represented as a single IuCS/IuPS interface to the CN. In other words, from the CN’s perspective, it appears as if it is connected to a single large radio network controller (RNC). This satisfies a key requirement from 3GPP system operators and many vendors that the femtocell system architecture not require any changes to existing CN systems.

The radio interface between HNB and UE is the standard RRC based air interface but has been modified to incude HNB specific changes like the closed subscriber group (CSG) related information.

Two new protocols were defined to address HNB-specific differences from the existing Iu interface protocol to 3GPP UMTS base stations (chiefly, RANAP at the application layer).

• HNB Application Protocol (HNBAP): An application layer protocol that provides HNB-specific control features unique to HNB/femtocell deployment (e.g., registration of the HNB device with the HNBGW).

• RANAP User Adaptation (RUA): Provides a lightweight adaptation function to allow RANAP messages and signaling information to be transported directly over Stream Control Transport Protocol (SCTP) rather than Iu, which uses a heavier and more complex protocol stack that is less well suited to femtocells operating over untrusted networks from home users (e.g., transported over DSL or cable modem connections).

Figure above is representation of the protocol stack diagram being used in TS 25.467.

Security for femtocell networks consists of two major parts: femtocell (HNB) device authentication, and encryption/ciphering of bearer and control information across the untrusted Internet connection between the HNB and the HNB-GW (e.g., non-secure commercial Internet service). The 3GPP UMTS femtocell architecture provides solutions to both of these problems. 3GPP was not able to complete the standardization of security aspects in UMTS Release 8; however, the basic aspects of the architecture were agreed on, and were partially driven by broad industry support for a consensus security architecture facilitated in discussions within the Femto Forum. All security specifications will be completed in UMTS Release 9 (targeted for Dec. 2009).

FEMTOCELL MANAGEMENT

Management of femtocells is a very big topic and very important one for the reasons discussed above.

The BBF has created CWMP, also referred to as TR-069. TR-069 defines a generic framework to establish connection between the CPE and the automatic configuration server (ACS) to provide configuration of the CPE. The messages are defined in Simple Object Access Protocol (SOAP) methods based on XML encoding, transported over HTTP/TCP. It is flexible and extensive enough to incorporate various types of CPE devices using various technologies. In fact, although TR-069 was originally created to manage the DSL gateway device, it has been adopted by many other types of devices and technologies.

The fundamental functionalities TR-069 provides are as follows:

• Auto-configuration of the CPE and dynamic service provisioning

• Software/firmware management and upgrade

• Status and performance monitoring

• Diagnostics

The auto-configuration parameters are defined in a data model. Multiple data model specifications exist in the BBF in order to meet the needs of various CPE device types. In fact, the TR-069 data model is a family of documents that has grown over the years in order to meet the needs of supporting new types of CPE devices that emerge in the market. In this respect, femtocell is no exception. However, the two most common and generic data models are:

• TR-098: “Internet Gateway Device Data Model for TR-069”

• TR-106: “Data Model Template for TR-069-Enabled Devices”

HAND-IN AND FEMTO-TO-FEMTO HANDOVERS

The 3GPP specifications focused on handovers in only one direction initially — from femtocell devices to the macrocellular system (sometimes called handout). A conscious decision was made to exclude handover from the macrocellular system to the femtocell devices (sometimes called macro to femtocell hand-in). This decision was driven by two factors:

• There are a number of technical challenges in supporting hand-in with unmodified mobile devices and core network components.

• The system operator requirements clearly indicate that supporting handout is much more important to end users.

Nonetheless, there is still a strong desire to develop open, interoperable ways to support handin in an efficient and reliable manner, and the second phase of standards in 3GPP is anticipated to support such a capability.

NEXT-G EFFORTS

3GPP Release 8 defines the over-the-air radio signaling that is necessary to support LTE femtocells. However, there are a number of RAN transport and core network architecture, interface, and security aspects that will be addressed as part off 3GPP’s Release 9 work efforts. While it is preliminary as of the publication of this article, it seems highly likely that all necessary RAN transport and core network work efforts for LTE femtocells will be completed in 3GPP Release 9 (targeted for completion by the end of 2009).

3GPP STANDARDS ON FEMTOCELLS

[1] 3GPP TS 25.331: RRC

[2] 3GPP TS 25.367: Mobility Procedures for Home NodeB (HNB); Overall Description; Sage 2

[3] 3GPP TS 25.467: UTRAN Architecture for 3G Home NodeB; Stage 2

[4] 3GPP TS 25.469: UTRAN Iuh Interface Home NodeB (HNB) Application Part (HNBAP) Signaling

[5] 3GPP TS 25.468: UTRAN Iuh Interface RANAP User Adaption (RUA) Signaling

[6] 3GPP TR 3.020: Home (e)NodeB; Network Aspects -(http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/R3_internal_TRs/R3.020_Home_eNodeB/)

[7] 3GPP TS 25.104: Base Station (BS) Radio Transmission and Reception (FDD)

[8] 3GPP TS 25.141: Base Station (BS) Conformance Testing (FDD)

[9] 3GPP TR 25.967: FDD Home NodeB RF Requirements

[10] 3GPP TS 22.011: Service Accessibility

[11] 3GPP TS 22.220: Service Requirements for Home NodeB (HNB) and Home eNodeB (HeNB)

[12] 3GPP TR 23.830: Architecture Aspects of Home NodeB and Home eNodeB

[13] 3GPP TR 23.832: IMS Aspects of Architecture for Home NodeB; Stage 2

[14] 3GPP TS 36.300: E-UTRA and E-UTRAN; Overall Description; Stage 2

[15] 3GPP TR 33.820: Security of H(e)NB 3GPP TR 32.821: Telecommunication Management; Study of Self-Organizing Networks (SON) Related OAM Interfaces for Home NodeB

[16] 3GPP TS 32.581: Telecommunications Management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Concepts and Requirements for Type 1 Interface HNB to HNB Management System (HMS)

[17] 3GPP TS 32.582: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Information Model for Type 1 Interface HNB to HNB Management System (HMS)

[18] 3GPP TS 32.583: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Procedure Flows for Type 1 Interface HNB to HNB Management System (HMS)

[19] 3GPP TS 32.584: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); XML Definitions for Type 1 Interface HNB to HNB Management System (HMS)

I would strongly recommend reading [3] and [6] for anyone who wants to gain better understanding of how Femtocells work.