Nokia Research Center on Impact of Keep-Alive Messaging on Power Consumption

With always on applications (think mobile eMail, IM, VoIP, etc.) on wireless devices, power consumption inevitably increases due to the constant exchange of TCP and UDP keep-alive messages to keep NAT firewalls open. Gone are the days in which wireless devices only communicated when there was really something to say. Pasi Eronen of the Nokia Research Center has taken a closer look at the issue and has measured and compared the impact of keep-alive messaging in 2G, 3G, 3.5G and Wifi networks. In the second part of the paper, Pasi then takes a look at how current VPN
security products could be enhanced to avoid frequent UDP keep-alive
messaging and thus increase the operating time of mobile devices. An interesting read, highly recommended!

Some of the findings:

  • NAT timeouts for UDP are anywhere between 30 and 180 seconds
  • NAT timeouts for TCP is anywhere between 30 and 60 minutes
  • Sending a keep-alive packet every 20s increases power consumption by a factor of 10 and more
  • The paper suggests that VPN products use a TCP connection to reestablish the UDP connection used for encrypted packets after a long timeout instead of sending frequent UDP keep-alives. Works well as long as no IM or VoIP client uses the VPN tunnel.

O2 Germany Doesn’t Care About APNs Anymore

Teltarif reported recently that O2 Germany have now configured their packet core to accept any kind of Access Point Name (APN) configuration of the mobile to activate a default Internet connection. According to O2 this will make it easier for customers to use the mobile Internet as configuring the mobile is simplified.

However, the article also mentions the bad side of this move: In the past, a non- or wrongly configured APN prevented accidental use. Now if the user forgets to lock his mobile before tugging it away in his pocket and that "@" key gets pressed, O2 happily starts charging. It already happened to me a couple of times under different circumstances. Especially nice when you are abroad…

So despite their probably good intentions I am a bit sceptical that this is a good move for consumers. From my point of view it's not the APN configuration that keeps people from trying the mobile Internet but the inadequate standard pricing many operators still have in place.

Being Really Always-On

Screenshot0041_2_really_always_on
Most of the time, I am almost always-on with one device or another, which means the device has an IP address only for the time I use an application. A couple of hours is usually the longest time since once I come home, my Wifi network takes over and my N95 starts using the home network. In the past, I have tried how long I could stay online with the mobile before the connection with the wireless network (the PDP context) is dropped. And there are many reasons for "packet call drops": Mobile resets, application crashes, network resets, network not configured correctly for Inter-SGSN routing area updates, you name it. So there are many causes for the connection to drop at some point and to be reestablished. So beyond a couple of hours to a day was usually the max. These days, things have much improved. In my latest test, I've been always-on with my N95 for almost 5 days. Take a look at the picture on the left. The last screenshot I took shows the packet data connection online counter at 4 days 19 hours and 47 minutes. That's what I call really always online 🙂 BTW: The network under test was that of T-Mobile Germany. Let's see if they can keep up this reliability once they roll in new equipment…

IMS Centralized Services (ICS)

Interesting to see which 3GPP Release 8 work items around the IP Multimedia Subsystem (IMS) are bearing fruit these days. While in Release 7, the hot application specifications for IMS services were Multi Media Telephony (MMTel) and device centric Voice Call Continuity (VCC), work in Release 8 seems to have to have shifted towards IMS Centralized Services (ICS) and a network centric Voice Call Continuity.

As the name implies, ICS offers centralized services, which means an IMS Application Server for ICS manages sessions for a user in several respects:

Multiple Devices – Several devices can be associated to the same user account and can be active simultaneously. Incoming media sessions can then be forwarded to one, several or all of these devices. Devices can be switched during ongoing sessions.

