You are here›Blog›Smartphone traffic impact on battery and networks
Smartphone traffic impact on battery and networks
Challenges with smartphone traffic
Everyone enjoys the smartphone revolution - users, developers, network operators, device vendors and network equipment vendors such as Ericsson. However, there are challenges since the network systems have not been optimised for smartphones from start. Until recently, the key optimisation objectives for mobile broadband networks have been peakrate and throughput, which are still important properties. The advent of mass-usage of smartphones, and the related traffic, has shown that also other properties of the 3G radio and networks are important. In particular, the high frequency of data activities, sometimes with moderate volumes of data transferred, has lead to both a high battery drain, and increased the signaling traffic in the system, due to the transitions between the standardised states of the 3G radio.
As for battery, different apps and different usage patterns will load different parts of the device differently. Generally though, the display is a large power consumer when using the device actively, and the 3G radio is a large power consumer for inactive devices (i.e. impacts standby time).
As for the signaling traffic, i.e. messages between the device and the mobile network for mobility and radio resource management, a smartphone user generally generates more signaling per transferred MB than a PC user. With the large number of smartphones, the aggregated effect can be large. However, it should be noted that the impact on the network depends very much on its original dimensioning. Therefore, some networks have seen large impact, whereas in others this has not been noticed.
There are several reasons for this traffic pattern of frequent data activities from smartphones:
- Usage patterns: The user experience of a smartphone, and the multitude of useful applications, encourages the user to often pick it up and do something, even if only for a short timeslot.
- Application behaviour: many applications provides the user with updated information, and are doing regular polling of its servers, often at user-configured time intervals (typical intervals being from 15 min up to several hours). Some applications (e.g. chat) are designed to do polling very often (every minute or even more frequent). Push-enabling applications is a way to avoid regular polling, but it is on the other hand needed to keep a TCP connection open through the network NATs/firewalls, which imply the usage of keep-alive messages. Mobile networks typically timeout TCP connections after 5 to 30 minutes, sometimes shorter or longer, so this is the minimum frequency of keepalives. However, often the keepalives are designed for worst-case, and could (for web-based applications "long polling") be in the order of 30-60 seconds.
Understanding the 3G radio state machine
The radio connection between a single device and the 3G network can be in one of several states:
- High - also referred to as HSPA or Cell_DCH
- Low – also referred to as FACH or Cell_FACH
- Standby – also referred to as URA , URA_PCH or Cell_PCH
The purpose is to balance different properties. In the higher radio states, the initial delay to transmit is shorter, and the throughput is higher. On the other hand, more of the shared resources are reserved in the network, potentially blocking other users. Also, the battery drain is higher in these states (even if there is no actual transmission). Conversely, the lower states (Idle, Standby/URA) are using something called sleep mode to conserve power, by letting radio circuits be active only at periodic occasions. But in these states no data transmission can occur.
Thus, there is a need to change states as required by the traffic to a device. Typically, upswitching to a higher state is triggered by any data packet (state Low/FACH or High/HSPA selected based on data volume), and downswitching is triggered by an Inactivity timer, in several steps. It is this state switching that causes increased signaling from smartphones. In particular the switching up from Idle state involves significant signaling, and significant delay before data can be transmitted. Therefore, the equally power-efficient Standby/URA state is deployed in more and more networks, allowing more state transitions and better battery life for the same amount of signaling.
There is one caveat here, and that is the so called Fast dormancy mechanism implemented by device vendors before any Standby/URA state was deployed. It overrides the initially very long (battery-draining) inactivity timers in many networks, by releasing the connection and going directly to Idle, quickly after data transmission ends. This not only increases the signaling (by increasing the amount of switching between Connected and Idle states), but also makes it impossible to go to the preferred state for battery efficiency (the Standby/URA state). Therefore, 3GPP has specified a formalized fast dormancy feature, which allows the device to trigger battery-savings, but retains control in the network to efficiently use the radio state machine available. As a gapfiller, devices are encouraged to use the pre-standard Fast dormancy selectively, e.g. only in networks with long inactivity timers, and networks are encouraged to configure shorter (battery-efficient) inactivity timers, together with the Standby/URA state.
In the future, networks will gradually be enhanced with new features to improve latency, data rates and power efficiency in different states, and improving transition between states. The fundamental tradeoff between downswitching from a state (increase signaling, increase data traffic latency) or remaining in a state (costs more battery and radio resources) will still remain. Therefore, the developers can gain, today and in the future, by designing application traffic optimized for the 3G radio.
Shaping application traffic
Based on understanding the 3G radio state machine, the following general principles could be proposed:
- Minimize chattiness of application traffic
- Optimize background traffic
- Small & infrequent keepalives
- When transmitting – transmit it all
This will allow the radio to stay longer times in battery-efficient states, at the same time minimizing state transitions (signaling & delay).
Below we briefly discuss a few examples.
Chat application, bad pattern example:
- Polling server every 1 minute
Improvement: longer intervals or even better use a push connection
- Sets up a new TCP at every request
Improvement: maintain the TCP, avoiding unnecessary TCP-related overhead
- Unclean closing of TCP with spurious TCP reset
Improvement: if closing TCP, do it cleanly, avoiding a spurious TCP reset, which brings up the radio again
Background polling applications:
Especially for a multi-tasking OS, the developer has to take responsibility for not screwing up. Sony Ericsson had a nice blog post outlining some advice for Android applications polling servers in the background:
- Synchronize polls with other apps
- use alarmManager with setInexactRepeating and/or RTC (rather than RTC_WAKEUP)
- Execute polls as short as possible
- single requests, short server responses, multi-queries, gzip
- Manage HTTP connections
- clean closing of connection when ready
- Stop services - wake up with intents
Push enable applications:
Using a persistent push connection is more efficient when high immediacy is required, and when frequency of new data is not too high. Furthermore, by using the push service offered by the platform (such as cloud2device messaging in Android, or Apple Push Notification service), multiple applications share the same persistent TCP connection, which minimizes the amount of keepalives needed.
Small keepalive messages
Not only is it good to reduce the frequency of keepalive messages (such as for keeping a TCP connection open). It is also beneficial to minimize the size of messages. If the size is below a certain threshold, the message will be sent in the Low/FACH state rather than the High/HSPA state. And even below the threshold, there is a gain in minimizing the size. Today, typical thresholds are 512 B for messages to the device, and 256 B from the device, although variations can be seen. Note that these sizes include TCP/IP headers.
Optimizing video streaming
For todays video services using HTTP progressive download, there is a certain interest to do throttling of the transmission rate. This could be done on the server side, in the client or by a proxy in between. This is motivated by the fact that most video clips are only viewed partly, thus avoiding transmitting data packets that are not consumed.
However, this leads to a situation where a device will be in the High/HSPA state almost constantly, thus wasting battery. Also, the radio resources are utilized more efficiently when there is more data in the buffers. Thus, from radio and battery efficiency point of view, it is better to download the data at peak rate, and then switch off the radios and save power in Standby/URA state. There is of course a trade off with the fact that most videos are viewed partly. An adaptive HTTP streaming solution, where data is transmitted in segments that are long enough to sleep in between, is probably a good idea.
The smartphone success is enjoyed by the users, the mobile industry and the developers. However, the chatty pattern of smartphone traffic poses new challenges, primarily for the device battery, but also for signaling between devices and the mobile network.
The measures to meet these challenges are in the hands of different parties:
- Operators and infrastructure vendors:
Dimensioning and tuning of mobile networks, and deploying features for optimizing battery and signaling.
E.g. Standby/URA state and short Inactivity timers.
- Device vendors:
Device behaviour in cooperation with networks (managing fast dormancy)
Impact application traffic to be radio- and batteryefficient
o Minimize chattiness of traffic
o Optimize background traffic
o Small & infrequent keepalives
o When transmitting – transmit it all
Check out the slides from my presentation on this topic at Droidcon 2010.
Looking forward to your comments.
-- Per Willars
Coding for Battery life, Google IO 2009.