Signals Research - Smart Phones and A 3G Network May 2010

SmartphoneS and a 3G network
Reducing the impact of smaRtphonegeneRated signaling tRaffic while incReasing the batteRy life of the phone thRough the use of netwoRk optimization techniques
May 2010
Prepared by Signals Research Group, LLC Paper developed for Nokia Siemens Networks
www.signalsresearch.com
On behalf of Nokia Siemens Networks, Signals Research Group, LLC conducted concurrent network tests in two 3G networks in order to quantify the impact of intelligent network optimization through the use of Cell_PCH and the appropriate network timer settings which release the handset from its current connection state. As the sole authors of this paper, we stand fully behind the highly objective results which we collected and then subsequently analyzed using a sophisticated drive test tool. In addition to providing consulting services on wireless-related topics, Signals Research Group is the publisher of the Signals Ahead research newsletter and The Dollars and Sense of Broadband Wireless, the first independent in-depth study of next-generation broadband wireless network economics (www.signalsresearch.com).
smartphones and a 3g network

Reducing the impact of smartphone-generated signaling traffic while increasing the battery life of the phone through the use of network optimization techniques
Table of Contents
1. Executive Summary
2. Introduction 11 3. Technical Background 12 3.1. RRC Connection States 12 3.2. Smartphone-generated Signaling in a 3G Network 14 3.3. Keep Alive Messages 14 3.4. Fast Dormancy 15 3.5. Tracing the Root Cause of 3G Network Congestion 15 4. Detailed Results 17 4.1. Test Methodology 17 4.2. Baseline Measurements 18 4.3. Keep Alive Messages 22 4.4. Chatting with a friend using Yahoo IM 25 4.5. Keeping Track of a Friend with the FindMe Application 29 4.6. Downloading Large Files 31 4.7. Web Browsing/Internet Surfing 33 4.8. Sending and Receiving Email 37 4.9. Using Nokia Maps to Find a Museum in Old Montreal 39 4.10. Watching a YouTube Video 41 4.11 Making a Skype Video Call 42 4.12. Receiving an Incoming Voice Call 43 5. Conclusions 47 6. Appendix 1 Additional Results 48
May 2010
Page 2

index of tables table 1. Summary of Test Results10 table 2. The Impact of Keep Alive Messages on Battery Life 24 table 3. Detailed Log File of Signaling Messages during an IM Session TELUS Network (Test Scenario 4) 50 table 4. Detailed Log File of Signaling Messages during an IM Session Part One Rogers Wireless Network (Test Scenario 4) 51 table 5. Detailed Log File of Signaling Messages during an IM Session Part One Rogers Wireless Network (Test Scenario 4) 52
index of figures figure 1. RRC Connection States 13 figure 2. Nokia N97 in the Idle State TELUS Network 18 figure 3. Nokia N97 in the Idle State Rogers Wireless Network 19 figure 4. Current Consumption with the Nokia N97 Handsets in the Idle State no backlight 20 figure 5. Current Consumption with the Nokia N97 Handsets in the Idle State backlight turned on 21 figure 6. RRC State Transitions due to Keep Alive Messages 22 figure 7. Current Requirements due to Keep Alive Messages 23 figure 8. RRC State Transition Changes due to Yahoo IM Test Scenario 4 25 figure 9. RRC State Transition Changes due to Yahoo IM Test Scenario 7 27 figure 10. The Impact of an Instant Messaging Session on Battery Life Test Scenario 7 28 figure 11. RRC State Transition Changes due to FindMe Test Scenario 2 29 figure 12. The Impact of the FindMe Application on Battery Life Test Scenario 2 30 figure 13. RRC State Transition Changes due to Downloading Large Files TELUS Network (Test Scenario 3) 31 figure 14. RRC State Transition Changes due to Downloading Large Files Rogers Wireless Network (Test Scenario 3) 32 figure 15. RRC State Transition Changes due to Web Browsing Test Scenario 2 33 figure 16. The Impact of Web Browsing on Battery Life Test Scenario 2 34 figure 17. RRC State Transition Changes due to Web Browsing Test Scenario 3 35 figure 18. The Impact of Web Browsing on Battery Life Test Scenario 3 36 figure 19. RRC State Transition Changes due to Sending and Receiving Email TELUS Network (Test Scenario 3) 37 figure 20. RRC State Transition Changes due to Sending and Receiving Email Rogers Wireless Network (Test Scenario 3) 38 figure 21. RRC State Transition Changes due to Nokia Maps Test Scenario 1 39
May 2010 Page 3

figure 22. RRC State Transition Changes due to Watching a YouTube Video 41 figure 23. RRC State Transition Changes due to a Skype Video Call Test Scenario 1 42 figure 24. RRC State Transition Changes due to an Incoming Voice Call TELUS Network 43 figure 25. The Impact of an Incoming Phone Call on Battery Life TELUS Network 44 figure 26. RRC State Transition Changes due to an Incoming Voice Call Rogers Wireless Network 45 figure 27. The Impact of an Incoming Phone Call on Battery Life Rogers Wireless Network 46 figure 28. RRC State Transition Changes due to Yahoo IM Test Scenario 6 48 figure 29. The Impact of an Instant Messaging Session on Battery Life Test Scenario 6 49 figure 30. RRC State Transition Changes due to Web Browsing Test Scenario 1 54 figure 31. The Impact of Web Browsing on Battery Life Test Scenario 1 55 figure 32. RRC State Transition Changes - Bloomberg 56 figure 33. RRC State Transition Changes due to Downloading Large Files Rogers Wireless Network (Test Scenario 1) 57 figure 34. RRC State Transition Changes due to Downloading Large Files TELUS Network (Test Scenario 1) 58 figure 35. RRC State Transition Changes due to a Skype Video Call Test Scenario 2 59 figure 36. RRC State Transition Changes due to Sending and Receiving Email Rogers Wireless Network (Test Scenario 1) 60 figure 37. RRC State Transition Changes due to Sending and Receiving Email Rogers Wireless Network (Test Scenario 1) 61
May 2010
Page 4

1. Executive Summary
Over the last several months, Signals Research Group, LLC (SRG) has been looking at the impact of smartphones on 3G network congestion with a particular focus on the signaling traffic that the smartphones generate. Although perhaps surprising to some industry followers, it isnt the data traffic being generated by smartphones that is creating network congestion in todays 3G networks, but the underlying signaling traffic due to the chattiness of various applications, the popularity of social networking services, and the typical user behavior patterns associated with normal smartphone usage. In addition to impacting the performance of the 3G network, the excessive signaling traffic has a direct impact on the expected life of the smartphone battery. In this whitepaper we present results from concurrent testing that was done in two different 3G networks during the week of April 19, 2010. By leveraging a sophisticated network drive test solution we were able to monitor the signaling traffic that a smartphone generates while using popular applications, such as Instant Messaging (IM), web browsing, tracking the location of a friend, watching a YouTube video, and downloading files via a web browser or through an email application. And since we were simultaneously conducting the tests in two different 3G networks, one which was supplied by Nokia Siemens Networks, we were able to determine if an operator and its infrastructure partner can limit the amount of signaling traffic that is being generated while not decreasing the life of the battery, and frequently extending the life of the battery, through features that the vendor supports as well as by other network optimization techniques that we describe in this whitepaper. Key conclusions and observations discussed in this whitepaper include the following:
3G network congestion is due largely to the high amount of smartphone-generated signaling traffic which is fully utilizing the resources of central network elements, thus preventing them from coping with the data traffic. Network congestion, when it exists, generally encompasses entire cities or markets even though high data usage is concentrated among a very small percentage of an operators installed base of subscribers. It is, therefore, highly unlikely that a small percentage of subscribers can bring down entire networks unless the chokepoint in the network is centrally located, thus impacting the entire network. Network elements, such as the RNC (Radio Network Controller) and SGSN (Serving GPRS Support Node), are two central nodes which must process the data traffic (user plane) and the signaling traffic (control plane). If one of these network elements becomes overburdened with processing signaling traffic it would have a subsequent impact on its ability to support the data traffic and intelligently assign network resources, thus impacting data throughput, slowing the network response time, and degrading the quality and reliability of the voice network. Through the course of prior research that we conducted as part of our Signals Ahead research newsletter, we heard from numerous operators and vendors how the amount of signaling traffic in their network was far outpacing the growth of data traffic, which in itself is growing
May 2010
Page 5

at exponential rates. And it is this unexpected level of signaling traffic that is creating congestion in todays 3G networks. Simply adding more capacity for data traffic (e.g., increased backhaul or deploying another radio carrier) will not solve the problem.
Some of the most popular smartphone applications are also some of the greatest generators of signaling traffic. Social networking applications, in which friends stay connected with each other for extended periods of time, inherently involve frequent back and forth messages or status updates. Instant messaging services, such as Yahoo IM and Skype, and other popular services, such as Facebook or various friend tracker applications, are just some of the examples while if someone is connected it wouldnt be uncommon for him or her to simultaneously leverage multiple social networking applications. These applications frequently generate very little meaningful data a typical IM consists of only 1-2kB of data but each time a message or status update is sent or received it generates approximately as much signaling traffic as is required to set up and tear down a voice call or a more extensive data session. Even more problematic, a typical IM session may consist of several back and forth responses, potentially involving a group of friends, thus creating a multiplicative effect from a signaling perspective. No one would think twice about sending and receiving several IMs with friends during an IM session that may only last a few minutes. Conversely, even the most frequent cell phone user would have a hard time placing as many voice calls during the same time period. In the Detailed Results chapter of this whitepaper we provide results which demonstrate the amount of signaling traffic generated during a typical IM session. Although the exact number of signaling messages is a function of several factors, including the number and frequency of IMs sent/received, our results indicate that IM can be a bigger offender when it comes to generating signaling traffic than a voice call over a given time period. This phenomenon is due to the continuous setting up and tearing down of the connection when each message is sent or received. From an operators perspective the issue is even more problematic since with very little data being sent and with the growing popularity of flat rate data plans, the operator is not able to charge an appropriate usage fee to offset the signaling load on its network. Social networking applications also generate so-called keep alive messages, which provide status updates of connected friends as they occur. Likewise, phones can send periodic messages for the purpose of maintaining an IP address or keeping a port open, such as what might be used by a firewall or an HTTP server. The amount of data sent during each message may be quite small (~150bytes) and the connection time may be quite short (6-7 seconds), but the number of signaling messages required to set up and tear down the session is no different than what is required for any other data session while the number of messages is largely on par with the number of messages required to set up and tear down a voice call. Since these keep alive messages occur any time the application is active a likely situation since most social networking applications launch when the device is turned on this means that these messages are being generated twenty-four hours a day and generally without the knowledge of the user.
May 2010
Page 6

