A Smartphone App Developer s Guide

A Smartphone

App Developer’s

Guide

Optimizing for mobile networks

Revised April 2014

introduction

Ericsson, the market leader in mobile telecommunications networks and services, is a founding member of Internet.org. The goals of the partnership include the sharing of tools, resources and best practices to enable universally affordable internet. With those goals in mind, Ericsson has prepared this guide to increasing the efficiency of app communications over mobile networks.

The guide outlines optimization considerations for the development of smartphone applications in mobile networks from a radio network perspective. It includes a general description of data handling in today’s mobile networks. Special focus has been given to issues on preserving the user experience in environments with limited connectivity. This is particularly important for the success of an app in emerging markets.

contents

BASICS 4

> Data handling in mobile networks 5

> Overview 5

> Tail energy 9

> Performance of mobile networks 10

DESIGN 11

> Efficient application design 12

> Avoid intermittent small transactions 12

> Scale to available radio technology and performance 13

> TCP connection handling 14

> Push vs. poll and background updates 16

> Lightweight protocols and compression 16

> Caching 16

> Usage growth 16

> Design considerations in emerging markets 17

> Lack of connectivity 17

> Lack of performance 17

> Battery consumption 17

EXAMPLES 18

> Examples of observed behavior 19

> Intermittent small transactions 19

> Network request coordination 19

> Streaming video 20

> Connection handling/data distribution 21

> Usage growth 21

> Data usage in emerging markets 22

CONCLUSIONS 23

data handling in

mobile networks

Data performance in today’s mobile networks is highly variable. This is due to a variety of issues, including:

> The use of different radio technologies,

e.g. GSM/EDGE, WCDMA/HSPA and LTE

> The radio channel being shared by many users

> The radio channel is subject to fluctuating

radio propagation due to signal attenuation and obstructions

This variation can result in throughput rates anywhere between 0 Kbps and many tens of Mbps.

An integral part of all cellular system standards is the handling and sharing of system resources in a fair manner between all the users who are trying to utilize the system. In this context, resources include, among other things, how much power the base station transmits to each specific device, how much power the device should transmit with, how user-plane data should be spread on different frequencies and time slots, and how much data a particular device should be allowed to transmit.

System resource sharing is completely managed by the system infrastructure, and devices request resources by signaling between the device and the network infrastructure through the base station.

Based on these requests, resources are assigned to the device to transmit and receive user data, (IP packets). At any point in time, the device cannot start sending user data without getting or already having a non-expired grant to do so from the system infrastructure. This general system setup can be depicted as in Figure 1; this is a general view for all cellular generations. The specifics of each

generation will be further detailed later in this chapter. What the different cellular standards have in common is the notion of idle and connected modes for the radio. In idle mode, no user-plane data can be exchanged between the device and the system infrastructure. To send/receive data from/to a device it needs to be lifted to the connected mode, either by a request from the device or as a consequence of incoming data from the internet to the device. In addition, the connected mode is comprised of a number of alternative states, not all of which allow the device to send/receive data.

How the radio is assigned to different modes and states also has an impact on the device behavior, including:

> Power consumption

> The interval on which the receiver is listening

for incoming signaling and user-plane data

> How much of the receiver is turned on

> How fast data can be received

Figure 1: Radio resource states

The system settings that govern the state machine of the radio have a high impact on the device battery consumption. There is also an impact on user

experience from state traversals since no state switch is instant. How much time is spent in connected state is, of course, also controlled by the various applications running on the device, and how often they request access to send/receive data.

This notion of idle/connected mode of the radio depicted should not be confused with the device having an IP address or not, since idle/connected is only a physical and logical state for the radio part of the connection. The IP address is assigned to the device on the first request to send data. The IP address, and any TCP connections, will persist when cycling through the different states of the radio. It can only be reset by specific signaling from the system to the device. Furthermore, it is important to understand that an application interacting with the smartphone’s APIs does not see and cannot query any states of the radio. The radio states are merely a consequence of the IP packet behavior for the aggregated set of applications on the device.

IDLE

CONNECTED

No data

IDLE ACTIVE

