Everyone enjoys the smartphone revolution - users, developers, network operators, device vendors and network equipment vendors such as Ericsson. However, there are challenges since the network systems have not been optimised for smartphones from start. Until recently, the key optimisation objectives for mobile broadband networks have been peakrate and throughput, which are still important properties. The advent of mass-usage of smartphones, and the related traffic, has shown that also other properties of the 3G radio and networks are important. In particular, the high frequency of data activities, sometimes with moderate volumes of data transferred, has lead to both a high battery drain, and increased the signaling load in the system, due to the transitions between the standardised states of the 3G radio.

1. understanding
smartphone traffic
impact on
battery and networks
Per willars, Ericsson

2. Public | © Ericsson AB 2010 | 2010-10-28 | Page 2
outline
› Challenges with smartphone traffic
› Understanding the 3G radio state machine
› Shaping application traffic
› Conclusion

3. Public | © Ericsson AB 2010 | 2010-10-28 | Page 3
outline
› Challenges with smartphone traffic
› Managing the radio connection
› Shaping application traffic
› Conclusion

4. Public | © Ericsson AB 2010 | 2010-10-28 | Page 4
battery
Battery lifetime is a challenge with smartphones
› Typically dominating:
– display, when user is active
– 3G radio modem, when inactive
– (CPU)
› Trend:
– slow increase in battery capacity
– faster increase in components
peak power
› Low duty cycle key for battery
lifetime
Example,Powertutorapp

5. Public | © Ericsson AB 2010 | 2010-10-28 | Page 5
3G Traffic load Comparison
traffic per active device
Data traffic
Signalingtraffic
Feature
phones
Smart
Phones
PCs
Data: IP packets to/from apps, services, Internet
Signaling: Mobile-specific messages for managing mobility
and resources for the Data traffic
Significant signaling
x
Many smartphones
=
Impact on some networks
Signaling load increasingly important with smartphones

6. Public | © Ericsson AB 2010 | 2010-10-28 | Page 6
smartphone challenges
overview
Application
server
Internet
Mobile
Network
Trade-off between:
- Battery efficiency
- Radio resources
- Signaling & network resources
- User experience (latencies)
Device
behavior
New usage
patterns
Application
behavior
Network
behavior
Battery Radio
resources
Signaling &
network resources
User
experience
Chatty
traffic
Application
behavior

7. Public | © Ericsson AB 2010 | 2010-10-28 | Page 7
smartphone challenges
focus areas
Application
server
Internet
Mobile
Network
Trade-off between:
- Battery efficiency
- Radio resources
- Signaling & network resources
- User experience (latencies)
Device
behavior
New usage
patterns
Application
behavior
Network
behavior
Battery Radio
resources
Signaling &
network resources
User
experience
Chatty
traffic
Application
behavior
Shaping application traffic
Managing the radio connection

8. Public | © Ericsson AB 2010 | 2010-10-28 | Page 8
outline
› Challenges with smartphone traffic
› Managing the radio connection
› Shaping application traffic
› Conclusion

9. Public | © Ericsson AB 2010 | 2010-10-28 | Page 9
Data rate / lower latency / resources
Powerconsumption(relative)
1
0.5
0.01-
0.02
HSPA
FACH
“Standby”Idle
3G Radio states
balancing data transfer, battery and resources
~ 2s inactivity
~ 10-30 s
inactivity
~ 10-30 min
inactivity
Activity
Activity
~ 256 byte UL
~ 512 byte DL
with IP headers
Activity
“High”
“Low”
URAIdle
IDLE CONNECTED
› Signaling needed for state transitions, esp. to/from Idle
› ”Standby” state (URA) deployed in more and more networks
Typical trigger
thresholds

10. Public | © Ericsson AB 2010 | 2010-10-28 | Page 10
Power
HSPA
FACH
“Standby”Idle
device-triggered fast dormancy
Today - aggressive disconnect to save battery
“High”
“Low”
URAIdle
IDLE CONNECTED
› Device trigger: data + display inactivity
› Problems: latency, signaling, shortcuts “Standby” state
~ 3s inactivity
Data rate

11. Public | © Ericsson AB 2010 | 2010-10-28 | Page 11
HSPA
FACH
“Standby”Idle
device-triggered fast dormancy
future solution – standardized behaviour
“High”
“Low”
URAIdle
IDLE CONNECTED
› Device-triggered battery efficiency in ”Standby” state
› Short-term recommendation:
– shorter timers in networks, selective Fast Dormancy in device
Power
Data rate

12. Public | © Ericsson AB 2010 | 2010-10-28 | Page 12
outline
› Challenges with smartphone traffic
› Managing the radio connection
› Shaping application traffic
› Conclusion

13. Public | © Ericsson AB 2010 | 2010-10-28 | Page 13
shaping application traffic
› Guiding principles
– Stay in battery-efficient states
– Minimize state transitions
– Minimize intermittent small
transactions
– When transmitting – transmit it all
– Small keepalive messages
Reduces battery consumption and network signaling
HSPA
FACH
“Standby”Idle
“High”
“Low”
URA
IDLE CONNECTED
Power
Data rate

