© 2010 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of...

© 2010 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of AT&T Intellectual Property.

TOP: Tail Optimization ProtocolFor Cellular Radio Resource Allocation

18th IEEE International Conference on Network Protocols, Oct 8 2010

Feng Qian1, Zhaoguang Wang1, Alex Gerber2, Z. Morley Mao1, Shubho Sen2, Oliver

Spatscheck2

1University of Michigan 2AT&T Lab Research

Introduction• Limited Radio resources in cellular networks need to be efficiently

managed/allocated – uses state machine• Release of resources controlled by inactivity timers• Timeout value, called Tail Time, causes inefficiencies of energy and

radio resources– Tail time can last up to 15 seconds

We address the tail effects in UMTS (Universal Mobile Telecommunications System) cellular networks Goal: Save radio resources and

radio energy of handsets

The RRC State Machine for UMTS Network

• State promotions have promotion delay• State demotions incur tail times• The key tradeoff

Tail Time

Tail Time

Delay: 1.5sDelay: 2s

Increase Inactivity Timers

Decrease Inactivity Timers

Decrease promotion delaysLower RAN OverheadBetter user experience

Increase promotion delaysHigher RAN overheadWorse user experience

Increase tail timesWaste radio resourcesWaste handset energy

Decrease tail timesSave radio resourcesSave handset energy

Example: Web Browsing Traffic on HTC TyTn II Smartphone

DCH Tail and FACH tail waste significant radio and energy• 34% of total radio energy• 33% of DCH/FACH channel occupation time

FACH DCH FACH and DCH

Wasted Radio Energy 27% 67% 34%

Wasted Channel Occupation Time 27% 67% 33%

Fast Dormancy

• A new feature added in 3GPP Release 7• When finishing transferring the data, a handset

sends a special RRC message to RAN• The RAN immediately releases the RRC connection

and lets the handset go to IDLE• Fast Dormancy dramatically reduces the tail time,

saving radio resources and battery life• Fast Dormancy has been supported in some devices

(e.g., Google Nexus One) in application-agnostic manner

Challenges of Using Fast Dormancy (1)

• How to accurately predict the end of a data transfer– User interactions inject randomness– The tradeoff when the prediction has errors

Conservatively Invoking FD

Limits the energy / radio resource savings

AggressivelyInvoking FD

Increases the statetransition overhead

Challenges of Using Fast Dormancy (2)

• How to handle concurrent applications– RRC state transitions are determined by the aggregated

traffic of all applications– Applications should not independently invoke FD

Fast Dormancy

Our Solution: The TOP Protocol

TOP: Tail Optimization Protocol For Cellular Radio Resource Allocation

• Use fast dormancy to optimize tails• Apps predict the inter-transfer time (ITT), the idle

period after each data transfer– The definition of a data transfer depends on the app. – FD is not invoked if the predicted idle period is smaller than

tail threshold (TT) to prevent unnecessary state promotions• TOP uses a novel coordination algorithm to handle

concurrent network activities– Also considers legacy apps that are unaware of TOP

Related Work for Reducing Tail Times• Tuning inactivity timers [Lee04] [Yeh09]

– Network based– Timers are statically and globally applied to all traffic– Inherently difficult to balance the tradeoff [Qian10]

• Shaping traffic pattern [Balasubramanian09][Aaron10]– UE based– For delay-tolerant apps (e.g., email, RSS), delay their transfers– Not applicable to interactive apps (e.g., Web browsing)

• Cooperation between UE and the network– Application agnostic approach [Fast Dormancy]– Application and traffic pattern aware approach [TOP]

TOP Overview• TOP schedules tail removals at the connection level• At the end of a data transfer an application invokes the tail removal

API:– TerminateTail (targetConn, predictedITT)

• The ideal case– Each connection can predict the arrival time of the next packet– At t0, we invoke FD iff min{t1,t2,t3} > TT (TT is the Tail Threshold)

t1

t2

t3

Connection 1

Connection 2

Connection 3

t0

Time

Predicted next packet

Cellular Measurement Data

• A large TCP header packet trace collected from a large UMTS carrier in April 2009

• 265 million TCP packets, 169 GB data• Preprocessing: extract Sessions

– A session consists of all packets transferred by the same user device (handset).

– One handset may have multiple sessions: use a threshold of 60 sec to decide a session has terminated.

– A session may consist of multiple TCP flows.

Deciding the Tail Threshold (TT) Value• TT is the most critical parameter

• Replay the 0.8 million sessions to an RRC state machine simulator

• TT = DCHFACH Timer value yields a good tradeoff

TT is too large The opportunity of invoking FD is very limitedTT is too small Incurs a large number of additional state promotions

Carrier 1 Carrier 2

Promo overhead (TT = α + β) 0 0

Saved DCH tail times (TT = α + β) 35% 61%

Promo overhead (TT = α) 22% 7%

Saved DCH Tail Times (TT = α) 100% 100%

α: DCHFACH Timer, β: FACHIDLE Timer

Practical Issues

• Some connections do not use TOP• Prediction is performed at transfer level, instead of