As a last general but important note on packet transfers in cellular systems, it should be said that the less time that a device spends in the packet transfer states of the state machine, the less battery power the device will consume. It will also utilize fewer system resources, resulting in performance benefits for all system users. Having simplified this description of IP packet transfer in a cellular system, we can now describe some of the differences between the different generations of cellular systems.

For GSM/EDGE there are two radio resource management states: idle mode and packet transfer mode. The device switches to transfer mode for transmitting and receiving data. After data transfer the device is in ‘TBF keep alive’ for one to two seconds, after which it is released to idle mode.

Battery consumption is much higher in packet transfer mode than in idle mode, especially during data transfer (reception and/or transmission). It is significantly lower when TBFs are kept alive, i.e. after data transfer, and lower still in packet idle mode.

It should be noted that transitioning from idle to transfer mode is a costly operation that involves a lot of signaling and introduces a connection delay of approximately 500 ms. This is one of the reasons why it is better to transfer all data in one go, avoiding transitions between idle mode and packet

transfer mode.

Figure 2: GSM/EDGE radio resource states

IDLE

CONNECTED

DATA RATE/LOWER LATENCY/RESOURCES

P O W E R CO N S U M P TIO N ( R E L A TIV E )

One difference between WCDMA/HSPA and the general description of the cellular state machine is the introduction of an intermediate state called FACH, which allows the device to send and receive small amounts of data with less power consumption compared with the high performance HSPA state. Another difference is the introduction of the URA state, which has low power consumption and allows a much faster transition to the packet executing states, compared to a transition from idle mode. In HSPA state the device can reach the highest throughput. In this state, the device will also have the highest battery usage and consume the highest amount of system resources.

State transitions in WCDMA/HSPA are controlled by signaling between the system and the device, and the move between the different states can be determined by inactivity time, various intelligent packet inspection mechanisms, buffer levels, throughput, etc.

Since state transitions within ‘connected mode’ are controlled by signaling, they are inherently slower than for LTE. To mitigate this, tail times are introduced in the states. This means that the device maintains the state beyond the latest packet transfer in anticipation for the next packet transfer. This has a positive impact on user experience but will have a negative effect on battery consumption. This will be further described in the next chapter.

Evolution in WCDMA/HSPA with continuous packet connectivity (CPC) and improved FACH reduces the need for state switching, while preserving battery life. WCDMA/HSPA radio state machine can be described according to the illustration below.

Figure 3: WCDMA/HSPA radio resource states

~8-30 s INACTIVITY ~256 BYTE UL ~512 BYTE DL

IDLE

CONNECTED

DATA RATE/LOWER LATENCY/RESOURCES

P O W E R CO N S U M P TIO N ( R E L A TIV E ) ANY DATA ~5-30 m INACTIVITY

The LTE radio state machine is illustrated by the figure below. Figure 4: LTE radio resource states

Using LTE radio, data can only be transmitted in the scheduled (active) state of the connected mode. After a short period of inactivity, the device switches to a discontinuous reception (DRX) state to save battery power. The DRX feature is essential for the device to be able to save battery. DRX allows the device to periodically turn off its radio transmitter and receiver as well as part of the baseband without going to idle state. At given intervals, the device listens for

activity requests from the network, and if the device is scheduled it ends the sleeping cycle and becomes active. Otherwise, it goes back to sleep. The sleep period differs between short and long DRX. The DRX state durations and transitions are controlled by timers rather than signaling, leading to better switching performance. The timers also ensure that the device and network states are synchronized.

ANY DATA T2 ~320 ms INACTIVITY ~10-60 s INACTIVITY T1 ~100 ms INACTIVITY

IDLE

CONNECTED

0.015 TYPICAL TRIGGER THRESHOLDS

1 0.07 LATENCY (RELATIVE) P O W E R CO N S U M P TIO N ( R E L A TIV E ) ANY DATA

Tail Energy

IP packet arrival is inherently stochastic with an increased probability for the next packet within a short time if there has recently been a packet in either direction. This is the main driver for introducing tail times in the packet transfer states. Tail times have two positive effects:

