Signals research -_smartphones_and_a_3_g_network_may_2010[1]

Smartphones and
a 3G Network
Reducing the impact of smartphonegenerated signaling traffic while
increasing the battery life of the
phone through the use of network
optimization techniques
May 2010
Prepared by Signals Research Group, LLC
Paper developed for Nokia Siemens Networks

www.signalsresearch.com

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

Smartphones and a 3G Network

Reducing the impact of smartphone-generated signaling traffic while increasing the battery life of the phone through
the use of network optimization techniques

Table of Contents
1. Executive Summary…

……………………………………………………………………………………………

5

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

May 2010

Page 2



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

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

Page 3



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

May 2010

Page 4




1. Executive Summary
Over the last several months, Signals Research Group, LLC (SRG) has been looking at the
impact of smartphones on 3G network congestion with a particular focus on the signaling
traffic that the smartphones generate. Although perhaps surprising to some industry followers,
it 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 applications, the popularity of social networking services, and the typical user behavior patterns
associated with normal smartphone usage. In addition to impacting the performance of the 3G
network, the excessive signaling traffic has a direct impact on the expected life of the smartphone battery.
In this whitepaper we present results from concurrent testing that was done in two different 3G
networks during the week of April 19, 2010. By leveraging a sophisticated network drive test
solution we were able to monitor the signaling traffic that a smartphone generates while using
popular applications, such as Instant Messaging (IM), web browsing, tracking the location of
a friend, watching a YouTube video, and downloading files via a web browser or through an
email application. And since we were simultaneously conducting the tests in two different 3G
networks, one which was supplied by Nokia Siemens Networks, we were able to determine if
an operator and its infrastructure partner can limit the amount of signaling traffic that is being
generated while not decreasing the life of the battery, and frequently extending the life of the
battery, through features that the vendor supports as well as by other network optimization
techniques that we describe in this whitepaper.
Key conclusions and observations discussed in this whitepaper include the following:
➤➤

3G network congestion is due largely to the high amount of smartphone-generated
signaling traffic which is fully utilizing the resources of central network elements, thus
preventing them from coping with the data traffic. Network congestion, when it exists,
generally encompasses entire cities or markets even though high data usage is concentrated
among a very small percentage of an 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

May 2010

Page 5




at exponential rates. And it is this unexpected level of signaling traffic that is creating congestion 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 generators of signaling traffic. Social networking applications, in which friends stay connected
with each other for extended periods of time, inherently involve frequent back and forth
messages or status updates. Instant messaging services, such as Yahoo IM and Skype, and
other popular services, such as Facebook or various friend tracker applications, are just some
of the examples while if someone is “connected” it 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.

May 2010

Page 6




➤➤“Keep alive” messages can also have a material impact on the expected life of the battery.

Since these “keep alive” messages bring the handset to a connected state called Cell_DCH,
where the current requirements for the radio portion of the handset are the highest (>200mA)
from the Idle state where the current requirements are the lowest (~5mA), there is an obvious
impact on the battery life of the smartphone. Although a single message only has a trivial
impact on the battery life, the collective sum of their impact over a 24 hour period can be
substantial.
In the Detailed Results chapter we demonstrate that over the course of an eight hour period
some applications generate enough “keep alive” messages to consume as much energy as
required to keep the backlight turned on a smartphone for a full hour. Most consumers
appreciate the importance of preserving battery life and take appropriate measures to limit
the amount of time that the backlight remains lit. And if asked, very few consumers would
be willing to leave their backlight turned on for a full sixty minutes before heading out of
the home in the morning. Yet these “keep alive” messages are having a similar effect on the
battery life, even when the phone is seemingly not being used and resting on a desk or stored
safely in one’s hip pocket.
➤➤ An

operator that has implemented Cell_PCH and selected appropriate network inactivity timer settings is able to significantly reduce the amount of signaling traffic in
its network while increasing the expected lifetime of the battery. When conducting
our network tests, we had the opportunity to use two different 3G networks in order to
measure the amount of signaling traffic that we were generating under largely identical
circumstances and usage scenarios. In one network, the operator (NSN supplied) had implemented Cell_PCH and selected appropriate network inactivity timer settings to correspond
with the Cell_PCH feature. As we discuss later in this whitepaper, a lot of the smartphonegenerated signaling traffic is due to the various Radio Resource Control (RRC) state transition changes that take place when a handset needs to connect to the network in order to
send or receive data, only to disconnect shortly thereafter, or after it has stopped sending or
receiving the data. In theory, these optimization techniques can reduce the number of state
transitions that take place, in particular those state transition changes that generate the most
signaling traffic.

Based on our test results, we conclude that the combination of Cell_PCH and the selection
of appropriate T1, T2 and T3 timer settings can significantly reduce the amount of signaling
traffic while increasing the life of the battery. The exact benefit is difficult to quantify since it
depends on the usage scenario, but we observed as much as a 65% reduction in the amount of
signaling traffic, after taking into consideration the reduction in signaling traffic which took
place within the network, and thus not captured by the test equipment in our handset.
Although these savings were not universal across all applications and usage scenarios, these
results did occur during normal usage scenarios involving IM (signaling reduction) and web
surfing (power savings), as examples. In the case of IM, the reduction in the amount of
signaling traffic, which ranged from 21% to 65%, was due to the combined use of Cell_PCH
May 2010

