Signals research -_smartphones_and_a_3_g_network_may_2010[1]

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 connec-tion 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 sophis-ticated 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 networkReducing the impact of smaRtphone-geneRated 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

Page 2May 2010


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 …………………………………………………………………………………………… 5

2. Introduction ……………………………………………………………………………………………………… 11

3. Technical Background …………………………………………………………………………………………123.1. RRC Connection States …………………………………………………………………………………123.2. Smartphone-generated Signaling in a 3G Network ………………………………………………143.3. “Keep Alive” Messages ……………………………………………………………………………………143.4. Fast Dormancy …………………………………………………………………………………………… 153.5. Tracing the Root Cause of 3G Network Congestion …………………………………………… 15

4. Detailed Results ………………………………………………………………………………………………… 174.1. Test Methodology ………………………………………………………………………………………… 174.2. Baseline Measurements …………………………………………………………………………………184.3. Keep Alive Messages ………………………………………………………………………………… 224.4. Chatting with a friend using Yahoo IM …………………………………………………………… 254.5. Keeping Track of a Friend with the FindMe Application …………………………………… 294.6. Downloading Large Files ………………………………………………………………………………… 314.7. Web Browsing/Internet Surfing ………………………………………………………………………334.8. Sending and Receiving Email ……………………………………………………………………………374.9. Using Nokia Maps to Find a Museum in Old Montreal ……………………………………… 394.10. Watching a YouTube Video ……………………………………………………………………………414.11 Making a Skype Video Call …………………………………………………………………………… 424.12. Receiving an Incoming Voice Call ………………………………………………………………… 43

5. Conclusions …………………………………………………………………………………………………… 47

6. Appendix 1 – Additional Results ………………………………………………………………………… 48

Page 3May 2010



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

index of tablestable 1. Summary of Test Results…………………………………………………………………………………10table 2. The Impact of “Keep Alive” Messages on Battery Life ……………………………………… 24table 3. Detailed Log File of Signaling Messages during an IM Session – TELUS Network (Test Scenario 4) …………………………………………………………………………… 50table 4. Detailed Log File of Signaling Messages during an IM Session Part One – Rogers Wireless Network (Test Scenario 4) ………………………………………………………………… 51table 5. Detailed Log File of Signaling Messages during an IM Session Part One – Rogers Wireless Network (Test Scenario 4) …………………………………………………………………52

Page 4May 2010



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

Page 5May 2010



1. Executive SummaryOver 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 isn’t the data traffic being generated by smartphones that is creating network congestion in today’s 3G networks, but the underlying signaling traffic due to the chattiness of various appli-cations, 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 smart-phone 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 operator’s 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

Page 6May 2010



at exponential rates. And it is this unexpected level of signaling traffic that is creating conges-tion in today’s 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 gener-➤➤

ators 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 wouldn’t 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 operator’s 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.

Page 7May 2010



“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 one’s hip pocket.

An operator that has implemented Cell_PCH and selected appropriate network inac-➤➤

tivity 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 imple-mented 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 smartphone-generated signaling traffic is due to the various Radio Resource Control (RRC) state tran-sition 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

Page 8May 2010



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 manufac-➤➤

turers, 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 tech-niques 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

Page 9May 2010



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 wire-less 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 smart-phones 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 tran-sitions 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.

Page 10May 2010



Application

No. of Observed Signaling Messages

Est. No. of Unobserved Signaling Messages

Average Current Consumption (mA) Message

Count Comparison

(%)

Current Consumption Comparison

(%)TELUS (NSN)

Rogers Wireless

TELUS (NSN)

Rogers Wireless TELUS (NSN) Rogers

WirelessIdle state (no application running)

Test Scenario 1 (no backlight)

0 0 0 0 43 35 N.M. N.M.

Test Scenario 2 (backlight) 0 0 0 0 275 268 N.M. N.M.

fring (keep alive messages)

Test Scenario 1 (per message)