> An increase in the responsiveness of the system,

as it has a higher likelihood of being in a packet transfer state when the next packet arrives

> A reduced system load from state switching,

as WCDMA/HSPA and GSM/EDGE control state transitions by signaling

The timeout-driven down switch to a low power state creates an inefficiency because a network transaction is followed by a period with no data transmission while remaining in a high power consumption state. The energy used in these inactive periods is usually referred to as tail energy.

The length and level of the tail energy depends on technology and network configurations, i.e. LTE with a few hundreds of milliseconds to WCDMA/HSPA with 10 seconds as a typical network configuration for reaching a low power state (URA/IDLE for WCDMA and Long DRX for LTE). Significant efforts are made to optimize the timers controlling these states to best fit the current traffic profile, as well as research initiatives for various adaptive schemes. To further reduce tail energy WCDMA/HSPA devices can signal that packet transfer is complete, enabling the network to switch the mobile to low power state earlier than the network inactivity timers. The rationale for this is that the device has more input for assessing the packet activity than the network.

The process described above is not visible to the applications. As an application developer, the main concern is to keep the active sessions as few and concentrated as possible, and to let the system deal with the rest.

The illustration below uses a web download as an example, with the red areas being the tail energy.

Of course, the power consumed during packet transfer will depend on the device’s distance from the radio base station due to the amount of output power required. But it is clear from the illustration that far more time is spent in the tail compared to actually transferring bits. Statistics from live networks also clearly indicate that small transfers completely dominate the traffic distribution so that tail energy is far from insignificant.

A small illustrative calculation can be made using the relative energy levels and nominal timer settings from the state illustration for WCDMA/HSPA.

An access taking the state to HSPA and returning to idle, based on timeouts via FACH and to URA, will cost: 1 (power) * 2 (time) + 1/2 (power) * 8 (time) = 6 as compared to remaining in URA

1/100 * 10 = 0.1 which is a factor of 60

If any network accesses can be merged, the pure overhead can be reduced, resulting in significant resource savings.

URA

IDLE HSPA

FACH HSPA RADIO STATES

Example: A web page download

0 0 5 10 15 20 25 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 T HR OU G HP U T (M BP S ) S TAT E TIME (S) DOWNLINK UPLINK 8 SECONDS

Where energy is really needed ~2 sec

Figure 5: Tail energy during web download example

Performance of mobile networks

Successive mobile technologies developed over the years have increasing performance for throughput and latency; there are also continuous enhancements within each standard. Many mobile networks today consist of two or more radio access technologies (GSM/EDGE, WCDMA/HSPA, LTE, Wi-Fi, etc). Software parameters are set to govern a device’s ability to switch between technologies as needed to maintain the best possible connection.The table below shows the best possible performance per technology deployed today.

The latency introduced when switching to packet transfer state is also an important performance aspect. The table below is based on Ericsson Smartphone lab analysis and will be slightly longer in loaded networks.

Figure 8: Time to switch to packet transfer state. Dependent on source state URA or idle

Network connection

establishment -500 ms 300-2000 ms 200-300 ms

GSM/EDGE (2G) WCDMA/HSPA (3G) LTE (4G)

Latency 100 ms 25 ms 15 ms

GSM/EDGE (2G) WCDMA/HSPA (3G) LTE (4G)

Downlink throughput 300 Kbit/s 42 Mbit/s 150 Mbit/s Uplink throughput 210 Kbit/s 5.8 Mbit/s 50 Mbit/s

Source: Ericsson Smartphone lab

Source: Ericsson Smartphone lab

Source: Based on Ericsson’s analysis of Speedtest.net results provided by Ookla (2013) Figure 6: Best performance with current technology in lab

In reality, this performance can rarely be achieved in a real network as capacity is shared by many users. In addition, there are server delays, performance degrades with distance from the base station and other propagation factors. As a reference, the performance variations in real networks is illustrated in Figure 7 by 3 different networks, one per type of technology.

Figure 7: Performance variations per technology, Oct-Nov (2013)

0 200 400 600 800 1,000 2G GPRS