Page 7




when the handset was inactive and Cell_FACH when the handset was sending and/or
receiving data. Conversely, the other handset returned to the Idle state during each period
of inactivity since Cell_PCH was not implemented in the network, thus when the handset
returned to Cell_DCH when it needed to send/receive data it generated a large amount of
signaling traffic. Said another way, far more signaling messages are inherently required for a
handset to move from the Idle state to the Cell_DCH state than are required to move from
Cell_PCH to Cell_FACH. We explain these states and the definition of the three network
inactivity timer settings in more detail in Chapter 3 of this whitepaper.
We also observed as much as a 27% reduction in current consumption in some of the test
scenarios. The reduction in current consumption was due to two factors. First, with the
use of Cell_PCH the operator could use more aggressive timer settings, thus more quickly
returning the handset to a lower connection state where the current requirements are lower.
This phenomenon was most prevalent during web browsing where the handset in the network
using Cell_PCH fairly consistently exited those connection states which have the greatest
impact on current consumption before the other handset in the non-Cell_PCH network.
Second, the handset in the network using Cell_PCH was also able to use Cell_FACH
(versus Cell_DCH) to send and receive IMs. By making use of CELL_FACH the handset
required nearly 50% less current than the handset which used the CELL_DCH state to
send/receive IMs.
With other applications, such as watching a YouTube video and downloading large files,
which involved very few state transitions and long periods of connectivity during which time
large amounts of data were transferred, the savings was less dramatic, and at the extreme the
savings was negligible.
➤➤ The

wireless industry, including operators, infrastructure suppliers, handset manufacturers, and application developers, needs to work together to address these challenges.
Although one obvious solution to the problem of smartphone-generated signaling traffic is
for operators to implement Cell_PCH – not necessarily an easy step if the infrastructure
supplier does not support the feature – there are other appropriate steps that the industry
needs to consider as well.
First, handset manufacturers need to understand the impact that their design decisions have
on the 3G network. Battery-saving techniques, such as fast dormancy, may go a long ways
toward increasing the life of the battery, but if not intelligently implemented, these techniques could result in a large number of unnecessary signaling messages. There is definitely a
tradeoff between having a smartphone with a longer battery life and its ability to minimize
the amount of signaling traffic that it generates. It is also generally in the best interest of the
handset manufacturer to maximize its battery life since consumers judge a handset based on
how long the battery lasts and not on how much signaling traffic it generates.
Mobile operators, on the other hand, are another matter. They have the ability to accept or
reject a smartphone based on the impact that the smartphone will have on its network while

May 2010

Page 8



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

May 2010

Page 9




Table 1. Summary of Test Results
Application

No. of Observed
Signaling Messages

TELUS
(NSN)
Idle state (no application running)

Est. No. of Unobserved
Signaling Messages

Rogers
Wireless

TELUS
(NSN)

Rogers
Wireless

Average Current
Consumption (mA)
TELUS (NSN)

Rogers
Wireless

Message
Count
Comparison
(%)

Current
Consumption
Comparison
(%)

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.

40-50

40-45

2-20

20

260

260

N.M.

N.M.

fring (keep alive messages)
Test Scenario 1 (per
message)
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%

Test Scenario 1

211

299

56

160

-42%

-

Test Scenario 2

199

318

58

200

172

221

-50%

-22%

129

180

46

68

-

-

-29%

-

Test Scenario 2

121

108

38

40

-

-

7%

-

Test Scenario 3

153

182

48

90

-

-

-26%

-

337

284

58

164

361

412

-12%

-12%

FindMe

Downloading Large Files
Test Scenario 1

Web Browsing
Test Scenario 1
Test Scenario 2

286

339

64

210

350

408

-36%

-14%

Test Scenario 3

402

408

96

234

320

383

-22%

-16%

Test Scenario 1

55

91

40

40

-

-

-27%

-

Test Scenario 2

73

88

44

60

-

-

-21%

-

Sending and Receiving Email

Nokia Maps
Test Scenario 1

138

160

32

60

-

-

-23%

-

Test Scenario 2

134

246

26

110

-

-

-55%

-

107

107

34

50

-

-

-10%

-

Test Scenario 1

105

109

32

60

-

-

-19%

-

Test Scenario 2

100

91

36

40

-

-

4%

-

123

180

20

40

62

-35%

-

62

20

20

-

-22%

-

Watching a YouTube Video
Test Scenario 1
Skype Video Call

Bloomberg
Test Scenario 1

108

Receiving an Incoming Phone Call
Test Scenario 11

44

-

1
Results influenced by more paging channel messages on the Rogers Network (there was a longer period of time before the phone was answered) In theory, for this particular test
scenario the results should be identical.
Source: Signals Research Group, LLC

May 2010

Page 10