40-50 40-45 2-20 20 260 260 N.M. N.M.

Yahoo IM

Test Scenario 1 128 248 22 180 - - -65% -

Test Scenario 2 123 179 20 120 - - -52% -

Test Scenario 3 138 118 18 80 - - -21% -

Test Scenario 4 306 517 28 280 - - -58% -

Test Scenario 5 220 289 32 160 329 399 -44% -18%

Test Scenario 6 211 260 26 140 329 451 -41% -27%

Test Scenario 7 208 294 30 174 298 342 -49% -13%

FindMe

Test Scenario 1 211 299 56 160 -42% -

Test Scenario 2 199 318 58 200 172 221 -50% -22%

Downloading Large Files

Test Scenario 1 129 180 46 68 - - -29% -

Test Scenario 2 121 108 38 40 - - 7% -

Test Scenario 3 153 182 48 90 - - -26% -

Web Browsing

Test Scenario 1 337 284 58 164 361 412 -12% -12%

Test Scenario 2 286 339 64 210 350 408 -36% -14%

Test Scenario 3 402 408 96 234 320 383 -22% -16%

Sending and Receiving Email

Test Scenario 1 55 91 40 40 - - -27% -

Test Scenario 2 73 88 44 60 - - -21% -

Nokia Maps

Test Scenario 1 138 160 32 60 - - -23% -

Test Scenario 2 134 246 26 110 - - -55% -

Watching a YouTube Video

Test Scenario 1 107 107 34 50 - - -10% -

Skype Video Call

Test Scenario 1 105 109 32 60 - - -19% -

Test Scenario 2 100 91 36 40 - - 4% -

Bloomberg

Test Scenario 1 123 180 20 40 62 108 -35% -

Receiving an Incoming Phone Call

Test Scenario 11 44 62 20 20 - - -22% -

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

table 1. summary of test Results

Page 11May 2010



2. IntroductionIn 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-gener-ated 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 infrastruc-ture 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.

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 company’s 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 operator’s 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 opera-tors 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 doesn’t 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 tech-nical 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 smartphone-generated signaling is a problem in today’s 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.

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.

Page 12May 2010



3. Technical BackgroundIn 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 StatesThere 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 isn’t 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 doesn’t 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 communi-cating 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

Page 13May 2010



number of physical channels, depending on the required bandwidth. When a mobile phone is 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 200mA.

There are also three inactivity timers that are used to determine when a handset or smartphone 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 state. The T2 timer is associated with the Cell_FACH state and it is used in a similar fashion 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.

Figure 1 illustrates the aforementioned RRC connection states, their associated current require-ments, and the recommended timer settings as defined by Nokia Siemens Networks. These recommendations assume the use of Cell_PCH.

DCH/HSPA>200mA*

FACH>100mA*

PCH<5mA*

IDLE<5mA*

<500ms

<100ms

*Terminal energy consumption

1-3

s hi

gh s

igna

ling

effo

rt

DCH/HSPA>200mA*

FACH>100mA*

PCH<5mA*

IDLE<5mA*

<500ms Set T1 to <5s

<100ms Set T2 to <5s

Set T3 to >20min

*Terminal energy consumption

1-3

s hi

gh s

igna

ling

effo

rt

figure 1. RRc connection states

Source: Nokia

Page 14May 2010



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. Obvi-ously, 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 NetworkBy 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 isn’t 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 an appreciably high number of data connec-tions 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” MessagesIn 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 subscriber’s knowledge. These messages originate within the smartphone or social networking application itself and are used to provide an update on the subscriber’s 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 isn’t 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

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 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.

Page 15May 2010



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 differ-ence 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 back-ground. Conversely, not even the busiest mobile phone user can claim to be making 30+ voice calls every hour of every day.

3.4. Fast DormancyAs 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 CongestionIn 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 today’s 3G networks. However, we can offer some food for thought which will hopefully make