packet level.

Transfer 1 Transfer 2

Time

The prediction is only available at the end of each transfer

Predict Predict

Deal with the Practical Case

pConnection 1

Connection 2

Connection 3

t0

p

t1 t2 t3

Predict

Interval Allow FD?

t0~t1 No

t1~t2 Yes

t2~t3 No

t3+ Yes

• When no prediction information is available– If a connection has sent/recv a packet in the past p

seconds, then we should not invoke FD– p is also set to alpha (the DCHFACH timer value), based

on the same reasoning for deciding TT.

The TOP Algorithm

• We invoke FD if and only if both hold:1. For any connection without the prediction information,

we do not observe a packet in the past p seconds.2. For all connections with the prediction information, their

minimal timestamp should be greater than current time plus TT

– We set p = TT = alpha (the DCHFACH timer value) – See paper for more implementation details

Evaluation Methodology

• Simulation using the passive trace (0.8 million sessions) collected from a commercial UMTS carrier

• Simulation using locally collected traces on Android G2– Web browsing and streaming (see paper for details)

• Runtime overhead of TOP– Major overhead: to record packets’ timestamps– Implement an Android kernel module for recording timestamps– Negligible (< 1%) CPU overhead

• On-going work: build a complete implementation of TOP for Android

Evaluation using Passive Traces

• Use the passive trace (0.8 million sessions) collected from a UMTS carrier

• Consider four types of applications by port # – Web (79%), Email (15%), Synchronization (0.2%):

probabilistically (vary the probability) use TOP with prediction accuracy w = 80%

– Define a transfer as consecutive connections of the same type whose interconnection time < 1 sec

– Other traffic (6%): not aware of TOP

Evaluation using Passive Traces

Given the fixed state promotion overhead (e.g., 15%)The saved energy and radio resource:TOP (18%) > Fast Dormancy (9%) > Timer (5~7%)

To save a fixed amount of resources (e.g., 12.5% of energy)The incurred state promotion overheadTOP (11%) < Fast Dormancy (19%) < Timer (39%)

Conclusions

• TOP leverages the knowledge of applications that predict the idle period after each data transfer.

• We carefully tune the value of the tail threshold by empirically measuring traces from a large UMTS carrier

• TOP introduces a novel coordination algorithm to handle concurrent network activities.

• On-going work– Design effective tail prediction algorithms for various apps– Build an implementation of TOP on Android phones

Thank You!

Q&A

Backup Slides

RRC State Machines of Two Commercial UMTS Carriers

Carrier 1 Carrier 2Timer Carrier 1 Carrier 2

DCHFACH (α timer) 5 sec 6 sec

FACHIDLE (β timer) 12 sec 4 sec

TyTN II vs. Google Nexus One

HTC TyTN IINo Fast Dormancy

Nexus OneWith Fast Dormancy

(Shorter FACHIDLE Timer)

FACH Tail: 12 sec

The TOP API

• The API exposed to application developers– void TerminateTail(targetConn, predictedITT)

– targetConn is 5-tuple (srcIP/port, dstIP/port, protocol)It can be NULL in the case where the connection does not exist now

– predictedITT is the predicted inter-transfer-timeIt can be a fixed large value if the application cannot decide its exact value (only knows that it is greater than TT)

• See our paper for more implementation details

Binary Prediction

• It may be difficult for applications to predict the exact value of ITT.– E.g., when user interactions are involved

• An application can performs binary prediction

• As long as the binary prediction is correct, the actual prediction value of ITT is much less important.

ITT ≤ TT Do not call the TOP APIITT > TT Call the TOP API with predicted ITT set to a

fixed large value (e.g., 60 sec)

Evaluations (cont.)

At the end of each transfer, each application independently calls theTOP with probability of z, The prediction accuracy is w.

Evaluation using Locally Collected Traces

• Use traces locally collected form eight Android G2 smartphone users

• Run two applications simultaneously– Pandora audio streaming

(a transfer: downloading a song track / Ad)– Web browsing (a transfer: downloading a page)

• Use simulation to compare two cases– Applications use TOP– Applications independently invoke FD

Evaluation using Locally Collected Traces

DCH Tail DCH Total State Promos Energy

Default

TOP

Fast Dormancy

• TOP significantly decreases the state promotion overhead from 66% to 17% by reasonably sacrificing savings of other three dimensions.

Feasibility of ITT Prediction

• Audio streaming– No user interaction involved, the app controls ITT

(a transfer: downloading a song)• Web browsing

– ITT depends on page content and user behavior– Based on our user study of 8 users for Carrier 2

91.2% of ITTs are longer than TT for m.cnn.com91.4% of ITTs are longer than TT for amazon.com(a transfer: downloading a page)

• Our on-going work– Design effective tail prediction algorithms for various apps

On-going Work

• Designing effective tail prediction algorithms for smartphone applications – Especially for applications involving user interactions

• Build a real implementation of TOP on Android phones

© 2010 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of...

Documents

Transcript of © 2010 AT&T Intellectual Property. All rights reserved. AT&T and the AT&T logo are trademarks of...