© 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
Page 3
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
Page 4
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
Page 5
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
Page 6
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
Page 7
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
Page 8
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]
Page 9
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
Page 10
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.
Page 11
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
Page 12
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
Page 13
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.
Page 14
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
Page 15
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
Page 16
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
Page 17
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%)
Page 18
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
Page 19
Thank You!
Q&A
Backup Slides
Page 21
RRC State Machines of Two Commercial UMTS Carriers
Page 22
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
Page 23
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
Page 24
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.
Page 25
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.
Page 26
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
Page 27
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.
Page 28
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
Page 29
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
Page 30