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.

Flatter Architecture from Nokia-Siemens Network

From Unstrung:

In its bid to overtake Ericsson AB and become the world’s top radio access infrastructure supplier in terms of revenue, Nokia Siemens Networks believes its approach to all-IP flat architecture on 3G networks will give it an edge. Nokia Siemens says operators do not have to wait for LTE, to get the benefits of an all-IP architecture, and it is the only vendor that currently champions a flat 3G radio access network (RAN) approach.

As mobile data traffic continues to surge, operators are considering how to adopt flat, all-IP architectures in their 3G networks before the advent of 4G in order to gain lower latency, lower cost per bit, support for multiple access networks, and preparation for next-generation networks. But there are different ways to implement such architectures, and just how operators arrive at a flatter data network architecture is hotly debated.

Nokia Siemens has put its money on a flat RAN approach for high-speed packet access (HSPA) and the coming HSPA+ standard, in addition to its support for the Direct Tunnel architecture.
In a flat RAN architecture, the radio network controller (RNC) is integrated into the Node B so that the base station communicates directly with the Gateway GPRS Support Node (GGSN).
But there are as many benefits as drawbacks to flat 3G RANs, which makes it a controversial approach, according to the recent Heavy Reading report, "Flat IP Architectures in Mobile Networks: From 3G to LTE."

With flat RANs, some of the benefits include lower latency for data applications, lower operational costs due to fewer nodes to maintain and manage, augmented data capacity through a data network overlay, and good preparation for so-called 4G LTE/SAE (System Architecture Evolution), which uses a similar functional architecture. Also, costs won’t grow in line with data traffic growth, because operators won’t have to deploy extra RNC and SGSN capacity as traffic increases.

It may be challenging to integrate the RNC into a Node B. RNCs are critical to supporting macro-diversity in mobile networks, which enables mobile handsets to communicate with multiple base stations on the uplink and allows operators to deploy fewer base stations. NSN’s flat RAN architecture supports this feature, but in an unorthodox way, according to the Heavy Reading report.

So far, Nokia Siemens has three customers using its Internet HSPA (I-HSPA) flat RAN solution: Stelera Wireless and TerreStar Neworks in the U.S. and T-2 in Slovenia. And Mobilkom Austria AG & Co. KG recently trialed the solution.

Nokia Siemens’ Rouanne explains that flat 3G RANs aren’t necessary when there is just “medium” data traffic, but are best suited when operators have big data traffic volumes. “Those networks that are starting to be under pressure with traffic are coming to us and wanting to direct traffic directly to the Internet,” he says.

Even though Nokia Siemens is the only vocal supporter of flat 3G RANs right now, Brown says the strategy isn’t risky, but it’s “forward-looking.”

And a flat 3G RAN can set up an operator to be ready for the shift to LTE with its inherent flat architecture.

According to an old Ericsson presentation, ”Direct Tunnel” support added for 3G payload optimization has the following advantages:

• Cost efficient scaling for Mobile Broadband deployments
• Increased flexibility in terms of network topology
• Allows the SGSN node to be optimized for control plane
• Specifications part of 3GPP rel-7
• Designed for operation in legacy (GGSN/UTRAN) networks
• First step towards the SAE architecture

According to heavy reading article:

To efficiently deliver mobile broadband services, operators require a network infrastructure that simultaneously provides lower costs, lower latency, and greater flexibility. The key to achieving this goal is the adoption of flat, all-IP network architectures. With the shift to flat IP architectures, mobile operators can:

• Reduce the number of network elements in the data path to lower operations costs and capital expenditure
• Partially decouple the cost of delivering service from the volume of data transmitted to align infrastructure capabilities with emerging application requirements
• Minimize system latency and enable applications with a lower tolerance for delay; upcoming latency enhancements on the radio link can also be fully realized
• Evolve radio access and packet core networks independently of each other to a greater extent than in the past, creating greater flexibility in network planning and deployment
• Develop a flexible core network that can serve as the basis for service innovation across both mobile and generic IP access networks
• Create a platform that will enable mobile broadband operators to be competitive, from a price/performance perspective, with wired networks

Note: Diagrams above shamelessly copied from Ericsson's presentation.

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

Flexible RLC in Release 7 and Release 8

In R99, RLC packets had to be relatively small to avoid the retransmission of very large packets in case of transmission errors. Another reason for the relatively small RLC packet size was the need to provide sufficiently small step sizes for adjusting the data rates for Release 99 channels.

