AMUSE: Empowering Users for Cost-Aware Offloading with Throughput-Delay Tradeoffs

16 Pages·2015·2.08 MB·English

IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 1
AMUSE: Empowering Users for Cost-Aware
Offloading with Throughput-Delay Tradeoffs
Youngbin Im, Student Member, IEEE, Carlee Joe-Wong, Student Member, IEEE,
Sangtae Ha, Senior Member, IEEE, Soumya Sen, Member, IEEE,
Ted “Taekyoung” Kwon, Member, IEEE, and Mung Chiang, Fellow, IEEE
Abstract—To cope with recent exponential increases in demand for mobile data, wireless Internet service providers (ISPs) are
increasingly changing their pricing plans and deploying WiFi hotspots to offload their mobile traffic. However, these ISP-centric
approachesfortrafficmanagementdonotalwaysmatchtheinterestsofmobileusers.Usersfaceacomplex,multi-dimensionaltradeoff
betweencost,throughput,anddelayinmakingtheiroffloadingdecisions:whiletheymaysavemoneyandreceiveahigherthroughput
by waiting for WiFi access, they may not wait for WiFi if they are sensitive to delay. To navigate this tradeoff, we develop AMUSE
(Adaptive bandwidth Management through USer-Empowerment), a functional prototype of a practical, cost-aware WiFi offloading
systemthattakesintoaccountauser’sthroughput-delaytradeoffsandcellularbudgetconstraint.Basedonpredictedfutureusage
andWiFiavailability,AMUSEdecideswhichapplicationstooffloadtowhattimesoftheday.Sincenearlyalltrafficflowsfrommobile
devicesareTCPflows,weintroduceanewreceiver-sidebandwidthallocationmechanismtopracticallyenforcetheassignedrateof
eachTCPapplication.Thus,AMUSEuserscanoptimizetheirbandwidthratesaccordingtotheirowncost-throughput-delaytradeoff
withoutrelyingonsupportfromdifferentapps’contentservers.Throughameasurementstudyof20smartphoneusers’trafficusage
traces,weobservethatthoughusersalreadyoffloadalargeamountofsomeapplicationtypes,ourframeworkcanoffloadasignificant
additionalportionofusers’cellulartraffic.WeimplementAMUSEonWindows7tabletsandevaluateitseffectivenesswith3Gand
WiFiusagedataobtainedfromatrialwith37mobileusers.OurresultsshowthatAMUSEimprovesuserutility;whencomparedwith
AMUSE,otheroffloadingalgorithmsyield14%and27%loweruserutilitiesforlightandheavyusers,respectively.Intelligentlymanaging
users’competinginterestsforcost,throughput,anddelaycanthereforeimprovetheiroffloadingdecisions.
IndexTerms—Bandwidthmanagement,mobiledata,WiFioffloading
(cid:70)
1 INTRODUCTION which parts of their traffic can be offloaded at what
times.
Recent unprecedented increases in demand for mobile
datatraffichavebeguntostressmanymobileoperators’
networks: Cisco, for instance, predicts that mobile data 1.1 EmpoweringUserDecisions
traffic will grow at 61% annually from 2013 to 2018,
Many data plans, especially in the U.S., charge large
reaching 15.9 exabytes per month by 2018 [1]. To cope
overage fees when users exceed a monthly usage cap.
with this surge in data usage, which is driven by appli-
While offloading to WiFi reduces cellular data usage,
cations such as mobile video, cloud services, and online
thus saving users money on their data spending, they
magazines, many ISPs (Internet service providers) have
mustalsotakeintoaccountWiFi’sintermittentavailabil-
adopted tiered pricing plans with monthly data caps to
ity and higher throughput performance. At some times,
discourage heavy usage [2]. To further reduce network
e.g.,whileoutshopping,auserdoesnothaveimmediate
traffic, many ISPs have also introduced supplementary
WiFi access and must wait for WiFi connectivity. The
networks such as WiFi hotspots or femtocells to offload
user then faces a choice:
their cellular traffic [3]–[5]. Such supplementary offer-
• Don’t wait for WiFi: The user must consume cellular
ings introduce new challenges for users as they decide
data, using up some of his data cap, and may
experience lower throughput than WiFi. However,
• Y.ImandS.HaarewiththeUniversityofColorado,Boulder,Colorado.
sheneednotwaitfordataaccess,whichisimportant
E-mails:{youngbin.im,sangtae.ha}@colorado.edu
• C. Joe-Wong and M. Chiang are with Princeton University, Princeton, for urgent applications, e.g. email.
NewJersey. • Wait for WiFi: The user can save money and ex-
E-mails:{cjoe,chiangm}@princeton.edu
perience higher throughput, but must decide how
• S. Sen is with the Carlson School of Management, University of Min-
nesota,MN. long to wait. Different applications can wait for
E-mail:[email protected] different periods of time, e.g., cloud backups might
• T.KwoniswithSeoulNationalUniversity,Seoul,Korea
be more delay tolerant than photo uploads to Face-
(correspondingauthortoprovidephone:[phone];fax:+822872
2045;e-mail:[email protected]). book.Giveneachapp’swillingnesstowaitforsome
period of time, users must anticipate whether WiFi
AnearlierversionofthispaperappearedintheIEEEINFOCOM2013mini-
conference. willbeavailableatthattimeanddecidewhetherthe
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 2
potential savings in data offloading and potential usage data collected from a trial with 37 mobile
increase in throughput are worth the wait. users.
Waiting for WiFi also introduces the risk that apps AMUSE is the first WiFi offloading system to fully
waiting for WiFi must share the limited 3G band- account for cost, delay, and throughput in offloading
width, should WiFi ultimately not be available. traffic from 3G to WiFi. Other works have considered
Some apps, such as videos, will require a large using WiFi offloading to reduce cost within a basic
amount of bandwidth; their quality can suffer sig- delay constraint, e.g., by using predictions of WiFi con-
nificantly if they must share bandwidth with other nectivity to improve offloading [6] or allocating more
apps, e.g., cloud backups.1 WiFi bandwidth to users who are expected to leave
Mostuserswillnotmanuallybalancethesecompeting the WiFi coverage area in a short amount of time [7].
factorsinmakingoffloadingdecisions.Thus,wepropose Mobility can also enhance prefetching data over WiFi
a user-side, automated WiFi offloading system called [8]. Wiffler [9] considers a more sophisticated model
AMUSE (Adaptive bandwidth Management through of different applications’ delay tolerances, but does not
USer EMpowerment) that intelligently navigates these consider different apps’ bandwidth needs or their need
tradeoffs for the user. AMUSE utilizes WiFi access and to share 3G bandwidth.
application usage predictions to decide how long appli- To fully incorporate cost, delay, and throughput, we
cation sessions should wait for WiFi and, in case WiFi is build an end-to-end mobile offloading system. In the
notavailable,tooptimallyallocate3Gbandwidthamong next section, we describe AMUSE’s components and the
different apps. Building such a system poses both algo- challenges of developing this end-user system.
rithmic and implementation challenges–not only must
theuser’stradeoffbetweencost,throughputquality,and
1.2 ComponentsofAMUSE
delay be quantified and balanced, but we require a way
to automatically enforce AMUSE’s waiting for WiFi and Figure 1 gives an overview of AMUSE’s components
sharingof3Gbandwidth.Insolvingtheseproblems,we andtheirinteractions.Thesystemarchitecturecomprises
make the following contributions: four main modules: the User Interface, Bandwidth Op-
1) We develop a system for cost-aware WiFi offload- timizer, TCP Rate Controller, and App-Level Session
ing that exploits a user’s delay tolerances for dif- Tracker. The latter two modules reside in the kernel
ferent applications and makes offloading decisions and are accordingly shaded darker in the control flow
satisfying her throughput-delay tradeoffs and 3G diagram (Fig. 1b); these enforce the offloading decisions
budget constraints. made by the User Interface and Bandwidth Optimizer,
2) To enforce AMUSE’s bandwidth allocation deci- which reside in the user-space. To illustrate the system’s
sions for each application, we implement a prac- full set of interactions, the Bandwidth Optimizer is split
tical receiver-side rate control algorithm for TCP.2 into three components: two prediction modules for app
The algorithm is fully contained on and driven by usage and WiFi availability, and an algorithm that com-
end-user devices, making it suitable for practical putes utility-maximizing offloading decisions.
deployment as it requires no modification of the
TCP server side. 1.2.1 UserInterface
3) In order to analyze current mobile offloading pat-
As suggested by its name, AMUSE’s User Interface
terns and the potential to offload more traffic from
interactsdirectlywiththeuser,displayingtheoffloading
different apps, we conduct a measurement study
decisions made as well as the user’s app-level usage
usingapplicationusagedatacollectedfrom20An-
history. The user may also set her preferences on the
droid smartphone users for one week.3 The results
user interface, e.g., the maximum budget for 3G usage
reveal several facts that show offloading practice
and delay tolerances for different applications.
and possibility of smartphone users.
4) We surveyed 100 participants in the U.S. to evalu-
1.2.2 BandwidthOptimizer
ateusers’tradeoffbetweenthecostof3Gusageand
their willingness to wait for WiFi access. We incor- The Bandwidth Optimizer makes offloading decisions
poratetheresultingcost-throughput-delaytradeoff for the user, given the preferences set by the user on the
estimates into our model, and evaluate AMUSE’s User Interface. It consists of the three medium-shaded
performance using these results and 3G and WiFi componentsinFig.1b:appusageprediction,WiFiaccess
prediction, and a utility maximization algorithm.
1.Whileoursystemsapplytoanyformofcellulardata,e.g.,3Gor AMUSE uses an adaptive user mobility model to
LTEnetworks,weframeourdiscussionintermsof3Gdata.LTEspeeds
predictWiFiavailabilityatfuturetimes(Fig.1b).Theapp
can exceed WiFi, which makes the users’ tradeoffs more complicated
andAMUSEevenmoreuseful. usage prediction component allows AMUSE to calculate
2.Weassumethatdownloadtrafficmakesupmostofusers’usage, the expected savings from offloading an application
sothatthereceiverissynonymouswiththeuser. session and to allocate 3G bandwidth to all active apps
3.Throughoutthiswork,“appusagedata”referstothevolumeof
at any given time, giving more bandwidth to the apps
data used by each application, not the time duration of application
usage. with higher bandwidth requirements.
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 3
Deferral and 
 Bandwidth detail,whileSection4givesanoverviewoftheTCPRate