Keep alive messages can also have a material impact on the expected life of the battery.
Since these keep alive messages bring the handset to a connected state called Cell_DCH, where the current requirements for the radio portion of the handset are the highest (>200mA) from the Idle state where the current requirements are the lowest (~5mA), there is an obvious impact on the battery life of the smartphone. Although a single message only has a trivial impact on the battery life, the collective sum of their impact over a 24 hour period can be substantial. In the Detailed Results chapter we demonstrate that over the course of an eight hour period some applications generate enough keep alive messages to consume as much energy as required to keep the backlight turned on a smartphone for a full hour. Most consumers appreciate the importance of preserving battery life and take appropriate measures to limit the amount of time that the backlight remains lit. And if asked, very few consumers would be willing to leave their backlight turned on for a full sixty minutes before heading out of the home in the morning. Yet these keep alive messages are having a similar effect on the battery life, even when the phone is seemingly not being used and resting on a desk or stored safely in ones hip pocket.
An
operator that has implemented Cell_PCH and selected appropriate network inactivity timer settings is able to significantly reduce the amount of signaling traffic in its network while increasing the expected lifetime of the battery. When conducting our network tests, we had the opportunity to use two different 3G networks in order to measure the amount of signaling traffic that we were generating under largely identical circumstances and usage scenarios. In one network, the operator (NSN supplied) had implemented Cell_PCH and selected appropriate network inactivity timer settings to correspond with the Cell_PCH feature. As we discuss later in this whitepaper, a lot of the smartphonegenerated signaling traffic is due to the various Radio Resource Control (RRC) state transition changes that take place when a handset needs to connect to the network in order to send or receive data, only to disconnect shortly thereafter, or after it has stopped sending or receiving the data. In theory, these optimization techniques can reduce the number of state transitions that take place, in particular those state transition changes that generate the most signaling traffic.
Based on our test results, we conclude that the combination of Cell_PCH and the selection of appropriate T1, T2 and T3 timer settings can significantly reduce the amount of signaling traffic while increasing the life of the battery. The exact benefit is difficult to quantify since it depends on the usage scenario, but we observed as much as a 65% reduction in the amount of signaling traffic, after taking into consideration the reduction in signaling traffic which took place within the network, and thus not captured by the test equipment in our handset. Although these savings were not universal across all applications and usage scenarios, these results did occur during normal usage scenarios involving IM (signaling reduction) and web surfing (power savings), as examples. In the case of IM, the reduction in the amount of signaling traffic, which ranged from 21% to 65%, was due to the combined use of Cell_PCH
May 2010 Page 7

when the handset was inactive and Cell_FACH when the handset was sending and/or receiving data. Conversely, the other handset returned to the Idle state during each period of inactivity since Cell_PCH was not implemented in the network, thus when the handset returned to Cell_DCH when it needed to send/receive data it generated a large amount of signaling traffic. Said another way, far more signaling messages are inherently required for a handset to move from the Idle state to the Cell_DCH state than are required to move from Cell_PCH to Cell_FACH. We explain these states and the definition of the three network inactivity timer settings in more detail in Chapter 3 of this whitepaper. We also observed as much as a 27% reduction in current consumption in some of the test scenarios. The reduction in current consumption was due to two factors. First, with the use of Cell_PCH the operator could use more aggressive timer settings, thus more quickly returning the handset to a lower connection state where the current requirements are lower. This phenomenon was most prevalent during web browsing where the handset in the network using Cell_PCH fairly consistently exited those connection states which have the greatest impact on current consumption before the other handset in the non-Cell_PCH network. Second, the handset in the network using Cell_PCH was also able to use Cell_FACH (versus Cell_DCH) to send and receive IMs. By making use of CELL_FACH the handset required nearly 50% less current than the handset which used the CELL_DCH state to send/receive IMs. With other applications, such as watching a YouTube video and downloading large files, which involved very few state transitions and long periods of connectivity during which time large amounts of data were transferred, the savings was less dramatic, and at the extreme the savings was negligible.
The
wireless industry, including operators, infrastructure suppliers, handset manufacturers, and application developers, needs to work together to address these challenges. Although one obvious solution to the problem of smartphone-generated signaling traffic is for operators to implement Cell_PCH not necessarily an easy step if the infrastructure supplier does not support the feature there are other appropriate steps that the industry needs to consider as well. First, handset manufacturers need to understand the impact that their design decisions have on the 3G network. Battery-saving techniques, such as fast dormancy, may go a long ways toward increasing the life of the battery, but if not intelligently implemented, these techniques could result in a large number of unnecessary signaling messages. There is definitely a tradeoff between having a smartphone with a longer battery life and its ability to minimize the amount of signaling traffic that it generates. It is also generally in the best interest of the handset manufacturer to maximize its battery life since consumers judge a handset based on how long the battery lasts and not on how much signaling traffic it generates. Mobile operators, on the other hand, are another matter. They have the ability to accept or reject a smartphone based on the impact that the smartphone will have on its network while
May 2010
Page 8

they can work with the handset manufacturer to help them make intelligent decisions about how the handset behaves without completely sacrificing the life of the battery. Likewise, application developers and social networking providers need to understand that what works well in the wired Internet can create problems when it is applied to a wireless environment. Status updates, which are delivered via keep alive messages are a key part of any social networking service, but they do not necessarily need to be provided on a minute by minute basis. Since first examining this problem at the beginning of the year we have observed at least one application that has seemingly incorporated changes to its service, which have resulted in a significant reduction in the number of messages that it generates over an extended period of time. It is now up to the rest of the industry to follow. Table 1 provides a summary of the results from the tests. A detailed explanation of the results and the test methodology are included within the whitepaper. However, in summary the number of observed signaling messages reflects the data we captured on the smartphones with our drive test tool (exclusive of handover-related messages) and the number of unobserved signaling messages includes those messages which occurred within the network (between the RNC and Node B or between the RNC and SGSN) for the observed state transitions that each phone went through during the test scenario. The reduced amount of current consumption is due to the smartphone in the NSN network spending less time in those RRC states which draw the most current from the smartphone. This phenomenon is due to the optimized timer settings that can be applied when Cell_PCH is also implemented in the network while in some cases the smartphone in the NSN supplied network was even able to significantly reduce or completely avoid using those RRC states which require the most current to maintain the connection. The same could not be said for the smartphone operating in the other network, even though the test scenario was identical. In many test scenarios that involved long connection times and infrequent RRC state transitions we did not record the current consumption since we felt the long time spent in the active connected state (DCH) would mask the underlying benefits of using Cell_PCH.
May 2010
Page 9

table 1. summary of test Results

Application No. of Observed Signaling Messages Rogers Wireless 0 0 40-45 Est. No. of Unobserved Signaling Messages TELUS (NSN) 0 0 2-20 Rogers Wireless 0 0 20 Average Current Consumption (mA) TELUS (NSN) 43 275 260 Rogers Wireless 35 268 260 Message Count Comparison (%) Current Consumption Comparison (%)
TELUS (NSN) Idle state (no application running) Test Scenario 1 (no backlight) Test Scenario 2 (backlight) fring (keep alive messages) Test Scenario 1 (per message) Yahoo IM Test Scenario 1 Test Scenario 2 Test Scenario 3 Test Scenario 4 Test Scenario 5 Test Scenario 6 Test Scenario 7 FindMe Test Scenario 1 Test Scenario 2 Downloading Large Files Test Scenario 1 Test Scenario 2 Test Scenario 3 Web Browsing Test Scenario 1 Test Scenario 2 Test Scenario 3 Sending and Receiving Email Test Scenario 1 Test Scenario 2 Nokia Maps Test Scenario 1 Test Scenario 2 Watching a YouTube Video Test Scenario 1 Skype Video Call Test Scenario 1 Test Scenario 2 Bloomberg Test Scenario 1 Test Scenario 11 123 44 105 100 107 138 134 55 73 337 286 402 129 121 153 211 199 128 123 138 306 220 211 208 40-50 0 0
N.M. N.M. N.M.
N.M. N.M. N.M.
248 179 118 517 289 260 294 299 318 180 108 182 284 339 408 91 88 160 246 107 109 91 180 62
22 20 18 28 32 26 30 56 58 46 38 48 58 64 96 40 44 32 26 34 32 36 20 20
180 120 80 280 160 140 174 160 200 68 40 90 164 210 234 40 60 60 110 50 60 40 40 20
329 329 298
399 451 342
-65% -52% -21% -58% -44% -41% -49% -42%
-18% -27% -13% -22% -12% -14% -16% -
172 361 350 320 62 -
221
-50% -29% 7% -26%
412 408 383
-12% -36% -22% -27% -21% -23% -55% -10% -19% 4%
108
-35% -22%
Receiving an Incoming Phone Call
1 Results influenced by more paging channel messages on the Rogers Network (there was a longer period of time before the phone was answered) In theory, for this particular test scenario the results should be identical. Source: Signals Research Group, LLC
May 2010
Page 10

2. Introduction
In January 2010, Signals Research Group, LLC (SRG) published a report as part of its Signals Ahead subscription-based research service which looked at the presence of smartphone-generated signaling traffic and its impact on a 3G network (SA 012810, The Trouble with Twitters). That report leveraged countless interviews with operators and many of the leading infrastructure vendors, handset manufacturers, and chipset suppliers in order to document the challenges facing 3G operators when their networks are burdened by smartphones, which generate a disproportionate amount of signaling traffic. This study is a natural follow-on to a published report that we did as part of our subscription-based Signals ahead research service with the test methodology and many of the test scenarios used in this study largely reflective of that first initiative. As part of the research that went into the report, we collaborated with Anite who provided us with access to two smartphones, complete with the companys network drive test tool (Anite Nemo Handy) in order to document the presence of the all-too-frequent signaling messages while using popular smartphone applications and social networking services. Those tests, which largely replicate the tests used in this study, were limited to a single operators network so no attempt was made to analyze how different operators and their infrastructure provider partners deal with these challenges. After publishing the Signals Ahead report we have heard countless new stories from both operators and vendors pertaining to this topic. We were also asked by Nokia Siemens Networks (NSN) to conduct a follow-on commissioned study to determine how much influence an operator and its infrastructure provider partner have on reducing the amount of signaling traffic. To be specific, we were asked to document the relative impact of a 3G network that has implemented Cell_PCH, along with selecting appropriate network timer settings (e.g., T1, T2 and T3), on both smartphone-generated signaling traffic and the battery life of the smartphone versus a 3G network that has not implemented Cell_PCH and which is using timer settings that are more appropriate for a network that doesnt support the Cell_PCH feature. We conducted these tests in Montreal, Canada during the week of April 19th, 2010 using the TELUS HSPA network (NSN supplied) and the Rogers Wireless HSPA network. Other than providing logistical support, including access to the Anite Nemo Handy drive test tool and the Anite Analyze post-processing tool, as well as two local SIM cards and answers for a few technical questions which came up during the course of our study, NSN had no involvement in the data collection and the analysis of the results. That responsibility relied solely on SRG. Chapter 3 contains some technical background information which highlights why smartphonegenerated signaling is a problem in todays 3G networks and it explains some of the technical terms which are used in this report. Chapter 4 provides the test results for many of the test scenarios that we analyzed and it includes a discussion of our test methodology. Chapter 5 provides some concluding remarks and Appendix 1 includes some supplementary test results which we did not include in the main section of this paper, but which are being included for completeness sake.
May 2010
Page 11