The RLC packet size in Release 99 is not only small, but it is also fixed for Acknowledged Mode Data and there are just a limited number of block sizes in UM Data. This limitation is due to transport channel data rate limitations in Release 99. The RLC payload size is fixed to 40 bytes in Release 99 for Acknowledged Mode Data. The same RLC solution is applied to HSDPA Release 5 and HSUPA Release 6 as well: the 40-byte packets are transmitted from RNC to the base station for HSDPA. An additional confi guration option to use an 80-byte RLC packet size was introduced in Release 5 to avoid extensive RLC protocol overhead, L2 processing and RLC transmission window stalling. With the 2 ms TTI used with HSDPA this leads to possible data rates being multiples of 160 kbps and 320 kbps respectively.

As the data rates are further increased in Release 7, increasing the RLC packet size even further would significantly impact on the granularity of the data rates available for HSDPA scheduling and the possible minimum data rates.

3GPP HSDPA and HSUPA allow the optimization of the L2 operation since L1 retransmissions are used and the probability of L2 retransmissions is very low. Also, the Release 99 transport channel limitation does not apply to HSDPA/HSUPA since the L2 block sizes are independent of the transport formats. Therefore, it is possible to use fl exible and considerably larger RLC sizes and introduce segmentation to the Medium Access Control (MAC) layer in the base station.

This optimization is included for downlink in Release 7 and for uplink in Release 8 and it is called flexible RLC and MAC segmentation solution. The RLC block size in fl exible RLC solution can be as large as an Internet Protocol (IP) packet, which is typically 1500 bytes for download. There is no need for packet segmentation in RNC. By introducing the segmentation to the MAC, the MAC can perform the segmentation of the large RLC PDU based on physical layer requirements when needed. The fl exible RLC concept in downlink is illustrated in Figure above.


There is a lot of interesting information in R&S presentation on HSPA. See here.

Main source of the content above and for further information see: LTE for UMTS: OFDMA and SC-FDMA Based Radio Access

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)

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.

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

All about F-DPCH

Fractional DPCH was added in Rel-6 to optimise the consumption of downlink channelization codes. When using HS-DSCH (High Speed Downlink Shared Channel), the main use for DL DPCH (also known as A-DPCH where A stands for Associated) is to carry power control commands (TPC bits) to the UE in order to adjust the uplink transmission. If all RBs (Radio Bearers) including SRBs (Signalling Radio Bearers) are mapped on to HS-DSCH then the DL codes are being wasted. SF 256 is used for A-DPCH and so every code being used by a user is seriously depleting the codes available for other UE's. To overcome this F-DPCH is used so that multiple UE's can share a single DL channelisation code. The limitation is 10 UEs in Rel-6.

For several users, the network configures each user having the same code but different frame timing and, thus, users can be transmitted on the single code source. The original timing is thus retained which avoids the need to adjust timings based on Release 99 power control loop implementation.

During slots where the DPCCH is not transmitted, the NodeB cannot estimate the uplink signal-to-interference ratio for power-control purposes and there is no reason for transmitting a power control bit in the downlink. Consequently, the UE shall not receive any power control commands on the F-DPCH in downlink slots corresponding to inactive uplink DPCCH slots.

There are some restrictions for FDPCH. It is not usable with services requiring data to be mapped to the DCH, such as AMR speech calls and CS video. Also, the lack of pilot information means that a method like feedback-based transmit diversity (closed loop mode) is not usable. The use of closed loop diversity is based on user-specific phase modification, wherein pilot symbols would be needed for verification of the phase rotation applied. On the other hand, when utilizing the F-DPCH, SRBs can benefit from high data rates of HSDPA and reduce service setup times remarkably

Finally, as you may have already figured out, by using F-DPCH the cell capacity has been improved and at the same time for same number of users, the interference has gone down significantly.

In Release 7, Rel-6 limitation has been removed. In R6, for a given UE in soft handover the TPC from all F-DPCH had to have the same offset timing. In R7, F-DPCH (TPC bits) can have different timing from different cells. This is possible due to introduction of 9 new F-DPCH slot formats (slot format 0 is the legacy F-DPCH slot format). The RRC signalling is done seperately for slot formats from the RNC to each of the cells.

You may also be interested in this Ericsson paper titled "The effect of F-DPCH on VoIP over HSDPA Capacity". Available here.

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.