14. Public | © Ericsson AB 2010 | 2010-10-28 | Page 14
shaping application traffic
bad application example
Device
Network
3s 5s
50s
3s 5s3s 5s
50s
3s 5s
› Chatty IM application example
– 2% of traffic generated 10% of
signalling load
– Lots of signaling due to
frequent polling
› Possible improvements:
– Clean close of TCP
(avoid TCP RST)
– Keeping TCP connection
(to own server)
– Push on one persistent TCP
connection
“High”
“Low”
Idle

15. Public | © Ericsson AB 2010 | 2010-10-28 | Page 15
background polling applications
› Multi-tasking: freedom with responsibility – higher risks screwing up!
› Developer tutorial from Sony Ericsson blog:
– Synchronize polls with other apps
› using alarmManager: setInexactRepeating and/or use RTC rather than
RTC_WAKEUP
– Execute polls as short as possible
› single requests, short server responses, multi-queries, gzip
– Manage HTTP connections
› use of Apache httpclient and explicitly shut down the connection when
poll is done
– Stop services
› wake up with intents (e.g. alarmManager) when needed
http://blogs.sonyericsson.com/developerworld/2010/08/23/android-tutorial-reducing-power-consumption-of-connected-apps/

16. Public | © Ericsson AB 2010 | 2010-10-28 | Page 16
synchronize background polling
example on synching android apps
HTC Hero, Android 1.5. Trace on WLAN. Showing all TCP activities.
FB app
Contacts FB
POP3 mail
Twitter
Google port 5228
Google/loc/m/api
Daytime
Snowstorm
weather
Newsrob RSS
google reader
AGPS
Poweron
Manual refreshes
Charging Wake
display

17. Public | © Ericsson AB 2010 | 2010-10-28 | Page 17
push instead of polling
Android 2.2 Cloud-to-device messaging (C2DM) API
CP/SP
CP/SP
Android
App App
API
Google
Internet
1. New event / data
2. Message to ”ID”
Data up to 1 kB
3. Message to ”ID”
4. Message to app.
Download more data and/or notify user.
long-lived TLS/TCP (port 5228)
also used for GTalk, Gmail,...
› Push more efficient if:
– high immediacy is required
– frequency of data is not too high
› Further optimizations:
– multiple apps share single
connection (c2dm)
=> reduced keepalives
– transmit only delta
=> no need for additional polls
FW/NAT
c2dm
Server

18. Public | © Ericsson AB 2010 | 2010-10-28 | Page 18
small keepalive signaling
› Minimize size of keepalive messages
– Allows switch from ”Standby” (URA) to stay in ”Low” (FACH) state
– Avoid upswitch by limiting data
Typical settings in todays networks: Uplink < 250B, Downlink < 500B, incl IP headers
Establishment
Infotransfer
Inactivity
“High”
“Low”
“Standby”
“Low”
“Standby”
PowerPower
Save battery, use small keepalive messages
6 messages
over radio
3 messages
over radio FACH
URA
HSPA
FACH
URA

19. Public | © Ericsson AB 2010 | 2010-10-28 | Page 19
optimizing video streaming
1. Download start
at peak rate
2. Server
throttling
3. Client throttling
› Staying long in ”High” (HSPA) state drains battery
› More efficient: transmit with peak rate, then sleep the radio
– Intervals long enough to use power-saving state,
but not too long since many videos not viewed fully
– Consider adaptive HTTP streaming (upcoming – not yet in Android)
Long Youtube
video on Android
Time [s]
Throughput[Mbps]

20. Public | © Ericsson AB 2010 | 2010-10-28 | Page 20
conclusions
› Smartphones a success for all involved
› Chatty smartphone traffic
– Impacting battery and network signaling
› Measures to manage smartphone traffic
– Network dimensioning, tuning and features
– Device behaviour - fast dormancy
– Impact application traffic to be battery- and radio-efficient
› minimize chattiness of traffic
› optimize background traffic
› small & infrequent keepalives
› when transmitting – transmit it all
NW operators/vendors
Terminal vendors
App developers

21. Public | © Ericsson AB 2010 | 2010-10-28 | Page 21
developer guidelines,
some references
› Our blog post on this topic:
– https://labs.ericsson.com/developer-community/blog/smartphone-
traffic-impact-battery-and-networks
› Android Application Coding Guidelines, Power Save:
– http://developer.sonyericsson.com/cws/download/1/788/263/127192
0135/dw-300012-Android_Power_Save.pdf
› Android tutorial, Reducing power consumption of
connected apps:
– http://blogs.sonyericsson.com/developerworld/2010/08/23/android-
tutorial-reducing-power-consumption-of-connected-apps/
› Coding for Battery life, Google IO 2009:
– http://www.youtube.com/watch?v=OUemfrKe65c

22. Q & A

23. Public | © Ericsson AB 2010 | 2010-10-28 | Page 23