& EDGE 3G WCDMA/HSPA 4G LTE

Latency L A TE NC Y (MS ) 0 3 6 9 12 15 2G GPRS

& EDGE 3G WCDMA/HSPA 4G LTE

Uplink throughput T HR OU G HP U T (M BP S ) 0 5 10 15 20 35 30 25 2G GPRS

& EDGE 3G WCDMA/HSPA 4G LTE

Downlink throughput T HR OU G HP U T (M BP S )

Figure 9: Utilize available throughput

efficient

application design

for performance from the radio network are:

> Minimizing the number of times each device

requests access to the radio channel

> Ensuring that data can be sent/received in the

fastest possible way – limited only by what the radio path can sustain

Following the above two priorities will give the highest possible system capacity and translate into the best user experience for all, and of course, be of immediate value to the particular user/application by getting optimum performance from the radio interface.

Having few, but full throttle, network accesses is also the optimal way to use the device battery resources, since this will minimize the occasions of costly inactivity states where tail energy is wasted. For the actual data transfer, the energy cost is independent of the transfer rate, meaning that per transferred bit, the energy is the same for 100 kbps or 1 Mbps. Since there is a given overhead cost for any transfer, e.g. the tail energy, this results in both network and battery resources being best utilized if the transfers are kept at the highest possible rate and as few transfers as possible.

Avoid intermittent small transactions

As stated previously, all network activity is subject to a fixed overhead, both in terms of battery usage and system utilization caused by timer settings in the radio network as well as signaling between the device and the network. Therefore, it is beneficial to minimize the number of network transactions and instead make each transaction bigger, which will decrease the relative radio overhead. Often the application will consist of multiple ongoing sessions, each with its own network activities. This is the case when ads or analytics set up sessions parallel with user activities from within an application. The network activities caused by these sessions should be coordinated to decrease the overall number of network accesses. Frequently, network activities are spread in the application usage, even if they are not needed from a user experience point-of-view. This could be due to easier application

development, or perhaps because the implications on radio performance were not known to the developer. Taking knowledge of network functionality into account during the development process and accumulating data for bulk network activities will pay off in both battery savings and reductions in network load. Grouping network requests does not need to mean simply retaining data for an aggregated transfer or synchronization of sessions. It could also mean fetching data ahead of time when it is likely to be needed. Such a strategy could have a number of positive effects, including:

> Removing overhead associated with a second fetch

> Increasing user experience since data that has been

anticipated is already available

Available/used throughput

15 s

2x overhead 1x overhead

Scale to available radio technology and performance

It is clear that the performance varies with technology, but also on instantaneous performance. Designing for this variation is a challenge that could impact app architecture and design choice, e.g. decoupling UI from network interaction, priority in loading data, and including or skipping graphics depending on performance.

For example, the transfer time for a 75 KB graphic can differ significantly:

> A 3G scenario with 3 Mbps resulting in an

approximate transmission time of 75,000 * 8 / 3,000,000 = 0.2 seconds

> A 2G scenario at 60 kbps instead results in an

approximate transmission time of 75,000 * 8 / 60,000 = 10 seconds

This difference needs to be considered from a user experience point-of-view:

> Is this resolution needed in this case?

> Is there other information which is more crucial

in order to deliver a high user experience – information which this picture transfer competes with?

> How should transfers and activities be scheduled

in an optimal way?

> How can it be ensured that the user is in control

of his/her experience?

Given the radio technology, current network load and radio propagation conditions, there is no API today that can predict the radio interface performance of the

next request. The native development environment, as opposed to the web environment, will give information on the current radio technology in use. This gives the developer a rough understanding that should be taken advantage of, primarily for 2G connections, in order to scale the user experience. However, the actual radio performance will vary dramatically within each technology.

The next level of adaptation is to keep track of how individual requests are performing. Having a number of slow picture downloads in a row is probably a good indication to retrieve a lower resolution for the next ones or to abandon the pictures altogether with proper feedback to the user.

Performance estimates on individual downloads can, however, be tricky:

> For small sized objects, connection establishment

