Yesterday, I've been looking at how LTE Radio Bearers are established and how data is transferred over the air interface. It's now time to draw a conclusion with a comparison of how data is transferred over the HSPA air interface to see if there are improvements concerning the time it requires to establish a radio bearer and how efficient the interface is for transporting small amounts of data.
Establishment Time
In current UMTS/HSPA networks, mobile devices are put into RRC_idle state after about 30 seconds of inactivity. If data transfer resumes, e.g. because the user clicks on a link on a web page, it takes about 2-3 seconds to re-establish the full bearer on the High Speed Downlink Shared Channels. This is quite different, to say a fixed line DSL connection, which has no such noticeable delay. The 30 seconds delay to put the mobile into idle state is thus a compromise to give the user a good browsing experience in most situations at the expense of power consumption, as the device requires a significant amount of power to keep the radio connection open, even if no data is transferred (more about that in one of the next blog entries).
In LTE on the other hand, state switches between idle and connected (on the air interface) have been designed to be very short. The requirements list a time of 0.1 seconds. Given the air interface structure as described in the previous article and only a single inquiry by the base station to the access gateway node to get the subscribers subscription profile and authentication information, it is likely that this target can be fulfilled. This means there will be almost no noticeable delay when the mobile moves back from a mostly dormant air interface state to a fully active state.
Another advantage of LTE is that base stations manage the radio interface autonomously. This is a significant difference to current HSPA networks, in which centralized Radio Network Controllers (RNCs) manage the air interface activity state on behalf of the base station. As more mobile devices are connected to the packet switched part of the network, the signaling load keeps increasing for the RNC and might well become a limiting factor in the future.
Transferring Small Amounts of Data
Even while in active state on the air interface, the network can react
to reduced activity and instruct the mobile to only listen at certain
intervals for incoming packets. During all other times, the mobile can
switch off its transceiver and thus conserve power. This enables
resumption of data transfer from the mobile even quicker than going
through a full state change. This method is called Discontinuous
Reception (DRX) and is likely to be an important tool to conserve
battery power and reduce signaling. Again, the base station is free to set and change the DRX period for an ongoing connection at any time and no information has to be exchanged with other nodes in the network.
In UMTS networks, the closest tool availble to handle connections in which only little data is exchanged is the Forward Access Channel (FACH). The FACH is also a a shared channel, but no power control is required. This saves a lot of energy at the mobile side as there is no dedicated channel for uplink power control required while data is exchanged on the FACH. With a capacity of only 32 kbit/s, however, the channels ability to handle many simultaneous connections is very limited. Furthermore, there are no DRX cycles, so the mobile has to continuously listen on the downlink for incoming data. Despite requiring much less energy than observing the high speed shared control channels and keeping a power control channel open in uplink direction, power requirements are still significant (as I will discuss in another blog post soon).
Why not sooner?
With all these advantages over UMTS, the question arises why UMTS has not been designed in this way in the first place? One of the answers probably is that when UMTS was specified back in the late 1990's, the world was still a circuit switched place for the end user. Most people still used dial-up modem connections and voice over IP up to the end user was not a hot topic. So the design of the radio network was strongly influenced by circuit switched thinking. HSPA was the first step into a fully packetized world with the introduction of the high speed downlink shared channels.
Today, however, even HSPA is still embedded into the concept of persistent radio channels and a hierarchical network structure in which control of the radio network is not fully at the base station but with radio network controllers. Also, there is still a high degree of communication with core network nodes such as the SGSN, e.g. whenever the RNC decides to put radio connection to the mobile into idle state. With HSPA, changes were made to give the base station more autonomy as data transfer over the high speed shared channels is controlled by the base station and no longer by the RNC.
To improve things further, companies organized in 3GPP have made many additional enhancements to the UMTS/HSPA air interface in recent versions of the standard. These are sometimes referred to as "Continued Packet Connectivity" CPC, and I reported about these new features here, here and here. Most of the CPC features are likely to be implemented and introduced in the next few years while LTE matures to help HSPA cope with the rising traffic until LTE can take over.
In UMTS packet data networks even prior to the CPC feature of release 7, you do not need to fall back all the way to RRC_Idle state, rather you can continue in an RRC Conencted mode through the URA_PCH and CELL_PCH states, which allow the connection to the core network to be retained, but you do lose the radio bearers. It is much faster to return to a fully connected mode (CELL_DCH state) from URA_PCH or CELL_PCH compared to RRC_Idle.
Hi Anil,
yes you are right, I should have written about those states as well in the post. It’s a bit strange. Cell_PCH and URA_PCH have been there since the first days of the UMTS standard. However, I have yet to encounter their implementation in live networks. In all networks I have used recently, the resume time after leaving Cell-FACH state is around 2.3 – 2.5 seconds. Not sure if that is from Idle state, but if Cell_PCH and URA_PCH are indeed quicker than returning from idle mode, then these times should have been considerably quicker. I wonder what the reason is for not having introduced these states in the network by now? Lack of interest from the operators, only minor improvements or backwards compatibility issues with mobiles?
Thanks for commenting!
Martin
Hi Martin, one reason CELL_PCH probably has not caught on is because it does have a higher signaling overhead compared to URA_PCH or RRC_IDLE, given that the mobile must transition back into CELL_FACH state to notify the network as it goes through cell reselection every time it moves to a new cell.
As for use of URA_PCH, my guess is that there has not until recently (thank you 3G iPhone!) been the kind of devices/applications in which users would really start to notice this delay. This is why the release 7 features such as CPC and enhanced CELL_FACH (and now the use of enhanced uplink in CELL_FACH in release 8) will be important in improving user experience moving forward.
I enjoy reading your posts very much, keep up the good work!
– Anil