Including GSM mobiles – ICS has been designed not only to work with IP/IMS devices but also with "legacy" GSM  phones without any special software on board. When mobiles are switched on the MSC server communicates with the ICS Application Server (the Service Centralization and Continuity Application Server SCC AS) on behalf of the mobile. This is done either directly, in case the MSC server has been enhanced to act as an IMS client for the mobile, or via an Intelligent Network (IN) node that communicates with the MSC Server via CAP (CAMEL Application Part). The later one is probably preferred by many suppliers since IN nodes and CAP are used today for many applications such as prepaid billing. This has the advantage that the MSC software does not have to be extended for ICS.

Managing Supplementary Services – The ICS offers a standardized way of implementing services such as call forwarding, barring, hold, resume, 3-way calling.

Combination of Different Types of Media– ICS is not limited to voice telephony. Video calling, picture sharing and other media streams can be added or removed from a session at any time. 

Handover to 2G – And finally, the 3GPP ICS working group has also thought about how to hand over the voice portion of a session to a circuit switched bearer when the mobile reaches the limit of the broadband wireless networks. Currently, handovers from LTE are supported to GSM and 1xCDMA (hello Verizon!). Unlike the previous Voice Call Continuity (VCC) specification which requires the handover decision to be made by the mobile, the ICS handover to a circuit switched channel is network initiated and controlled. The advantage of network control is that the device does not have to be attached to two different radio networks simultaneously. This is important since like GSM/UMTS mobiles today, future LTE mobiles will also not be able to connect to two cellular network technologies simultaneously. From my point of view this network centric Single Radio Voice Call Continuity (SR VCC) approach is a major step towards solving the LTE voice gap. I'll describe the details in a future post.

For further information, here are links to the three main ICS specifications:

And for some more general background reading, here are some more resources:

Moving To A 2 SIM Strategy

In the past I have usually used at least one SIM card for voice telephony and a separate one for Internet access. I never liked this approach very much and always looked for ways to combine the two. These days, combined voice and data offers on a single SIM have improved so I've been using my Nokia N95 for voice telephony, Internet access directly form the phone and as a modem for notebook Internet access over the past couple of weeks now. Interestingly enough, it turns out that the combined SIM is not as convenient as I always thought.

There are a number of reasons:

  • When a voice call comes I have the option to remove the cable from the phone or to have my movement restricted by the cable while being on the phone. Both feel uncomfortable as I don't want to loose the Internet connection while I am on the phone but also often don't want to remain in front of the computer.
  • During phone calls, the connection is often handed over from the 3G network to 2G network. This cuts the Internet connection since most GSM networks are still not Dual Transfer Mode (DTM) capable. This can be fixed by locking the phone into 3G only mode. This has the disadvantage, however, that I have to reset the network mode later when I am on the move again as 3G network coverage is still not in all places where 2G coverage can be found.
  • Unlike others, Nokia mobiles still don't charge over the USB cable. Thus, the battery drains very quickly if no power socket is available, which is usually the case at airports and other public places. 

Bluetooth might be an alternative for the USB cable. The power cable would still be required but that can be disconnected easly for a phone call. For now, version 2.x with it's theoretical top speed of around 2-3 MBit/s is still fast enough for most HSPA connections. With HSPA speeds continuously rising, that won't hold for much longer.

Efficiency: LTE vs. HSPA

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.

Establishment of LTE Radio Bearers

Quite a number of whitepapers on the LTE Radio Layer and about the general architecture of LTE can be found these days on the web. A good one for example is the Agilent LTE Air Interface Introduction, about which I have reported previously. What's still missing, however, is a good description of how resources are dynamically assigned in the uplink and downlink direction of the air interface. This process is also referred to as Radio Resource Control (RRC) and has a big impact on how well the available bandwidth can be shared between all active subscribers in the network. The following blog entry aims at shedding some light on this process.

The description below is based on the following documents, which are an ideal source for further background reading:

Idle State

