understanding smartphone traffic - droidcon 2010

understandingsmartphone traffic

impact on battery and networks

Per willars, Ericsson

Public | © Ericsson AB 2010 | 2010-10-28 |

outline

› Challenges with smartphone traffic

› Understanding the 3G radio state machine

› Shaping application traffic

› Conclusion


outline


› Managing the radio connection


› Conclusion


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

Exam

ple

, P

ow

ert

uto

r ap

p


3G Traffic load Comparisontraffic per active device

Data traffic

Sig

nalin

g t

raff

ic

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


smartphone challengesoverview

Application server

Internet

MobileNetwork

Trade-off between:- Battery efficiency - Radio resources- Signaling & network resources- User experience (latencies)

Device behavior

New usage patterns

Application behavior

Networkbehavior

Battery Radio resources

Signaling &network resources

Userexperience

Chattytraffic



smartphone challengesfocus areas

Application server

Internet

MobileNetwork

Trade-off between:- Battery efficiency - Radio resources- Signaling & network resources- User experience (latencies)

Device behavior

New usage patterns


Networkbehavior

Battery Radio resources

Signaling &network resources

Userexperience

Chattytraffic


Shaping application traffic

Managing the radio connection


outline




› Conclusion


Data rate / lower latency / resources

Po

we

r co

nsu

mp

tio

n (

rela

tive

)

1

0.5

0.01-

0.02

HSPA

FACH

“Standby”Idle

3G Radio statesbalancing 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


Po

we

r

HSPA

FACH

“Standby”Idle

device-triggered fast dormancyToday - 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


HSPA

FACH

“Standby”Idle

device-triggered fast dormancyfuture 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

Po

we

r

Data rate


outline




› Conclusion


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

Pow

er

Data rate


shaping application trafficbad 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


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/


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


push instead of pollingAndroid 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


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

Esta

blis

hm

ent

Info

tra

nsfe

r

Inactivity

“High”

“Low”

“Standby”

“Low”

“Standby”Po

we

rP

ow

er

Save battery, use small keepalive messages

6 messagesover radio

3 messagesover radio FACH

URA

HSPA

FACH

URA


optimizing video streaming1. Download start at peak rate

2. Serverthrottling

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]

Thro

ug

hp

ut

[Mbps]


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


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

understanding smartphone traffic - droidcon 2010

Technology

public ericsson ab

battery battery lifetime

data traffic significant

smartphone traffic impact

battery consumption

s inactivity data rate

battery lifetime example

device power data rate