Page 16May 2010



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 operator’s 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 depen-dent, 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 gener-ally 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, opera-tors 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).

In other words, it can’t 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 perfor-mance associated with processing these messages would impact the network element’s 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 today’s 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.

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.

Page 17May 2010



4. Detailed ResultsIn this chapter we present results from numerous test scenarios which attempted to replicate likely usage patterns associated with today’s 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 MethodologyAll 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.

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 post-processing 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

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.

Page 18May 2010



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 MeasurementsBefore 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.

Observed signaling messages = 0

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH

14:30:00 14:35:00 14:40:00 14:45:00 14:50:00 14:55:00 15:00:00 15:05:00 15:10:00

TELUS (NSN) Network

Time

figure 2. nokia n97 in the idle state – telus network


Page 19May 2010



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

Observed signaling messages = 0

14:30:00 14:35:00 14:40:00 14:45:00 14:50:00 14:55:00 15:00:00 15:05:00 15:10:00

Rogers Wireless Network

Time

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 20May 2010



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 can’t 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


0

100

200

300

400

mA

Backlight goes off

Backlight goes on

TELUS (NSN) Network with backlight off = 43mA (123% of Rogers Wireless)

Rogers Wireless Network with backlight off = 35mA

14:30

.5

14:32

.0

14:33

.1

14:34

.2

14:35

.3

14:36

.4

14:37

.5

14:38

.6

14:4

0.1

14:4

1.2

14:4

2.3

14:4

3.4

14:4

4.5

14:4

5.6

14:47

.1

14:4

8.2

14:4

9.3

14:50

.4

14:51

.5

14:52

.6

14:54

.1

14:55

.2

14:56

.3

14:57

.4

14:58

.5

14:59

.6

15:0

1.1

15:0

2.2

15:0

3.3

15:0

4.4

15:0

5.5

15:0

6.6

15:0

8.1

15:0

9.1

15:10

.2

14:2

9.4

Time


Page 21May 2010



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 consump-tion 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 consump-tion 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 Blue-tooth 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

mA

Time

12:35

.2

12:31

.1

12:31

.2

12:31

.3

12:31

.3

12:31

.4

12:31

.5

12:31

.5

12:32

.0

12:32

.1

12:32

.2

12:32

.2

12:32

.3

12:32

.4

12:32

.5

12:32

.5

12:33

.0

12:33

.1

12:33

.1

12:33

.2

12:33

.3

12:33

.4

12:33

.4

12:33

.5

12:33

.6

12:34

.1

12:34

.1

12:34

.2

12:34

.3

12:34

.3

12:34

.4

12:34

.5

12:34

.6

12:35

.0

12:35

.1

0

100

200

300

400

TELUS (NSN) Network with backlight on = 275mA (103% of Rogers Wireless)

Rogers Wireless Network with backlight on = 268mA

M1 M2

TELUS (NSN) Network



Page 22May 2010



4.3. Keep Alive MessagesIn 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

“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


Time07:40:00 07:50:00 08:00:00 08:10:00 08:20:00 08:30:00 08:40:00

TELUS (NSN) Network


RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 23May 2010



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 today’s 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 require-ments 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


mA

Average current requirement during “keep alive” message = 260mA

Time

0

100

200

300

400

500

600

700

07:35

.1

07:37

.1

07:39

.1

07:4

1.1

07:4

3.1

07:4

5.1

07:47

.1

07:4

9.1

07:51

.1

07:53

.1

07:55

.1

07:57

.1

07:59

.1

08:0

1.1

08:0

3.1

08:0

5.1

08:0

7.1

08:0

9.1

08:11

.1

08:13

.1

08:15

.1

08:17

.1

08:19

.1

08:2

1.1

08:2

3.1

08:2

5.1

08:2

7.1

08:2

9.1

08:31

.1

08:33

.1

08:35

.1

08:37

.1

08:39

.1

08:4

1.1

08:4

3.1

08:4

