© 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 Protocol For Cellular Radio Resource Allocation 18th IEEE International Conference on Network Protocols, Oct Feng Qian 1, Zhaoguang Wang 1, Alex Gerber 2, Z. Morley Mao 1, Shubho Sen 2, Oliver Spatscheck 2 1 University of Michigan 2 AT&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 Delay: 1.5s Delay: 2s Increase Inactivity Timers Decrease Inactivity Timers Decrease promotion delays Lower RAN Overhead Better user experience Increase promotion delays Higher RAN overhead Worse user experience Increase tail times Waste radio resources Waste handset energy Decrease tail times Save radio resources Save 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 FACHDCHFACH and DCH Wasted Radio Energy27%67%34% Wasted Channel Occupation Time27%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 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., , 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 t 0, we invoke FD iff min{t 1,t 2,t 3 } > TT (TT is the Tail Threshold) t1t1 t2t2 t3t3 Connection 1 Connection 2 Connection 3 t0t0 Time Predicted next packet Page 10

Cellular Measurement Data A large TCP header packet trace collected from a large UMTS carrier in April 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 = DCH  FACH Timer value yields a good tradeoff α: DCH  FACH Timer, β: FACH  IDLE Timer Page 12

Practical Issues Some connections do not use TOP Prediction is performed at transfer level, instead of packet level. Transfer 1Transfer 2 Time The prediction is only available at the end of each transfer Predict Page 13

Deal with the Practical Case p Connection 1 Connection 2 Connection 3 t0t0 p t1t1 t2t2 t3t3 Predict 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 DCH  FACH 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 DCH  FACH 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%), (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 overhead TOP (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 2 TimerCarrier 1Carrier 2 DCH  FACH (α timer)5 sec6 sec FACH  IDLE (β timer)12 sec4 sec

TyTN II vs. Google Nexus One HTC TyTN II No Fast Dormancy Nexus One With Fast Dormancy (Shorter FACH  IDLE 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-time It 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 ≤ TTDo not call the TOP API ITT > TTCall 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 the TOP 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 TailDCH TotalState PromosEnergy 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 % of ITTs are longer than TT for m.cnn.com 91.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