will have a high relative performance impact, so care must be taken to secure proper evaluation

> Multiple simultaneous downloads will share the

throughput, so once again it is important to make the right comparisons

In order to consistently maximize the user experience, it may be necessary to introduce adaptivity, and not just resort to the lowest common denominator. Of course this also includes keeping in mind that the radio performance may quickly improve and allow the app to go back to a higher resolution again. The above type of adaptivity is often used for streaming video, an example of using recent performance for deciding what resolution to choose for the next segment transfer. On the other hand, fetching data which is not immediately consumed (pre-fetch) can

have a negative impact on the user’s data quota if the data is ultimately not needed. Optimization by grouping network requests may be seen as challenging, but given the radio state machine and its behavior, this constitutes significant potential for improving performance.

Figure 10: Overhead for multiple requests

PAYLOAD PAYLOAD OVERHEAD OVERHEAD

TCP connection handling

TCP reuse is an important aspect of connection handling since there is an overhead in establishing connections. This is especially true for secure connections where the number of roundtrips may go all the way up to three. In a high latency 2G scenario, with content servers placed far from the client, the connection time setup may actually exceed the object transfer time for the smaller objects. Therefore, reusing these whenever possible, and avoiding the establishment overhead for every object, is always a good optimization. However, reusing connections does not imply that all objects should always be fetched in series. It can be inefficient for a number of reasons:

> If a server is slow to respond with some data,

it blocks the trailing requests and transfers

> Non-pipelined requests suffer from roundtrip

delays between each request, and even if pipelined they can suffer head-of-line blocking as above

> TCP slow start may restrict fully utilizing the air interface capacity.

Establishing multiple simultaneous connections is often necessary in order to get the most responsive behavior, at least in a non-HTTP 2.0 world. But, of course, when a transfer is ready on one connection that connection can be reused for a new request, so there is no contradiction between multiple connections and connection reuse.

But what is a reasonable number of parallel connections to use the available throughput as optimally as possible? There is no simple answer. In a low latency, high throughput scenario, current browser and server setups using domain sharding have shown that a lot of parallel connections can increase performance. However, in this guideline, the much more limited scenario where latency can be very high and throughput very limited is also considered. In a limited 2G scenario with throughputs in the range of 50 Kbps, the TCP initial congestion window contains more than 2 seconds worth of data transmission. It is easily understood that having multiple TCP sessions starting at approximately the same time over such a low throughput link will cause the behavior to be far from optimal, with possible timeouts and restarts among the different connections. In such a scenario, a more serialized approach should be considered for optimal performance, prioritizing the requests most crucial for user experience.

Reducing the number of individual requests may also prove beneficial. If possible, from a use-case point-of-view, pre-aggregating data in different ways rather than retrieving each piece individually can be beneficial. This is possible both within one server and between different servers, in order to limit the overhead associated with each request and the challenges with outlining them in time.

Figure 11: Communication to multiple servers

SYN ACK CLIENT HELLO

KEY CLIENT EXCHANGE ACK ACK ACK FIN, ACK ACK FIN, ACK SYN, ACK APPLICATION DATA ACK SERVER HELLO

CHANGE CIPHER SPEC CERTIFICATE... SERVER HELLO DONE

D E V ICE S ER V ER

The above discussion applies especially to a situation in which many small objects need to be transferred. For large data transfers, it is important to make sure that TCP and the application using TCP do not restrict the pace of the data transfer. Remember, the application should always try to minimize the time it

needs to send data. TCP receiver buffers need to be big enough to handle the maximum anticipated rate of the transfer. The application also needs to make sure that the send buffer is continuously filled and the receiver buffer continuously emptied in order not to limit the transfer rate.

Release of TCP connections will cause unnecessary network load and battery usage if done without consideration to other network activities. Many times the release is not coordinated with the actual transmission, causing the radio to come back on in a high power state only for the release signaling. Frequently, it is not known at the end of a transmission whether the connection is needed again quickly. Keeping a connection up for a long duration is dependent on the configuration of the server. A server-initiated release of the connection can be worse than a device-initiated release as the device needs to be paged by the system before the channel can be re-established. There is both a user-experience