5.1


Page 24May 2010



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) Time Required to Equate to a Full Hour of the Backlight Turned On (hours)

1 7.53

2 15.06

3 22.59

4 30.12


Page 25May 2010



4.4. Chatting with a friend using Yahoo IMIn this scenario we will examine the impact of an instant messaging session between two smart-phones. 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

Time

Start

M1 M1

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

Rogers Wireless network observed signaling messages = 517: estimate of unobserved messages = 280➤ M1 messages = 96; M2 messages = 65➤ Observed T2 Timer Setting = 3.3 sec

Start

11:35:00 11:36:00 11:37:00 11:38:00 11:39:00 11:40:00 11:41:00 11:42:00

TELUS (NSN) Network


RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 26May 2010



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.

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 wasn’t possible for us to determine at what point there was inactivity in the channel.

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.

Page 27May 2010



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.


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

Rogers Wireless network observed signaling messages = 294: estimate of unobserved messages = 174➤ M1 messages = 62

TELUS (NSN) Network


Time

12:24:00 12:25:00 12:26:00 12:27:00 12:28:00 12:29:00 12:30:00 12:31:00 12:32:00

M1

Start

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 28May 2010



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 network average current requirement = 298mA➤ M1 = 277mA; M2 = 291mA

Rogers Wireless network average current requirement = 342mA➤ M1 = 406mA; M2 = 388mA

TELUS (NSN) Network


mA

Time

0

100

200

300

400

500

600

700

12:2

2.4

12:2

2.5

12:2

3.1

12:2

3.2

12:2

3.4

12:2

3.6

12:2

4.1

12:2

4.3

12:2

4.4

12:2

4.6

12:2

5.1

12:2

5.3

12:2

5.4

12:2

5.6

12:2

6.1

12:2

6.3

12:2

6.4

12:2

6.6

12:2

7.1

12:2

7.3

12:2

7.4

12:2

8.0

12:2

8.2

12:2

8.3

12:2

8.5

12:2

9.0

12:2

9.2

12:2

9.3

12:2

9.5

12:30

.0

12:30

.2

12:30

.3

12:30

.5

12:31

.0

12:31

.2

12:31

.3

M1 M2


Page 29May 2010



4.5. Keeping Track of a Friend with the FindMe ApplicationThe 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

TELUS (NSN) Network


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

Time

18:45:30 18:46:00 18:46:30 18:47:00 18:47:30 18:48:00 18:48:30 18:49:00 18:49:30 18:50:30 18:51:00

Start End

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 30May 2010



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

Time

mA

0

100

200

300

400

500

600

TELUS network average current requirement = 172mA

Rogers Wireless network average current requirement = 221mA

TELUS (NSN) Network


18:4

4.4

18:4

4.5

18:4

5.0

18:4

5.2

18:4

5.3

18:4

5.4

18:4

5.5

18:4

6.0

18:4

6.1

18:4

6.3

18:4

6.4

18:4

6.5

18:47

.0

18:47

.1

18:47

.2

18:47

.4

18:47

.5

18:47

.6

18:4

8.1

18:4

8.2

18:4

8.3

18:4

8.5

18:4

8.6

18:4

9.1

18:4

9.2

18:4

9.3

18:4

9.4

18:4

9.5

18:50

.1

18:50

.2

18:50

.3

18:50

.5

18:51

.0

18:51

.1

18:51

.3

18:50

.4


Page 31May 2010



4.6. Downloading Large FilesPrior 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 concur-rently downloading three whitepapers which appeared on the trade association’s 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

TELUS network observed signaling messages = 153; estimate of unobserved messages = 48➤ Total payload = 5.8MB

Time

13:39:00 13:39:30 13:40:00 13:40:30 13:41:00 13:41:30 13:42:00 13:42:30

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 32May 2010



Since this test scenario only resulted in a few RRC state transition changes the number of signaling messages on the two networks wasn’t 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 observed signaling messages = 182; estimate of unobserved messages = 90➤ Total payload = 5.8MB