3. Technical Background
In order to appreciate the results contained in the next chapter, it is important to first have a good understanding of how a smartphone, or for that matter any phone, behaves in a 3G network, as well as why smartphone-generated signaling is so problematic.
3.1. RRC Connection States

There are four primary RRC (Radio Resource Control) states in a 3G network: Idle, Cell_PCH, Cell_FACH and Cell_DCH. Of these four states, the last three states indicate various levels of being connected to the network, albeit the definition of being connected varies widely between the three states. As we will point out in this section, when a device is connected to the network it is generally consuming at least some network resources while transitioning between the various RRC states can generate a little or a lot of signaling traffic. Finally, the RRC state has an impact on the battery life with some states requiring considerably more current consumption than other states. Idle. When in Idle mode the mobile phone is basically dormant and not communicating with the network although it does listen for certain broadcast messages. In this state the radio portion of the phone isnt consuming any network resources and it consumes the least amount of power, or in the range of only 5mA. Cell_PCH. In Cell_PCH (Cell Paging Channel) the network (Radio Network Controller or RNC) knows where the phone is located in the network, but this basic knowledge only has a minimal requirement for RNC resources. The mobile phone monitors the broadcast channel for critical information but since this channel is shared by all mobile devices, the inclusion of an additional mobile phone in Cell_PCH state really doesnt have any impact on the network. URA_PCH is very similar to Cell_PCH, although to the best of our knowledge vendors have not implemented it in their solutions. For purposes of this study readers should consider the two states largely equivalent. Like the Idle state, the current consumption is very modest, or in the range of only 5mA. Cell_FACH. In Cell_FACH (Cell Forward Access Channel) the mobile phone is communicating with the network via a shared channel and the network (RNC) knows where the mobile phone is located, thus the mobile phone is consuming network resources both in terms of air interface capacity as well as with respect to RNC processing power (more on this in a bit). In the current implementation of HSPA, small bits of data can be transmitted while in the Cell_ FACH state at a relatively low data rate, or on the order of up to 64kbps in the downlink and 8-16kbps in the uplink. Another critical feature of Cell_FACH is that in this state the mobile phone shares the forward and uplink access channels with other mobile devices, which also means that the maximum amount of data that can be transmitted over Cell_FACH depends on the overall loading of the common channels. The mobile phone power consumption is higher than it is in Idle or Cell_PCH states, or more than 100mA. Cell_DCH. As the name implies, in Cell_DCH (Cell Dedicated Channel) the mobile phone is allocated a dedicated transport channel in the downlink and in the uplink along with a requisite
May 2010 Page 12

DCH/HSPA >200mA*
There are also three inactivity timers that are used to determine when a handset or smartphone <100ms should move to a lower state following a specified period of inactivity. The T1 timer refers to the period of inactivity within the Cell_DCH state before the 3G device is sent to a lower PCH state. The T2 timer is associated with the Cell_FACH state and it is used in a similar fashion <5mA* for determining how long the 3G device should remain in the Cell_FACH state without any activity. Finally, the T3 timer determines how long the handset should remain in Cell_PCH before returning to the Idle state.
IDLE Figure 1 illustrates the aforementioned RRC connection states, their associated current require<5mA* ments, and the recommended timer settings as defined by Nokia Siemens Networks. These recommendations assume the use of Cell_PCH. *Terminal energy consumption
figure 1. RRc connection states

DCH/HSPA >200mA* <500ms 1-3 s high signaling effort FACH >100mA* <100ms PCH <5mA* Set T3 to >20min Set T2 to <5s Set T1 to <5s
1-3 s high signaling effort
number of physical channels, depending on the required bandwidth. When a mobile phone is <500ms in Cell_DCH it is consuming the most network resources, including both RNC processing and air interface resources, while the drain on the battery is also at its highest level, or more than FACH 200mA. >100mA*
IDLE <5mA*
*Terminal energy consumption

Source: Nokia
May 2010
Page 13

While up to 28 signaling messages are required for a 3G device to transition from Idle to Cell_DCH, only 7 signaling messages are required to go from Cell_PCH to Cell_DCH, with only 2 signaling messages when transitioning from Cell_PCH to Cell_FaCH.
The connection states and the associated timer settings are important since each time a mobile phone moves between the various RRC states it generates signaling traffic, while moving across several RRC states generates more signaling traffic than moving between two adjacent states. For example, according to the 3GPP standard there are 24-28 signaling messages, including messages that extend back into the core network, required for a mobile phone to transition from Idle to Cell_DCH. Conversely, only 7 signaling messages are required to go from Cell_PCH to Cell_DCH and only 2 signaling messages required to go from Cell_PCH to Cell_FACH. Thus, one way to reduce the amount of signaling traffic would be to use very long timer settings, thus keeping the 3G mobile phone stuck in its current RRC state. The impact on the battery life, however, would be catastrophic, especially when dealing with the T1 and T2 timer settings. Instead, a logical approach would be to use timer settings which take into consideration the associated impact on the battery life for T1 and T2 timer settings that are too long as well as the impact on the amount network signaling traffic if the timer settings are too short. Obviously, the use of Cell_PCH is an important part of this process since from a power consumption perspective it is no different than the Idle state while from a signaling perspective the number of signaling messages required to return to Cell_FACH or Cell_DCH is greatly reduced.
3.2. Smartphone-generated Signaling in a 3G Network

By nature, people use their smartphones more frequently to generate mobile data traffic than they use a USB dongle or similar form factor device to access the Internet. And while it is true that some of the more popular smartphones generate a lot of data traffic on the order of hundreds of Megabytes per subscriber per month it isnt the amount of data traffic that is creating the 3G network congestion problems that exist today, but the way in which the data traffic is being generated in the 3G network. The typical smartphone user does data snacking in which the handset consumes modest amounts of data per data connection, albeit with a high number of connections throughout the day and each with its associated signaling messages required to set up the connection. The typical smartphone user does data snacking in which the handset consumes modest amounts of data per data connection, albeit with an appreciably high number of data connections throughout the day. Examples of data snacking include the use of Instant Messaging (IM) services, push email services, such as widely-popular BlackBerry service, and to a lesser extent Internet browsing. As discussed in the previous section, each connection attempt can generate a significant amount of signaling traffic that the network may not be designed to support.
3.3. Keep Alive Messages

In addition to the network connections that the subscriber originates and is aware of, there is also the presence of so-called keep alive messages, which typically occur without the 3G subscribers knowledge. These messages originate within the smartphone or social networking application itself and are used to provide an update on the subscribers status where am I located, am I available to respond to an IM message, etc. Anyone who is familiar with using one of the popular social networking services should be all too familiar with receiving status updates from connected friends, including notices when a friend signs off from the service or the Internet. What isnt perhaps realized is that these keep alive messages are constantly being sent by the handset as long as the application is active, even when the handset is seemingly not being used. Given that many of these applications and social networking services launch automatically
May 2010
Page 14

when the smartphone is turned on and they remain active without user intervention, the net result is that these keep alive messages are being generated 24 hours a day, 7 days a week. As we will demonstrate in the next chapter, these messages generate very little in the way of data traffic although they can generate a tremendous amount of signaling traffic while also impacting the expected life of the smartphone battery. In other words, the amount of signaling traffic required to set send a keep alive message is no different than the amount of signaling traffic required to set up a data session in which meaningful amounts of data are sent. Another way to look at the problem associated with the keep alive messages is that the number of signaling messages required to send these status updates is largely equivalent to the number of signaling messages required to set up a voice call. Although the technical implications of the messages may be different and perhaps impact different network elements, the biggest difference is that the signaling messages which precede and follow the transmission of a keep alive message occur on the order of every few minutes while the application is running in the background. Conversely, not even the busiest mobile phone user can claim to be making 30+ voice calls every hour of every day.
3.4. Fast Dormancy

As alluded to in an earlier section, it is in the best interest of the smartphone battery to remain in the lowest possible RRC connection state and to quickly exit Cell_DCH or even Cell_FACH as soon as possible in order to preserve battery life. As such, many of the leading suppliers of smartphones implement a feature known as fast dormancy which forces the handset to return to the idle state the moment the phone has stopped sending or receiving data, even before the network timers have expired. This action is all fine and good if it is done intelligently, but frequently the smartphone disconnects in order to preserve battery life, only to quickly reconnect to the network a few seconds later when it needs to send or receive more data. Keep in mind that each of these releases and connections generate additional signaling traffic. Internet browsing and IM are just a couple of examples of usage patterns where fast dormancy would typically be problematic from a signaling perspective. If an operator has implemented Cell_PCH and selected appropriate network inactivity timer settings then there is little need for fast dormancy since the current drain associated with the Cell_PCH state is largely on par with the current drain of the Idle state. Nokia is an example of a handset manufacturer that has implemented a feature, which it dubs Quick Release, which can determine if Cell_PCH is active in the network, and if it is active the handset relies on the network timer settings for determining when it should leave the Cell_DCH and Cell_FACH states and return to Cell_PCH, thus preserving battery life while minimizing the amount of unnecessary signaling traffic.
3.5. Tracing the Root Cause of 3G Network Congestion

In the next section we will prove that smartphones generate a lot of signaling traffic, but we will not necessarily conclusively prove that it is the signaling traffic that is creating congestion in todays 3G networks. However, we can offer some food for thought which will hopefully make
May 2010 Page 15

our case. Further, we note that multiple operators and vendors have confided to us that signaling is the root cause of the congestion, although from an operators perspective this topic is rather sensitive in nature. Our first point starts with the fact that operators and vendors universally agree that the large amount of mobile data traffic that exists today is highly concentrated among a small percentage of the installed base of subscribers. While the exact distribution is operator and country dependent, if we were to state that 90% of the mobile data traffic is concentrated among 10% of the users, no one would suggest that our numbers were way off base. However, when an operator has an issue with 3G network congestion, the congestion generally exists across entire cities versus being concentrated among individual cell sites where the heaviest users happen to be located. Unless the small minority of users was somehow universally distributed throughout the network, all accessing the network at the same time, the network congestion would have to be taking place at a centralized point within the network and not associated with these heavy users. Our second point stems from the realization that operators always give priority in their network to the voice user over the data user since revenues from voice services still dwarf the revenues from data services, while consumers would be less tolerant of a poor user experience when making a voice call versus when using the data capabilities of the network. Further, operators that we have interviewed actually reserve capacity in their network in the event that they need to support a sudden jump in unanticipated voice traffic (e.g., several subscribers suddenly decide to place a voice call in the same cell site or they all move into the same cell from other cell sites). For numerous reasons it cannot be the data traffic, per se, that is taking all of the available bandwidth in the air interface across large swaths of a congested 3G network. In other words, it cant be the data traffic, per se, that is taking all of the available bandwidth in the air interface and creating dropped voice calls, failed call attempts, slow network response times, and sluggish data throughput across large swaths of a congested 3G network. Instead, the problem must be occurring at a centralized point or points within the 3G network where all voice and/or data traffic are routed. As operators have stated to us, much of the problem that they are having is due to the impact of excessive signaling traffic, brought on by smartphones, and the additional processing requirements that it is placing on centralized network elements, such as the RNC and SGSN. These network elements must process the signaling messages in order to maintain control of the network and track all of the devices within the network. Therefore, any degraded performance associated with processing these messages would impact the network elements ability to support all users in the network and it would limit the network elements ability to provide sufficient processing power to move the data traffic that they are also responsible for delivering to the intended users. Given that the sudden rise in smartphones and their associated usage patterns were largely unanticipated when todays platforms were first being designed, it would not be surprising if these network elements lacked sufficient processing power to deal with a phenomenon that was largely unanticipated.
May 2010 Page 16