3G or 4G: What should India do?

The first thing I should mention as I always do, please stop calling LTE as 4G as its commonly called as 3.9G. Labelling it as 4G does make it sound better (or sexy, some would say) but its not correct. Maybe the authors who label LTE as 4G dont want to try hard and do some research or its just to make the end users panic that India has missed a complete generation of mobile technology. LTE-Advanced will be the 4G technology and its still long way away (part of Rel-10).

Last week I wrote about Indian subscribers getting taste of 3G as the state owned MTNL and BSNL have launched some services. I am not sure what has been launched but all I can say is there is a dismal takeup as of yet. I read an article today about how Motorola is testing 4G [sic] and this can spoil the governments plan of rasing Rs 35,000 crore (£4.6Billion: 1Billion = 100 crores).

People may start panicking that investing in 3G is now doomed and it can just cause problems for the operators in future. The reality though is much more simpler. In a simple sentence, I would say that going for 3G or LTE does not matter much. Read on.

Lets first get Hardware out of the way. Most of the Base Stations (NodeB's, eNodeB's, RNC, etc) have a major part as SDR's or Software Defined Radios. The advantage of this is that if you have bought a 3G Node B, with just software change it should be upgradable to LTE eNode B. I have come across quite a few products where the equipment manufacturers are claiming that their 3G equipment is fully upgradeable to LTE. I did blog about some of this in this post here.

The second point we should get out of the way is the terminology. For a layman, 3G is something that was introduced 10 years back in 2000 so its quite an obsolete technology. In reality, 3G is commonly used to refer to even the new developments within the 3G spectrum. For example some of the people may have heard of HSDPA which is actually referred to as 3.5G in the mobile domain. Similarly we have HSUPA which is 3.75G and so on. The latest development is going on around 3.8G and 3.85G as part of Release 8. In general usage 3.5G, 3.75G, etc. is referred to as 3G but its more than 3G (3G+ ;). The good thing is that this 3G+ is till evolving. Release 8 was finalised in Dec. 2008 and the terminals based on that are still being tested. It should hopefully be available soon.

So whats the difference between LTE and HSPA+ (also known as 3G even though its 3.8/3.85G). Not much I would say from a general users point of view. Please note I am not arguing about the fundamental technologies because 3G+ uses WCDMA and LTE uses OFDMA/SC-FDMA technologies. OFDM based technologies will generally be always superior to WCDMA ones but it doesnt matter much. The main enhancement that has happened with LTE as compared to 3G is that in 3G the bandwidth is fixed to 5MHz whereas in case of LTE the bandwidth is flexible and can go all the way to 20MHz. Now if we compare the data speeds in 5MHz spectrum then there may not be much difference between them. Now how many operators will be rolling out services across 20MHz bandwidth? More general case will be using 10MHz.

In case of HSPA+, there is a new feature that allows a UE to use couple of cells. In this case even though the bandwidth is 5MHz but due to Dual Cell feature the UE would effectively see 10MHz bandwidth. This will definitely enhance the speeds.

Now coming to devices. 3G/HSPA/HSPA+ technologies have evolved over quite few years. There are some nice sleek and cheap handsets available. The technology in it as been rigourously tested. As a result the handsets are quite stable and many different design and models available.

LTE is yet to come. NTT DoCoMo and Verizon will be the first one to roll it out probably end 2010. Initial plan is to roll out the dongles then handsets will the eventually arrive. The initial ones will have problems, crashes, etc. Will take atleast till 2010 to sort out everything.

The big problem with LTE as many of us know is that the standards have to support for the old style CS voice and SMS. This should be fixed in Release 9 which is going to be standardised in Dec. 2009 (Mar. 2010 practically). There are different approaches and maybe untill LTE is rolled out we wont know which of them is better.

Last thing I should mention is the spectrum. The consensus is that 3G operates in 2.1GHz spectrum mostly worldwide. LTE would initially be deployed in 2.6GHz spectrum. The digital dividend spectrum when it becomes available will also be used for LTE. Most of the devices for LTE will be designed that way. As a result, 3G will continue to operate as it is in the 2.1GHz band. The devices will always be available and will be usable for long time.

Considering all the facts above, I think 3G (HSPA/HSPA+) is the best option in India or as a matter of fact in any country that is thinking of jumping directly from 2G to LTE. When the time is right, it should not be difficult to move from 3G to LTE.

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