Time13:52:30 13:53:00 13:54:00 13:54:30 13:55:00 13:55:30 13:56:00 13:56:30 13:57:30 13:58:00 13:58:30

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 33May 2010



4.7. Web Browsing/Internet SurfingIn 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

TELUS (NSN) Network


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

Time

13:22:00 13:23:00 13:24:00 13:25:00 13:26:00 13:27:00 13:28:00 13:29:00 13:30:00

M1

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 34May 2010



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 Wire-less 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

mA

TELUS network average current requirement = 350mA➤ M1 = 366mA

Rogers Wireless network average current requirement = 342mA➤ M1 = 464mA

Time

0

100

200

300

400

500

600

700

TELUS (NSN) Network


13:2

1.2

13:2

1.3

13:2

1.5

13:2

2.0

13:2

2.2

13:2

2.3

13:2

2.5

13:2

2.6

13:2

3.1

13:2

3.3

13:2

3.4

13:2

3.5

13:2

4.1

13:2

4.2

13:2

4.4

13:2

4.5

13:2

5.1

13:2

5.2

13:2

5.3

13:2

5.5

13:2

6.0

13:2

6.2

13:2

6.3

13:2

6.4

13:2

7.0

13:2

7.1

13:2

7.3

13:2

7.4

13:2

7.6

13:2

8.1

13:2

8.2

13:2

8.4

13:2

8.5

13:2

9.1

13:2

9.2

13:2

9.3

13:2

9.5

13:30

.0

13:30

.2

13:30

.3

M1


Page 35May 2010



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.


TELUS (NSN) Network


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

Time

10:42:00 10:43:00 10:44:00 10:45:00 10:46:00 10:47:00 10:48:00 10:49:00 10:50:00 10:51:00

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 36May 2010




mA



Time

0

100

200

300

400

500

600

700

TELUS (NSN) Network


10:4

1.0

10:4

1.2

10:4

1.4

10:4

1.6

10:4

2.2

10:4

2.3

10:4

2.5

10:4

3.1

10:4

3.3

10:4

3.4

10:4

4.0

10:4

4.2

10:4

4.4

10:4

4.5

10:4

5.1

10:4

5.3

10:4

5.5

10:4

6.0

10:4

6.2

10:4

6.4

10:4

6.6

10:47

.1

10:47

.3

10:47

.5

10:4

8.1

10:4

8.2

10:4

8.4

10:4

8.6

10:4

9.1

10:4

9.3

10:4

9.5

10:50

.1

10:50

.3

10:50

.4

10:51

.0

10:51

.2

10:51

.4

10:51

.5

10:52

.1


Page 37May 2010



4.8. Sending and Receiving EmailFor 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)

TELUS (NSN) Network

TELUS network observed signaling messages = 73; estimate of unobserved messages = 44➤ Total payload = 65kB

Time

13:59:30 13:59:40 13:59:50 14:00:00 14:00:10 14:00:20 14:00:30 14:00:40 14:00:50

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 38May 2010



figure 20. RRc state transition changes due to sending and Receiving email – Rogers wireless network (test scenario 3)


Rogers Wireless network observed signaling messages = 88: estimate of unobserved messages = 60➤ Total payload = 71kB

Time14:26:30 14:26:40 14:26:50 14:27:00 14:27:10 14:27:20 14:27:30 14:27:40 14:27:50 14:28:00

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 39May 2010



4.9. Using Nokia Maps to Find a Museum in Old MontrealFor 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

TELUS (NSN) Network


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

Time12:02:00 12:03:00 12:04:00 12:05:00 12:06:00 12:07:00 12:08:00 12:09:00

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 40May 2010



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).

Page 41May 2010



4.10. Watching a YouTube VideoOne 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 shouldn’t 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

TELUS (NSN) Network


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