4. Detailed Results
In this chapter we present results from numerous test scenarios which attempted to replicate likely usage patterns associated with todays smartphone users. The next section discusses our test methodology while the remaining sections in this chapter provide many of the results. For completeness sake, we include some additional results and other supporting data in the appendix.
4.1. Test Methodology

All network testing took place in Montreal, Canada during the week of April 19, 2010. For logistical and convenience purposes, most of the testing took place from a hotel room where we had the ability to recharge the phones and GPS receivers, while we could also work in a protected environment without any interruptions. We identify those test scenarios, such as the Nokia Maps and FindMe test scenarios, which took place outdoors and/or in pedestrian mode. In order to obtain highly objective results, the tests were conducted with Nokia N97 smartphones that were preinstalled with the anite Nemo Handy client in order to capture the signaling messages that were being generated. NSN provided us with two Nokia N97 smartphones and two SIM cards one SIM card for the TELUS HSPA network and one SIM card for the Rogers Wireless HSPA network. Both phones came with the Anite Nemo Handy client pre-installed. This tool allowed us to capture all of the interactions between the phone and the network, including the signaling traffic and the amount of data traffic that was being generated. We used the Anite Nemo Analyze postprocessing tool to analyze the data and to create many of the graphs which appear in this paper. Worth noting, the Nemo Handy client can only capture the signaling messages between the handset and the network. For obvious reasons it cannot see and capture signaling traffic that is occurring between network elements within the radio access and core networks (e.g., between the RNC and Node B or between the RNC and SGSN). Therefore, we provide two sets of numbers when analyzing the number of signaling messages for a given scenario the number of signaling messages that we can physically count in the Nemo Handy log file and the number of signaling messages that we estimate took place elsewhere within the network, based on the number and type of RRC connection changes as well as what the 3GPP standard specifies must take place regarding signaling call flow in order for those state transitions to occur. In order to focus on the impact of signaling that is due specifically to the RRC state transition changes we excluded those messages which we could attribute to other factors, such as messages that were generated when the smartphone was in a soft handover or actually handing off to another cell. Prior to departing for Montreal, we pre-loaded the two smartphones with commonly-used applications, including AccuWeather, Bloomberg, FindMe and fring, a social networking application that can be used to combine the several different social networking services. For purposes of our testing, we used Yahoo IM and Skype. We also set up the appropriate Yahoo IM and Skype accounts so that we could establish connections between the two smartphones and we configured both phones with a POP3 email account tied to our Signals Research Group
May 2010
Page 17

email server. Finally, we installed Nokia Energy Profiler to monitor and record the impact on the battery life (e.g., current consumption). Most test scenarios were repeated several times and, when appropriate, both phones were tested simultaneously. In some instances, such as when we tested the impact of synching an email account, we tested each smartphone individually. Other details and nuances associated with each test scenario are described within the appropriate sections in the rest of this chapter.
4.2. Baseline Measurements

Before we look at the impact of smartphone applications on the amount of generated signaling traffic and the impact on battery life it is important first to establish a baseline so that the impact can be fully appreciated and understood. The first test scenario captures the signaling traffic and current consumption with the Nokia smartphones in idle mode with no applications running. Figure 2 provides the results for the N97 smartphone in the TELUS network and Figure 3 contains the results for the N97 smartphone in the Rogers Wireless network. As evident in both figures there is not any messaging activity taking place throughout the duration of the tests.
figure 2. nokia n97 in the idle state telus network

Observed signaling messages = 0 RRC State Cell_DCH
Cell_FACH
Cell_PCH
URA_PCH TELUS (NSN) Network Idle 14:30:00 14:35:00 14:40:00 14:45:00 14:50:00 Time 14:55:00 15:00:00 15:05:00 15:10:00
Source: Signals Research Group, LLC
May 2010
Page 18

figure 3. nokia n97 in the idle state Rogers wireless network

Observed signaling messages = 0 RRC State Cell_DCH
Cell_FACH
Cell_PCH
URA_PCH Rogers Wireless Network Idle 14:30:00 14:35:00 14:40:00 14:45:00 14:50:00 Time 14:55:00 15:00:00 15:05:00 15:10:00
May 2010
Page 19

Figure 4 illustrates the current consumption of the two phones during this test. We have labeled where the backlight of the two phones turned off and where it turned on, although this event should be fairly obvious. The results of this test indicate that the N97 handset in the TELUS network used slightly more current when in idle mode. We cant explain why this was the case but it was a consistent phenomenon. We note that the Nemo Handy application and the Bluetooth radio in the handsets were both active as they were required to do the network tests the Bluetooth radio was used to connect to a separate GPS receiver which we placed near a window.
figure 4. current consumption with the nokia n97 handsets in the idle state no backlight
TELUS (NSN) Network Rogers Wireless Network mA 400 Backlight goes off 300
200 Backlight goes on
100
0 14:29.4 14:30.5 14:32.0 14:34.2 14:35.3 14:36.4 14:37.5 14:41.2 14:42.3 14:43.4 14:44.5 14:48.2 14:49.3 14:51.5 14:56.3 14:38.6 14:45.6 14:50.4 14:52.6 14:58.5 14:33.1 14:40.1 14:47.1 14:54.1 14:55.2 14:57.4 14:59.6 15:01.1 15:02.2 15:03.3 15:04.4 15:05.5 15:06.6 15:08.1 15:09.1 15:10.2
Time TELUS (NSN) Network with backlight off = 43mA (123% of Rogers Wireless) Rogers Wireless Network with backlight off = 35mA
May 2010
Page 20

Since during this test we did not measure a long enough period with the backlight turned on we are leveraging another test with similar parameters in order to determine the current consumption with the backlight turned on. This information is presented in Figure 5. The measurement, which was made over two separate periods (M1 and M2), indicates that the current consumption with the backlight turned on was largely equivalent with the N97 handset used in the TELUS network requiring 3% more current. Although not shown in this whitepaper, we also used the same test methodology to determine the current requirements with the Nemo Handy application turned off, albeit with the Bluetooth radio turned on, although not connected to a separate GPS device. In that test the average current consumption was slightly less, as expected, or 230mA. Now that we have established a baseline for both the current consumption and the signaling traffic with the phone in the Idle state we can start introducing the impact of various smartphone applications under normal usage patterns.
figure 5. current consumption with the nokia n97 handsets in the idle state backlight turned on
TELUS (NSN) Network Rogers Wireless Network mA 400
300
200
M1
M2
100
0 12:32.4 12:33.6 12:34.5 12:34.6 12:32.0 12:32.2 12:32.2 12:33.0 12:34.2 12:34.4 12:35.0 12:35.2
Page 21
12:32.1
12:32.5
12:32.5
12:33.1
12:33.1
12:33.5
12:34.1
12:34.1
12:31.2
12:31.3
12:31.3
12:31.4
12:31.5
12:31.5
12:32.3
12:33.2
12:33.3
12:33.4
12:33.4
12:34.3
Time TELUS (NSN) Network with backlight on = 275mA (103% of Rogers Wireless) Rogers Wireless Network with backlight on = 268mA
May 2010
12:34.3
12:35.1
12:31.1

4.3. Keep Alive Messages

In this test scenario we used Nemo Handy and Nokia Energy Profiler to determine the impact of keep alive messages on the amount of signaling traffic that was generated and the impact on current requirements. To be specific, we launched the fring application, which bundled together Yahoo IM and Skype, set the two smartphones down on a table, and went out for lunch. All of the smartphone signaling activity, with the exception of the signaling traffic due to initialing launching and terminating the application, was self-generated by the social networking service with no human intervention whatsoever. Figure 6 shows the signaling activity associated with this test scenario, including the initial launch of the application at the beginning of the test. In this test scenario the N97 phone in the TELUS network did not use Cell_PCH, except at the very beginning. As a consequence
figure 6. RRc state transitions due to keep alive messages

TELUS (NSN) Network Rogers Wireless Network RRC State Cell_DCH
Cell_FACH
Cell_PCH
URA_PCH Rogers Wireless Network Idle 07:40:00 07:50:00 08:00:00 08:10:00 Time 08:20:00 08:30:00 08:40:00
Keep alive message payload = ~150bytes; frequency = 2-8 minutes TELUS network generates 7-53 observed signaling messages per keep alive message Typical observed number per message = 40-50; estimated unobserved messages = 20; average connection time = 7.2 sec Rogers Wireless network generates 24-46 signaling messages per keep alive message Typical observed number per message = 40-45 ; estimated unobserved messages = 20; average connection time = 6.5 sec
May 2010
Page 22

the number of observed signaling message per keep alive message was no better than the N97 phone in the Rogers Network, and in some instances it was worse since it remained connected to the network for a slightly longer period of time (~0.7 seconds on average). However, when it did use Cell_PCH the number of observed signaling messages was substantially lower than when the starting point was the Idle state, or only 7 messages. One interesting observation is that the keep alive messages become less frequent during the later stages of the test than at the beginning of the test. This behavior was dramatically different than what we observed when we conducted this very same test as part of the research going into our Signals Ahead newsletter. In that test the frequency of the messages was once every two minutes throughout the hour long test. We can only conclude that the application provider and/ or the various social networking services that it integrates, have taken prudent steps in the last few months to address the impact that its application is having on todays 3G networks. Figure 7 shows the impact of the keep alive messages on the current requirements of the two handsets. During those instances where the keep alive message was active the current requirements were approximately 260mA, or higher than the current requirements associated with an active backlight (230mA).
figure 7. current Requirements due to keep alive messages

TELUS (NSN) Network Rogers Wireless Network mA 700 600 500 400 300 200 100 0 07:35.1 07:37.1 07:39.1 07:41.1 07:43.1 07:45.1 07:47.1 07:49.1 07:51.1 07:53.1 07:57.1 08:01.1 08:03.1 08:05.1 08:07.1 08:09.1 08:11.1 08:13.1 08:15.1 08:17.1 08:19.1 08:21.1 08:23.1 08:27.1 08:29.1 08:31.1 08:33.1 08:35.1 08:37.1 08:39.1 08:41.1 08:43.1 08:45.1 07:55.1 07:59.1 08:25.1
Time Average current requirement during keep alive message = 260mA
May 2010
Page 23