2. Introduction
In January 2010, Signals Research Group, LLC (SRG) published a report as part of its Signals
Ahead subscription-based research service which looked at the presence of smartphone-generated signaling traffic and its impact on a 3G network (SA 012810, “The Trouble with Twitters”).
That report leveraged countless interviews with operators and many of the leading infrastructure vendors, handset manufacturers, and chipset suppliers in order to document the challenges
facing 3G operators when their networks are burdened by smartphones, which generate a
disproportionate amount of signaling traffic.
This study is a natural follow-on to a
published report that we did as part
of our subscription-based Signals
Ahead research service with the test
methodology and many of the test
scenarios used in this study largely
reflective of that first initiative.

As part of the research that went into the report, we collaborated with Anite who provided us
with access to two smartphones, complete with the 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 operators and vendors pertaining to this topic. We were also asked by Nokia Siemens Networks
(NSN) to conduct a follow-on commissioned study to determine how much influence an operator
and its infrastructure provider partner have on reducing the amount of signaling traffic. To be
specific, we were asked to document the relative impact of a 3G network that has implemented
Cell_PCH, along with selecting appropriate network timer settings (e.g., T1, T2 and T3), on
both smartphone-generated signaling traffic and the battery life of the smartphone versus a 3G
network that has not implemented Cell_PCH and which is using timer settings that are more
appropriate for a network that 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 technical questions which came up during the course of our study, NSN had no involvement in the
data collection and the analysis of the results. That responsibility relied solely on SRG.
Chapter 3 contains some technical background information which highlights why smartphonegenerated signaling is a problem in 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.

May 2010

Page 11



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

3.1. RRC Connection States
There are four primary RRC (Radio Resource Control) states in a 3G network: Idle, Cell_PCH,
Cell_FACH and Cell_DCH. Of these four states, the last three states indicate various levels of
being connected to the network, albeit the definition of being connected varies widely between
the three states. As we will point out in this section, when a device is connected to the network
it is generally consuming at least some network resources while transitioning between the
various RRC states can generate a little or a lot of signaling traffic. Finally, the RRC state has
an impact on the battery life with some states requiring considerably more current consumption
than other states.
Idle. When in Idle mode the mobile phone is basically dormant and not communicating with
the network although it does listen for certain broadcast messages. In this state the radio portion
of the phone 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 communicating with the network via a shared channel and the network (RNC) knows where the mobile
phone is located, thus the mobile phone is consuming network resources – both in terms of air
interface capacity as well as with respect to RNC processing power (more on this in a bit). In
the current implementation of HSPA, small bits of data can be transmitted while in the Cell_
FACH state at a relatively low data rate, or on the order of up to 64kbps in the downlink and
8-16kbps in the uplink. Another critical feature of Cell_FACH is that in this state the mobile
phone shares the forward and uplink access channels with other mobile devices, which also
means that the maximum amount of data that can be transmitted over Cell_FACH depends on
the overall loading of the common channels. The mobile phone power consumption is higher
than it is in Idle or Cell_PCH states, or more than 100mA.
Cell_DCH. As the name implies, in Cell_DCH (Cell Dedicated Channel) the mobile phone is
allocated a dedicated transport channel in the downlink and in the uplink along with a requisite
May 2010

Page 12



DCH/HSPA
>200mA*

1-3 s high signaling effort

number of physical channels, depending on the required bandwidth. When a mobile phone is
<500ms
in Cell_DCH it is consuming the most network resources, including both RNC processing and
air interface resources, while the drain on the battery is also at its highest level, or more than
FACH
200mA.
>100mA*
There are also three inactivity timers that are used to determine when a handset or smartphone
<100ms
should move to a lower state following a specified period of inactivity. The T1 timer refers to
the period of inactivity within the Cell_DCH state before the 3G device is sent to a lower
PCH
state. The T2 timer is associated with the Cell_FACH state and it is used in a similar fashion
<5mA*
for determining how long the 3G device should remain in the Cell_FACH state without any
activity. Finally, the T3 timer determines how long the handset should remain in Cell_PCH
before returning to the Idle state.
IDLE
Figure 1 illustrates the aforementioned RRC connection states, their associated current require<5mA*
ments, and the recommended timer settings as defined by Nokia Siemens Networks. These
recommendations assume the use of Cell_PCH.
*Terminal energy consumption

Figure 1. RRC Connection States
DCH/HSPA
>200mA*

1-3 s high signaling effort

<500ms

Set T1 to <5s
FACH
>100mA*
Set T2 to <5s

<100ms
PCH
<5mA*

Set T3 to >20min

IDLE
<5mA*

*Terminal energy consumption
Source: Nokia

May 2010

Page 13


While up to 28 signaling messages
are required for a 3G device to
transition from Idle to Cell_DCH,
only 7 signaling messages are
required to go from Cell_PCH to
Cell_DCH, with only 2 signaling
messages when transitioning from
Cell_PCH to Cell_FACH.


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

3.2. Smartphone-generated Signaling in a 3G Network
By nature, people use their smartphones more frequently to generate mobile data traffic than
they use a USB dongle or similar form factor device to access the Internet. And while it is
true that some of the more popular smartphones generate a lot of data traffic – on the order
of hundreds of Megabytes per subscriber per month – it 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 a high number of connections
throughout the day and each with
its associated signaling messages
required to set up the connection.