Let's assume the mobile device is already registered and the network has assigned an IP address to it. Further, no data has been exchanged with the network for some time, so the mobile has been put into Idle state. In this state the radio part of the mobile is mostly dormant but periodically performs the following main tasks:

  • Observes the paging channel in case the network needs to notify the device of incoming IP packets.
  • Observes the broadcast channel of the current cell to be informed of configuration changes.
  • Performs radio channel quality measurements on the current cell and neighboring cells. Neighboring cells can be other LTE cells but also UMTS, GSM and CDMA cells. For this purpose, the current cell broadcasts a list of neighboring cells. In case the radio coverage of the current cell becomes inferior to that of another cell, the mobile performs a cell reselection to a different cell.

Then let's assume the user starts the web browser on the mobile device and selects a web page from the bookmarks. This means that the mobile device has to request the establishment of a new radio bearer from the base station. It's important to note at this point that it's only the radio link that needs to be re-established, as an IP address is still assigned to the device. 

The Random Access (TS 36.300, 10.1.5)

The first step in re-establishing radio contact is to initiate a Random Access Procedure on the (uplink) Random Access Channel (RACH). Where in the frequency/time resource grid the RACH is located is known to the mobile via the (downlink) Broadcast Channel (BCH). The random access message itself only consists of 6 bits and the main content is a random 5 bit identity.

If the network receives the message correctly it sends a Random Access Response Message at a time and location on the Physical Downlink Shared Channel (PDSCH) that can be calculated from the time and location the random access message was sent. This message contains the random identity sent by the device, a Cell Radio Network Temporary ID (C-RNTI) which will be used for all further bandwidth assignments, and an initial uplink bandwidth assignment.

The mobile device then uses the bandwidth assignment to send a short (around 80 bits) RRC Connection Request message which includes it's identity which has previously been assigned to it by the core network (or the Non Access Stratum (NAS) in 3GPP talk).This NAS id is required as the base station can only establish a radio bearer with information stored in the access gateway as described below.

Establishment of Radio Bearers

As the mobile device is already known in the core network the following radio bearers are now established automatically:

  • A low priority signaling (message) bearer (SRB1)
  • A high priority signaling (message) bearer (SRB2)
  • A data radio bearer (DRB), i.e. a bearer for IP packets

Part of the bearer establishment procedure are authentication and activation of encryption. The required data for this process is retrieved by the base station (the eNodeB or eNB in 3GPP talk) from the Access Gateway (aGW), or more precisely from the Mobility Management Entity (MME). The MME also delivers all necessary information that is required to configure the data radio bearer, like for example min/max bandwidth, quality of service, etc. 

Setting up a radio connection is a pretty extensive task. For the user, however, the delay caused by these procedures should be as little noticeable as possible. The LTE requirements say that the whole procedure should not take more than 100 milliseconds. It's likely that this can be achieved in practice, as the transmit time interval (TTI) of LTE is 1 millisecond, which means there are enough opportunities to exchange messaging in uplink and downlink within this period to complete the task.

Resource Scheduling

Once the DRB is in place, everything is set up and the mobile then listens on the Physical Downlink Control Channel (PDCCH) for uplink/downlink bandwidth assignments. The PDCCH is broadcast every millisecond (i.e. 1000 times a second) in the first 1-3 symbols out of 14 symbols which are transmitted every millisecond. Figure 24 in the Agilent document visualizes this very nicely.

In downlink direction, resources are scheduled for the device on the PDCCH whenever data arrives from the network. How many Physical Downlink Shared Channel (PDSCH) ressources are scheduled and when mainly depends on the quality of service settings for the user and the current radio conditions.