At first glance the impact on battery life may seem rather insignificant, and with a frequency of one message every 8 minutes it probably is not all that important. However, consider what would happen if the messages were being generated more frequently, as will be the case with an upcoming test scenario, or if there were multiple applications running in the background, each generating its own keep alive message. Table 1 equates the impact of keep alive messages for varying frequencies relative to the impact of keeping the backlight on the phone turned on for one full hour. We have selected this comparison since most consumers understand that keeping the backlight turned on their phone will have a material impact on their expected battery life while we doubt that consumers would entertain the idea of keeping their backlight turned on for an hour at the start of each day before heading to work. As indicated in the table, a frequency of one keep alive message every minute over a normal eight hour work day would require more energy than what is required to keep the backlight on for 60 minutes. Likewise, a frequency of one message every two minutes, or what this particular application was generating earlier this year, would achieve the same threshold in the waking hours of a typical day (15 hours).
table 2. the impact of keep alive messages on battery life

Keep Alive Message Frequency (minutes) 1 2 3 4 Time Required to Equate to a Full Hour of the Backlight Turned On (hours) 7.53 15.06 22.59 30.12
May 2010
Page 24

4.4. Chatting with a friend using Yahoo IM

In this scenario we will examine the impact of an instant messaging session between two smartphones. As indicated in the Test Methodology section we used the Yahoo IM application within the fring application. For all IM scenarios, we sent messages between the two smartphones. The time between receiving and sending a message was somewhat arbitrary and based in large part on the time between sending the message and receiving it on the other phone (not always an instantaneous process), a varying wait period to simulate how a typical user would behave, and the time spent typing the message. Since we wanted to avoid the backlight turning off on the phones we limited the wait time to less than one minute (the maximum setting allowed on the Nokia phone), although in hindsight a longer wait period would be entirely reasonable. Figure 8 shows the results of a representative test scenario. In order to exclude the signaling messages due to the start of the application and in order to focus only on the signaling messages
figure 8. RRc state transition changes due to yahoo im test scenario 4

Cell_FACH
Cell_PCH
URA_PCH
M1
M1
StartStart Idle 11:35:00
11:36:00
11:37:00
11:38:00
11:39:00 Time
11:40:00
11:41:00
11:42:00
IM message (This is a test, this is only a test) payload = 1-2kB TELUS network observed signaling messages = 306; estimate of unobserved messages = 28 M1 messages = 37; M2 messages = 39
M1 messages = 96; M2 messages = 65 Observed T2 Timer Setting = 3.3 sec
Rogers Wireless network observed signaling messages = 517: estimate of unobserved messages = 280
May 2010
Page 25

due to the sending and receiving of instant messages, the actual start period of the test is at the 11:35:30 mark. We separately counted the number of signaling messages during two time periods, which are labeled M1 and M2. We selected these time intervals since they include frequent RRC state transitions for the N97 handset in the TELUS network and since we wanted to demonstrate that the impact of these state transitions has only a minimal impact on the level of signaling traffic. The N97 smartphone in the TELUS (NSN) network generated 58% less signaling traffic than the N97 smartphone in the Rogers Wireless network for the same Instant Messaging session. As indicated in Figure 8, the N97 smartphone in the TELUS (NSN) network generated 41% less signaling traffic than the N97 smartphone in the Rogers Wireless network (58% less signaling traffic if we include unobserved signaling traffic) for the same test scenario involving the sending and receiving of instant messages between the two handsets. If we isolate the time period to one of the measurement periods where the TELUS Network undergoes a large number of state transition changes between Cell_PCH and Cell_FACH, the reduction for the observed messages is comparable or even better (M1 = 61%, M2 = 40%). This result occurred because very few signaling messages are required to move between these two states. Worth noting, in addition to leveraging Cell_PCH the smartphone in the TELUS network almost always used Cell_FACH to send and receive the IMs. This feature had a significant impact on both reducing the signaling load as well as freeing up network capacity for other voice and data users. One final observation is that our analysis of the Rogers Wireless network suggests that the T2 timer was set to 3.3 seconds. Since the TELUS network used Cell_FACH to send and receive data it wasnt possible for us to determine at what point there was inactivity in the channel.
May 2010
Page 26

Figure 9 provides the results for another IM session while the appendix contains additional results, as well as excerpts from the log file which shows the actual test messages. In this test scenario the N97 in the TELUS (NSN) network generated 49% less signaling traffic.

Cell_FACH
Cell_PCH
M1 URA_PCH
Start Idle 12:24:00 12:25:00 12:26:00 12:27:00 Time IM message (This is a test, this is only a test) payload = 1-2kB TELUS network observed signaling messages = 208; estimate of unobserved messages = 30 M1 messages = 50
M1
12:28:00
12:29:00
12:30:00
12:31:00
12:32:00
Rogers Wireless network observed signaling messages = 294: estimate of unobserved messages = 174 messages = 62
May 2010
Page 27

Figure 10 illustrates the impact on the battery life for the IM session shown in Figure 9. Throughout the entire test period the N97 smartphone in the TELUS (NSN) network used 13% less current than the smartphone in the Rogers Wireless network, and arguably much less in numerous instances (e.g., 32% less during M1 and 25% less during M2) where the N97 smartphone in the TELUS network was able to leverage a combination of Cell_FACH and a more aggressive T2 timer setting.
figure 10. the impact of an instant messaging session on battery life test scenario 7
TELUS (NSN) Network Rogers Wireless Network mA 700 600 500 400 300 200 M1 100 0 12:23.1 12:25.1 12:25.3 12:25.4 12:25.6 12:26.1 12:28.0 12:28.3 12:28.5 12:30.0 12:30.3 12:30.5 12:31.0 12:22.4 12:22.5 12:23.2 12:23.4 12:23.6 12:24.1 12:24.3 12:24.4 12:24.6 12:26.3 12:26.4 12:26.6 12:27.3 12:27.4 12:28.2 12:29.0 12:29.2 12:29.3 12:29.5 12:30.2 12:31.2 12:31.3 12:27.1 M2
Time TELUS network average current requirement = 298mA M1 = 277mA; M2 = 291mA Rogers Wireless network average current requirement = 342mA M1 = 406mA; M2 = 388mA
May 2010
Page 28

4.5. Keeping Track of a Friend with the FindMe Application

The FindMe application is available for free from the Ovi website. As the name suggests the application allows friends to find each other on a digitally-displayed map. For purposes of our test we used GPS to identify our location, which happened to be outdoors near the Notre Dame cathedral, although Cell ID or even a manual entry process can be used. Most importantly, we selected the default time settings, which meant a status update was being sent once every minute. Keep in mind that a list of multiple friends would create a multiplicative effect on the amount of signaling traffic that was being generated since each time another friend provides an update it creates its own message. As shown in Figure 11, both handsets required Cell_DCH to send/receive the updates; however, the N97 smartphone in the TELUS network returned to Cell_PCH after each message where it remained until the next message was sent/received. During the defined test period we observed that the N97 smartphone in the TELUS network generated 37% less signaling messages (50% less if we include unobserved signaling messages).
figure 11. RRc state transition changes due to findme test scenario 2
Cell_FACH
Cell_PCH
URA_PCH Start Idle End
18:45:30
18:46:00
18:46:30
18:47:00
18:47:30
18:48:00 Time
18:48:30
18:49:00
18:49:30
18:50:30
18:51:00
TELUS network observed signaling messages = 199; estimate of unobserved messages = 58 Total payload = 90kB Rogers Wireless network observed signaling messages = 318: estimate of unobserved messages = 200 Total payload = 92kB
May 2010
Page 29

In terms of the impact on the battery life, the N97 smartphone in the TELUS network required 22% less current throughout the test period. We attribute the savings primarily to less time being spent in the Cell_DCH state (e.g., a shorter T1 timer setting).
figure 12. the impact of the findme application on battery life test scenario 2
TELUS (NSN) Network Rogers Wireless Network mA 600 500
400
300
200
100
0 18:48.1 18:44.4 18:44.5 18:45.0 18:45.3 18:45.4 18:45.5 18:46.0 18:46.3 18:46.4 18:46.5 18:47.0 18:47.2 18:47.4 18:47.6 18:48.2 18:48.3 18:48.5 18:48.6 18:49.3 18:49.4 18:49.5 18:50.1 18:46.1 18:47.1 18:47.5 18:49.1 18:50.2 18:50.3 18:50.4 18:50.5 18:51.0 18:51.1 18:45.2 18:49.2 18:51.3
Time TELUS network average current requirement = 172mA Rogers Wireless network average current requirement = 221mA
May 2010
Page 30

4.6. Downloading Large Files

Prior to starting this test scenario we set the home page of our browser to the 3G Americas website so that once we launched the browser we would not have to navigate to the website that we had selected where we would have ready access to multiple files that we could download. In terms of the actual test itself, the process involved launching the browser and then concurrently downloading three whitepapers which appeared on the trade associations home page. Once we completely downloaded a file we then proceeded to download the next file until we had downloaded all three files. For this scenario we tested each handset separately. Figure 13 provides the results for the N97 smartphone in the TELUS (NSN) network and Figure 14 provides the results for the N97 smartphone in the Rogers Wireless network.
figure 13. RRc state transition changes due to downloading large files telus network (test scenario 3)
TELUS (NSN) Network RRC State Cell_DCH
Cell_FACH
Cell_PCH
URA_PCH
Idle
13:39:00
13:39:30
13:40:00
13:40:30
13:41:00 Time
13:41:30
13:42:00
13:42:30
TELUS network observed signaling messages = 153; estimate of unobserved messages = 48 Total payload = 5.8MB
May 2010
Page 31

Since this test scenario only resulted in a few RRC state transition changes the number of signaling messages on the two networks wasnt as meaningful as it was in other test scenarios. Further, unlike previous test scenarios, a fairly material amount of data was transferred, or 5.8MB. We did not use the Nokia Energy Profiler application during these tests since the results would be fairly predictable and not all that interesting. The appendix contains very similar results for another test run using the same methodology.
figure 14. RRc state transition changes due to downloading large files Rogers wireless network (test scenario 3)
Rogers Wireless Network RRC State Cell_DCH
Cell_FACH
Cell_PCH
URA_PCH
Idle 13:52:30 13:53:00 13:54:00 13:54:30 13:55:00 13:55:30 Time 13:56:00 13:56:30 13:57:30 13:58:00 13:58:30
Rogers Wireless network observed signaling messages = 182; estimate of unobserved messages = 90 Total payload = 5.8MB
May 2010
Page 32

4.7. Web Browsing/Internet Surfing