The typical smartphone user does “data snacking” in which the handset consumes modest
amounts of data per data connection, albeit with an appreciably high number of data connections throughout the day. Examples of data snacking include the use of Instant Messaging (IM)
services, push email services, such as widely-popular BlackBerry service, and to a lesser extent
Internet browsing. As discussed in the previous section, each connection attempt can generate a
significant amount of signaling traffic that the network may not be designed to support.

3.3. “Keep Alive” Messages
In addition to the network connections that the subscriber originates and is aware of, there
is also the presence of so-called “keep alive” messages, which typically occur without the 3G
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

May 2010

Page 14



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

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

3.5. Tracing the Root Cause of 3G Network Congestion
In the next section we will prove that smartphones generate a lot of signaling traffic, but we will
not necessarily conclusively prove that it is the signaling traffic that is creating congestion in
today’s 3G networks. However, we can offer some food for thought which will hopefully make
May 2010

Page 15



our case. Further, we note that multiple operators and vendors have confided to us that signaling
is the root cause of the congestion, although from an 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 dependent, if we were to state that 90% of the mobile data traffic is concentrated among 10% of the
users, no one would suggest that our numbers were way off base.
However, when an operator has an issue with 3G network congestion, the congestion generally exists across entire cities versus being concentrated among individual cell sites where the
heaviest users happen to be located. Unless the small minority of users was somehow universally
distributed throughout the network, all accessing the network at the same time, the network
congestion would have to be taking place at a centralized point within the network and not
associated with these heavy users.
Our second point stems from the realization that operators always give priority in their network
to the voice user over the data user since revenues from voice services still dwarf the revenues
from data services, while consumers would be less tolerant of a poor user experience when
making a voice call versus when using the data capabilities of the network. Further, operators that we have interviewed actually reserve capacity in their network in the event that they
need to support a sudden jump in unanticipated voice traffic (e.g., several subscribers suddenly
decide to place a voice call in the same cell site or they all move into the same cell from other
cell sites).
For numerous reasons it cannot be
the data traffic, per se, that is taking
all of the available bandwidth in the
air interface across large swaths of a
congested 3G network.

In other words, it 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 performance 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.

May 2010

Page 16



4. Detailed Results
In this chapter we present results from numerous test scenarios which attempted to replicate
likely usage patterns associated with 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 Methodology
All network testing took place in Montreal, Canada during the week of April 19, 2010. For
logistical and convenience purposes, most of the testing took place from a hotel room where
we had the ability to recharge the phones and GPS receivers, while we could also work in a
protected environment without any interruptions. We identify those test scenarios, such as the
Nokia Maps and FindMe test scenarios, which took place outdoors and/or in pedestrian mode.
In order to obtain highly objective
results, the tests were conducted
with Nokia N97 smartphones that
were preinstalled with the Anite
Nemo Handy client in order to
capture the signaling messages that
were being generated.

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

May 2010

Page 17




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

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

Figure 2. Nokia N97 in the Idle State – TELUS Network
Observed signaling messages = 0
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH
TELUS (NSN)
Network
Idle
14:30:00

14:35:00

14:40:00

14:45:00

14:50:00
Time

14:55:00

15:00:00

15:05:00

15:10:00


May 2010

Page 18




Figure 3. Nokia N97 in the Idle State – Rogers Wireless Network
Observed signaling messages = 0
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH
Rogers Wireless
Network
Idle
14:30:00

14:35:00

14:40:00

14:45:00

14:50:00
Time

14:55:00

15:00:00

15:05:00

15:10:00


May 2010

Page 19




Figure 4 illustrates the current consumption of the two phones during this test. We have
labeled where the backlight of the two phones turned off and where it turned on, although
this event should be fairly obvious. The results of this test indicate that the N97 handset in the
TELUS network used slightly more current when in idle mode. We 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
Rogers Wireless Network
mA
400
Backlight goes off
300

200
Backlight goes on

100

15:09.1

15:10.2

15:08.1

15:06.6

15:05.5

15:04.4

15:03.3

15:02.2

15:01.1

14:59.6

14:57.4

14:58.5

14:56.3

14:54.1

14:55.2

14:51.5

14:52.6

14:49.3

14:50.4

14:47.1

14:48.2

14:44.5

14:45.6

14:43.4

14:41.2

14:42.3

14:40.1

14:38.6

14:37.5

14:36.4

14:35.3

14:34.2

14:33.1

14:30.5

14:32.0

14:29.4

0

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


Rogers Wireless Network with backlight off = 35mA

May 2010

Page 20




Since during this test we did not measure a long enough period with the backlight turned on we
are leveraging another test with similar parameters in order to determine the current consumption with the backlight turned on. This information is presented in Figure 5. The measurement,
which was made over two separate periods (M1 and M2), indicates that the current consumption with the backlight turned on was largely equivalent with the N97 handset used in the
TELUS network requiring 3% more current.
Although not shown in this whitepaper, we also used the same test methodology to determine
the current requirements with the Nemo Handy application turned off, albeit with the Bluetooth radio turned on, although not connected to a separate GPS device. In that test the average
current consumption was slightly less, as expected, or 230mA. Now that we have established a
baseline for both the current consumption and the signaling traffic with the phone in the Idle
state we can start introducing the impact of various smartphone applications under normal
usage patterns.