cost (due to latency) and a system efficiency cost in re-establishing TCP connections which are needed quickly again.

Connections which are known to not be needed quickly again should be released immediately at the end of transmission. Measures to avoid uncoordinated server-initiated release of connections should be taken whenever possible, assuming the application developer has control over server behavior. Whenever it is possible, the connections should be released in combination with other network activity since the marginal cost of doing so is close to zero.

APPLICATION APPLICATION

HTTP HTTP

TCP RECEIVE

BUFFER TCP SEND BUFFER

Keeps buffers empty until end of data

Keeps buffers full until end

of data

VoIP SERVER CHAT SERVER EMAIL SERVER

All bindings are maintained unsynchronized by each application

PROXY

One binding – one keep alive By Google – GCN By Apple – APNS By Microsoft – MPNS

PROXY

PUSH

SERVER

Figure 13: Impact from using multiple push channels

Dedicated push channels

Figure 14: Impact from using multiple push channels

Using OS available push channels

Lightweight protocols and compression

To maximize responsiveness and to decrease system load, lightweight protocols with minimal overhead per transaction and minimal amount of round trips should be used. Where possible, compression methods should also be used.

Caching

Data caching should be used extensively to avoid sending/receiving the same data more than once. Changing orientation of the device should not imply downloading data again, unless new information such

as graphics with higher resolution are needed. Given the growing memory capabilities of devices, bigger media clips should also be considered for caching.

Usage growth

Avoid network traffic avalanches. As the subscriber base and usage of an application grows, it becomes necessary to make sure that the network traffic is distributed over time. This is needed from the perspective of application servers as well as the radio network system. For example, do not trigger applications to retrieve mail synchronized in time.

Push vs. poll and background updates

From a user-experience point-of-view, background updates are an important way to have fresh data in the application whenever the user decides to enter it. Should these updates happen by means of polling a server or by push? Since all the operating systems include an always-on push mechanism this will in most cases be the preferred method, in comparison with polling for new information. However, the individual application case must always decide on how often things should be pushed, e.g. it is not obvious that each new tweet should be sent in isolation to a device. These should be grouped on a time or size constraint.

The user behavior and expectations for the particular application should be factors in determining update frequency. As an example, iOS7 includes a polling mechanism which tries to account for user behavior and also ensures that applications are coordinated in their effort to minimize activities on the radio channel which can be an alternative to push.

Application-specific push channels should be avoided to the greatest extent possible due to varying NAT/ FW binding policies in operator networks. If deemed necessary, they will have an extra effect on battery consumption when they are not coordinated with other applications.

Design considerations in emerging markets

As we have seen so far, optimizing apps for mobile networks is a very important aspect for user

satisfaction. The challenging performance conditions in many emerging markets accentuate a lot of the issues considered so far. In emerging markets today, the availability of 4G and even 3G cannot be assumed, and most mobile connections use 2G technology. High speed Wi-Fi is also not very widespread. Even with the latest radio technology, in many emerging markets the backhaul links and distances to data centers may negatively impact data throughput and latency. This is illustrated by the figures to the right comparing performance in different regions and countries.

1. Lack of connectivity

Designing applications to perform well in challenging connectivity conditions is important for emerging markets. How this should be approached depends on the type of application under consideration. Are there use-cases that can be supported with intermittent connectivity, and synched when a connection is next available? Possibilities should be explored using caching and pre-fetch of data, and designed not to fail by default when faced with poor or intermittent connectivity.

More use-cases could be possible if the application is constantly refreshed in the background. However, pre-fetching information may be an exception to the general rule, keeping data usage low.

A strategy is needed for each application and

use-case. A user should not be restricted unnecessarily just because a connection to a server is unavailable.

2. Lack of performance

Scaling the application experience to the actual situation should always be a consideration, given that radio performance will always vary. Working with multiple resolutions of pictures is an obvious remedy. As all objects are competing for the same bandwidth, prioritizing objects and getting the fastest possible time-to-screen for one object may imply that things need to be scheduled more serially. Understand your current connectivity situation: “My first few transactions were very slow, so I need to make sure that I get these two objects before requesting this picture. Maybe the user should be notified about the situation.”