Time18:55:00 18:55:30 18:56:00 18:56:30 18:57:00 18:57:30 18:58:00 18:58:30 18:59:00 18:59:30 19:00:00 19:00:30 19:01:00

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 42May 2010



4.11 Making a Skype Video CallFor 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

TELUS (NSN) Network


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

Time18:55:00 18:55:30 18:56:00 18:56:30 18:57:00 18:57:30 18:58:00 18:58:30 18:59:00 18:59:30 19:00:00 19:00:30 19:01:00

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 43May 2010



4.12. Receiving an Incoming Voice CallAlthough 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

TELUS (NSN) Network

TELUS network observed signaling messages = 44; estimate of unobserved messages = 20

Time16:58:30 16:58:45 16:59:00 16:59:15 16:59:30 16:59:45 17:00:00 17:00:15 17:00:30 17:00:45 17:01:00 17:01:15 17:01:30

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 44May 2010



figure 25. the impact of an incoming phone call on battery life – telus network

mA

Average current requirement ➤ idle; backlight on = 214mA➤ idle; backlight off = 44mA➤ active call; backlight on = 392mA ➤ active call; backlight off = 253mA

Time

0

100

200

300

400

500

600

16:58

.0

16:58

.1

16:58

.2

16:58

.2

16:58

.3

16:58

.4

16:58

.4

16:58

.5

16:58

.6

16:59

.0

16:59

.1

16:59

.2

16:59

.2

16:59

.3

16:59

.4

16:59

.4

16:59

.5

16:59

.6

17:0

0.0

17:0

0.1

17:0

0.2

17:0

0.3

17:0

0.3

17:0

0.4

17:0

0.5

17:0

0.5

17:0

1.0

17:0

1.1

17:0

1.1

17:0

1.2

17:0

1.3

17:0

1.3

17:0

1.4

17:0

1.5

17:0

1.6

17:0

2.0

TELUS (NSN) Network

Backlight goes out

Backlight goes out

Call endsIncoming call backlight comes on


Page 45May 2010



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


Rogers Wireless network observed signaling messages = 62; estimate of unobserved messages = 20

16:45:00 16:45:30 16:46:00 16:65:30 16:47:00 16:47:30 16:48:00 16:48:30 16:49:00 16:49:30 16:50:00

Time

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 46May 2010



mA

Average current requirement ➤ idle; backlight on = 289mA➤ idle; backlight off = 31mA➤ active call; backlight on = 386mA ➤ active call; backlight off = 241mA

Time

Backlight goes out

Backlight goes out

Call endsIncoming call backlight comes on

0

100

200

300

400

500

600

16:4

4.3

16:4

4.4

16:4

4.5

16:4

5.0

16:4

5.1

16:4

5.2

16:4

5.4

16:4

5.5

16:4

5.6

16:4

6.1

16:4

6.2

16:4

6.3

16:4

6.4

16:4

6.5

16:47

.0

16:47

.1

16:47

.3

16:47

.4

16:47

.5

16:47

.6

16:4

8.1

16:4

8.2

16:4

8.3

16:4

8.5

16:4

8.6

16:4

9.1

16:4

9.2

16:4

9.3

16:4

9.4

16:4

9.5

16:50

.0

16:50

.2

16:50

.3

16:50

.4

16:50

.5

16:50

.6


figure 27. the impact of an incoming phone call on battery life – Rogers wireless network


Page 47May 2010



5. ConclusionsThe 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 operator’s 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 opera-tors 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.

Page 48May 2010



6. Appendix 1 – Additional ResultsIn 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 informa-tion. We also include some of the detailed log files in this section.

Figure 28 and Figure 29 provide results for a Yahoo IM session.


TELUS (NSN) Network


TELUS network observed signaling messages = 211; estimate of unobserved messages = 26 Rogers Wireless network observed signaling messages = 260: estimate of unobserved messages = 140

Time