Figure 5. Current Consumption with the Nokia N97 Handsets in the Idle State – backlight turned on
TELUS (NSN) Network
mA
400

300

M1

200

M2

100

Time

12:35.1

12:35.2

12:35.0

12:34.6

12:34.5

12:34.4

12:34.3

12:34.3

12:34.1

12:34.2

12:34.1

12:33.5

12:33.6

12:33.4

12:33.4

12:33.3

12:33.2

12:33.1

12:33.1

12:33.0

12:32.5

12:32.5

12:32.3

12:32.4

12:32.2

12:32.1

12:32.2

12:31.5

12:32.0

12:31.5

12:31.4

12:31.3

12:31.3

12:31.2

12:31.1

0


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

May 2010

Page 21




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

Figure 6. RRC State Transitions due to “Keep Alive” Messages
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH
Rogers Wireless
Network
Idle
07:40:00

07:50:00

08:00:00

08:10:00
Time

“Keep alive” message payload = ~150bytes; frequency = 2-8 minutes

08:20:00

08:30:00

08:40:00


TELUS network generates 7-53 observed signaling messages per “keep alive” message
➤ Typical observed number per message = 40-50; estimated unobserved messages = 20; average connection time = 7.2 sec
Rogers Wireless network generates 24-46 signaling messages per “keep alive message
➤ Typical observed number per message = 40-45 ; estimated unobserved messages = 20; average connection time = 6.5 sec

May 2010

Page 22




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

Figure 7. Current Requirements due to “Keep Alive” Messages
TELUS (NSN) Network
mA
700
600
500
400
300
200
100

08:43.1

08:45.1

08:41.1

08:39.1

08:37.1

08:33.1

08:35.1

08:31.1

08:29.1

08:27.1

08:25.1

08:21.1

08:23.1

08:17.1

08:19.1

08:13.1

Time

08:15.1

08:11.1

08:07.1

08:09.1

08:03.1

08:05.1

07:59.1

08:01.1

07:57.1

07:55.1

07:51.1

07:53.1

07:49.1

07:47.1

07:45.1

07:41.1

07:43.1

07:39.1

07:37.1

07:35.1

0


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

May 2010

Page 23



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

Table 2. The Impact of “Keep Alive” Messages on Battery Life
“Keep Alive” Message Frequency (minutes)

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

May 2010

Page 24




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

Figure 8. RRC State Transition Changes due to Yahoo IM – Test Scenario 4
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

M1

M1

URA_PCH

StartStart
Idle
11:35:00

11:36:00

11:37:00

11:38:00

11:39:00
Time

IM message (“This is a test, this is only a test”) payload = 1-2kB

11:40:00

11:41:00

11:42:00

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

May 2010

Page 25



due to the sending and receiving of instant messages, the actual start period of the test is at
the 11:35:30 mark. We separately counted the number of signaling messages during two time
periods, which are labeled M1 and M2. We selected these time intervals since they include
frequent RRC state transitions for the N97 handset in the TELUS network and since we
wanted to demonstrate that the impact of these state transitions has only a minimal impact on
the level of signaling traffic.
The N97 smartphone in the TELUS
(NSN) network generated 58%
less signaling traffic than the N97
smartphone in the Rogers Wireless
network for the same Instant
Messaging session.

As indicated in Figure 8, the N97 smartphone in the TELUS (NSN) network generated 41%
less signaling traffic than the N97 smartphone in the Rogers Wireless network (58% less
signaling traffic if we include unobserved signaling traffic) for the same test scenario involving
the sending and receiving of instant messages between the two handsets. If we isolate the
time period to one of the measurement periods where the TELUS Network undergoes a large
number of state transition changes between Cell_PCH and Cell_FACH, the reduction for the
observed messages is comparable or even better (M1 = 61%, M2 = 40%). This result occurred
because very few signaling messages are required to move between these two states. Worth
noting, in addition to leveraging Cell_PCH the smartphone in the TELUS network almost
always used Cell_FACH to send and receive the IMs. This feature had a significant impact on
both reducing the signaling load as well as freeing up network capacity for other voice and data
users.
One final observation is that our analysis of the Rogers Wireless network suggests that the T2
timer was set to 3.3 seconds. Since the TELUS network used Cell_FACH to send and receive
data it wasn’t possible for us to determine at what point there was inactivity in the channel.

May 2010

Page 26




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

Figure 9. RRC State Transition Changes due to Yahoo IM – Test Scenario 7
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

M1
URA_PCH

Start
Idle
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

Time
IM message (“This is a test, this is only a test”) payload = 1-2kB


➤ M1 messages = 50
messages = 62

➤ M1

May 2010

Page 27




Figure 10 illustrates the impact on the battery life for the IM session shown in Figure 9.
Throughout the entire test period the N97 smartphone in the TELUS (NSN) network used
13% less current than the smartphone in the Rogers Wireless network, and arguably much
less in numerous instances (e.g., 32% less during M1 and 25% less during M2) where the N97
smartphone in the TELUS network was able to leverage a combination of Cell_FACH and a
more aggressive T2 timer setting.

Figure 10. The Impact of an Instant Messaging Session on Battery Life – Test Scenario 7
TELUS (NSN) Network
mA
700
600
500
400
300
200
M1