Testing the application behavior under limited link conditions should be a vital part of the app development process.

> What are the most annoying symptoms of this

limited performance?

> Is it clearly understood why it behaves like this?

Setting up these limited scenarios is not complicated with freely available tools for limiting throughput and increasing latency. What is actually happening on

Figure 15: Performance comparison emerging vs developed contries , median 50%

the wire? Our experience shows that such a visual examination of the transport layer can be an eye opener, and many are surprised by what they see.

3. Battery consumption

Shortage of electricity, unreliable power distribution, and a relatively high cost per kWh can all be seen as part of everyday life in many emerging markets. These circumstances should be taken into account when designing apps for these markets, which means that minimized device battery consumption should be a key objective for creating a successful app.

The screen consumes a major part of a device’s battery power, and since this is directly related to user interaction this can partly be controlled by the user. Nevertheless, the app design should keep this in mind and avoid unnecessarily long or frequent interactivity sessions, cache user information to speed up interaction, and avoid overly long menu traversals. It is clearly important to ensure only required data is transferred, and that the transfers are properly planned and confined to as few and as fast bursts as possible. By doing this the radio will be active for as few seconds as possible, and the costly tail energy can be kept to a minimum.

Finally, ensure that the user is aware of the

consequences regarding energy usage and is offered options and choices to control settings to optimize power consumption. 0 0 L a te n c y (m s) T h ro u g hpu t ( M b ps ) Latency Throughput Uplink Downlink 50 1 2 3 4 5 6 100 150 200 Indonesia Africa United States India China United Kingdom

Source: Based on Ericsson’s analysis of Speedtest.net results provided by Ookla (2013)

examples of

observed behavior

Intermittent small transactions

When transmitting, transmit it all: group the network requests and avoid intermittent small transactions. The figure below is an audio streaming analysis. It shows songs being downloaded in chunks (red spikes), but uncoordinated intermittent traffic is causing the radio to reconnect many times in between songs being loaded, only to be released again.

Figure 16: Audio streaming

Network request coordination

Network request coordination is exemplified by the background (pre-fetch) feature in iOS7. The pre-fetch is piggy-backed on other network activities to avoid intermittent connections.

Figure 17: iOS7 pre-fetch feature coordinated with other application traffic

URA IDLE HSPA FACH 0 0 500 1000 1500 1 2 3 4 5 6 7 8 9 10 T HR OU G HP U T (M BP S ) S TAT E TIME (S) DOWNLINK UPLINK STATE 0 0 500 550 600 650 700 750 800 850 TIME (S) PRE-FETCH OTHER TRAFFIC

Streaming video

Video streaming can be implemented in many ways. The implementation below causes the radio to be on in a high power state for most of the viewing time. We recommend downloading in chunks, 30-60 seconds of video, with the highest possible throughput. This will enable the device to use its low power radio state.

Figure 18: Video streaming

URA

IDLE HSPA

FACH STREAMING OBSERVED BEHAVIOR

0 0 100 200 300 400 500 600 700 800 900 1 2 3 4 5 6 7 8 9 10 T HR OU G HP U T (M BP S ) S TAT E TIME (S) DOWNLINK UPLINK VI DE O B U FFE R

Buffer size, big enough to fit 30-60 seconds viewing

Radio sleep (s) = Size – low mark – refill

Low mark threshold, buffer refill point, small enough to allow substantial radio sleep Pace at refill, limited by radio/TCP behavior alone, no application level throttling! STATE URA IDLE HSPA FACH STREAMING WANTED BEHAVIOR

0 0 100 200 300 400 500 600 700 800 900 1 2 3 4 5 6 7 8 9 10 T HR OU G HP U T (M BP S ) S TAT E TIME (S) DOWNLINK UPLINK STATE

Burstiness: byte range requests with sleep in between to efficiently handle abandonment, performed at air interface speed

Note: unwanted server side throttling in this test

Connection handling/data distribution