In advance of starting this test scenario, we set the home page of our browser to CNN.com (the smartphones defaulted to the mobile website). During the actual test we launched both browsers in rapid succession and then proceeded to periodically navigate to new pages within the CNN website after waiting for the page to load and allowing for sufficient time to quickly read the article. Note that we went to the same web pages with each smartphone and since there was inherently a very short period of time (<1 sec) between the time we tapped the next page on one phone and then the second phone, we randomly switched which phone we tapped first when advancing to the next web page. As indicated in Figure 15 the number of observed signaling messages associated with loading 10 web pages was largely equal between the two networks although there were a number of signaling messages, especially on the Rogers Wireless network, that had to have occurred between interfaces that did not extend to the handset. Thus, while the observed reduction was only 16%, the estimated reduction, which includes the unobserved messages, was 36%.
figure 15. RRc state transition changes due to web browsing test scenario 2
Cell_FACH
Cell_PCH
URA_PCH M1
Idle
13:22:00
13:23:00
13:24:00
13:25:00
13:26:00 Time
13:27:00
13:28:00
13:29:00
13:30:00
TELUS network observed signaling messages = 286; estimate of unobserved messages = 64 M1 messages = 64; estimated unobserved messages = 12 Total payload = 382kB Rogers Wireless network observed signaling messages = 339: estimate of unobserved messages = 210 M1 messages = 69; estimated unobserved messages = 50 Total payload = 377kB
May 2010
Page 33

The amount of current required to perform this test favored the N97 smartphone in the TELUS network, we believe largely due to the longer Cell_DCH times (T1 timer setting) in the Rogers Wireless network. During the M1 test period there was a 21% reduction versus the Rogers Wireless network, although as indicated in Figure 15, the number of observed signaling messages was largely equivalent (the TELUS network exhibited a 30% reduction after factoring in the unobserved messages during the M1 period).
figure 16. the impact of web browsing on battery life test scenario 2
TELUS (NSN) Network Rogers Wireless Network
mA 700 600 500 400 300 200 100 0

13:21.2 13:21.3 13:21.5 13:22.0 13:22.2 13:22.3 13:22.5 13:22.6 13:23.1 13:23.3 13:23.4 13:23.5 13:24.2 13:24.5 13:25.1 13:25.2 13:25.3 13:25.5 13:26.2 13:26.3 13:27.0 13:27.3 13:28.2 13:28.4 13:28.5 13:29.2 13:29.3 13:29.5 13:30.0 13:30.2 13:24.4 13:26.0 13:26.4 Time TELUS network average current requirement = 350mA M1 = 366mA Rogers Wireless network average current requirement = 342mA M1 = 464mA
M1
May 2010
Page 34
13:30.3
13:24.1
13:27.1
13:27.4
13:27.6
13:28.1
13:29.1

Figure 17 and Figure 18 show the results for a similar web browsing experience, once again using the CNN website. In this case the number of observed signaling messages on the two networks was largely equal. However, after taking into consideration those signaling messages which could not be observed with the test equipment, the reduction was 22%. The current consumption was also 16% lower in the TELUS network.
Cell_FACH
Cell_PCH
URA_PCH
Idle 10:42:00 10:43:00 10:44:00 10:45:00 10:46:00 Time TELUS network observed signaling messages = 402; estimate of unobserved messages = 96 Total payload = 464kB Rogers Wireless network observed signaling messages = 408: estimate of unobserved messages = 234 Total payload = 467kB 10:47:00 10:48:00 10:49:00 10:50:00 10:51:00
May 2010
Page 35

TELUS (NSN) Network Rogers Wireless Network mA 700 600 500 400 300 200 100 0
10:46.0 10:44.0 10:46.6 10:48.6 10:46.2 10:48.2 10:46.4 10:48.4 10:50.4 10:44.2 10:44.4 10:42.2 10:44.5 10:50.3 10:42.5 10:41.0 10:45.5 10:42.3 10:43.4 10:49.5 10:45.3 10:49.3 10:41.6 10:43.3 10:51.0 10:41.2 10:41.4 10:48.1 10:50.1 10:47.5 10:47.3 10:51.2 10:51.4 10:45.1 10:49.1 10:51.5 10:43.1 10:52.1 10:47.1
May 2010
Page 36

4.8. Sending and Receiving Email

For this test scenario we configured the email application in both phones so that it could access our Signals Research Group email. For the test, we sent three identical emails to our account from our Gmail account with the last email containing a small attachment (Excel spreadsheet). We then proceeded to download the three emails and after downloading the last email we sent a short reply to the first message, indicating that the message was received. For hopefully obvious reasons we tested each phone separately. Figure 19 contains the results for the TELUS (NSN) network and Figure 20 contains the results for the Rogers Wireless network. In both figures, the first instance of Cell_DCH indicates the time during which we were downloading the three email messages. The second instance of Cell_ DCH occurs when we sent the response to the first email. The last, and very short, Cell_DCH period took place when we disconnected from the POP3 email server. Worth pointing out, the N97 smartphone in the TELUS network remained in Cell_PCH during the time between receiving and sending the email. The handset in the Rogers Wireless network returned to the Idle state, thus generating more signaling traffic when it returned to Cell_DCH.
figure 19. RRc state transition changes due to sending and Receiving email telus network (test scenario 3)
Cell_FACH
Cell_PCH
URA_PCH
Idle 13:59:30 13:59:40 13:59:50 14:00:00 14:00:10 Time TELUS network observed signaling messages = 73; estimate of unobserved messages = 44 Total payload = 65kB
14:00:20
14:00:30
14:00:40
14:00:50
May 2010
Page 37

figure 20. RRc state transition changes due to sending and Receiving email Rogers wireless network (test scenario 3)
Cell_FACH
Cell_PCH
URA_PCH
Idle 14:26:30
14:26:40
14:26:50
14:27:00
14:27:10
14:27:20 Time
14:27:30
14:27:40
14:27:50
14:28:00
Rogers Wireless network observed signaling messages = 88: estimate of unobserved messages = 60 Total payload = 71kB
May 2010
Page 38

4.9. Using Nokia Maps to Find a Museum in Old Montreal

For this test scenario we went to Old Montreal and used the Nokia Maps application to search for a nearby museum. We then used the application to obtain step by step directions, which were continuously updated, along with our location, as we proceeded to walk aimlessly around the popular tourist spot. Both phones were tested concurrently. The results of this test were particularly interesting to us since we wanted to know how much data traffic the application generated an important consideration given that we are most likely to use this application while roaming internationally and we would prefer to minimize our monthly phone bill. As it turns out, the Nokia Maps application, as indicated in Figure 21, generates only a modest amount of data traffic all at the beginning of the session when the user searches for the desired landmark. Throughout the course of the 7 minute test the total amount of transferred data on either network was less than 45kB. Further, there was a relatively minor amount of signaling traffic.
figure 21. RRc state transition changes due to nokia maps test scenario 1
Cell_FACH
Cell_PCH
URA_PCH
Idle 12:02:00 12:03:00 12:04:00 12:05:00 Time TELUS network observed signaling messages = 138; estimate of unobserved messages = 32 Total payload = 43.1kB Rogers Wireless network observed signaling messages = 160: estimate of unobserved messages = 60 Total payload = 32.6kB
12:06:00
12:07:00
12:08:00
12:09:00
May 2010
Page 39

The one interesting observation from these test results is that the N97 smartphone in the TELUS network remained in the Cell_PCH throughout the entire test, unless the handset required the Cell_DCH state. Given that the application only returned to Cell_DCH at the end of the test (and one other transition at the 12:04 mark which according to the data in the log file appears to have occurred during a cell reselection process), the impact on reducing the amount of signaling traffic was slight. However, the results do indicate that the operator is using an extended Cell_PCH state. In one of the test results in the appendix we show just how long (>18 minutes) the handset remains in Cell_PCH before returning to the Idle state (e.g., the T3 timer setting).
May 2010
Page 40

4.10. Watching a YouTube Video

One of the more popular mobile data applications as of late is watching user-generated videos from services such as YouTube. Going into the test our belief was that the results would not be all that interesting since the smartphone shouldnt require numerous RRC state changes. Instead, we assumed that the smartphone would enter the Cell_DCH state when the video link was selected and subsequently exit the state at some point after the complete video had been downloaded to the smartphone. The results, as shown in Figure 22, confirm that our initial hypothesis was correct. For a relatively meaningful amount of data that was transferred, the number of signaling messages was low. The number of signaling messages associated with the N97 smartphone in the TELUS network was equal to the number of signaling messages generated by the smartphone in the Rogers Wireless network, but after including the unobserved messages the reduction in signaling traffic was 10%.
figure 22. RRc state transition changes due to watching a youtube Video
Cell_FACH
Cell_PCH
URA_PCH
Idle 18:55:00
18:55:30
18:56:00
18:56:30
18:57:00
18:57:30
18:58:00 Time
18:58:30
18:59:00
18:59:30
19:00:00
19:00:30
19:01:00
TELUS network observed signaling messages = 107; estimate of unobserved messages = 34 Total payload = 12.3MB Rogers Wireless network observed signaling messages = 107; estimate of unobserved messages = 50 Total payload = 12.3MB
May 2010
Page 41

4.11 Making a Skype Video Call

For this test scenario we placed a Skype video call between the two handsets. As was the case with the Yahoo IM test scenarios, the Skype application was used within the fring application. The results for this test scenario are shown in Figure 23. In this test the N97 smartphone in the TELUS network called the N97 smartphone in the Rogers Wireless network. We repeated the test with the call process reversed (see appendix).
figure 23. RRc state transition changes due to a skype Video call test scenario 1
Cell_FACH
Cell_PCH
URA_PCH
Idle 18:55:00 18:55:30 18:56:00 18:56:30 18:57:00 18:57:30 18:58:00 Time 18:58:30 18:59:00 18:59:30 19:00:00 19:00:30 19:01:00
TELUS network observed signaling messages = 105; estimate of unobserved messages = 32 Total payload = 2.8MB Rogers Wireless network observed signaling messages = 109: estimate of unobserved messages = 60 Total payload = 2.6MB
May 2010
Page 42

4.12. Receiving an Incoming Voice Call

Although this test scenario has nothing to do with data, we are including it since it provides a frame of reference for how a handset behaves when receiving an incoming voice call. For this test scenario the test phone did not have applications running so it was truly idle until the incoming phone call. The test scenario includes a period of waiting, answering the incoming call after a few rings, and then maintaining the call for a period or approximately 90 seconds. Figure 24 shows the RRC state transition changes for the N97 smartphone in the TELUS network and Figure 25 shows the impact of the incoming call on the required current consumption.
figure 24. RRc state transition changes due to an incoming Voice call telus network
Cell_FACH
Cell_PCH
URA_PCH
Idle 16:58:30
16:58:45
16:59:00
16:59:15
16:59:30
16:59:45
17:00:00 Time
17:00:15
17:00:30
17:00:45
17:01:00
17:01:15
17:01:30
TELUS network observed signaling messages = 44; estimate of unobserved messages = 20
May 2010
Page 43