M2

100

12:31.3

12:31.2

12:31.0

12:30.3

12:30.5

12:30.2

12:29.5

12:30.0

12:29.3

12:29.2

12:29.0

12:28.3

12:28.5

12:28.2

12:28.0

12:27.3

12:27.4

12:27.1

12:26.4

12:26.6

12:26.1

12:26.3

12:25.4

12:25.6

12:25.3

12:25.1

12:24.6

12:24.3

12:24.4

12:24.1

12:23.6

12:23.4

12:23.1

12:23.2

12:22.4
12:22.5

0

Time
TELUS network average current requirement = 298mA
➤ M1 = 277mA; M2 = 291mA


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

May 2010

Page 28




4.5. Keeping Track of a Friend with the FindMe Application
The FindMe application is available for free from the Ovi website. As the name suggests the
application allows friends to find each other on a digitally-displayed map. For purposes of our
test we used GPS to identify our location, which happened to be outdoors near the Notre Dame
cathedral, although Cell ID or even a manual entry process can be used. Most importantly,
we selected the default time settings, which meant a status update was being sent once every
minute. Keep in mind that a list of multiple friends would create a multiplicative effect on the
amount of signaling traffic that was being generated since each time another friend provides an
update it creates its own message.
As shown in Figure 11, both handsets required Cell_DCH to send/receive the updates; however,
the N97 smartphone in the TELUS network returned to Cell_PCH after each message where it
remained until the next message was sent/received. During the defined test period we observed
that the N97 smartphone in the TELUS network generated 37% less signaling messages (50%
less if we include unobserved signaling messages).

Figure 11. RRC State Transition Changes due to FindMe – Test Scenario 2
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH
Start
Idle

18:45:30

End

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

Time

➤ Total payload = 90kB

May 2010

Page 29




In terms of the impact on the battery life, the N97 smartphone in the TELUS network required
22% less current throughout the test period. We attribute the savings primarily to less time
being spent in the Cell_DCH state (e.g., a shorter T1 timer setting).

Figure 12. The Impact of the FindMe Application on Battery Life – Test Scenario 2
TELUS (NSN) Network
mA
600
500

400

300

200

100

18:51.3

18:51.1

18:51.0

18:50.5

18:50.3

18:50.4

18:50.2

18:50.1

18:49.5

18:49.3

18:49.4

18:49.2

18:49.1

18:48.6

18:48.3

18:48.5

18:48.2

18:48.1

18:47.6

18:47.5

18:47.4

18:47.2

18:47.1

18:47.0

18:46.5

18:46.3

18:46.4

18:46.1

18:46.0

18:45.5

18:45.3

18:45.4

18:45.2

18:44.5

18:45.0

18:44.4

0

Time



May 2010

Page 30




4.6. Downloading Large Files
Prior to starting this test scenario we set the home page of our browser to the 3G Americas’
website so that once we launched the browser we would not have to navigate to the website that
we had selected where we would have ready access to multiple files that we could download.
In terms of the actual test itself, the process involved launching the browser and then concurrently downloading three whitepapers which appeared on the trade 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
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle

13:39:00

13:39:30

13:40:00

13:40:30

13:41:00
Time

➤ Total payload = 5.8MB

May 2010

13:41:30

13:42:00

13:42:30


Page 31




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)
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
13:52:30

13:53:00

13:54:00

13:54:30

13:55:00

13:55:30
Time

13:56:00

13:56:30

13:57:30

13:58:00

13:58:30


Rogers Wireless network observed signaling messages = 182; estimate of unobserved messages = 90

May 2010

Page 32




4.7. Web Browsing/Internet Surfing
In advance of starting this test scenario, we set the home page of our browser to CNN.com
(the smartphones defaulted to the mobile website). During the actual test we launched both
browsers in rapid succession and then proceeded to periodically navigate to new pages within
the CNN website after waiting for the page to load and allowing for sufficient time to quickly
read the article. Note that we went to the same web pages with each smartphone and since there
was inherently a very short period of time (<1 sec) between the time we tapped the next page
on one phone and then the second phone, we randomly switched which phone we tapped first
when advancing to the next web page.
As indicated in Figure 15 the number of observed signaling messages associated with loading
10 web pages was largely equal between the two networks although there were a number of
signaling messages, especially on the Rogers Wireless network, that had to have occurred
between interfaces that did not extend to the handset. Thus, while the observed reduction was
only 16%, the estimated reduction, which includes the unobserved messages, was 36%.

Figure 15. RRC State Transition Changes due to Web Browsing – Test Scenario 2
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH
M1

Idle

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

Time
➤ M1 messages = 64; estimated unobserved messages = 12


➤ M1 messages = 69; estimated unobserved messages = 50

May 2010

Page 33




The amount of current required to perform this test favored the N97 smartphone in the TELUS
network, we believe largely due to the longer Cell_DCH times (T1 timer setting) in the Rogers
Wireless network. During the M1 test period there was a 21% reduction versus the Rogers Wireless network, although as indicated in Figure 15, the number of observed signaling messages
was largely equivalent (the TELUS network exhibited a 30% reduction after factoring in the
unobserved messages during the M1 period).