ThrotStltea tSiscthicesd ule,
 Optim izer ((cid:106)II)
IntUesrfearc e User BPured fgeerte, nces WPPFirrFeeuidd tCuiiccroettoo n Urrn ((es(cid:106)(cid:106)acIItgIIi..veBAi t)) y Usage DB ApApAplppiAclpiapclitpacioltaiincotiasno t ni#o #n1 # 1 C5,onwtreololebrs’esrvaelgomriothbimle aunsderism’ pwleirmeleensstatnioentw. oInrkSeucstaiogne
pattern from the viewpoint of WiFi offloading, and find
how much and which kind of applications are currently
TCP/IP protocol stack
Kernel offloaded and can be offloaded more. In Section 6,
TCP Rate Controller App- level Congestion Control
((cid:106)III) Session Tracker Algorithms we evaluate AMUSE’s effectiveness in improving users’

experience, utilizing 3G and WiFi data gathered from 37
Microsoft NDIS Driver
mobile users. When compared with two representative
H/W Network Card offloadingalgorithms(on-the-spotanddelayed[11]),we
(a)Systemimplementationarchitecture. show that AMUSE increases user utility by intelligently
managing the cost-throughput-delay tradeoff for heavy
App-­‐Level
 Session

Tracker

andlightusers.Finally,weconcludethepaperinSection
User
 Interface
  7.
3G
 Usage
  App
 Delay
  App
 Usage

Budget
  Tolerances
  History

2 RELATED WORK
App
 Usage

Predic"on
  Recent studies of 3G and WiFi usage traces, e.g. [11]
U"lityA
 lMgoarxiitmhmiza
 "on
  TCP
 Rate
 Controller
  have showed that offloading 3G traffic to WiFi can
WiFi
 Access

Predic"on
  significantly benefit mobile ISPs. Other systems have