figure 25. the impact of an incoming phone call on battery life telus network
TELUS (NSN) Network
mA
600 500 400 300 200 Backlight goes out 100 0 16:58.2 16:58.2 16:59.1 16:59.2 16:59.2 17:00.0 17:00.1 17:00.2 17:00.3 17:00.3 17:00.4 17:00.5 17:00.5 17:01.0 17:01.1 17:01.1 17:01.2 17:01.3 17:01.3 17:01.4 17:01.5 17:01.6 17:02.0 16:58.0 16:58.1 16:58.3 16:58.4 16:58.4 16:58.5 16:58.6 16:59.0 16:59.3 16:59.4 16:59.4 16:59.5 16:59.6 Incoming call backlight comes on Call ends
Backlight goes out
Time Average current requirement idle; backlight on = 214mA idle; backlight off = 44mA active call; backlight on = 392mA active call; backlight off = 253mA
May 2010
Page 44

Likewise, Figure 26 and Figure 27 provide the results for the N97 smartphone in the Rogers Wireless network. Although the number of signaling messages generated in the Rogers Wireless network was higher than the number in the TELUS network, we believe it was due entirely to a slightly lower time between when the phone started ringing and when we hit answered the phone. In theory, the number of signaling messages for this particular scenario should have been equal between the two networks.
figure 26. RRc state transition changes due to an incoming Voice call Rogers wireless network
Cell_FACH
Cell_PCH
URA_PCH
Idle 16:45:00 16:45:30 16:46:00 16:65:30 16:47:00 Time Rogers Wireless network observed signaling messages = 62; estimate of unobserved messages = 20
16:47:30
16:48:00
16:48:30
16:49:00
16:49:30
16:50:00
May 2010
Page 45

figure 27. the impact of an incoming phone call on battery life Rogers wireless network
Rogers Wireless Network
mA
600 500 400 300 Backlight goes out 200 100 0 16:50.0 16:45.0 16:45.2 16:50.2 16:50.3 16:50.4 16:50.5 16:50.6 16:44.3 16:44.4 16:44.5 16:45.1 16:45.4 16:45.5 16:45.6 16:46.1 16:46.2 16:46.3 16:46.4 16:46.5 16:47.0 16:47.1 16:47.3 16:47.4 16:47.5 16:47.6 16:48.1 16:48.2 16:48.3 16:48.5 16:48.6 16:49.1 16:49.2 16:49.3 16:49.4 16:49.5 Incoming call backlight comes on Call ends Backlight goes out
Time Average current requirement idle; backlight on = 289mA idle; backlight off = 31mA active call; backlight on = 386mA active call; backlight off = 241mA
May 2010
Page 46

5. Conclusions
The growing popularity of smartphones and social networking services is here to stay. The recent introduction of Android-based smartphones and the soon-to-be emergence of MIDs and smartbooks mean that an even greater percentage of an operators installed base will make use of devices that inherently generate a lot of signaling traffic due to the way in which they are used. Over the last few months the problems associated with smartphone-generated signaling traffic have risen to the forefront and it appears that some steps have been taken to address the problem. However, the industry needs to continue to work together to address the problem so that operators can get the most out of their network resources while consumers can continue to have a favorable user experience. For operators, this means working with their infrastructure supplier to implement important features such as Cell_PCH, assuming that their vendor supports this capability, and selecting appropriate network inactivity timer settings to maximize its effectiveness. Of all the solutions to the problem that exist, this solution has the most bang for the buck, in particular when dealing with chatty smartphone applications that frequently transmit and receive relatively small amounts of data, without any associated ill consequences. Likewise, operators need to take the lead in working with handset manufacturers, application developers, and social networking services, to ensure that the impact of certain design decisions that are being made by the various constituencies on network performance and smartphone battery life are understood. There are obviously tradeoffs between battery life and the amount of signaling traffic that a smartphone generates. However, by working together the industry can make appropriate compromises which are in the best overall interest of all.
May 2010
Page 47

6. Appendix 1 Additional Results

In this appendix we include the results for some of the test scenarios which did not find their way into the main report. However, for completeness sake we are including them in this section. The results from these test scenarios are either similar in nature to the results that we presented earlier in this paper or they contain very little in the way of interesting and noteworthy information. We also include some of the detailed log files in this section. Figure 28 and Figure 29 provide results for a Yahoo IM session.
Cell_FACH
Cell_PCH
URA_PCH
Idle 12:53:00
12:53:30
12:54:00
12:54:30
12:55:00
12:55:30
12:56:00 Time
12:56:30
12:57:00
12:57:30
12:58:00
12:58:30
12:59:00
TELUS network observed signaling messages = 211; estimate of unobserved messages = 26 Rogers Wireless network observed signaling messages = 260: estimate of unobserved messages = 140
May 2010
Page 48

figure 29. the impact of an instant messaging session on battery life test scenario 6
mA
800 700 600 500 400 300 200 100 0 12:52.6 12:53.3 12:53.4 12:54.3 12:54.4 12:54.6 12:55.4 12:56.0 12:56.1 12:56.3 12:56.4 12:56.5 12:56.5 12:57.3 12:57.4 12:57.6 12:58.1 12:58.3 12:54.0 12:58.2 12:58.2 12:58.4 12:53.1 12:53.2 12:53.2 12:53.5 12:54.1 12:54.2 12:54.5 12:55.1 12:55.2 12:55.2 12:55.3 12:55.5 12:56.2 12:57.0 12:57.1 12:57.2 12:57.5
Table 2 through Table 4 provide a detailed list of all of the signaling traffic that was generated over a two minute period while doing a Yahoo IM session between the two phones. We had to limit the time period in order to reduce the number of pages for the second set of results which already have to be split between Table 3 and Table 4 due to the large number of messages that were observed. We note that in addition to removing those messages associated with soft handovers, we also deleted all of the signaling traffic which took place on the broadcast control channel (BCCH) since that channel is a shared channel while the signaling traffic would have little bearing with the actual usage of the phone.
May 2010
Page 49

table 3. detailed log file of signaling messages during an im session telus network (test scenario 4)
Time 36:50.9 36:50.9 36:50.9 37:04.5 37:04.5 37:04.8 37:04.8 37:07.8 37:07.8 37:07.8 37:16.5 37:16.5 37:16.7 37:16.9 37:16.9 37:21.7 37:21.7 37:21.7 37:46.1 37:46.2 37:46.2 37:46.4 37:46.4 37:49.9 37:49.9 37:49.9 37:51.5 37:51.5 37:51.8 37:51.8 37:52.8 37:54.4 37:54.4 37:54.4 Cell PCH Uplink Downlink DCCH DCCH PHYSICAL_CHANNEL_RECONFIGURATION_COMPLETE PHYSICAL_CHANNEL_RECONFIGURATION
RRC State Cell PCH
Direction Downlink Uplink
Channel DCCH DCCH CCCH DCCH DCCH DCCH DCCH CCCH CCCH DCCH DCCH DCCH DCCH PCCH CCCH DCCH DCCH DCCH DCCH CCCH DCCH DCCH CCCH
Message Type PHYSICAL_CHANNEL_RECONFIGURATION PHYSICAL_CHANNEL_RECONFIGURATION_COMPLETE CELL_UPDATE CELL_UPDATE_CONFIRM UTRAN_MOBILITY_INFORMATION_CONFIRM PHYSICAL_CHANNEL_RECONFIGURATION_COMPLETE PHYSICAL_CHANNEL_RECONFIGURATION CELL_UPDATE CELL_UPDATE_CONFIRM_CCCH CELL_UPDATE_CONFIRM UTRAN_MOBILITY_INFORMATION_CONFIRM PHYSICAL_CHANNEL_RECONFIGURATION_COMPLETE PHYSICAL_CHANNEL_RECONFIGURATION PAGING_TYPE_1 CELL_UPDATE CELL_UPDATE_CONFIRM UTRAN_MOBILITY_INFORMATION_CONFIRM PHYSICAL_CHANNEL_RECONFIGURATION PHYSICAL_CHANNEL_RECONFIGURATION_COMPLETE CELL_UPDATE CELL_UPDATE_CONFIRM UTRAN_MOBILITY_INFORMATION_CONFIRM RRC_CONNECTION_SETUP
Cell FACH Uplink Downlink Uplink Cell PCH Uplink Downlink Cell FACH Uplink Downlink Downlink Uplink Cell PCH Uplink Downlink Downlink Cell FACH Uplink Downlink Uplink Cell PCH Downlink Uplink Cell FACH Uplink Downlink Uplink Downlink
May 2010
Page 50

table 4. detailed log file of signaling messages during an im session part one Rogers wireless network (test scenario 4)
Time 37:00.7 37:01.0 37:01.0 37:01.2 37:01.2 37:01.2 37:01.2 37:01.8 37:03.4 37:03.7 37:04.0 37:04.3 37:04.3 37:04.3 37:04.6 37:07.9 37:07.9 37:07.9 37:07.9 37:07.9 37:08.3 37:08.4 37:08.4 37:08.4 37:08.4 37:08.7 37:08.7 37:08.7 37:08.8 37:08.8 37:09.0 37:09.1 37:09.1 37:09.2 37:09.5 37:09.5 37:09.7 37:09.8 Cell DCH Uplink Downlink Uplink DCCH DCCH DCCH RADIO_BEARER_SETUP_COMPLETE RADIO_BEARER_RECONFIGURATION RADIO_BEARER_RECONFIGURATION_COMPLETE
RRC State Cell FACH
Direction Downlink Uplink Downlink
Channel DCCH CCCH DCCH DCCH DCCH CCCH CCCH CCCH CCCH DCCH DCCH PCCH DCCH
Message Type RADIO_BEARER_RECONFIGURATION CELL_UPDATE CELL_UPDATE_CONFIRM RADIO_BEARER_RECONFIGURATION_COMPLETE UTRAN_MOBILITY_INFORMATION_CONFIRM RRC_CONNECTION_SETUP RRC_CONNECTION_SETUP RRC_CONNECTION_SETUP RRC_CONNECTION_SETUP RRC_CONNECTION_RELEASE RRC_CONNECTION_RELEASE_COMPLETE PAGING_TYPE_1 SERVICE_REQUEST
Cell FACH Uplink Uplink Downlink Downlink Downlink Downlink Downlink Idle Uplink Idle Downlink Uplink Cell FACH Uplink Downlink Cell DCH Cell DCH Uplink Uplink Downlink Downlink Downlink Downlink Uplink Downlink Uplink Uplink Uplink DCCH DCCH DCCH DCCH DCCH DCCH DCCH DCCH DCCH DCCH DCCH INITIAL_DIRECT_TRANSFER DCCH_RRC_CONNECTION_SETUP_COMPLETE MEASUREMENT_CONTROL MEASUREMENT_CONTROL MEASUREMENT_CONTROL SECURITY_MODE_COMMAND SECURITY_MODE_COMPLETE RADIO_BEARER_SETUP MEASUREMENT_REPORT MEASUREMENT_REPORT MEASUREMENT_REPORT CCCH CCCH RRC_CONNECTION_REQUEST RRC_CONNECTION_SETUP
May 2010
Page 51