Figure 16. The Impact of Web Browsing on Battery Life – Test Scenario 2
TELUS (NSN) Network

mA
700
600
500
400
300
200

M1

100

13:30.3

13:30.2

13:30.0

13:29.3

13:29.5

13:29.1

13:29.2

13:28.5

13:28.4

13:28.2

13:28.1

13:27.4

13:27.6

13:27.1

13:27.3

13:27.0

13:26.3

13:26.4

13:26.2

13:26.0

13:25.3

13:25.5

13:25.1

13:25.2

13:24.5

13:24.4

13:24.1

13:24.2

13:23.5

13:23.3

13:23.4

13:23.1

13:22.6

13:22.3

13:22.5

13:22.2

13:22.0

13:21.3

13:21.5

13:21.2

0
Time
➤ M1 = 366mA


➤ M1 = 464mA

May 2010

Page 34




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.

Figure 17. RRC State Transition Changes due to Web Browsing – Test Scenario 3
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
10:42:00

10:43:00

10:44:00

10:45:00

10:46:00

10:47:00
Time


10:48:00

10:49:00

10:50:00

10:51:00



May 2010

Page 35




Figure 18. The Impact of Web Browsing on Battery Life – Test Scenario 3
TELUS (NSN) Network
mA
700
600
500
400
300
200
100

10:52.1

10:51.5

10:51.4

10:51.2

10:51.0

10:50.4

10:50.1

10:50.3

10:49.5

10:49.1

10:49.3

10:48.4

10:48.6

10:48.2

10:47.5

10:48.1

10:47.1

10:47.3

10:46.4

10:46.6

10:46.2

10:46.0

10:45.5

10:45.1

10:45.3

10:44.5

10:44.4

10:44.2

10:44.0

10:43.3

10:43.4

10:43.1

10:42.3

10:42.5

10:41.6

10:42.2

10:41.4

10:41.2

10:41.0

0

Time



May 2010

Page 36




4.8. Sending and Receiving Email
For this test scenario we configured the email application in both phones so that it could access
our Signals Research Group email. For the test, we sent three identical emails to our account
from our Gmail account with the last email containing a small attachment (Excel spreadsheet).
We then proceeded to download the three emails and after downloading the last email we sent a
short reply to the first message, indicating that the message was received. For hopefully obvious
reasons we tested each phone separately.
Figure 19 contains the results for the TELUS (NSN) network and Figure 20 contains the results
for the Rogers Wireless network. In both figures, the first instance of Cell_DCH indicates the
time during which we were downloading the three email messages. The second instance of Cell_
DCH occurs when we sent the response to the first email. The last, and very short, Cell_DCH
period took place when we disconnected from the POP3 email server. Worth pointing out, the
N97 smartphone in the TELUS network remained in Cell_PCH during the time between
receiving and sending the email. The handset in the Rogers Wireless network returned to the
Idle state, thus generating more signaling traffic when it returned to Cell_DCH.

Figure 19. RRC State Transition Changes due to Sending and Receiving Email – TELUS Network (Test Scenario 3)
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
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

Time

May 2010


Page 37




Figure 20. RRC State Transition Changes due to Sending and Receiving Email – Rogers Wireless Network (Test Scenario 3)
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
14:26:30

14:26:40

14:26:50

14:27:00

14:27:10

14:27:20
Time


May 2010

14:27:30

14:27:40

14:27:50

14:28:00


Page 38




4.9. Using Nokia Maps to Find a Museum in Old Montreal
For this test scenario we went to Old Montreal and used the Nokia Maps application to search
for a nearby museum. We then used the application to obtain step by step directions, which
were continuously updated, along with our location, as we proceeded to walk aimlessly around
the popular tourist spot. Both phones were tested concurrently.
The results of this test were particularly interesting to us since we wanted to know how much
data traffic the application generated – an important consideration given that we are most likely
to use this application while roaming internationally and we would prefer to minimize our
monthly phone bill.
As it turns out, the Nokia Maps application, as indicated in Figure 21, generates only a modest
amount of data traffic – all at the beginning of the session when the user searches for the
desired landmark. Throughout the course of the 7 minute test the total amount of transferred
data on either network was less than 45kB. Further, there was a relatively minor amount of
signaling traffic.

Figure 21. RRC State Transition Changes due to Nokia Maps – Test Scenario 1
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
12:02:00

12:03:00

12:04:00

12:05:00

12:06:00

12:07:00

12:08:00

12:09:00

Time
➤ Total payload = 43.1kB


➤ Total payload = 32.6kB

May 2010

Page 39



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

May 2010

Page 40




4.10. Watching a YouTube Video
One of the more popular mobile data applications as of late is watching user-generated videos
from services such as YouTube. Going into the test our belief was that the results would not
be all that interesting since the smartphone 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
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
18:55:00

18:55:30

18:56:00

18:56:30

18:57:00

18:57:30

18:58:00
Time

18:58:30


18:59:00

18:59:30

19:00:00

19:00:30

19:01:00



May 2010

Page 41