12:53:00 12:53:30 12:54:00 12:54:30 12:55:00 12:55:30 12:56:00 12:56:30 12:57:00 12:57:30 12:58:00 12:58:30 12:59:00

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 49May 2010



figure 29. the impact of an instant messaging session on battery life – test scenario 6

mA



Time

0

100

200

300

400

500

600

700

800

12:52

.6

12:53

.1

12:53

.2

12:53

.2

12:53

.3

12:53

.4

12:53

.5

12:54

.0

12:54

.1

12:54

.2

12:54

.3

12:54

.4

12:54

.5

12:54

.6

12:55

.1

12:55

.2

12:55

.2

12:55

.3

12:55

.4

12:55

.5

12:56

.0

12:56

.1

12:56

.2

12:56

.3

12:56

.4

12:56

.5

12:56

.5

12:57

.0

12:57

.1

12:57

.2

12:57

.3

12:57

.4

12:57

.5

12:57

.6

12:58

.1

12:58

.2

12:58

.2

12:58

.3

12:58

.4

TELUS (NSN) Network



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.

Page 50May 2010



Time RRC State Direction Channel Message Type

36:50.9 Cell PCH

36:50.9 Downlink DCCH PHYSICAL_CHANNEL_RECONFIGURATION

36:50.9 Uplink DCCH PHYSICAL_CHANNEL_RECONFIGURATION_COMPLETE

37:04.5 Cell FACH

37:04.5 Uplink CCCH CELL_UPDATE

37:04.8 Downlink DCCH CELL_UPDATE_CONFIRM

37:04.8 Uplink DCCH UTRAN_MOBILITY_INFORMATION_CONFIRM

37:07.8 Cell PCH



37:16.5 Cell FACH


37:16.7 Downlink CCCH CELL_UPDATE_CONFIRM_CCCH



37:21.7 Cell PCH



37:46.1 Downlink PCCH PAGING_TYPE_1

37:46.2 Cell FACH




37:49.9 Cell PCH



37:51.5 Cell FACH




37:52.8 Downlink CCCH RRC_CONNECTION_SETUP

37:54.4 Cell PCH



table 3. detailed log file of signaling messages during an im session – telus network (test scenario 4)


Page 51May 2010




37:00.7 Downlink DCCH RADIO_BEARER_RECONFIGURATION

37:01.0 Cell FACH



37:01.2 Cell FACH

37:01.2 Uplink DCCH RADIO_BEARER_RECONFIGURATION_COMPLETE






37:04.3 Downlink DCCH RRC_CONNECTION_RELEASE

37:04.3 Idle

37:04.3 Uplink DCCH RRC_CONNECTION_RELEASE_COMPLETE

37:04.6 Idle

37:07.9 Downlink PCCH PAGING_TYPE_1

37:07.9 Uplink DCCH SERVICE_REQUEST

37:07.9

37:07.9 Cell FACH

37:07.9 Uplink CCCH RRC_CONNECTION_REQUEST


37:08.4 Cell DCH

37:08.4 Cell DCH

37:08.4 Uplink DCCH INITIAL_DIRECT_TRANSFER

37:08.4 Uplink DCCH DCCH_RRC_CONNECTION_SETUP_COMPLETE

37:08.7 Downlink DCCH MEASUREMENT_CONTROL



37:08.8 Downlink DCCH SECURITY_MODE_COMMAND

37:08.8 Uplink DCCH SECURITY_MODE_COMPLETE

37:09.0 Downlink DCCH RADIO_BEARER_SETUP

37:09.1 Uplink DCCH MEASUREMENT_REPORT



37:09.5 Cell DCH

37:09.5 Uplink DCCH RADIO_BEARER_SETUP_COMPLETE



table 4. detailed log file of signaling messages during an im session part one – Rogers wireless network (test scenario 4)


Page 52May 2010




37:30.0 Cell FACH

37:30.0 Cell FACH










37:33.3 Idle



37:33.4

37:33.5 Idle

37:35.8


