Similar Pages

Transcript

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. 2  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 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 >> References 23 3  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE basics 4  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE data handling in mobile networks Overview Data performance in today’s mobile networks is highly variable. This is due to a variety of issues, including: How the radio is assigned to different modes and states also has an impact on the device behavior, including: >> T  he use of different radio technologies, e.g. GSM/EDGE, WCDMA/HSPA and LTE >> Power consumption >> The radio channel being shared by many users >> T  he 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. 5  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE >> T  he 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 IDLE CONNECTED Any data ACTIVE IDLE No data 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. 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. 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. 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. 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. 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. Figure 2: GSM/EDGE radio resource states IDLE CONNECTED POWER CONSUMPTION (RELATIVE) ~0.5 SEC PACKET TRANSFER WHEN BUFFER EMPTY TBF KEEP ALIVE IDLE 1-2s INACTIVITY DATA RATE/LOWER LATENCY/RESOURCES ACTIVITY 6  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE <60 MS INACTIVITY WCDMA/HSPA radio state machine can be described according to the illustration below. Figure 3: WCDMA/HSPA radio resource states IDLE POWER CONSUMPTION (RELATIVE) 1 CONNECTED ANY DATA HSPA ~2 s INACTIVITY ~256 BYTE UL ~512 BYTE DL FACH 0.5 ~5-30 m INACTIVITY IDLE ~8-30 s INACTIVITY URA 0.01 ANY DATA TYPICAL TRIGGER THRESHOLDS DATA RATE/LOWER LATENCY/RESOURCES ACTIVITY INACTIVITY 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. 7  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 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. The LTE radio state machine is illustrated by the figure below. Figure 4: LTE radio resource states IDLE CONNECTED ANY DATA SCHEDULED POWER CONSUMPTION (RELATIVE) 1 ANY DATA T1 ~100 ms INACTIVITY SHORT DRX 0.07 T2 ~320 ms INACTIVITY ~10-60 s INACTIVITY 0.015 ANY DATA LONG DRX TYPICAL TRIGGER THRESHOLDS IDLE 0.007 1 0.25 0.03 0.02 LATENCY (RELATIVE) ACTIVITY INACTIVITY 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 8  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 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. 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. Figure 5: Tail energy during web download example HSPA RADIO STATES Example: A web page download 5 ~2 sec Where energy is really needed 4.5 HSPA 3 2.5 STATE THROUGHPUT (MBPS) 4 3.5 8 SECONDS FACH 2 1.5 URA 1 0.5 0 0 5 10 15 20 IDLE 25 TIME (S) STATE DOWNLINK UPLINK 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. 9  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 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. 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. Figure 6: Best performance with current technology in lab GSM/EDGE (2G) WCDMA/HSPA (3G) LTE (4G) Latency 100 ms 25 ms 15 ms 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 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) Latency 15 Uplink throughput 35 600 400 9 6 200 3 0 0 2G GPRS 3G WCDMA/ & EDGE HSPA 4G LTE Worst 10% Downlink throughput 30 12 THROUGHPUT (MBPS) LATENCY (MS) 800 Median 50% THROUGHPUT (MBPS) 1,000 Best 10% 25 20 15 10 5 0 2G GPRS 3G WCDMA/ & EDGE HSPA 4G LTE 2G GPRS 3G WCDMA/ & EDGE HSPA Source: Based on Ericsson’s analysis of Speedtest.net results provided by Ookla (2013) 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 GSM/EDGE (2G) WCDMA/HSPA (3G) LTE (4G) -500 ms 300-2000 ms 200-300 ms Source: Ericsson Smartphone lab 10  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 4G LTE design 11  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE efficient application design The two most important optimization parameters 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. Figure 9: Utilize available throughput Available/used throughput To be avoided 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 12  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE Recommended 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 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 2x overhead 1x overhead 15 s PAYLOAD PAYLOAD OVERHEAD 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. 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. For example, the transfer time for a 75 KB graphic can differ significantly: 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. >> 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 Performance estimates on individual downloads can, however, be tricky: >> For small sized objects, connection establishment  his difference needs to be considered from T a user experience point-of-view: will have a high relative performance impact, so care must be taken to secure proper evaluation >> Multiple simultaneous downloads will share the >> 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 13  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 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. 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. 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. 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. SYN SYN, ACK ACK CLIENT HELLO ACK SERVER HELLO CERTIFICATE... SERVER HELLO DONE ACK ACK KEY CLIENT EXCHANGE CHANGE CIPHER SPEC ACK APPLICATION DATA FIN, ACK FIN, ACK ACK 14  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE SERVER DEVICE Figure 11: Communication to multiple servers 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. 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. Figure 12: TCP buffer impact on transfer Keeps buffers empty until end of data APPLICATION APPLICATION HTTP HTTP TCP RECEIVE BUFFER TCP SEND BUFFER 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 15  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE Keeps buffers full until end of data 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. 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. Figure 13: Impact from using multiple push channels Dedicated push channels KEEP-ALIVES PROXY KEEP-ALIVES NAT/FW KEEP-ALIVES EMAIL SERVER CHAT SERVER VoIP SERVER All bindings are maintained unsynchronized by each application Figure 14: Impact from using multiple push channels Using OS available push channels PROXY NAT/FW One binding – one keep alive 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 16  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE PUSH SERVER EMAIL SERVER CHAT SERVER VoIP SERVER By Google – GCN By Apple – APNS By Microsoft – MPNS 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. 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. Figure 15: Performance comparison emerging vs developed contries , median 50% India Latency 200 Indonesia China Africa Latency (ms) 150 United Kingdom United States 100 50 0 6 Throughput 5 Throughput (Mbps) 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. 4 3 2 1 0 Uplink Downlink Source: Based on Ericsson’s analysis of Speedtest.net results provided by Ookla (2013) 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. >> Is it clearly understood why it behaves like this? 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. Setting up these limited scenarios is not complicated with freely available tools for limiting throughput and increasing latency. What is actually happening on 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. >> What are the most annoying symptoms of this limited performance? 17  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE examples 18  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 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 10 9 HSPA 7 6 STATE THROUGHPUT (MBPS) 8 5 4 FACH 3 2 URA 1 IDLE 1500 0 0 500 1000 TIME (S) DOWNLINK UPLINK STATE 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 0 0 500 550 PRE-FETCH OTHER TRAFFIC 19  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 600 650 TIME (S) 700 750 800 850 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 STREAMING OBSERVED BEHAVIOR 10 9 THROUGHPUT (MBPS) 8 HSPA 7 STATE 6 5 4 FACH 3 2 URA 1 0 0 100 200 300 400 500 600 700 800 IDLE 900 TIME (S) DOWNLINK UPLINK STATE STREAMING WANTED BEHAVIOR Note: unwanted server side throttling in this test 10 9 HSPA 8 7 6 5 4 FACH 3 URA 2 1 0 0 100 200 300 400 500 TIME (S) 600 700 DOWNLINK UPLINK STATE Buffer size, big enough to fit 30-60 seconds viewing 20  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE VIDEO BUFFER Pace at refill, limited by radio/TCP behavior alone, no application level throttling! Radio sleep (s) = Size – low mark – refill Low mark threshold, buffer refill point, small enough to allow substantial radio sleep 800 IDLE 900 STATE THROUGHPUT (MBPS) Burstiness: byte range requests with sleep in between to efficiently handle abandonment, performed at air interface speed 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. Figure 19: Connection handling impacting time to interact Last TCP closes Start establish of 35 TLS sessions Frequent retransmissions due to link contention 50000 Last application data First application data request 25000 0 2.0S 4.0S 6.0S 8.0S 10.0S 12.0S 14.0S 16.0S 18.0S 20.0S 22.0S 0 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 EMAIL TRAFFIC FROM ONE SMARTPHONE VENDOR, MBB OPERATOR 16 EMAIL SERVERS ARE CONTACTED EVERY 15 MIN BETWEEN 8AM AND 8PM 14 12 HOURLY UPDATES DURING THE NIGHT THROUGHPUT (MBPS) 10 8 6 4 2 0 0 2:00 4:00 6:00 8:00 10:00 12:00 14:00 LOCAL TIME 21  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 16:00 18:00 20:00 22:00 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. Figure 21: Comparison between a free and a premium game 161X 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). 35X 26X BATTERY CONSUMPTION NETWORK SIGNALING PREMIUM VERSION 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 FREE VERSION Figure 22: Advertising data for three weather apps 9 8 7 6 5 4 3 2 1 0 APP 1 APP 2 AD DATA (RELATIVE) 22  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE APP 3 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/ericssonmobility-report-november-2013.pdf Smartphone Traffic Impact on Battery and Networks, 2010 http://labs.ericsson.com/blog/smartphone-trafficimpact-on-battery-and-networks Ericsson Mobility Report, June 2013 http://www.ericsson.com/res/docs/2013/ericssonmobility-report-june-2013.pdf Ericsson Innovation Lab http://www.ericsson.com/thecompany/press/ releases/2014/02/1763215 23  ERICSSON - A SMARTPHONE APP DEVELOPER’S GUIDE 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. Ericsson SE-126 25 Stockholm, Sweden Telephone +46 10 719 00 00 www.ericsson.com EAB – 14:012074 Uen © Ericsson AB 2014