4.11 Making a Skype Video Call
For this test scenario we placed a Skype video call between the two handsets. As was the case
with the Yahoo IM test scenarios, the Skype application was used within the fring application.
The results for this test scenario are shown in Figure 23. In this test the N97 smartphone in the
TELUS network called the N97 smartphone in the Rogers Wireless network. We repeated the
test with the call process reversed (see appendix).

Figure 23. RRC State Transition Changes due to a Skype Video Call – Test Scenario 1
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
18:55:00

18:55:30

18:56:00

18:56:30

18:57:00

18:57:30

18:58:00
Time

18:58:30


18:59:00

18:59:30

19:00:00

19:00:30

19:01:00



May 2010

Page 42




4.12. Receiving an Incoming Voice Call
Although this test scenario has nothing to do with data, we are including it since it provides a
frame of reference for how a handset behaves when receiving an incoming voice call. For this
test scenario the test phone did not have applications running so it was truly idle until the
incoming phone call. The test scenario includes a period of waiting, answering the incoming
call after a few rings, and then maintaining the call for a period or approximately 90 seconds.
Figure 24 shows the RRC state transition changes for the N97 smartphone in the TELUS
network and Figure 25 shows the impact of the incoming call on the required current
consumption.

Figure 24. RRC State Transition Changes due to an Incoming Voice Call – TELUS Network
TELUS (NSN) Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
16:58:30

16:58:45

16:59:00

16:59:15

16:59:30

16:59:45

17:00:00
Time


May 2010

17:00:15

17:00:30

17:00:45

17:01:00

17:01:15

17:01:30


Page 43




Figure 25. The Impact of an Incoming Phone Call on Battery Life – TELUS Network
TELUS (NSN) Network

mA
600
500
400

Backlight goes out

300
200
Incoming call
backlight comes on

Backlight goes out
100

Call ends

17:02.0

17:01.5

17:01.6

17:01.4

17:01.3

17:01.3

17:01.1

17:01.2

17:01.1

17:01.0

17:00.5

17:00.5

17:00.4

17:00.3

17:00.3

17:00.2

17:00.1

16:59.6

17:00.0

16:59.5

16:59.4

16:59.4

16:59.3

16:59.2

16:59.1

16:59.2

16:59.0

16:58.5

16:58.6

16:58.4

16:58.4

16:58.3

16:58.2

16:58.2

16:58.1

16:58.0

0

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

May 2010


Page 44




Likewise, Figure 26 and Figure 27 provide the results for the N97 smartphone in the Rogers
Wireless network.
Although the number of signaling messages generated in the Rogers Wireless network was
higher than the number in the TELUS network, we believe it was due entirely to a slightly
lower time between when the phone started ringing and when we hit answered the phone. In
theory, the number of signaling messages for this particular scenario should have been equal
between the two networks.

Figure 26. RRC State Transition Changes due to an Incoming Voice Call – Rogers Wireless Network
RRC State
Cell_DCH

Cell_FACH

Cell_PCH

URA_PCH

Idle
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

May 2010

Page 45




Figure 27. The Impact of an Incoming Phone Call on Battery Life – Rogers Wireless Network

mA
600
500
Backlight goes out

400
300
Backlight goes out
200

Call ends

Incoming call
backlight comes on

100

16:50.5

16:50.6

16:50.4

16:50.3

16:50.2

16:49.5

16:50.0

16:49.4

16:49.3

16:49.2

16:49.1

16:48.6

16:48.3

16:48.5

16:48.2

16:48.1

16:47.6

16:47.5

16:47.4

16:47.3

16:47.1

16:47.0

16:46.5

16:46.4

16:46.3

16:46.1

16:46.2

16:45.5

16:45.6

16:45.4

16:45.2

16:45.1

16:44.5

16:45.0

16:44.3

16:44.4

0

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

May 2010


Page 46



5. Conclusions
The growing popularity of smartphones and social networking services is here to stay. The
recent introduction of Android-based smartphones and the soon-to-be emergence of MIDs and
smartbooks mean that an even greater percentage of an 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 operators can get the most out of their network resources while consumers can continue to have a
favorable user experience.
For operators, this means working with their infrastructure supplier to implement important
features such as Cell_PCH, assuming that their vendor supports this capability, and selecting
appropriate network inactivity timer settings to maximize its effectiveness. Of all the solutions
to the problem that exist, this solution has the most “bang for the buck,” in particular when
dealing with chatty smartphone applications that frequently transmit and receive relatively
small amounts of data, without any associated ill consequences.
Likewise, operators need to take the lead in working with handset manufacturers, application
developers, and social networking services, to ensure that the impact of certain design decisions
that are being made by the various constituencies on network performance and smartphone
battery life are understood. There are obviously tradeoffs between battery life and the amount
of signaling traffic that a smartphone generates. However, by working together the industry can
make appropriate compromises which are in the best overall interest of all.

May 2010

Page 47

Signals research -_smartphones_and_a_3_g_network_may_2010[1]

Signals research -_smartphones_and_a_3_g_network_may_2010[1]

Recommended

Recommended

More Related Content

Similar to Signals research -_smartphones_and_a_3_g_network_may_2010[1]

Similar to Signals research -_smartphones_and_a_3_g_network_may_2010[1] (20)

Recently uploaded

Recently uploaded (20)

Signals research -_smartphones_and_a_3_g_network_may_2010[1]