In LTE, these things might be less of a worry, as the air interface has been redesigned from scratch and addresses these areas from day one. UMTS, however, did not address such things initially and over recent years a number of enhancements were specified. These are Fast Dormancy (FD, see here), Continuous Packet Connectivity (CPC, see here, here and here) and Cell-PCH (see here), a battery and signaling friendly semi-dormant air interface activity state. I have extensively blogged about these over the last years so for details click on the links and explore. But how do these features come together, are they mutually exclusive or should they be used in combination?
So here is a typical scenario that includes all functionalities above that I think networks and mobile devices could be using in the future once all features are developed and used:
The user of a mobile device starts the web browser and clicks through different pages, quickly at first until the desired piece of information is found, then a bit slower, say one new page every 30 seconds to a minute as subsequent additional information is discovered or read. When the browser is started, the air interface connection is in RRC Idle state, very good for the battery but the time until the first page starts to load is quite long, around 2.5 seconds. Not very good for the user experience. But once the connection is in the RRC Cell-DCH state, getting a page behind a link will be much faster as the radio link is already established. Due to the Continuous Packet Connectivity (CPC) feature, battery drain has been reduced compared to today so the network could keep the connection in the fast Cell-DCH state for much longer than today, say a minute or two.
Once the user is done with web browsing he exits the browser or puts it into the background and there is no further data traffic. The mobile device detects that there is no application in the foreground that exchanges data frequently so it will use the Fast Dormancy Feature specified in 3GPP Release 8 to indicate to the network that it would like to enter a more battery efficient radio state. The network then puts the radio connection into the Cell-PCH RRC state which is both battery efficient and allows the mobile device to resume communication within around 700-800 milliseconds. That is a much improved user experience over the 2.5 seconds from the fully idle state. The state is also good for the network, as a lot less signaling is required once there is renewed activity.
Applications running in the background while the mobile is carried in the pocket have to send keep-alive messages every now and then to keep their connection with a server in the network from timing out. Examples are e-mail push services, instant messengers, etc. These keep-alive intervals could be anywhere from a couple of minutes to half an hour. As the mobile is in Cell-PCH state, the keep-alive response is received very quickly and the mobile can indicate to the network right after the keep-alive exchange via the fast dormancy mechanism that it wants to go back to a more battery efficient state. No need to linger around in a more battery consuming state as it is unlikely any more data exchange will follow.
For such background message exchanges, the connection could be set to the RRC Cell-DCH state and here, Fast Dormancy has an additional plus for the networks as there are limits to how many users can be kept in Cell-DCH state simultaneously. So in addition to saving battery power it helps the network to remove idle connections from the air interface. Another option is to use the Cell-FACH state for such quick message exchanges, which might be sufficient for the few packets exchanged for the keep-alive, especially if the Forward Access Channel (FACH) uses the fast downlink shared channels, a feature of CPC.
If the user is quickly moving from cell to cell, the downside of the Cell-PCH state is that in each new cell, a Cell Update message has to be sent. This can be countered, as is already done in some networks today, by setting the device into URA-PCH state which only requires a Cell Update message at URA (UMTS Registration Area) boundaries.It all sounds very complicated but I think it should be manageable and achievable. Except for the new features such as FD Release 8 and CPC, the only other thing required is an intelligent RRC state handling in the mobile device because only there is the knowledge available on what the user and the applications do at the moment. Just invoking fast dormancy when the display's backlight is not on, independent of which applications are running in the background, is too simple. There could be, for example, an application running in the background that streams video from the network and requires data bursts every 10 seconds. Using FD when this happens is quite counter productive. Also, switching fast dormancy off while the backlight is on is also too simplistic because it could just be an MP3 player in the foreground which doesn't interact with the network and hence, fast dormancy can be used for applications running in the background.
In summary, I think all features mentioned in the title of the post will have to be used in the future to run a UMTS network efficiently and to reduce battery consumption as devices with always-on features become more and more common. The required network features are already through the standardization pipe and I am sure mobile device developers are also not sitting on their hands. In other words I am confident that things will be in place once they are needed.
"In LTE, these things might be less of a worry, as the air interface has been redesigned from scratch and addresses these areas from day one".
Hi, Martin
Could you talk about something about means that used in LTE?
Thanks
Posted by: Mac | July 01, 2010 at 10:33 AM