37:35.8 Cell FACH



37:36.2 Cell DCH

37:36.2 Cell DCH










37:37.3 Cell DCH



table 5. detailed log file of signaling messages during an im session part one – Rogers wireless network (test scenario 4)


Page 53May 2010



37:41.8 Idle






37:41.9

37:42.8


37:42.8 Cell FACH



37:43.2 Cell DCH

37:43.2 Cell DCH








37:44.6 Cell DCH






table 5. detailed log file of signaling messages during an im session part one – Rogers wireless network (test scenario 4), con’t.


Page 54May 2010



Figure 30 and Figure 31 provide the results for a web browsing session.


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

Time

13:06:00 13:07:00 13:08:00 13:09:00 13:10:00 13:11:00 13:12:00 13:13:00

TELUS (NSN) Network


RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 55May 2010




mA



Time

TELUS (NSN) Network


0

100

200

300

400

500

600

700

800

13:0

5.2

13:0

5.4

13:0

5.5

13:0

6.0

13:0

6.2

13:0

6.3

13:0

6.4

13:0

6.6

13:0

7.1

13:0

7.2

13:0

7.4

13:0

7.5

13:0

8.0

13:0

8.2

13:0

8.3

13:0

8.4

13:0

8.6

13:0

9.1

13:0

9.2

13:0

9.4

13:0

9.5

13:10

.0

13:10

.2

13:10

.3

13:10

.4

13:10

.6

13:11

.1

13:11

.2

13:11

.4

13:11

.5

13:12

.0

13:12

.2

13:12

.3

13:12

.4

13:12

.6

13:13

.1

13:13

.2

13:13

.4

13:13

.5

13:14

.0


Page 56May 2010



Figure 32 illustrates the results from a test in which we used the Bloomberg smartphone appli-cation 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

TELUS network Cell_PCH Time = 18 min 16 sec

Time

14:45:00 14:50:00 14:55:00 15:00:00 15:05:00

TELUS (NSN) Network


RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 57May 2010



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)

Rogers Wireless network observed signaling messages = 180; estimate of unobserved messages = 68➤ Total payload = 6MB

Time

14:06:30 14:07:3014:07:00 14:08:3014:08:00 14:09:3014:09:00 14:10:3014:10:00


RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 58May 2010



figure 34. RRc state transition changes due to downloading large files – telus network (test scenario 1)

TELUS network observed signaling messages = 129; estimate of unobserved messages = 46➤ Total payload = 6MB

Time

14:22:00 14:22:15 14:22:30 14:22:45 14:23:00 14:23:15 14:23:30 14:24:00 14:24:15 14:24:3014:23:45

TELUS (NSN) Network

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 59May 2010



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

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

Time

11:59:15 11:59:35 11:59:45 12:00:00 12:00:15 12:00:30 12:00:45 12:01:00 12:01:15 12:01:30 12:01:45 12:02:00 12:02:15

TELUS (NSN) Network


RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 60May 2010



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 attach-ment, after which point we responded to the first message with a simple reply indicating that we had received the message.


Rogers Wireless network observed signaling messages = 91; estimate of unobserved messages = 40➤ Total payload = 61.8kB

Time

14:21:40 14:21:50 14:22:00 14:22:10 14:22:20 14:22:30 14:22:40 14:22:50 14:23:00 14:23:10 14:23:20


RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 61May 2010




TELUS network observed signaling messages = 55; estimate of unobserved messages = 40➤ Total payload = 64.2kB

Time

13:38:15 13:38:30 13:38:45 13:39:00 13:39:15 13:39:30 13:39:45 13:40:00 13:40:15 13:40:30 13:40:45 13:41:00 13:41:15

TELUS (NSN) Network

RRC State

Idle

URA_PCH

Cell_PCH

Cell_FACH

Cell_DCH


Page 62May 2010




Technology

Signals research -_smartphones_and_a_3_g_network_may_2010[1]