demonstrated offloading’s benefits for user experience
(b)Controlschematicandmainmodules.
[6],[8],[9];otherworksdemonstratethatWiFioffloading
Fig.1. OverviewofAMUSE’scomponents. can benefit both ISPs and users [12] and even generate
The user’s offloading decisions at any given time more revenue for ISPs [13].
must take into account future offloading decisions–for Someworkshavefocusedonincentivizinguserstoof-
instance, a myopic algorithm may delay all sessions floadtraffictoWiFi.In[14],theauthorsdevelopautility
in the morning to 12 noon, if the probability of WiFi and cost-based formulation to decide the 3G network
access at that time is high. However, should WiFi not be load that maximizes the user’s benefit and apply the
availablethen,allofthedelayedsessionswouldhaveto decided loads using a modified SCTP implementation
sharethelimited3Gbandwidth,orelsewaitevenlonger in Linux that stripes traffic across multiple interfaces.
for WiFi. Thus, at the beginning of each day, AMUSE Win-Coupon [15] takes a slightly different perspective
optimizesovertheentirerestoftheday,usingestimates and proposes a reverse-auction scheme to incentivize
of WiFi access probabilities and the size of application users to offload their traffic so as to decrease the overall
sessions at different times (e.g., hours). It then refines network. Other works, including [16], consider the en-
this initial solution over the day to reflect the observed ergy consumption when making an offloading decision.
usage and WiFi access patterns. We do not consider energy in this work, but can easily
incorporate the battery consumption into our proposed
1.2.3 TCPRateControllerandSessionTracker optimization algorithm.
Since 99.7% of mobile traffic flows are TCP, we enforce Several research works have analyzed the traffic of
the Bandwidth Optimizer’s 3G bandwidth allocations smartdevicesinordertounderstandtheiruserbehavior
and offloading decisions with a TCP rate controller on [17], [18], [19], [20], [21]. In particular, [17] examines
end-user devices [10]. To do so, the controller modifies users’ traffic diversity, relationship to application types,
the TCP advertisement window in outgoing acknowl- interactivity,anddiurnalpatterns,while[18]investigates
edgement (ACK) packets. Unlike typical bandwidth theusagepatternsofsmartphoneappsvianetwork-side
throttling mechanisms, this rate control is completely measurements. Our work is different from these in that
specified by the end user on a per-application basis; thus, wespecificallyfocusonthepotentialforWiFioffloading
for example, file downloads may be delayed to wait for of different applications and incorporate findings on
WiFi, while streaming videos may receive a higher 3G their delay tolerances.
bandwidth and not be delayed. The app-level session Unlike most offloading works, AMUSE also controls
trackermeasurestheactualusageforeachapplicationas the 3G bandwidth for different applications. AMUSE is
the rate controller enforces the Bandwidth Optimizer’s uniqueinusingofreceiver-sideTCPadvertisementwin-
decisions. These usage data are then used to update dows to control application-specific 3G bandwidth from
AMUSE’s prediction modules, as shown in the control the user side. While several commercial applications
flow diagram (Fig. 1b), and are displayed to the user on (e.g.,[22]–[24])provideuser-sideapplicationratecontrol,
the User Interface. mostrequireuserstomanuallyspecifythedesiredrates.
In Section 2, we discuss prior works that propose AMUSE provides automated bandwidth rates and, by
functions related to components of the AMUSE system. conformingtoTCPinteractions,avoidstheTCPtimeouts
Section 3 discusses the Bandwidth Optimizer in more common to existing user-side rate control applications.
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 4
Although the TCP advertisement window is normally locations: while WiFi is always physically available at a
used by the TCP receiver to inform the TCP sender of given location, the user may not access WiFi every time
its available buffer space, other trials [25] have used the that she is there. For instance, a user may sometimes
advertisement window as a means to control the rate of connect to WiFi at her local Starbucks, but may walk
applications. However, this approach has been mainly by on weekdays without initiating a connection. These
applied to the enforcement of different application pri- access probabilities also depend on time: a user might
orities,ratherthandirectcontroloftheapplicationrates. stop at Starbucks in the morning but not in the evening.
Othersolutions,suchas[26],focusontheedgegateway, We use a training set of empirical WiFi access data to
rather than the end user. estimate these time-dependent WiFi access probabilities
at each location, and modify them as we collect more
3 BANDWIDTH OPTIMIZER access data.4 For a location l, we denote the probability
of WiFi access during period k as v (l). We use L to
In this section, we describe the individual components k k
denote the set of observed locations in period k.
of AMUSE’s bandwidth optimization algorithm. Our
Given the time- and location-specific probabilities
design follows two principles: 1) AMUSE’s offloading
v (l), we then predict overall WiFi access by incorporat-
decisions will be implemented in real time on arriving k
ing predictions of users’ future locations. We define w
sessions, and 2) AMUSE must use only the data and k
to be the overall WiFi probability in period k, i.e., the
computational resources available on the end user’s
expected WiFi probability, considering the probabilities
device.Thus,werequiresimple,yetaccurate,algorithms
of all possible locations in period k and the WiFi access
to compute concrete offloading decisions that can be
probability in period k for each location. We use a
communicated directly to the TCP Rate Controller (cf.
second-order Markov chain for the location prediction,
Fig.1b).Inthediscussionbelow,wefirstintroduceprac-
which has been shown to be highly accurate [27]. Algo-
tical algorithms to predict WiFi access and application-
rithm1summarizesthecalculationofoverallWiFiaccess
specificusage(Sections3.1and3.2).Wethenincorporate
probabilities. We use the notation pk+2(l l ) to denote
these predictions into a mathematical allocation frame- l k k+1
the probability that a user is at location l∈L during
work in Section 3.3 and propose a heuristic algorithm k+2
period k+2, given his locations l in period k and l
for computing AMUSE’s bandwidth allocations and of- k k+1
in period k+1. To calculate these pk, we define Nk(s)
floading decisions in Section 3.4.
as the number of times that s is observed, where s is a
To consider a user’s different delay tolerances on
sequenceoflocationsthatendsinperiodk;theobserved
different applications, we group a user’s traffic into dif-
location in each period k is denoted by λ . We update
ferent application types, e.g., streaming, browsing, and k
the pk values using the empirical probabilities of a user
downloads. For practical implementability, we assume
being at different locations during period k.
that only the most heavily used (e.g., top five) applica-
tions are considered, and denote these collectively as a
setJ.Wesupposethatthedayisdividedintondiscrete 3.2 PredictingFutureUsage
periods of time, e.g., 24 hours, and for each period, we
At the beginning of each day, we use previous data to
predictbothWiFiaccessandapplicationusagevolumes.
predict the size s (k) of each application type j ∈ J’s
Given these predictions, we (i.e., AMUSE) must de- j
usageineachperiodk.Toaccommodatethedependence
cide which applications to offload when, subject to a
of session size on the amount of bandwidth allocated,
maximum 3G usage budget. By delaying sessions to
our definitions of session “size” depend on the appli-
future periods, users may gain WiFi access and the
cation: for fixed-volume application sessions such as
ability to offload; however, if WiFi is unavailable, the
downloads, in which the volume (MB) does not depend
user must send these sessions over 3G, which has a
on the available bandwidth, we define the session size
finitebandwidthcapacitythatmustbesharedamongthe
asitsvolume.Forfixed-timesessionssuchasstreaming,
different applications. AMUSE therefore computes a 3G
in which the volume does depend on the bandwidth,
bandwidthallocationwhendecidingwhethertowaitfor
we define the size as the time to complete. We use J to
WiFi. Following the first principle above, we formulate v
denote the set of fixed-volume and J the set of fixed-
thisdecisionasamultiplechoiceknapsackproblem,and t
time application types. We stress that our prediction
propose a heuristic solution algorithm.
algorithms do not depend on the definition of session
size;theyrelyonlyonusers’consistencyfromdaytoday.
3.1 PredictingWiFiConnectivity
We estimate the future usage s (k) by taking a moving
j
SinceWiFiavailabilityisheavilylocation-dependent,we average of the observed usage sizes σ (k) of application
j
predict the probabilities of WiFi access by combining j in period k over some fixed number of days.5
user location prediction with the probabilities of WiFi
access at different locations. We define a “location” to 4.Onemayrefinethesecalculationsbyusingonlyweekdayoronly
be an area with WiFi coverage (e.g., a user’s home). weekend data, as user mobility will likely differ on weekdays and
weekends.
To improve our prediction algorithm’s accuracy, we
5.Otherpredictionmethods(e.g.,ARIMA)canbesubstitutedfora
consider the functional availability of WiFi at different movingaveragewithoutaffectingtheoverallstructureofoursystem.
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 5
Algorithm 1: Computation of WiFi access probabili- 3.3 UserUtilityMaximization
ties over the rest of the day in period i.
In this section, we formulate the user’s offloading de-
ifi=1then cision problem, assuming the future WiFi probabilities
fork←1tondo
wk←(cid:80)l∈Lkvk(l)NkN(l),N isthenumberofdaysofdata. wthkeapnhdrausseag“eosrijg(ikn)aallrye kinnopwenri.oIdn tih”einddisiccuastessionthbaetlothwe,
// Calculate WiFi probabilities for the next
n periods. applicationsession(s)underconsiderationarecompleted
in period i if they are not deferred to a future period.
ifi>1then
fork←2tondo
forallthel∈Lk,lk−1∈Lk−1,lk−2∈Lk−2do
ifNk−1(lk−2lk−1)>0then 3.3.1 UtilityFunctions
pkl(lk−2lk−1)← NNkk−(1lk(l−k2−l2kl−k1−l1)) To mathematically formulate the user’s offloading de-
else cision problem, we need a concrete measure of the
pkl(lk−2lk−1)← NNkk−(1lk(l−k1−l1)) uTsheurs’,s ftorradaeogffivsebnetawpepelnicactoiosnt, ttyhproeujghipnutp,erainodd di,elwaye.
wk←(cid:80)l∈Lkpkl(λk−2λk−1)vk(l) derive expressions for users’ utility of completing those
application sessions over 3G and over WiFi. This utility
is determined by the per-volume price p of 3G, the
amount of time t the session is deferred, the bandwidth
In updating our usage estimates, we modify the
speed r at which the session is completed, and the size
moving-average calculation to take into account our de-
s of the session. We use U (p,t,r,s) to denote the utility
j
ferral recommendations; we wish to predict the amount
of application j ∈J.
of future usage without the deferrals recommended by
Though many functions could be used as the U , we
ouralgorithm.Sinceausermaydelayapplicationusage j
note that these should be decreasing in p and t (price
to another time in order to offload it to WiFi, we “shift
and time deferred) and increasing in r (bandwdith). For
the usage back” in order to evaluate and detect changes
fixed-volume applications, we suppose that the utility is
in the underlying usage pattern over the day. We per-
decreasingins,sincealargersizeindicatesmoretimeto
form these adjustments if the observed usage size for
complete the session. We use the economic principle of
application j in period i is much less than the predicted
diminishing marginal utility to argue that as r becomes
s (i), i.e., the user has shifted her usage of application
j larger or t becomes smaller, users’ marginal utility from
j from period i. To account for the uncertainty in our
rshoulddecrease,andthemarginalutilityfromtshould
predictions, we suppose that the actual usage deferred
increase. For simplicity, we take the units of t to be
to period k from each period i is proportional to the
the number of periods deferred, and do not consider
predicted usage deferred;6 this assumption ensures that
sessions’ timing within the period to which they are
we do not calculate that more usage was deferred to
deferred. Since different users will have different trade-
period k than the actual usage observed in that period.
offs between cost, quality, and delay, we suppose that
Thus, for each application j ∈ J and period i < k, we
the U functions take the same form, but have different
adjust the observed usage σ (i) and σ (k) by j
j j
parameters that depend on the particular application
σ (i)←σ (i)+ (cid:88)n cji(k)sj(i)σj(k) , anTdhuesaebr.ove guidelines still leave many possible utility
j j s (k)+(cid:80)k−1cj(k)s (l)
k=i+1 j l=1 l j functions. To narrow these down, we conducted an on-
σj(k)←σj(k)−k(cid:88)−1s (k)cji+(k(cid:80))skj−(i1)σcjj((kk))s (l). lainndessutarfvfefyroomfoUve.Sr.1u0n0ivuesersrist,iepsr.imFoarrielyacshtuadpepnltisc,aftaiocnultiny
i=1 j l=1 l j Table 1, we gave participants the cost to complete one
applicationsessionover3G,aswellasthespeedofWiFi
Here cji(k) is an indicator variable taking the value 1 if relative to 3G. We then asked the participants how long
application j is deferred from period i to period k and they would wait for WiFi access instead of immediately
0 otherwise. The first expression adjusts the observed completing the session over 3G; for each question, we
usage for application j in period i by adding the traffic offered five options for the maximum amount of time
amount deferred to later time periods, while the second participants were willing to wait, ranging from “I won’t
expressionadjustsbysubtractingthetrafficamountsde- wait” to “as long as necessary.”7
ferredfromprevioustimes.Thismethodisapproximate, We find that our survey data provides a good fit with
but we expect that it will be helpful for predicting the the functional form
future traffic amounts from observed traffic.
(cid:40)
U (p,t,r,s)=C exp(−ν+rν−µt)−ηprs j ∈J
j j t
6.Weassumethatatthetimeofdeferringanapplication,wecannot Uj(p,t,r,s)=Cjexp(−(s/r)ν−µt)−ηps j ∈Jv,
knowhowmuchtraffictheuserwilldefer.Formanyapplicationssuch (1)
asweb browsingand socialnetworking, itishard toknow theexact
traffic amount they will use in advance, since their contents can be
dynamicallyselectedorcreatedbytheuser. 7.Thesurveyquestionsareavailablein[28].
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 6
TABLE1
γ can be chosen without affecting the user’s expected
Estimatedparametersfortheutilityfunction(1).
utility from WiFi in period k. This utility, for a session
C µ ν η of type j originally in period i, is then
Email 0.9848 0.1527 0.1527 assumed0
Browsing 0.6865 0.3269 0.0263 assumed0  
SocialVniedtewo. 00..94379398 00..0010464 40..3070865 00..00998866 (cid:88)cji(k,γ)wkUj(0,k−i,1,sj(i)),
Downloads 0.6737 0.0097 0.0097 0.0986 γ∈Γ
where U denotes the parameterized utility function for while the expected utility from 3G in period k is
j
application types j; prs for j ∈ J and ps for j ∈ J
t v (cid:88)
denote the cost of each session; and Cj, µ, ν, and η are cji(k,γ)(1−wk)Uj(p,k−i,γ,sj(i)).
nonnegative parameters that depend on j. These func- γ∈Γ
tions satisfy several desirable properties: for example,
The user wishes to maximize the sum of these utilities
theconstantsC allowfordifferentuserprioritiesfordif-
j over all (original) periods i and application types j:
ferent types of sessions (e.g. a user intrinsically derives
more utility from certain applications, even with zero (cid:88)n (cid:34)(cid:88)(cid:32)(cid:88)(cid:32)(cid:88)(cid:16) (cid:0) (cid:1)
delayortimetocompletion).8 Forj ∈Jv,thes/r termin max wkUj 0,k−i,1,sj(i) +
cj(k,γ)
the exponential represents the time to completion, while i i=1 j∈J k≥i γ∈Γ
(cid:33)(cid:33)(cid:35)
for j ∈Jt, the bandwidth r represents the quality of the (1−w )U (cid:0)p,k−i,γ,s (i)(cid:1)(cid:17)cj(k,γ)
streaming video. k j j i
Table1showstheparametervaluescalculatedforeach
(2)
session type. To estimate these parameter values, we
(cid:88)(cid:88)
used the probability that a user would not wait for WiFi s.t. cj(k,γ)=1; cj(k,γ)∈{0,1}, (3)
i i
as the utility function value, with b, t, r and s measured k≥iγ∈Γ
relative to their values for WiFi. We assume a negligible
where (3) ensures that each application j in period i is
cost term for low-volume (e.g., email) sessions. We then
deferred to only one period k (we may have k = i),
used nonlinear curve-fitting methods to calculate the
with3Gspeedγ.Thisoptimizationisperformedsubject
utility function parameters, and found a small average
to two constraints: a budget constraint on expected 3G
squared-error of 0.05 for each survey question, upon
usage, and capacity constraints on the 3G bandwidth in
comparing the actual answers with our estimates.
each period.
We see that the C coefficients roughly match our
j
Weassumethattheuserspecifiesamaximummonthly
expectations, with email the most important and social
budget B for 3G usage. We then calculate a daily budget
networking(photouploads)theleastimportantapplica-
B, taking into account both the number of days remain-
tions. The parameter µ represents the amount of time
ing in the month (denoted by m) and the amount of
that a user will wait to start an application, e.g., in
budgetB thathasnotyetbeenspent.Toallowtheuser
anticipation of WiFi access or higher 3G speeds: it is r
someflexibility,wemultiplytheaverageusageB /mby
largest (i.e., users are least willing to wait) for browsing the factor exp(cid:0)1−m−1(cid:1), which equals 1 only ifrm = 1:
and email. The importance of available throughput is
at the end of the month, the user cannot exceed the
parameterized by ν, and is highest for video and lowest
remaining budget. The daily budget B is then defined
for social networking. as B exp(cid:0)1−m−1(cid:1)/m, and the budget constraint is
r
3.3.2 Users’OptimizationProblem n (cid:34)  
(cid:88) (cid:88) (cid:88)(cid:88)
We now use the utility functions (1) to formulate the p  cji(k,γ)(1−wk)sj(i)+
user’s optimization problem. To represent possible 3G
i=1 j∈Jv k≥iγ∈Γ
and WiFi bandwidth speeds, we normalize the volume  (cid:35)
u1.niTtsheso3Gthastpetehde fiγxiesdcpheors-esnecofrnodmWaiFfiinsitpeeesdubesqeutaolsf (cid:88)(cid:88)(cid:88)cji(k,γ)(1−wk)γsj(i) ≤B, (4)
possibilities Γ; generally, all γ < 1 since 3G speeds are j∈Jt k≥iγ∈Γ
usually slower than WiFi, though for LTE networks we The 3G bandwidth capacity constraints ensure that the
may have γ > 1. For each γ ∈ Γ and period k ≥ i, sum of the bandwidth allocated to each application in
we define the indicator variables cji(k,γ) to be 1 if a a given period does not exceed the fixed maximum
session of type j is deferred from period i to period k bandwidth, which we denote as β. Mathematically, this
and assigned 3G speed γ, and 0 otherwise. Note that γ constraint is
is always chosen for each delayed period k; this speed
(cid:88)(cid:88)(cid:88)
γ is then used if WiFi is not available in period k. If (1−wl) cji(l,γ)γ ≤(1−wl)β. (5)
the probability of WiFi availablity is 100%, any value of i≤l j∈Jγ∈Γ
We include a 1−w term on each side so that if w =
8.The−νintheexponentialforj∈Jtisincludedfornormalization: l l
withmaximumbandwidth1andnodelay,wethenhaveUj =Cj. 1 and all sessions complete over WiFi, any 3G speed
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 7
γ may be chosen. Putting (2-5) together, we obtain the Algorithm 2: Bandwidth allocation over a day.
optimization problem
i←1// The current period is denoted by i.
n (cid:34) (cid:32) (cid:32) B←(Br/m)exp(cid:0)1−m−1(cid:1)// Calculate the budget for the
(cid:88) (cid:88) (cid:88) (cid:88)(cid:16) (cid:0) (cid:1) day.
max wkUj 0,k−i,1,sj(i) + CalculateWiFiprobabilitiesusingAlgorithm1withi=1.
cj(k,γ) Calculatepredictedusageoverallnperiodsusingamovingaverage.
i i=1 j∈J k≥i γ∈Γ
Allocatebandwidthbyapproximatelysolving(6-9).
(cid:33)(cid:33)(cid:35)
(1−wk)Uj(cid:0)p,k−i,γ,sj(i)(cid:1)(cid:17)cji(k,γ) (6) foriB←←2sptBoenn−didSnoig−1S/i−/1Reimnaipneirnigoddaii−ly1.budget, given the
UpdateWiFiprobabilitiesusingAlgorithm1.
n (cid:34)   Updatebandwidthallocationsbyre-solving(6-9)fortheremaining
s.t.p(cid:88) (cid:88) (cid:88)(cid:88)cij(k,γ)(1−wk)sj(i)+ n−i+1periods.
i=1 j∈Jv k≥iγ∈Γ
 (cid:35) This Lagrange multiplier algorithm starts from a so-