The example below illustrates the need to re-use TCP connections, consider TLS and reduce the number of servers to interact with. The use case is tested on a 2G connection and is a good illustration of how app design impacts user experience. The 35 TLS sessions being set up at the start flood the link, causing lots of re-transmissions. This results in approximately 20 seconds of time to interact for the application.

Usage growth

Below is an illustration of clock-synced email polling. Widespread use of this method would have severe impacts on networks and servers. The illustration was captured in a live mobile network where the email traffic for a device vendor was filtered for analysis. You can clearly see the clock sync effect on the traffic pattern.

Figure 20: Clock sync impact when scaling to many users

0 2.0S 4.0S 6.0S 8.0S 10.0S 12.0S 14.0S 16.0S 18.0S 20.0S 22.0S 0 25000 50000 Start establish of 35 TLS sessions Frequent retransmissions

due to link contention First application data request Last application data Last TCP closes

EMAIL TRAFFIC FROM ONE SMARTPHONE VENDOR, MBB OPERATOR

0 0 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 2 4 6 8 10 12 14 16 T HR OU G HP U T (M BP S ) LOCAL TIME HOURLY UPDATES DURING THE NIGHT

EMAIL SERVERS ARE CONTACTED EVERY

15 MIN BETWEEN 8AM AND 8PM Figure 19: Connection handling impacting time to interact

The amount of data for advertising can also vary significantly between apps. Figure 22 shows the results of testing three popular weather apps. One is using eight times more data than the other two, with frequent updates for advertising. The app downloaded 2.5 MB in data for ads over a 45 minute test, during which the app was only in the foreground (on the device’s display) for 10 minutes.

Data usage in emerging markets

In countries with small bucket plans or high cost for data usage, the use of a content-rich user interface and advertisement as app revenue generation could be costly for the user.

The impact of advertising on free games is illustrated in Figure 21. Whereas the network is only used for game stats and analytics in the premium version, in the free version the user pays significantly more in data usage (and battery consumption).

Figure 22: Advertising data for three weather apps

Figure 21: Comparison between a free and a premium game

BATTERY CONSUMPTION 35X 26X 161X NETWORK

SIGNALING USAGEDATA FREE VERSION PREMIUM VERSION APP 3 APP 2 AD DATA (RELATIVE) APP 1 0 1 2 3 4 5 6 7 8 9

Conclusion

We have reviewed the basics of data handling in mobile networks, explored various issues in optimizing the user’s experience of smartphone apps by utilizing the networks in the most efficient way, and presented a number of examples. An app which is designed without consideration of its impact on the network loses responsiveness and wastes network resources that are shared by all users. In gaining a basic understanding of data handling in mobile networks, app developers are presented with a real opportunity to improve the quality of experience for those who download their apps, as well as others sharing the network.

References

Ericsson Mobility Report, November 2013

http://www.ericsson.com/res/docs/2013/ericsson-mobility-report-november-2013.pdf

Ericsson Mobility Report, June 2013

http://www.ericsson.com/res/docs/2013/ericsson-mobility-report-june-2013.pdf

Smartphone Traffic Impact on Battery and Networks, 2010

http://labs.ericsson.com/blog/smartphone-traffic-impact-on-battery-and-networks

Ericsson Innovation Lab

http://www.ericsson.com/thecompany/press/ releases/2014/02/1763215

Ericsson

Ericsson is a world-leading provider of communications technology and services. We are enabling the Networked Society with efficient real-time solutions that allow us all to study, work and live our lives more freely, in sustainable societies around the world.

Our offering comprises services, software and infrastructure within Information and Communications Technology for telecom operators and other industries. Today 40 percent of the world’s mobile traffic goes through Ericsson networks and we support customers’ networks servicing more than 2.5 billion subscriptions.

We are more than 110,000 people working with customers in more than 180 countries. Founded in 1876, Ericsson is headquartered in Stockholm, Sweden. In 2013 the company’s net sales were SEK 227.4 billion (USD 34.9 billion). Ericsson is listed on NASDAQ OMX, Stockholm and NASDAQ, New York stock exchanges.

The content of this document is subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.