In uplink direction, the mobile is only allowed to send data on the Physical Uplink Shared Channel (PUSCH) when the network schedules uplink transmission opportunities on the PDCCH. Uplink and downlink bandwidth assignments on the PDCCH are encapsulated in so called Control Channel Elements (CCE's, in case you come across this acronym in the specification documents), which are fixed length containers to simplify the search for the mobile on the PDCCH for its own bandwidth assignments)

Uplink resources are scheduled based on the amount of data in the uplink buffer of the mobile. The mobile device can signal the amount of data waiting to be transmitted in a the MAC header part of uplink packets. QoS and other parameters are of course also used by the base station in the uplink scheduling decision.

HARQ

As transmissions over the air interface are prone to transmission errors due to interference, each packet sent in uplink and downlink direction has to be acknowledged by the other end. This is done by sending Hybrid Automatic Repeat Request (HARQ) acknowledgments or non-acknowledgments on control channels.

In downlink direction, HARQ acks/nacks are for uplink transmissions are sent on the Physical HARQ Indicator Channel (PHICH), which is part of the PDCCH, i.e. they are transmitted in the first 1-3 symbols of each TTI. In uplink direction, HARQ ACK/NACKs are sent on the Physical Uplink Control Channel (PUCCH), which is implicitly scheduled shortly after a downlink transmission. Figure 27 in the Agilent document shows the PUCCH in orange.

CQI and Neighboring Cell Measurements

To be able to optimize downlink transmissions by adapting the modulation and coding scheme (MCS), the mobile device has to send channel quality indications (CQI) on the PUCCH and the PUSCH). In addition, the mobile also collects measurements on neighboring cells and reports them to the base station whenever a threshold is crossed (e.g. a neighboring cell is received better than the current cell).

DRX

With all of this work going on besides sending and receiving data, a discontinuous reception (DRX) mechanism has been designed so the mobile can switch off its transmitter periodically to conserve battery power. The activity and switch-off time can be set by the base station based on the QoS of the connection and current activity of the device. It's interesting to note at this point that the DRX cycle can range from a few milliseconds up to several seconds. More precisely the DRX cycle can be as long as the paging cycle while the mobile does not have a radio bearer. 

Many more details could be added, but I think this description covers the basic procedures for exchanging data of the LTE air interface. Hope you liked it.

Rise and Demise: Wind Italy vs. 3 UK

In my recent travels I have noticed that some wireless network operators have greatly improved their network for Internet access while others have consistently declined. To examples from both ends of the scale:

I haven't used the network of Wind in Italy for notebook access to the Internet a lot in the past anymore since they had no HSPA in their network. Even in the standard 3G mode, connections where slow due high packet loss. Recently, however, they have upgraded their network to HSPA, at least in Rome, and I have since gone back using their prepaid SIM for notebook Internet access. I consistently get around 1 MBit/s in downlink direction (most likely traffic shapped) and 384 kbit/s in uplink direction when sending eMails with file attachments and pictures. Well done Wind!

On the other end of the scale is 3UK. I've bought one of their SIM cards a couple of months ago and during that time, their performance in the UK was ok. These days however, both in the UK and abroad, I consistently get bad throughput and sometimes the connection doesn't work at all. During a week in London last week I got so frustrated with their service that I stopped using it at some point and replaced it with another prepaid SIM. Randomly blocked TCP and UDP ports to keep me from getting eMail and setting up my VPN connection in addition to slow throughput is not acceptable. This week in Rome it's also been pretty much unusable, data rates are just too slow. Well, I guess I will try again in half a year. Not earlier probably, because I don't see a reason to waste 10 pounds to activate the data option just to find out their service is anything but a service…

For alternatives and other countries take a look at the prepaid wireless Internet access Wiki.

Will There Be Enough Capacity for Evolved-EDGE?

In the past I've reported on activities in 3GPP on Evolved EDGE (here and here). Looks like standards are well on their way now and a number of network vendors and terminal manufacturers are working on the implementation.

According to analyst resources, especially China and India could be countries in which operators are interested in the new features, especially in the dual carrier functionality that promises to further increase data rates per device. In these countries, no or only little 3G has been deployed to date so it might well happen that operators in these countries will go directly to LTE, WiMAX and beyond and try to fill the gap in the meantime by evolving their GSM networks.

What I am wondering though is if networks in these countries really have enough capacity to assign timeslots on several carriers to a single mobile device? I would assume their network density and capacity is pretty well adapted to current traffic levels which doesn't leave much room for this. When looking at it from a different perspective the question is if they would be prepared to increase capacity (and thus CAPEX and OPEX) in their networks for the dual carrier feature?

If you have an opinion on this, please consider leaving a comment below.