(cid:88) (cid:88)(cid:88)
 cij(k,γ)(1−wk)γsj(i) ≤B lution that maximizes (6) without considering the con-
j∈Jt k≥iγ∈Γ straints (7-9). The solution is then adjusted so that all
(7) constraints are satisfied, beginning with the “most vi-
(1−w )(cid:88)(cid:88)(cid:88)ci(l,γ)γ ≤(1−w )β∀l (8) olated” (i.e., the constraint with largest Lagrange mul-
l j l
tiplier). This process repeats until no constraints are
i≤l j∈Jγ∈Γ
(cid:88)(cid:88) violated, and the solution can then be improved by
ci(k,γ)=1∀j ∈J; i=1,2,...,n (9)
j adjusting the solution one variable at a time, so as to
k≥iγ∈Γ mostincreasetheobjectivevaluewhilestillnotviolating
cij(k,γ)∈{0,1}. the constraints.10
As the user consumes data over the day, we update
Notethattheproblem’sdecisionvariablescj(k,γ)forall
i both the remaining daily budget B and our predictions
time periods i and applications j represent the schedule
of future WiFi connectivity {w }. The new optimization
k
for application deferrals and 3G rates to be used if
problem over the remainder of the day can then be
the WiFi is not available at the scheduled times. Other
solvedbytakingtheexistingsolutionastheinitialpoint
variablessuchasw ands (i)arecalculatedbyempirical
k j ofourLagrangemultiplieralgorithm.Thissolutionmay
data as explained in Sections 3.1 and 3.2. We can view
well be feasible: the 3G capacity constraints do not
the constraints (9) as choosing exactly one item from a
changeunlessWiFibecomesdefinitelyavailableinsome
knapsack, where each (i,j) pair for i = 1,2,...,n and
period (w → 1), in which case that period k’s capacity
j ∈ J is associated with a knapsack consisting of items k
constraint is removed. Thus, if the existing solution sat-
indexed by the variables k ≥ i and γ ∈ Γ. With this
isfies the new budget constraint, we can skip directly to
interpretation, (6-9) can be seen as a multidimensional,
the “solution improvement” step, significantly reducing
multiple choice knapsack problem. In the Appendix A,
the computational overhead. Algorithm 2 presents this
we show that we can easily extend this formulation so
fullonlinealgorithm,alongwiththeWiFiandappusage
thatthevaryingWiFicapacityisconsideredandtheuser
predictions (Sections 3.1 and 3.2).
chooses which network to use depending on the utility
values of WiFi and 3G.
4 IMPLEMENTATION
3.4 OnlineAlgorithm We implemented an AMUSE prototype on Windows 7
In this section, we present an online algorithm to solve tabletswiththesystemarchitectureshowninFig.1a.We
the optimization problem (6-9). At the beginning of usedtheWindowsFilteringPlatform(WFP)[30]totrack
each day, the user computes an initial solution, given application usage and implement a user-side TCP rate
estimates of the w and s (k). As the w estimates and controlalgorithmtocontroleachapplication’sdownload
k j k
known usage amounts are updated over the day, this rate.
solution is refined. The AMUSE prototype displays both total usage and
While various algorithms exist to compute solutions the usage of individual applications on a daily, weekly,
of the knapsack problem (6-9) to different degrees of and monthly basis, as well as the current upload and
accuracy, we use a Lagrange-multiplier based solution download rates. We also provide user interfaces from
[29] that has relatively small computational overhead which the user can, if he so chooses, set the download
and generally returns good approximations to the opti- rateofeachapplicationandconfigurehisbillingstarting
mum.9 Givenafeasiblesolution,thealgorithmimproves
thesolutionwhilemaintainingitsfeasibility,allowingus 10.If the constraints are especially tight, the Lagrange multiplier
algorithmmaynotyieldasolution.Whileinpracticesuchasituation
to update previously computed solutions over the day.
isunlikelytooccur,wecaneasilyrecoverfromthisfailurebytakingas
theinitialallocationtheworst-casescenario,inwhichallsessionsare
9.Since our estimates of WiFi access and future usage are already giventhelowestpossiblebandwidth;weassumethatthisisafeasible
approximations, even an exact solution to the optimization (6-9) will solution. If only the bandwidth constraint is violated, we can simply
beanapproximationofthe“true”optimum. scaledownthe3Gbandwidthsassignedtodifferentapplications.
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 8
$ DataWiz $ DataWiz
Monthly Usage 3G ▼ Bandwidth Control Algorithm 3: Receiver-side TCP rate control.
UHsoamgee 115500000 1M 2o n3 t h4C l y5u c r6ra e p7n t8 U 9Cs 1au0g m1e1 u12la 1t3i v14e 1 u5 s16a 1g7e 1 8o 1f9 2th0 Pi2s1r o 2mj2e o2c3tne 2td4h 2U 5s 2a6g 2e7 28 29 30 UHsoamgee DUDCapouvlwoirdnar-ldoPe aSCndp teSleypde re1ud.5 n06. n1M2ibn Mpgsb p s TopAPC 1proopn0clnie cebsacsattieionosnnd s3s w4 87 0i0d th used InitmtaiairlnigzeaattidoBvnW:wi←n←//51D2es(biyrteeds)bandwidth (bytes/sec)
Monthly Usage Jan Feb Mar Apr May Monthly Usage adv win←min adv win
Monthly Usage History
BandwSidethtu Cpo ntrol 115500000 Jan Feb Mar Apr May Jun Jul Aug BandwSidethtu Cpo ntrol lbcayhstetecskc←hpeec0rki(obtdiymt←ees0)←.2c(usrerc)ent time(sec)
Fig.2. ScreenshotsoftheAMUSEprototype.Userscan // accumulated received bytes for current period
α←0.5// smoothing factor
view their monthly usage and set bandwidth rates for
ForeachTCPdataandACKpacket:
individualapplications. begin
ifadatapacketisreceivedthen
dateanddataplan(e.g.,2GBpermonth).Figure2shows bytes←bytes+packet len
ifcurrent time−last check time>check periodthen
screenshots of these features. interval←current time−last check time
We next describe the details of our receiver-side TCP throughput←bytes/interval
inc←adv win∗ targetBW−throughput ∗α
rate control algorithm, followed by experimental data targetBW
adv win←adv win+inc
verifying its efficacy. ifadv win>rcv buf sizethen
adv win←rcv buf size
elseifadv win<min adv winthen
4.1 Receiver-SideTCPRateControl
adv win←min adv win
Algorithm2decidesthe3GratethatwillbeusedifWiFi last check time←current time
bytes←0
is not available during the scheduled time period. In
this section, we introduce a TCP rate control algorithm ifanACKpacketisreadytobesentthen
settheadvertisementwindowoftheACKtoadv win
that applies the decided 3G rate to the receiver-side
TCP connection, enforcing the result of Algorithm 2. We
devised a receiver-side TCP rate control algorithm since
Algorithm 3 presents the pseudo code of our imple-
TCP accounts for most Internet traffic [10], and sender-
mentation. The algorithm first initializes the adv wnd to
side TCP rate control can be easily implemented (e.g.
thedefaultvalue(min adv win)whentheconnectionis
using tc in the Linux system).
set up, and periodically calculates the traffic throughput
A TCP sender adjusts a session’s rate based on its
for each application in each period.12 The throughput is
congestion window size (cwnd). The ACK packets from
obtainedbydividingthereceivedbytes(bytes)bythein-
the receiver act as a feedback to the sender on how
tervallength(interval).Ifthethroughputforagivenpe-
much has been sent and how much more can be sent
riod is smaller than the target bandwidth (target BW),
to the receiver. We use this ACK clocking to shape the
we increase the advertisement window size by an
incoming/downloading rates of TCP traffic, by mod-
amount (inc) proportional to the deficit throughput.
ifying the TCP advertisement window size (rcv wnd)
Similarly, if the throughput is larger than the target
field in each ACK packet using the WFP driver. The
bandwidth, we decrease the size of the advertisement
idea behind this approach is that a TCP sender cannot
window by an amount (dec) proportional to the surplus
send more than min(cwnd,rcv wnd). While one could
throughput. Depending on the increase/decrease of the
instead shape the TCP traffic rates by adjusting the
advertisement window, the TCP sender will increase or
round-trip time (RTT) of each flow (i.e., stretching each
decrease the rate of the traffic accordingly, assuming
ACK packet), this latter approach increases the overall
its congestion window is mostly larger than its adver-
response time and renders some interactive or video
tisement window. Here, we multiply the deficit/surplus
TCP applications useless. Modifying the advertisement
bandwidthbyaratioα,inordertoreducetheoscillation
window size does not increase the RTT of each flow,
of throughput due to the drastic window size changes.
making it suitable for all TCP applications.
We use α = 0.5 after experimentally determining this
Unlike current traffic control tools, our proposed con-
value’s efficacy in achieving the target bandwidth in
trol mechanism does not forcibly drop incoming pack-
several different environments. We prevent the adver-
ets, a measure that can induce such undesirable side
tisementwindowsizefrommovingabovethemaximum
effects as frequent TCP timeouts. The principle behind
buffer size (rcv buf size) and below minimum window
our mechanism is as follows: we increase the size of the
size (min adv win).
advertisement window if the traffic rate recently received is
smallerthanthetargetbandwidth,anddecreaseitifthetraffic
4.2 ExperimentalEfficacy
rate recently received is larger than the target bandwidth.
With this approach, we can implement the bandwidth To verify Algorithm 3 in practice, we first test our
control entirely at the TCP receiver. The sender is not receiver-side bandwidth control algorithm by running
modified, but it will react to the advertisement window Iperf over Ethernet, WiFi, and 3G networks. We used
from the receiver according to TCP flow control.11 target bandwidths of 100 Kbps, 500 Kbps, and 1 Mbps;
experimental results for the three cases are shown in
11.Inordertonothurtauser’sresponsetimewithshort-livedTCP
flows,thealgorithmonlyrunsafter5secs,duringwhichtheseshort- 12.We set this value to 200 msec. We found this value works well
livedflowscancompletetheirtransfers. invarioussettingsaftercomprehensiveexperiments.
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 9
TABLE2
600 35K
Throughput
BasicratecontroltestusingIperf.Parenthesesdenote 500 rcv_wnd 30K
TEartWgheeitrFnrieatte th18103e03.10.s84Kt((a03bn..p46ds23))ard5d450e50690v.2i(Ka6(0b.t4i.p4o6s2)n)s. 19100,3201.24.42(K2(11b..86p17s)) Throughput(Kbps) 234000000 11220505KKKK rcv_wnd(Bytes)
3G 95.28(1.52) 474.7(11.86) 896(47.28) 100 5K
0
0 10 20 30 40 50 60
TABLE3 Time(Seconds)
ApplicationratecontroltestusingHTTPandFTP. Fig. 3. An example of throughput and advertisement
Parenthesesdenotethestandarddeviations. windowvariations.
Application(rate) HTTP(300Kbps) FTP(300Kbps)
Ethernet 297.04(3.54) 291.2(4.68)
WiFi 271.12(10.77) 269.28(8.27)
3G 296.16(3.33) 279.2(4.43)
Table2.Whilethebandwidthcontrolalgorithmachieves
the target rate in each of the three different networks,
we observe that the rate over the Ethernet link is much
closer to the target rate than the rates over WiFi and
3G: packet loss rate and link jitter are the smallest in
Ethernet.
We also test the algorithm with different applications.
For this experiment, we set the target bandwidth to 300 Fig.4. Screenshotsoftheusagemonitoringapp.
Kbps and run two applications (HTTP and FTP). Our
results (Table 3) show that the rates achieved are similar
to the target rate. download usage amounts for each application in bytes.
Finally, we show the time evolution of the advertise- To compare AMUSE to other offloading algorithms in
mentwindowsizercv wndandtheresultingdownload- Section 6, we also collected another data set from an
ingrateinFigure3foroneFTPflowwithatargetband- additional 12 Android users and 25 iPhone users in the
width of 300 Kbps. The target bandwidth is represented U.S. This second dataset includes participants’ 3G and
by a straight green line. The time evolution of rcv wnd WiFi usage, WiFi availability, and user locations at a ten
and the rate behave as expected: if the flow rate is minute granularity.13
smaller than the target, then the window size increases,
increasing the rate after a delay. The opposite behavior
is seen if the flow rate is larger than the target, but
eventually both the flow rate and window size stabilize. 5.2 Applicationtypes
5 MEASUREMENT
In Section 3, we classify user’s traffic into 5 application
We conduct a measurement study in order to analyze types (i.e. Email, Browsing, Video, Social networking,
mobileusers’networkusagepatternfromtheviewpoint Downloads). In this subsection, we verify that these
of WiFi offloading. Specifically, in Section 5.2 we show application types comprise most of users’ traffic by vol-
thattheapplicationtypesconsideredinTable1comprise ume,indicatingthatAMUSEcoversmostcellulartraffic.
alargeportionofusers’cellulartraffic.InSection5.3,we In Tables 4 and 5, we list the top 15 applications for
examine the degree to which these applications are al- WiFi and cellular networks, respectively. To identify the
ready offloaded and their potential for more offloading. applicationtypes,wemanuallysearchedforthepackage
names in the Android application market and used the
5.1 DataCollection
application descriptions there. Packages not found in
To collect empirical traffic data for the measurement the Android application market were classified using
study in this section, we recruited smartphone users the name itself (e.g. com.android.email is classified as
to participate in our trial. We recorded the data by “Email”).Packagenamesthatcannotbeidentifiedusing
implementing a usage monitoring app and installing it these methods are designated as “Unclassified.” In the
on users’ phones. Figure 4 shows the screenshots of the case of cellular network, the top five applications corre-
usage monitoring app, which informed users of their spondtotheapplicationtypesinTable1,accountingfor
overall usage over different timescales and usage at 54% of the total cellular traffic. From these observations,
different geographical locations. we can conclude that our offloading mechanism can
We collected application usage data from 20 Android handle a large portion of mobile users’ cellular traffic,
smartphone users in Alaska for 7 days, including appli- demonstrating the possibility of significantly reducing
cation package names and categories and upload and the data cost.
IEEETRANSACTIONSONMOBILECOMPUTING,VOL.XX,NO.YY,MONTH2014 10
25000
Cellular Download
Cellular Upload 1
WiFi Download
20000 WiFi Upload
MB) 0.8
Traffic Amount( 1105000000 CDF 00..46
5000
0.2 WiFi-Email
0 WiFi-Social Networking
Email BrowsingVideo SneotcwiaolrkingDownloadsUncategorized 0 0 20 40 6T0ime C(Helol uu8lra0sr)-SociCa 1le 0Nll0ueltawr-oErkm 1ina2gi0l 140
Application Type
Fig. 5. Traffic amounts for each category and network Fig.7. CDFofthenumberofperiodsforwhicheachuser
type. usesEmailandSocialnetworkingapplications.
100
Upload
WiFi/celluar traffic ratio 1 10 Download buHloasoaendwrdssew,vtwoiedrewt,hboaybiatsncefodormvrhepWaatsihrFianhitgiignuthshoeerrcdsoraeswrttiaotgiostenfumoesrroeaVrlehliydifg,eohorinbaVcaneinddndetiDowvoiitzdwhitnanhng-.
0.1 Email Browsing Video Social networkDinogwnloadsUncategorized faoonfrdDDdooowwwnnnlollooaaadddssa.paWpreshoiilfnefldoaiacdasteiegdsn,ittfihhcaeatnhtmigfohrraedcetioloafnflyotoaofdleivnraigdnecioes
Traffic Type possible.
Fig. 6. The ratio of traffic WiFi to cellular network traffic We also see that the Email and Social networking
foreachapplicationtype. applications have some offloading potential. Figure 7
shows CDFs for the number of periods in which a
5.3 Offloadingpractice user uses E-mail and Social networking applications.
We observe that about 40% of users use WiFi data for
From users’ usage traces, we find that users are already
Email and Social networking applications 30% of the
offloading a large portion of their traffic, but a large
time. Over cellular, the data usage frequency decreases,
amount of video and social networking cellular traffic
but 20% of users spend significant amounts of time on
still runs over WiFi and can be delayed for offloading.
email and social networking. This high usage frequency
In Figure 5, we illustrate the amount of upload and
indicates that some Email and Social Networking traffic
downloadtrafficforeachapplicationtypeincellularand
can be offloaded if a user does not need to wait very
WiFi networks. As expected, the amount of WiFi traffic
long for WiFi access.
is much larger than that of cellular, and the amount of
download traffic is larger than the upload traffic.
As in [1], video traffic accounts for the largest por- 6 EXPERIMENTAL EVALUATION
tion of traffic for WiFi uploads/downloads and cellular
To evaluate the effects of AMUSE’s Bandwidth Opti-
downloads (74, 70, 49% respectively). For these types of
mizer (Algorithm 2 in Section 3) on users’ offloading
traffic, the order of the application types according to
experience,wecollected3GandWiFiusageandmobility
the traffic amount is Video, Social networking, Email,
datafromanadditional12Androidand25iPhoneusers
Browsing,andDownloads.Inthecaseofcellularupload,
over a period of 19 days and one week, respectively,
the traffic amount is in the order of Social networking-
as explained in Section 5.1. We then simulate the per-
Browsing-Email-Video-Downloads. We find that 84% of
formance of AMUSE’s bandwidth optimizer, taking the
the total upload and 66% of the total download traffic
recordedusagedataasthehistoricalusage,andcompare
uses WiFi.
AMUSE’sperformancewithtwootherknownoffloading
To investigate the fraction of each application’s traffic
algorithms in [11]. Our results show that AMUSE can
thatisoffloadedtoWiFinetworks,wecalculatetheratio
both reduce users’ spending and improve their utility
of WiFi to cellular upload and download traffic for all
compared with these two benchmarks.
theapplicationtypes,asshowninFigure6.Ifthisratiois
large, it means that the users already offload their traffic
to WiFi for that application type, either because that 6.1 ExperimentalDataandSettings
application type is delay-tolerant or because it requires
Since some of our users exhibited very similar traffic
WiFi’s high bandwidth (e.g., video applications).
patterns and some showed very limited data usage, we
From Figure 6, we see that different application types
choose sixteen representative users’ data on which to
showdifferentratios.Inparticular,theVideoandDown-
run the AMUSE simulation (eight each for iPhone and
loadtypesshowlargevaluesforbothuploadanddown-
Android). Figures 8a and 8b represent the normalized
load traffic. This coincides with the small values of µ in
cumulative usage of selected iPhone users for cellular
Table 1 for these application types. Video requires high
andWiFi,respectively.Thenormalizedcumulativeusage
ofselectedAndroidusersforcellularandWiFinetworks
13.We do not collect iPhone application usage data due to iOS
implementationrestrictions. are shown in Figure 9a and 9b. We can observe that the