table 5. detailed log file of signaling messages during an im session part one Rogers wireless network (test scenario 4)
Time 37:30.0 37:30.0 37:30.0 37:30.0 37:30.0 37:30.0 37:30.7 37:32.3 37:32.8 37:32.8 37:32.9 37:33.3 37:33.3 37:33.3 37:33.4 37:33.5 37:35.8 37:35.8 37:35.8 37:35.8 37:36.0 37:36.2 37:36.2 37:36.2 37:36.2 37:36.5 37:36.5 37:36.5 37:36.6 37:36.6 37:36.6 37:36.8 37:37.3 37:37.3 37:41.5 Cell DCH Uplink Uplink DCCH DCCH RADIO_BEARER_SETUP_COMPLETE MEASUREMENT_REPORT
RRC State Cell FACH Cell FACH
Direction
Channel
Message Type
Uplink Downlink Uplink Uplink Downlink Downlink Downlink Downlink Downlink Idle Uplink Downlink Idle Uplink Cell FACH Uplink Downlink Cell DCH Cell DCH Uplink Uplink Downlink Downlink Downlink Downlink Uplink Uplink Downlink
CCCH DCCH DCCH DCCH CCCH CCCH CCCH CCCH CCCH DCCH DCCH
CELL_UPDATE CELL_UPDATE_CONFIRM UTRAN_MOBILITY_INFORMATION_CONFIRM RADIO_BEARER_RECONFIGURATION_COMPLETE RRC_CONNECTION_SETUP RRC_CONNECTION_SETUP RRC_CONNECTION_SETUP RRC_CONNECTION_SETUP RRC_CONNECTION_SETUP RRC_CONNECTION_RELEASE_COMPLETE RRC_CONNECTION_RELEASE
DCCH CCCH CCCH
SERVICE_REQUEST RRC_CONNECTION_REQUEST RRC_CONNECTION_SETUP
DCCH DCCH DCCH DCCH DCCH DCCH DCCH DCCH DCCH
DCCH_RRC_CONNECTION_SETUP_COMPLETE INITIAL_DIRECT_TRANSFER MEASUREMENT_CONTROL MEASUREMENT_CONTROL MEASUREMENT_CONTROL SECURITY_MODE_COMMAND SECURITY_MODE_COMPLETE MEASUREMENT_REPORT RADIO_BEARER_SETUP
May 2010
Page 52

table 5. detailed log file of signaling messages during an im session part one Rogers wireless network (test scenario 4), cont.
37:41.8 37:41.8 37:41.8 37:41.8 37:41.8 37:41.8 37:41.9 37:42.8 37:42.8 37:42.8 37:42.8 37:43.0 37:43.2 37:43.2 37:43.2 37:43.2 37:43.3 37:43.9 37:43.9 37:43.9 37:44.2 37:44.6 37:44.6 37:44.8 37:44.8 37:44.9 37:44.9 Cell DCH Uplink Uplink Uplink Downlink Uplink DCCH DCCH DCCH DCCH DCCH RADIO_BEARER_SETUP_COMPLETE MEASUREMENT_REPORT MEASUREMENT_REPORT RADIO_BEARER_RECONFIGURATION RADIO_BEARER_RECONFIGURATION_COMPLETE
Idle Uplink Downlink Downlink Uplink Downlink DCCH DCCH DCCH DCCH DCCH RRC_CONNECTION_RELEASE_COMPLETE RRC_CONNECTION_RELEASE RRC_CONNECTION_RELEASE RRC_CONNECTION_RELEASE_COMPLETE RRC_CONNECTION_RELEASE
Uplink Cell FACH Uplink Downlink Cell DCH Cell DCH Uplink Uplink Uplink Downlink Downlink Uplink Downlink
DCCH CCCH CCCH
SERVICE_REQUEST RRC_CONNECTION_REQUEST RRC_CONNECTION_SETUP
DCCH DCCH DCCH DCCH DCCH DCCH DCCH
INITIAL_DIRECT_TRANSFER DCCH_RRC_CONNECTION_SETUP_COMPLETE MEASUREMENT_REPORT MEASUREMENT_CONTROL SECURITY_MODE_COMMAND SECURITY_MODE_COMPLETE RADIO_BEARER_SETUP
May 2010
Page 53

Figure 30 and Figure 31 provide the results for a web browsing session.
Cell_FACH
Cell_PCH
URA_PCH
Idle 13:06:00 13:07:00 13:08:00 13:09:00 Time TELUS network observed signaling messages = 337; estimate of unobserved messages = 58 Total payload = 512kB Rogers Wireless network observed signaling messages = 284: estimate of unobserved messages = 164 Total payload = 477kB
13:10:00
13:11:00
13:12:00
13:13:00
May 2010
Page 54

mA
800 700 600 500 400 300 200 100 0 13:07.1 13:07.2 13:07.4 13:07.5 13:05.2 13:06.0 13:06.2 13:06.3 13:06.4 13:06.6 13:08.2 13:09.1 13:09.2 13:09.4 13:09.5 13:10.2 13:10.3 13:10.6 13:12.0 13:12.2 13:11.1 13:11.2 13:12.3 13:12.4 13:12.6 13:13.1 13:13.2 13:05.4 13:05.5 13:08.0 13:08.3 13:08.4 13:08.6 13:10.0 13:14.0 13:10.4 13:11.4 13:11.5 13:13.4 13:13.5
May 2010
Page 55

Figure 32 illustrates the results from a test in which we used the Bloomberg smartphone application to track a series of stock quotes. We had expected numerous connections throughout the period of the test in order to provide updated quotes but this event did not happen. However, the results are interesting since they show how long the TELUS network keeps a smartphone or handset in the Cell_PCH state, or more than 18 minutes.
figure 32. RRc state transition changes - bloomberg

Cell_FACH
Cell_PCH
URA_PCH
Idle 14:45:00 TELUS network Cell_PCH Time = 18 min 16 sec 14:50:00 14:55:00 Time
15:00:00
15:05:00
May 2010
Page 56

Figure 33 and Figure 34 provide the results for test scenario that involved downloading large files from a website using the web browser of the smartphone. The results are very similar to the results that are discussed in Chapter 4.
figure 33. RRc state transition changes due to downloading large files Rogers wireless network (test scenario 1)
Cell_FACH
Cell_PCH
URA_PCH
Idle 14:06:30
14:07:00
14:07:30
14:08:00
14:08:30 Time
14:09:00
14:09:30
14:10:00
14:10:30
Rogers Wireless network observed signaling messages = 180; estimate of unobserved messages = 68 Total payload = 6MB
May 2010
Page 57

figure 34. RRc state transition changes due to downloading large files telus network (test scenario 1)
Cell_FACH
Cell_PCH
URA_PCH
Idle 14:22:00
14:22:15
14:22:30
14:22:45
14:23:00
14:23:15 Time
14:23:30
14:23:45
14:24:00
14:24:15
14:24:30
TELUS network observed signaling messages = 129; estimate of unobserved messages = 46 Total payload = 6MB
May 2010
Page 58

Figure 35 provides the results for a Skype video call in which the smartphone in the Rogers Wireless network called the smartphone in the TELUS network.
figure 35. RRc state transition changes due to a skype Video call test scenario 2
Cell_FACH
Cell_PCH
URA_PCH
Idle 11:59:15
11:59:35
11:59:45
12:00:00
12:00:15
12:00:30
12:00:45 12:01:00 Time
12:01:15
12:01:30
12:01:45
12:02:00
12:02:15
TELUS network observed signaling messages = 100; estimate of unobserved messages = 36 Total payload = 1.65MB Rogers Wireless network observed signaling messages = 91; estimate of unobserved messages = 40 Total payload = 1.72MB
May 2010
Page 59

Finally, Figure 36 and Figure 37 show the results for another test that involved the repeat of a test in which we downloaded three emails from our POP3 server, including one with an attachment, after which point we responded to the first message with a simple reply indicating that we had received the message.
Cell_FACH
Cell_PCH
URA_PCH
Idle 14:21:40 14:21:50 14:22:00 14:22:10 14:22:20 14:22:30 Time Rogers Wireless network observed signaling messages = 91; estimate of unobserved messages = 40 Total payload = 61.8kB
14:22:40
14:22:50
14:23:00
14:23:10
14:23:20
May 2010
Page 60

Cell_FACH
Cell_PCH
URA_PCH
Idle 13:38:15 13:38:30 13:38:45 13:39:00 13:39:15 13:39:30 13:39:45 Time TELUS network observed signaling messages = 55; estimate of unobserved messages = 40 Total payload = 64.2kB
13:40:00
13:40:15
13:40:30
13:40:45
13:41:00
13:41:15
May 2010
Page 61

May 2010
www.signalsresearch.com Page 62

Signals Research - Smart Phones and A 3G Network May 2010

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Signals Research - Smart Phones and A 3G Network May 2010

Încărcat de

Drepturi de autor:

Formate disponibile

SmartphoneS and a 3G network

smartphones and a 3g network

smartphones and a 3g network

smartphones and a 3g network

smartphones and a 3g network

smartphones and a 3g network

smartphones and a 3g network

smartphones and a 3g network

smartphones and a 3g network

smartphones and a 3g network

table 1. summary of test Results

N.M. N.M. N.M.

N.M. N.M. N.M.

329 329 298

399 451 342

-65% -52% -21% -58% -44% -41% -49% -42%

-18% -27% -13% -22% -12% -14% -16% -

172 361 350 320 62 -

-50% -29% 7% -26%

412 408 383

-12% -36% -22% -27% -21% -23% -55% -10% -19% 4%

Receiving an Incoming Phone Call

smartphones and a 3g network

smartphones and a 3g network

3.1. RRC Connection States

smartphones and a 3g network

figure 1. RRc connection states

1-3 s high signaling effort

*Terminal energy consumption

smartphones and a 3g network

3.2. Smartphone-generated Signaling in a 3G Network

3.3. Keep Alive Messages

smartphones and a 3g network

3.4. Fast Dormancy

3.5. Tracing the Root Cause of 3G Network Congestion

smartphones and a 3g network

smartphones and a 3g network

4.1. Test Methodology

smartphones and a 3g network

4.2. Baseline Measurements

figure 2. nokia n97 in the idle state telus network

Source: Signals Research Group, LLC

smartphones and a 3g network

figure 3. nokia n97 in the idle state Rogers wireless network

Source: Signals Research Group, LLC

smartphones and a 3g network

200 Backlight goes on

smartphones and a 3g network

Source: Signals Research Group, LLC

smartphones and a 3g network

4.3. Keep Alive Messages

figure 6. RRc state transitions due to keep alive messages

Source: Signals Research Group, LLC

smartphones and a 3g network

figure 7. current Requirements due to keep alive messages

Time Average current requirement during keep alive message = 260mA

Source: Signals Research Group, LLC

smartphones and a 3g network

table 2. the impact of keep alive messages on battery life

smartphones and a 3g network

4.4. Chatting with a friend using Yahoo IM

figure 8. RRc state transition changes due to yahoo im test scenario 4