Design, Implementation, and Evaluation ofEnergy-Aware Multi-Path TCP

Yeon-sup Lim1, Yung-Chih Chen1, Erich M. Nahum2, Don Towsley1,Richard J. Gibbens3, and Emmanuel Cecchet1

1College of Computer and Information Sciences, University of Massachusetts Amherst, MA, USA2IBM Thomas J. Watson Research Center, Yorktown Heights, NY, USA

3Computer Laboratory, University of Cambridge, UK{ylim, yungchih, towsley, cecchet}@cs.umass.edu1, nahum@us.ibm.com2, richard.gibbens@cl.cam.ac.uk3

ABSTRACTMulti-Path TCP (MPTCP) is a new transport protocolthat enables systems to exploit available paths throughmultiple network interfaces. MPTCP is particularlyuseful for mobile devices, which usually have multiplewireless interfaces. However, these devices have limitedpower capacity and thus judicious use of these interfacesis required.In this work, we design, implement, and evaluate

an energy-aware variant called eMPTCP, which seeksto reduce power consumption compared to standardMPTCP, with minimal impact on download latency.eMPTCP uses a combination of power-aware subflowmanagement and delayed subflow establishment to ac-complish its goals. Power-aware subflow managementallows eMPTCP to choose paths dynamically to maxi-mize per-byte energy efficiency, using runtime measure-ments and a parameterized energy consumption modelthat accounts for multiple interfaces. Delayed subflowestablishment lets eMPTCP avoid heavy power con-sumptions in cellular interfaces for small transfers.We implement eMPTCP on Android mobile devices

and evaluate it across several scenarios, both in the laband in the wild. We measure both energy consumptionand download times, varying network bandwidth, back-ground traffic, user mobility, client and server location,and download size. Our results show that eMPTCP re-duces power consumption compared to MPTCP by upto 90% for small file downloads and up to 50% for largefile downloads.

Permission to make digital or hard copies of all or part of this work for personalor classroom use is granted without fee provided that copies are not made ordistributed for profit or commercial advantage and that copies bear this noticeand the full citation on the first page. Copyrights for components of this workowned by others than ACM must be honored. Abstracting with credit is per-mitted. To copy otherwise, or republish, to post on servers or to redistribute tolists, requires prior specific permission and/or a fee. Request permissions frompermissions@acm.org.

CoNEXT’15 December 01-04, 2015, Heidelberg, Germanyc© 2015 ACM. ISBN 978-1-4503-3412-9/15/12. . . $15.00

DOI: http://dx.doi.org/10.1145/2716281.2836115

CCS Concepts•Networks → Transport protocols; Network ex-perimentation; Mobile networks; Wireless localarea networks;

KeywordsMulti-Path TCP; Energy Efficiency; Measurements

1. INTRODUCTIONMulti-Path TCP (MPTCP) is a new standardized

transport protocol that enables end hosts to take si-multaneous advantage of multiple network interfacesand utilize path diversity in the network [10, 29, 32].MPTCP can achieve greater throughput, robustness andavailability than standard single-path TCP, all whilemaintaining compatibility with existing applications. Onenatural fit for MPTCP is on mobile devices, such assmartphones, which typically include both cellular andWiFi interfaces.Applying MPTCP to mobile devices introduces a new

concern, namely, the additional energy consumed fromoperating multiple network interfaces. Mobile devicesare frequently constrained by the amount of availablebattery power. Thus, power consumption is an im-portant area of research, particularly in mobile devicessuch as smartphones. In many environments, standardMPTCP does not reduce power consumption comparedto single-path TCP. Standard MPTCP does not con-sider the per-byte energy efficiency of a network path,which depends on several factors, including availablebandwidth and the interface type. It also ignores thehigh fixed energy costs of activating cellular interfaces,known as the promotion and tail costs [1].This paper makes the following contributions:

• We design and implement eMPTCP, a multi-pathTCP for power-constrained mobile devices. Thegoal of eMPTCP is to improve the energy effi-ciency of MPTCP while having minimal impact ondownload latency. eMPTCP is the first MPTCPimplementation that monitors path characteristics

at run time and dynamically chooses paths basedon per-byte energy efficiency. Energy efficiency isprovided by extending a standard power model [1,14] to include multiple interfaces [17]. It is the firstMPTCP implementation that addresses high fixedcellular overheads by using delayed subflow estab-lishment to avoid those overheads when possible.It requires no user intervention and no changes toapplications.

• We evaluate eMPTCP in a controlled lab setting(§4), showing how it naturally chooses the mostenergy efficient path. We show that it is robust tochanging bandwidths and interfering nodes, anddynamically adapts in response to mobility.

• We evaluate eMPTCP in the wild (§5), using a va-riety of client environments and server locations tovary network conditions and determine how well itperforms in real-world environments. eMPTCP re-duces energy consumption by up to 90% for smalldownloads (§5.2) and up to 50% for large down-loads (§5.3). In a more representative Web-sitedownload consisting of multiple URLs and connec-tions, power is reduced by 40% with no reductionin download speed (§5.4)

A preliminary version of this work appeared in [17].In this paper, we refine and enhance the preliminary ap-proach of [17], and perform comprehensive evaluations.Other previous approaches in this area have either reliedonly on analysis and simulation [22, 24] or have studieda much more restricted range of operating environments[21, 28]. Our approach is implemented on the phone andrequires no offloaded computation at run time in con-trast to [24]. In addition, none of the above attempt toreduce cellular fixed overheads. Ours is the first broadevaluation of an implemented, deployable energy-awareMPTCP.The remainder of this paper is organized as follows.

Section 2 provides the background context for our work.We present our energy-aware MPTCP in Section 3. Sec-tion 4 evaluates the performance of eMPTCP in a con-trolled lab setting, while Section 5 evaluates eMPTCPin the wild. Related work is reviewed in Section 6, andwe conclude in Section 7.

2. BACKGROUND

2.1 Multi-path TCPMPTCP splits a single data stream across multiple

paths known as subflows, which are defined logicallyby all end-to-end interface pairs. For example, if eachhost has two interfaces, an MPTCP connection consistsof four subflows. These subflows are exposed to theapplication layer as one standard TCP connection.The benefits of leveraging MPTCP in mobile devices

are three-fold: First, by utilizing the available band-width of each subflow, an MPTCP connection can achieve

higher throughput than a standard TCP connection[27]. Second, while connectivity in one network candegrade or disappear, MPTCP offers a seamless TCPconnection by using paths (subflows) through anothernetwork [28]. Finally, the MPTCP layer is hidden fromuser applications by providing a standard TCP socket.Existing TCP applications need not be modified to sup-port MPTCP [9].MPTCP has three modes of operation to control sub-

flow usage: Full-MPTCP, Single-Path and Backup mode[21]. Full-MPTCP is the standard mode of operation,described above, that utilizes all interfaces. In Single-Path mode, MPTCP uses only one path at a time, es-tablishing a new subflow only after the interface of theactive current subflow goes down. In Backup mode,MPTCP opens TCP subflows over all interfaces, butuses only a subset of them for packet transmission. Theremaining interfaces are kept idle as backups. If a usersets a particular interface to backup mode, MPTCPsends no traffic through the associated subflows unlessall other subflows break. By setting the mode of eachinterface, a user can manually decide path usage con-sidering traffic pricing or battery life [21]. MPTCP cur-rently allows manual configuration of interface usage,but does not support automatic use of the most energy-efficient path.

2.2 Energy in Mobile and WirelessDue to the limited battery life of mobile devices, un-

derstanding and reducing energy consumption in mo-biles has been an active area of research. Researchershave observed high power overheads in cellular network-ing [1, 14], which contributes to cellular interfaces be-ing less power-efficient thanWiFi interfaces [14]. Othershave discovered that more energy is consumed when thesignal is weak [7, 31], and that multiple access pointscan cause extra power loss [19]. Researchers have ex-aminedWiFi in particular, reducing power consumptionvia rate adaptation [16], sleeping short periods [15], us-ing fewer antennas [11], or lowering the clock rate [18].Techniques to improve energy efficiency have included

utilizing the most efficient available interface [23, 26],deferring transmissions until the signal is strong [3, 31],or until a more power-efficient interface is available [25].

2.3 Cellular Promotion and TailMultiple works have identified and addressed the po-

wer overheads in cellular interfaces, frequently calledthe promotion and the tail [1, 14]. The 3rd GenerationPartnership Project (3GPP) standard defines a statemachine for cellular interfaces, and describes the pos-sible power states of each device connected to the net-work. Idle interfaces typically remain in a low-powerstate to save energy. Before a packet can be sent orreceived, an idle interface must switch from a low po-wer state to a high power one, which takes additionaltime, called the promotion. After a transmission is com-plete, however, a cellular interface does not immediately

0

2

4

6

8

10

12

14

WiFi 3G LTE

Fix

ed E

ner

gy O

ver

hea

d (

J)

Interface

0.15 0.06

Galaxy S3Nexus 5

Figure 1: Fixed Energy Cost: WiFi and Cellular

Name Samsung Galaxy S3 LG Nexus 5Release Date May 2012 Nov 2013App.Processor

QualcommMSM8960

Qualcomm8974-AA

Semiconductor 28nm LP 28nm HPMAndroidVersion

4.1.2 (Jelly Bean) 4.4.4 (KitKat)

Kernel Version 3.0.48 3.4.0

WiFi chipsetBroadcomBCM4334

BroadcomBCM4339

Table 1: Mobile Devices

return to the lower power state. Instead, ostensiblyto save energy, the interface remains in the high po-wer state for a period of time. If there is no furtherpacket transmission during that period, the interfacethen returns to the low power state. This period iscalled the tail, and can last 6–12 seconds depending onthe provider. Given its length, the tail contributes asignificant portion of the energy cost for transmission,especially for short transfers. We refer to these as thefixed energy overheads. Our mobile devices share theseoverheads, as shown in Figure 1. Device specificationsare given in Table 1.

3. ENERGY AWARE MPTCPIn this section, we present the design and implemen-

tation of eMPTCP.

3.1 OvervieweMPTCP’s goal is to reduce energy consumption com-

pared to standard MPTCP, while minimizing additionaldelay. It does this by dynamically choosing paths basedon estimated energy efficiency. It also tries to avoid un-necessary cellular fixed costs by delaying subflow estab-lishment over cellular interfaces, unless it believes it ismore energy efficient to do so.To this end, eMPTCP requires an energy model that

captures power consumption according to network in-terface usage. There is a large body of literature thatconsiders mobile devices’ energy consumption based onbandwidth, signal strength, simultaneous use of inter-faces, and so on [1, 7, 14, 17, 20]. We utilize our ex-isting parameterized energy model described in [17] togenerate the required information for eMPTCP.Figure 2 presents the architecture of the eMPTCP

Figure 2: eMPTCP Architecture

implementation. Four core components are depictedthat extend the regular MPTCP implementation at thetransport layer: The bandwidth predictor (§3.2) moni-tors bandwidths over all active subflows and predictsfuture bandwidths. The energy information base (§3.3)holds the transition thresholds, indexed by bandwidth,for selecting which interfaces to use. The path usagecontroller (§3.4) makes decisions about which subflowsto utilize, based on information retrieved from the band-width predictor and the energy information base. Thedelayed subflow (§3.5) module manages subflow estab-lishment requests and delays them if necessary, basedon information from the other two components. Wedescribe each component in turn.

3.2 Bandwidth PredictorThe bandwidth predictor samples all active subflow

throughputs and predicts their future values. By query-ing the routing information at the Internet layer, thebandwidth predictor identifies the interfaces associatedwith active subflows and categorizes predictions per in-terface. The sampling interval δ for each subflow is cho-sen based on its measured round-trip time (RTT) dur-ing subflow establishment, i.e., the elapsed time for theTCP three way handshake. Throughput predictions aremade using a Holt-Winters time-series forecasting algo-rithm [30], which is known to be more accurate thanformula-based predictors [13].If an interface is inactive, the bandwidth predictor

will not have any current throughput information aboutthat interface. This can occur for two reasons: becausethe interface was activated but is now deactivated, orbecause it has never been activated. If the interfacewas deactivated, the bandwidth predictor uses old ob-served samples together with new sampled throughputs.If the interface has never been activated, the predictorassumes non-zero throughput (e.g., 5 Mbps) as an ini-tial bandwidth for the interface to allow eMPTCP toprobe the path through the interface.

0 2 4 6 8 10

WiFi Throughput (Mbps)

0

2

4

6

8

10L

TE

Th

rou

gh

pu

t (M

bp

s)

0.8

1

1.2

1.4

1.6

1.8

Figure 3: Energy Efficiency per DownloadedByte (Samsung Galaxy S3)

3.3 Energy Information BaseThe Energy Information Base (EIB) contains the data

required for eMPTCP to decide which interface(s) touse to maximize energy efficiency. Since we cannot pre-dict the amount of data remaining to be transferred,eMPTCP assumes a large transfer and defines efficiencyin terms of per-byte energy consumption. This informa-tion is computed offline using our parameterized modelfor energy consumption that accounts for multiple inter-faces [17] and generates the EIBs for two mobile deviceslisted in Table 1. Note that any energy model generatedby state-of-art techniques such as [33, 34] can be usedto populate the EIB.Given the energy model, we are able to character-

ize the operating region where MPTCP is more energyefficient than standard single-path TCP over Cellularor WiFi. For example, Figure 3 shows the relative en-ergy consumption per downloaded byte over both WiFiand LTE on the Samsung Galaxy S3, normalized by theamount of energy consumed using the best single inter-face (WiFi or LTE). The Figure is a grey-scale heat mapwhere the darker the area, the more energy-efficientMPTCP is. At the left side of the region, TCP overLTE is the most energy efficient, whereas on the rightside TCP over WiFi is the most efficient. In the regiondefined by the “V” shape, inside the solid white curves,using both interfaces consumes the smallest amount ofenergy to download a byte. This heat map is instanti-ated in the EIB.The EIB represents this data as an array, indexed

by the observed LTE throughput, where each entry in-cludes two WiFi throughputs. This pair of throughputsspecifies the transition points where eMPTCP shouldswitch from a single interface to multiple interfaces andvice versa. For example, in the second row in Table2, given an observed LTE throughput of 1 Mbps, ifthe observed WiFi throughput < 0.134 Mbps, LTE-only should be used; if the observed WiFi throughput ≥0.502 Mbps, WiFi-only should be used; otherwise, bothshould be used.

LTE Thpt. WiFi throughput (Mbps)

(Mbps)LTE OnlyThreshold

WiFi OnlyThreshold

0.5 < 0.043 ≥ 0.2341.0 < 0.134 ≥ 0.5021.5 < 0.209 ≥ 0.8032.0 < 0.304 ≥ 1.070... ......

Table 2: Example of Energy Information Base

3.4 Path Usage ControllerThe path usage controller dynamically decides which

paths to use based on energy efficiency. Once a multi-path connection is established, eMPTCP dynamicallydecides which interfaces to use by retrieving the cur-rent estimates from the bandwidth predictor and usingthem to query the EIB. If data needs to be queued ona subflow, the subflow with the highest per-byte energyefficiency is chosen. Thus, eMPTCP seeks a local opti-mum in terms of total energy consumption.To prevent oscillations, our algorithm uses a 10%

‘safety factor’ when switching from one state to another.Continuing the earlier example (second row of Table 2),if eMPTCP is using both interfaces, it requires a pre-dicted WiFi throughput of 0.552 Mbps, not 0.502, totransition to WiFi-only. Similarly, if eMPTCP is usingWiFi-only, it would require a predicted WiFi through-put of 0.452 Mbps to switch to both interfaces. Thisadds some hysteresis to the system and prevents it fromswitching states too frequently.Note that, eMPTCP does not typically switch to us-

ing a cellular interface only, since the expected gain isnot much more than using both.

3.5 Delayed Subflow EstablishmentWhen data transfers are small, we wish to avoid any

unnecessary expenditure of power establishing a cellularsubflow, with the attendant energy costs of the promo-tion and tail states. To this end, if a cellular interfaceis not already active, eMPTCP introduces a delay be-tween WiFi and 3G/LTE subflow establishment. Thecellular subflow is not started until after eMPTCP re-ceives κ bytes through the WiFi interface, thus avoidingthese fixed overheads when transferring data fewer thanκ bytes.Even after κ bytes of data have been transferred,

eMPTCP still postpones a cellular subflow establish-ment if the measured WiFi throughput is large enoughsuch that using WiFi-only is more energy-efficient thanusing both interfaces, as indicated by the energy infor-mation base.If the available WiFi throughput is poor, solely using

the WiFi subflow until κ bytes are transferred can beless energy efficient than using both interfaces. Indeed,κmay never be reached on a slow WiFi subflow. To pre-clude this scenario, eMPTCP also uses a timer to triggercellular subflow establishment. If the timer expires af-

ter τ seconds, eMPTCP establishes a cellular subflow,even if fewer than κ bytes have been transferred. Thetime threshold τ needs to be tuned to correctly estimateWiFi throughput: τ must be larger than or equal to thetime required to collect enough samples after the WiFisubflow throughput stabilizes. Suppose BW is the avail-able throughput over WiFi, Winit the initial congestionwindow size, RW the WiFi RTT, and φ the number ofrequired samples. Then the condition for τ is:

τ ≥ RW ×(log2

BW ×RW +Winit

Winit+ φ

)(1)

eMPTCP also postpones cellular subflow establishmentif the current MPTCP connection is in an idle state withno transmission activity, even if the timer τ expires.This avoids unnecessary cellular subflow establishmentfor idle connections, as some applications (e.g., HTTP[8]) hold connections open in idle states even after com-pleting data transfer. eMPTCP regards a connection asidle if it does not send or receive any packets during anestimated RTT.

3.6 ImplementationWe have implemented eMPTCP in the Android ver-

sions specified in Table 1. We focus on downloads overthe WiFi and LTE interfaces since they are more com-mon. Each component of eMPTCP utilizes the routinginformation at the Internet layer to identify the inter-face associated with a subflow (subsocket). eMPTCPchecks the destination entry of the socket. The desti-nation entry (struct dst_entry) includes a pointer tothe related network device (struct net_device *dev)which has a name of the interface and a pointer tothe wireless device information (struct wireless_dev*ieee80211_ptr). Thus, eMPTCP can identify whethera socket is associated with a WiFi interface or not bychecking if dev has a valid ieee80211_ptr.MPTCP requires a default primary interface with

which to initiate and receive transfers. Since WiFi ismore energy efficient than cellular on our equipmentand has negligible promotion and tail costs, as shownin Figure 1, we use WiFi as the default interface.Once eMPTCP decides path usage for better energy

efficiency, eMPTCP accordingly adds an MP PRIO op-tion [10], which changes the priority of subflows, to thenext packet to be transmitted; for example, MP PRIOindicating that LTE subflow is in low priority is addedin the next packet if using LTE is energy inefficient.When the device re-uses a path over an interface sus-

pended by the path usage controller, the sender needsto utilize the additional subflow quickly. To this end,eMPTCP disables the CWND reset after an idle periodlonger than the retransmission timeout in RFC2861 [12]to ensure that a subflow avoids unnecessary slow-startwhen eMPTCP starts re-using the subflow. In addition,eMPTCP sets the measured round trip time (RTT) ofthe new subflow to zero. This modification enables arenewed subflow to be quickly probed by the MPTCP

0

2

4

6

8

10

12

1 2 3 4 5 6

LT

E T

hro

ughput

(Mbps)

WiFi Throughput (Mbps)

Download size1MB4MB

16MB

Figure 4: Operating Region where MPTCP isthe Most Energy Efficient to Complete an EntireTransfer (Samsung Galaxy S3)

scheduler, since it selects a subflow with the lowest RTTfor packet transmission [29]. Note that this is only forre-used subflows; new subflows behave the same as stan-dard MPTCP in terms of CWND and RTT.

4. EVALUATION IN A CONTROLLEDLAB

The goal of our first set of experiments is to investi-gate the behavior of eMPTCP in an environment wherewe can control wireless conditions. We first examine astatic configuration (§4.2), then vary the WiFi band-width (§4.3). We examine the impact of backgroundtraffic (§4.4), and then the impact of mobility(§4.5). Weexplore how well eMPTCP adaptively controls path us-age to obtain greater energy efficiency than standardMPTCP, as well as the impact on download time.

4.1 SetupThe mobile devices access a wired server, running

Ubuntu Linux 12.04 with the MPTCP implementation[29]. The server is connected to our campus networkthrough a single Gigabit Ethernet interface. Mobile de-vices can communicate with the server over the Internetusing a WiFi access point (IEEE 802.11g), 3G or 4G cel-lular interfaces from AT&T. Energy traces are collectedusing the techniques described in [17].For the controlled experiments with bandwidth changes,

the mobile device downloads a large file while experienc-ing changing network conditions. We compare eMPTCPto standard MPTCP and TCP over WiFi in several sce-narios, using the Samsung Galaxy S3.We set eMPTCP parameters as follows. The down-

load amount threshold κ to postpone an LTE subflow isset to one MB. This is because MPTCP is rarely moreenergy efficient than single path TCP when download-ing a file smaller than this size. Figure 4 presents thecalculated throughput region where MPTCP is more en-ergy efficient than TCP over WiFi-only and LTE-only,for 1 MB, 4 MB, and 16 MB downloads. Based on ourenergy model in [17], the regions inside the curves ofeach size correspond to the throughput values where

0 50

100 150 200 250 300 350 400 450

MPTCP eMPTCP TCPover WiFi

To

tal

En

ergy C

onsu

mpti

on (

J)

(a) Energy Consumption

0

50

100

150

200

250

MPTCP eMPTCP TCPover WiFi

Dow

nlo

ad

Tim

e (

sec)

(b) Download Time

Figure 5: Static Good WiFi Comparison

0

200

400

600

800

1000

1200

1400

1600

MPTCP eMPTCP TCPover WiFi

Tota

l E

ner

gy C

onsu

mp

tion (

J)

(a) Energy Consumption

0

500

1000

1500

2000

2500

3000

MPTCP eMPTCP TCPover WiFi

Do

wnlo

ad T

ime (

sec)

(b) Download Time

Figure 6: Static Bad WiFi Comparison

MPTCP is more energy efficient than single-path TCPto download a file of that size. The timer threshold τ isset to three seconds: given our experimental setting, theestimated condition based on equation (1) to guaranteeten bandwidth samples is τ ≥ 2.67s. While these valueshave worked well for our experiments, refining them toimprove performance remains a subject for future work.

4.2 Experiments with Static ConfigurationThe purpose of these experiments is to show that, in

relatively simple static environments, eMPTCP makesthe proper path decisions to reduce power consump-tion. We measure energy consumption and downloadtime of eMPTCP, MPTCP, and TCP over WiFi fortwo extreme cases: persistent high (>10Mbps) and low(<1Mbps) WiFi bandwidth while the device downloadsa 256 MB file at a fixed location. Figures 5 and 6 com-pare the energy consumption and download times aver-aged over five runs for the two cases. In the first case,WiFi bandwidth is high, and thus using it is more po-wer efficient than using either LTE or both interfaces.Figure 5 shows that eMPTCP chooses WiFi-only, effec-tively behaving similar to single-path TCP over WiFi.In contrast, when WiFi bandwidth is small (<1Mbps),and thus less energy-efficient than LTE, Figure 6 showsthat eMPTCP yields almost the same performance asMPTCP by using both interfaces (after the LTE startupdelay determined by parameters κ and τ). This illus-trates that eMPTCP automatically seeks the most en-ergy efficient path usage without user involvement.

4.3 Experiments with Bandwidth ChangesNext we examine how robust eMPTCP is to changes

transfer completes transfer completestransfer completes

050

100150200250300350

Ene

rgy

(J)

MPTCPeMPTCPTCP over WiFi

02468

1012

0 100 200 300 400Time (sec)

WiF

ith

roug

hput

(M

bps)

Figure 7: Accumulated Energy ConsumptionExample with Random WiFi Bandwidth Change

MPTCP

eMPTCP

TCP over WiFi

300 325 350 375 400Energy (J)

100 200 300 400 500Download time (sec)

Figure 8: Random WiFi Bandwidth Changes

in network bandwidth. Here, WiFi link bandwidth ismodulated by a two state on-off process with exponen-tially distributed times spent in the on or off state witha mean of 40 seconds. The bandwidth provided by theAP is ≤1Mbps or ≥10Mbps, depending on its state.Measurements are taken while the device downloads a256 MB file at a fixed location.Figure 7 presents an example time series trace of the

accumulated energy consumption of eMPTCP, MPTCP,and TCP over WiFi for a single run with random WiFibandwidth changes. At the beginning of the trace,after the LTE startup delay, eMPTCP uses both in-terfaces since WiFi throughput is too small to be en-ergy efficient. However, eMPTCP suspends the LTEsubflow after the WiFi bandwidth increases at aroundtime 60, while MPTCP continues to use both interfaces.By suspending the LTE subflow, eMPTCP spends ap-proximately 20% less energy than standard MPTCP atthe cost of a 40% larger download time. Compared tosingle-path TCP over WiFi, eMPTCP both completesthe download sooner (by about 50%) and consumes lessenergy (by about 15%).Figure 8 compares energy consumption and down-

load time averaged over ten runs. This figure, as wellas similar ones to follow, uses a symbol to show the sam-ple mean together with horizontal bars of length twicethe standard error of the mean (SEM). The quantitySEM for a sample x1, x2, . . . , xn is given by the expres-

sion s/√n where

s =

√√√√ 1

n− 1

n∑i=1

(xi − x) (2)

is the sample standard deviation and x = 1n

∑ni=1 xi is

the sample mean. In this set of experiments, eMPTCPconsumes approximately 8% and 6% less energy on av-erage than MPTCP and TCP over WiFi, respectively.However, eMPTCP is approximately 22% slower on av-erage than MPTCP since it utilizes the LTE subflowonly when the LTE subflow can improve energy effi-ciency. In contrast to single-path TCP over WiFi, byutilizing an LTE subflow when WiFi throughput is ≤1Mbps, eMPTCP completes downloads twice as fast andconsumes less energy. Note that the performance gainachieved by eMPTCP differs according to how WiFibandwidth changes. If WiFi bandwidth changes fre-quently, the switching overhead in eMPTCP may be-come noticeable as an LTE interface triggers a promo-tion and tail state each time that it starts to be usedagain.

4.4 Experiments with Background TrafficIn this section we investigate how well eMPTCP copes

with random background traffic. It is well known thatmultiple WiFi nodes can contend for the air channel,causing interference and loss (e.g., [19]). Backgroundtraffic causes contention and interference in the commu-nication channel, resulting in throughput changes simi-lar to link bandwidth changes. In these experiments, weutilize n = 2 or n = 3 interfering nodes, which use thesame WiFi channel as the mobile device. While the de-vice downloads a 256 MB file at a fixed location, eachnode generates UDP traffic according to a two stateMarkov on-off process, with rates (per second) λon andλoff. We fix λon = 0.05, and then perform experimentswith λoff = 0.025 and λoff = 0.05. As in Section 4.3, wecontrol background traffic for the WiFi channel only.Figure 9 shows sample throughput traces of MPTCP

and eMPTCP when two interfering nodes turn trafficon and off with λon = 0.05 and λoff = 0.025. We ob-serve that standard MPTCP avoids aggressive use ofthe LTE subflow when the WiFi subflow provides highbandwidth, e.g., during the interval 10–60 seconds inFigure 9. This is because the MPTCP subflow sched-uler chooses the WiFi subflow for packet transmissionbecause it has a large CWND and the smallest RTT[29]. However, MPTCP consumes energy utilizing theLTE subflow even though the throughput gain is small.In contrast, eMPTCP suspends the LTE subflow whenWiFi bandwidth is sufficiently large in order to avoid en-ergy inefficient path usage. Note that at around time 60,the LTE throughput of MPTCP increases more slowlythan that of eMPTCP. This is because the LTE subflowof MPTCP is in congestion avoidance after experiencinga loss at time 10 while that of eMPTCP is in slow-start

0

5

10

15

0

5

10

15

MPT

CP

eMPT

CP

0 50 100 150 200Time (sec)

Thr

ough

put (

Mbp

s)

LTEWiFi

Figure 9: Example Throughput Trace with Ran-dom WiFi Background Traffic (n = 2, λon = 0.05,and λoff = 0.025)

(λoff=0.025, n=2)

(λoff=0.025, n=3)

(λoff=0.05, n=3)

80% 100% 120% 140%Energy

eMPTCP TCP over WiFi

100% 200% 300% 400% 500%Download time

Figure 10: Comparison normalized relative toMPTCP in Random WiFi Background Traffic

since it is used for the first time. In Figure 9, eMPTCPincorrectly uses an LTE subflow in the intervals [140,150] and [190, 200]. This is due to sudden decreasingWiFi throughputs, which result in incorrect throughputpredictions. However, eMPTCP stops using the LTEsubflow after the WiFi estimates improve.Figure 10 presents the average energy consumption

and download times for different values of n and λoff,in percentage terms relative to MPTCP, i.e., smallernumbers are better, and numbers lower than 100% arebetter than standard MPTCP. MPTCP’s place on theFigure is denoted by the red dashed line. Values areaveraged over five experiments.Figure 10 shows that eMPTCP consumes less energy

than MPTCP as n and λoff decreases. When λoff =0.025, we observe that the eMPTCP and WiFi-onlyare more efficient that MPTCP when n = 2. Recallthat the energy efficiency of eMPTCP improves whenit can suspend an LTE subflow in situations where us-ing WiFi only is more energy efficient. Larger numbersof interfering WiFi nodes result in more losses causedby collisions when background traffic is present, result-ing in more CWND decreases. Thus, the device islikely to obtain a larger TCP throughput with a largerCWND when there is no background traffic, resultingin a greater energy efficiency of TCP over WiFi andeMPTCP. Note that TCP over WiFi is most energyefficient when n = 2 and λoff = 0.025. However, asshown in Figure 10, in that setting, TCP over WiFi re-quires twice as much time to complete a download aseMPTCP, while it consumes just 11% less energy.As shown in Figure 10, MPTCP provides the smallest

Figure 11: Mobile Scenario inside UMass CSbuilding. Route starts at the blue point. Thered square is the AP. The red dashed circle isthe estimated usable access range of the AP.

download times, regardless of the values of n and λoff,since it always utilizes the LTE subflow. In addition, asexpected, the download time of TCP over WiFi becomessignificantly larger as n and λoff increase. Compared toMPTCP, download times under eMPTCP are 20-40%larger while energy consumption is 9-11% lower. Thismay be because eMPTCP sometimes poorly predictsavailable bandwidth due to fluctuating throughputs, asillustrated in Figure 9, and it also incurs additional en-ergy overhead when suspending and resuming an LTEsubflow due to the promotion and tail costs. Comparedto single-path TCP over WiFi, eMPTCP reduces down-load time by up to 70%, while at the same time usingless energy.

4.5 Experiments with MobilityThe focus of this section is to determine how well

eMPTCP performs and adapts in a mobile scenario. Wetake measurements while moving for 250 seconds alongthe route shown in Figure 11. To make our comparisonbetween MPTCP and eMPTCP as fair as possible, weuse the same route for the experiments.Figure 12 presents example traces of accumulated en-

ergy consumption from our mobile scenario. In thisexperiment, the device is sometimes within WiFi com-munication range, and sometimes outside it, depend-ing on its location. As the device moves outside thecommunication range, WiFi throughput decreases, e.g.,the duration around 25-40 seconds in Figure 12. Atthe beginning of the route, MPTCP starts by establish-ing both subflows, whereas eMPTCP postpones estab-lishing an LTE subflow, since WiFi throughput is highenough to be more energy efficient than using both in-terfaces. However, eMPTCP establishes an LTE sub-flow after the WiFi bandwidth decreases when the de-vice is leaving the AP communication range (at around25 seconds in Figure 12). Then, whenever the devicecannot obtain enough WiFi bandwidth to be more en-ergy efficient than using both interfaces, eMPTCP uti-lizes the LTE subflow rather than only using the badWiFi subflow. In this experiment, we observe that since

0100200300400500600

Ene

rgy

(J) MPTCP

eMPTCPTCP over WiFi

0

5

10

15

20

0 50 100 150 200 250Time (sec)

WiF

ith

roug

hput

(M

bps)

Figure 12: Example of Accumulated EnergyConsumption with Mobile Scenario

MPTCP

eMPTCP

TCP over WiFi

0.8 0.9 1.0 1.1Energy (J/b)

250 300 350 400 450 500Download amount (MB)

Figure 13: Mobile Scenario Comparison

the device is inside WiFi communication range most ofthe time, eMPTCP utilizes the LTE subflow only for afew short periods. Therefore, as shown in Figure 12, theslope of eMPTCP’s accumulated energy consumption(the energy consumption per second) is larger than thatof TCP over WiFi, but smaller than that of MPTCP.We now examine the per-byte energy efficiencies of

MPTCP, eMPTCP, and single-path TCP over WiFi.Figure 13 compares the energy consumption per byteand download amount for 250 seconds averaged overfive runs. eMPTCP’s energy consumption per byteis 22% smaller than that of MPTCP and 15% largerthan that of TCP over WiFi, since eMPTCP utilizesthe LTE subflow for only several short periods. Be-cause WiFi throughput degradation is due only to thedistance between the AP and device (as there is noWiFi background traffic in these experiments), TCPover WiFi is slightly better in terms of energy efficiencythan eMPTCP, corresponding to the case when n = 2and λoff = 0.025 in Figure 10.Focusing on the amount of data downloaded during

the experiments, we observe that eMPTCP downloads25% less data than MPTCP, while exhibiting 22% lowerper-byte energy costs. Here, eMPTCP roughly losesabout the same in performance that it saves in energy,due to the overhead of switching betweenWiFi-only andusing both interfaces. eMPTCP downloads 28% moredata than single-path TCP over WiFi even though ityields almost as good per-byte energy efficiency (just8% more energy consumption per byte).

4.6 Comparison with existing approachesRaiciu et. al [28] propose a simple strategy called

MPTCP with WiFi First, where MPTCP only usesWiFi when available, and only uses the cellular net-work otherwise. This is accomplished by placing thecellular subflow in backup mode and activating it onlywhen WiFi is not available. This simple strategy mayseem similar to eMPTCP, however, it cannot take ad-vantage of dynamic situations where TCP over LTE orMPTCP is more energy-efficient than TCP over WiFi.MPTCP with WiFi First can only utilize an LTE sub-flow when the WiFi subflow explicitly breaks, such asdue to a WiFi AP disassociation. For example, in ourmobile scenario in Section 4.5, MPTCP with WiFi Firstwould not use the LTE subflow even when the WiFi sub-flow becomes unusable, e.g., the duration around 25∼40seconds in Figure 12, since the device does not lose theWiFi association. Therefore, if WiFi provides too lowbandwidth to be more energy efficient than LTE while itis still associated, MPTCP with WiFi First degeneratesinto single-path TCP over WiFi, which yields inefficientenergy usage as shown in subsections 4.2–4.5. It alsoneedlessly activates the cellular interface at connectionestablishment.Pluntke et al. [24] introduce a Markov Decision Pro-

cess (MDP) based MPTCP path scheduler to minimizeenergy consumption. The MDP based scheduler cannotbe computed in the Kernel at run time since it requiresexpensive computational overhead and a finite state ma-chine of throughput changes with transition probabili-ties, which makes it hard to be practical in real deploy-ments. Therefore, rather than directly implementingtheir approach in mobile devices, we generate the MDPbased schedulers and simulate their behaviors given ourexperimental scenarios and energy model. Unit timefor state transitions is set to one second as in [24].Note that the authors consider only 3G andWiFi energymodels in which 3G energy consumption becomes lowerthan WiFi for high data rates. In contrast, LTE en-ergy consumption per second never becomes lower thanWiFi in our energy model. We observe that the gener-ated MDP schedulers choose WiFi-only for all scenarios,resulting in same energy performance (and limitations)as TCP over WiFi.

5. EVALUATION IN THE WILDWe next examine whether eMPTCP provides greater

energy efficiency than standard MPTCP in more realis-tic environments. We deploy MPTCP enabled servers inAsia (Singapore - SNG), Europe (Amsterdam - AMS),and North America (Washington D.C. - WDC). Eachserver has one network interface on the public Inter-net. We investigate the performance of eMPTCP whendownloading files of different sizes (256 KB for small filetransfer and 16 MB for large file transfer) at three loca-tions: a university building where the WiFi AP is con-nected to the campus network, student housing where

0

5

10

15

20

25

0 5 10 15 20 25

LT

E T

hro

ughp

ut

(Mbps)

WiFi Throughput (Mbps)

Bad-Bad

Bad-Good

Good-Bad

Good-Good

Figure 14: Trace Categories according to WiFiand LTE throughput - 16MB Downloads

the AP is connected to the campus network throughCisco Long-Reach Ethernet, and a personal residencewhere the AP connects to a cable network.We collect ten traces for each combination of file size,

device and server locations. Since network conditionscan vary over time, for each configuration we conductten iterations of a set of experiments. Each set con-sists of one run each of eMPTCP, original MPTCP, andsingle-path TCP over WiFi for the same configuration.The ordering within the set is randomized.

5.1 Trace CategorizationWe group the collected traces into four categories

based on the qualities of WiFi and LTE, either Good orBad. We set 8 Mbps as a threshold to decide whethera network is good or bad. Figure 14 presents a scat-terplot of measured WiFi and LTE throughputs for allexperiments downloading 16 MB files. The scatterplotis divided into the four categories, and the red line indi-cates the boundary above which MPTCP is more energyefficient than TCP over WiFi for downloading.

5.2 Small File TransfersFigure 15 presents Whisker plots showing first quar-

tile (Q1), median, third quartile (Q3), and outliers ofmeasured total energy consumptions and download timesin the 256 KB traces for each of the four categories.Dots are outliers, which sit outside the range [Q1 −1.5IQR,Q3 +1.5IQR], where IQR is the inter-quartilerange defined as (Q3 −Q1).In this environment, eMPTCP almost always behaves

the same as TCP over WiFi across all categories, yield-ing significantly less total energy consumption (from75% to 90%) with statistically similar download timesas MPTCP. This is because the transfer is short, canbe completed over WiFi, and eMPTCP avoids the tailstate power costs of the LTE interface by delaying LTEsubflow establishment.eMPTCP does use the LTE subflow in a few instances,

namely the outliers in Figure 15(a) and (b), which ex-hibit similar values to MPTCP. In these cases, LTEsubflow establishment is triggered via timer expiration

0 2 4 6 8 10 12

Energy Consumption (J)

0 1 2 3 4 5 6 7 8

Download Time (sec)

(a) Bad WiFi & Bad LTE

0 2 4 6 8 10 12

Energy Consumption (J)

MPTCP

0 1 2 3 4 5 6 7 8

Download Time (sec)

(b) Bad WiFi & Good LTE

0 1 2 3 4 5 6 7

Energy Consumption (J)

eMPTCP

0 0.2 0.4 0.6 0.8 1 1.2

Download Time (sec)

(c) Good WiFi & Bad LTE

0 1 2 3 4 5 6 7

Energy Consumption (J)

TCP over WiFi

0 0.2 0.4 0.6 0.8 1 1.2

Download Time (sec)

(d) Good WiFi & Good LTE

Figure 15: Small File Transfers (256 KB Downloads)

0 20 40 60 80 100 120 140 160

Energy Consumption (J)

0 100 200 300 400

Download Time (sec)

(a) Bad WiFi & Bad LTE

0 20 40 60 80 100 120 140 160

Energy Consumption (J)

MPTCP

0 100 200 300 400

Download Time (sec)

(b) Bad WiFi & Good LTE

0 5 10 15 20

Energy Consumption (J)

eMPTCP

0 5 10 15 20

Download Time (sec)

(c) Good WiFi & Bad LTE

0 5 10 15 20

Energy Consumption (J)

TCP over WiFi

0 5 10 15 20

Download Time (sec)

(d) Good WiFi & Good LTE

Figure 16: Large File Transfers (16 MB Downloads)

since the WiFi throughput obtained by eMPTCP is ex-ceptionally small. Recall that after the timer expires,eMPTCP greedily chooses paths based on expected per-byte efficiency without knowing the length of the trans-fer remaining. Thus, even though the remaining data istoo small for eMPTCP to take advantage of LTE’s rel-ative energy efficiency in this scenario, eMPTCP usesboth because of the extremely slow WiFi.

5.3 Large File TransfersFigure 16 presents Whisker plots of measured total

energy consumption and download time of the 16 MBdownload experiments for each category. We observethe following:Bad WiFi & Bad LTE: eMPTCP consumes 33% less

energy than MPTCP and TCP over WiFi, while com-pleting downloads in 20% less time. eMPTCP is themost energy efficient since it adaptively controls pathusage according to expected per-byte efficiency. TCPover WiFi exhibits similar energy consumption to stan-dard MPTCP but with roughly 6x longer downloadtimes.Bad WiFi & Good LTE: eMPTCP yields similar en-

ergy consumption to MPTCP with slightly larger down-load times. eMPTCP behaves similarly to MPTCP,since the throughput obtained over WiFi is small. The

slightly larger download times than MPTCP are dueto the delayed LTE subflow establishment. TCP overWiFi performs the worst, both in terms of downloadtime and efficiency, since the WiFi is poor.Good WiFi & Bad LTE: eMPTCP uses roughly 50%

of the energy that MPTCP does, since it never utilizesthe LTE subflow. TCP over WiFi behaves similarly.eMPTCP takes about 20% longer than MPTCP to com-plete downloads. eMPTCP essentially behaves the sameas TCP over WiFi, and obtains similar results.Good WiFi & Good LTE: This is similar to the above

case, since the WiFi is fast and using WiFi-only is morepower efficient than using both.

5.4 Case Study: Web BrowsingWe now examine whether eMPTCP improves energy

efficiency with a common application: Web browsing.To this end, we deploy a copy of CNN’s home page (asof 9/11/2014), which consists of 107 Web objects, intoour MPTCP server in Washington DC. At our depart-ment building, we measure the energy consumption andlatency to download all objects in the page. We con-sider the environment in this setting to have good WiFiand good LTE.Figure 17 shows the average measured energy con-

sumption and latency of MPTCP, eMPTCP, and single-

0

5

10

15

20

25

30

MPTCP eMPTCP TCPover WiFi

Tot

al E

nerg

y C

onsu

mpt

ion

(J)

(a) Energy Consumption

0

2

4

6

8

10

12

MPTCP eMPTCP TCPover WiFi

Lat

ency

(se

cond

s)

(b) Latency

Figure 17: Web browsing Comparison

path TCP over WiFi. In this experiment, the An-droid web browser establishes six parallel (MP)TCPconnections to the server (12 subflows for MPTCP),with HTTP persistent connections. Note that the val-ues are averaged over 10 runs and the power consumedfor the Web browser application is included in the to-tal energy consumption. As shown in Figure 17(a),MPTCP consumes 60% more energy (around 10J) thaneMPTCP and TCP over WiFi. Since almost of all ob-jects in the Web page are small (<256 KB), eMPTCPdoes not utilize the LTE network and achieves betterenergy efficiency. Figure 17(b) shows that eMPTCPyields almost the same latency as MPTCP with less en-ergy consumption. This is because, for small downloads,it is hard for MPTCP to obtain gains by utilizing anLTE subflow in the case of small object downloads [4].In contrast, eMPTCP automatically postpones an LTEsubflow establishment unless a user initiates a large datatransfer, such as video streaming. If a large transfer oc-curs, eMPTCP adaptively switches path usage betweenusing both interfaces and WiFi-only, resulting in betterenergy efficiency than MPTCP. This example is meantto illustrate the potential benefits of eMPTCP for morecomplex workloads. More representative and exhaus-tive application scenarios remain as future work.

6. RELATED WORKPluntke et al. [24] are the first to introduce the con-

cept of scheduling paths in MPTCP to minimize energyconsumption. They use a scheduler based on a Markovdecision process. Schedules are computationally expen-sive operations, hence they are computed in the cloudand downloaded periodically to the device, which isimpractical for real deployment. They evaluate theirscheduler via simulation, using models of device energyconsumption. They find they can reduce energy con-sumption by almost 10% in one out of four scenarios.Our algorithm, in contrast, is evaluated experimentallyusing a real MPTCP implementation on a physical de-vice, and across many scenarios. It also achieves muchhigher energy reductions, up to 90%. Pluntke et al. [24]is discussed in more detail in Section 4.6.Raiciu et al. [28] look at a number of issues in us-

ing MPTCP for mobility, including power consumption.They propose and evaluate a simple strategy that pe-

riodically samples both paths for 10 seconds and thenuses the more energy-efficient path for 100 seconds. Eval-uating their approach via simulation, their method ismore energy efficient than an energy-unaware MPTCPimplementation, but achieves lower bandwidth. Theyalso propose a strategy called“MPTCP withWiFi First”,which exclusively uses WiFi when it is present, andonly uses the cellular network when WiFi is unavail-able. However, this approach cannot avoid inefficientuse of energy due to automatic activation of the cellu-lar interface and the attendant promotion and tail statecosts. Raiciu et al. [28] are discussed in more detail inSection 4.6.Paasch et al. [21] studied mobile/WiFi handover per-

formance with MPTCP. They also measure energy con-sumption on a Nokia N950 smartphone for two down-load scenarios and find that using WiFi alone is moreenergy-efficient than base MPTCP. They also suggestSingle-Path Mode, which establishes a new subflow onlyafter the current interface goes down. By setting WiFias the primary interface, Single-Path Mode MPTCPcan avoid the fixed energy overhead for 3G/LTE whenWiFi is available.Compared to our approach, however, both strategies

are unable to take advantage of more dynamic situationswhere TCP over LTE or MPTCP may become moreenergy efficient than TCP over WiFi. In addition, theycan only utilize an LTE subflow when the WiFi subflowexplicitly breaks, such as disassociating with an AP.Peng et al. [22] study energy consumption in MPTCP

via analysis as a global optimization problem. Theypresent two algorithms, customized for real-time andfile transfer, and evaluate them via simulation. Whilethey do utilize an energy model, they do not considercellular promotion and tail costs, and do not evaluatetheir approach experimentally.Bui et al. [2] present GreenBag, a middleware system

to aggregate bandwidth of asymmetric wireless linksfor video streaming. GreenBag estimates the availablebandwidth of WiFi and LTE and determines the amountof traffic to allocate to each interface. The authors showthat GreenBag reduces energy consumption by 14∼25%compared with a bandwidth aggregation for throughputmaximization. Since GreenBag operates above the TCPlayer as a system background process, it only works formodified HTTP requests sent not to original destina-tions but to GreenBag. Thus, each application needs tobe modified to cooperate with GreenBag, making de-ployment difficult. MPTCP, in contrast, requires noapplication modifications and works with all TCP traf-fic.Ding et al. [6] proposes a mobile traffic offloading ar-

chitecture that utilizes WiFi to migrate mobile trafficfrom cellular while reducing energy consumption. Theauthors demonstrate that the proposed architecture ob-tains more than 80% energy savings, using a proto-type on a Nokia N900 smartphone and their own musicstreaming application. However, they do not consider

potential energy gain from simultaneous use of both in-terfaces. As with Bui et al. [2], applications must bemodified for the approach to work.Croitoru et al. [5] show that MPTCP can improve

user experience over WiFi by associating with multipleAPs simultaneously. By utilizing an MPTCP connec-tion with subflows connected to all available APs, a mo-bile client can maintain seamless connectivity withouthaving to consider a handover. The authors also inves-tigate situations when connecting to multiple APs candegrade network performance. They propose estimat-ing client-side AP efficiency and using ECN notificationto direct traffic to subflows associated with the mostefficient APs while avoiding use of subflows that expe-rience poor throughput. Their study does not considercellular usage or energy consumption.

7. CONCLUSIONThis paper proposes, implements, and evaluates an

enhanced MPTCP designed to improve energy efficiency,called eMPTCP. eMPTCPmanages subflow usage basedon expected per-byte energy efficiency given availablebandwidth. Our experimental results using our imple-mentation in real mobile devices show that eMPTCPis able to consume less energy than MPTCP while stillproviding MPTCP’s benefits of multi-path such as im-proved performance, availability, and transparency. Forfuture work, we plan to examine more statistically var-ied application traffic such as video streaming, Webdownloads, and upload scenarios, as well as other wire-less technologies such as Bluetooth.

AcknowledgementsThis research was sponsored by the US Army ResearchLaboratory and the UKMinistry of Defence and was ac-complished under Agreement No. W911NF-06-3-0001.We would like to thank the anonymous reviewers fortheir useful comments.

8. REFERENCES[1] N. Balasubramanian, A. Balasubramanian, and

A. Venkataramani. Energy consumption in mobilephones: A measurement study and implicationsfor network applications. In Proc. of ACM IMC,pages 280–293, 2009.

[2] D. H. Bui, K. Lee, S. Oh, I. Shin, H. Shin,H. Woo, and D. Ban. Greenbag: Energy-efficientbandwidth aggregation for real-time streaming inheterogeneous mobile wireless networks. In Proc.of IEEE RTSS, pages 57–67, 2013.

[3] A. Chakraborty, V. Navda, V. N. Padmanabhan,and R. Ramjee. Coordinating cellular backgroundtransfers using loadsense. In Proc. of ACMMobiCom, pages 63–74. ACM, 2013.

[4] Y.-C. Chen, Y.-S. Lim, R. J. Gibbens, E. Nahum,R. Khalili, and D. Towsley. A measurement-based

study of multipath TCP performance in wirelessnetworks. In Proc. of ACM IMC, pages 455–468,Nov 2013.

[5] A. Croitoru, D. Niculescu, and C. Raiciu.Towards WiFi mobility without fast handover. InProc. of USENIX NSDI, pages 219–234, 2015.

[6] A. Ding, B. Han, Y. Xiao, P. Hui, A. Srinivasan,M. Kojo, and S. Tarkoma. Enabling energy-awarecollaborative mobile data offloading forsmartphones. In Proc. of IEEE SECON, pages487–495, 2013.

[7] N. Ding, D. Wagner, X. Chen, Y. C. Hu, andA. Rice. Characterizing and modeling the impactof wireless signal strength on smartphone batterydrain. In Proc. of ACM SIGMETRICS, pages29–40, 2013.

[8] R. Fielding and J. Reschke. Hypertext TransferProtocol (HTTP/1.1): Message Syntax andRouting. RFC 7230, 2014.

[9] A. Ford, C. Raiciu, M. Handley, S. Barre, andJ. Iyengar. Architectural guidelines for multipathTCP development. RFC 6182 (Informational),Mar. 2011.

[10] A. Ford, C. Raiciu, M. Handley, andO. Bonaventure. TCP extensions for multipathoperation with multiple addresses. RFC 6824,2013.

[11] D. Halperin, B. Greenstein, A. Sheth, andD. Wetherall. Demystifying 802.11n powerconsumption. In Proceedings of the 2010 workshopon Power aware computing and systems(HotPower), page 1. USENIX Association, 2010.

[12] M. Handley, J. Padhye, and S. Floyd. TCPcongestion window validation. IETF RFC 2861,2000.

[13] Q. He, C. Dovrolis, and M. Ammar. On thepredictability of large transfer TCP throughput.In Proc. of ACM SIGCOMM, pages 145–156,2005.

[14] J. Huang, Q. Feng, A. Gerber, Z. M. Mao, S. Sen,and O. Spatscheck. A close examination ofperformance and power characteristics of 4G LTEnetworks. In Proc. of ACM MobiSys, pages225–238, 2012.

[15] K.-Y. Jang, S. Hao, A. Sheth, and R. Govindan.Snooze: Energy management in 802.11n WLANs.In Proc. of ACM CoNEXT, pages 12:1–12:12,2011.

[16] C.-Y. Li, C. Peng, S. Lu, and X. Wang.Energy-based rate adaptation for 802.11n. InProc. of ACM MobiCom, pages 341–352. ACM,2012.

[17] Y.-S. Lim, Y.-C. Chen, E. M. Nahum, D. Towsley,and R. J. Gibbens. How green is multipath TCPfor mobile devices? In Proc. of ACMAllThingsCellular, pages 3–8, 2014.

[18] F. Lu, G. M. Voelker, and A. C. Snoeren. SloMo:Downclocking WiFi communication. In Proc. ofUSENIX NSDI, pages 255–258, 2013.

[19] J. Manweiler and R. Roy Choudhury. Avoidingthe rush hours: WiFi energy management viatraffic isolation. In Proc. of ACM MobiSys, pages253–266, 2011.

[20] A. Nika, Y. Zhu, N. Ding, A. Jindal, Y. C. Hu,X. Zhou, B. Zhao, and H. Zheng. Energy andperformance of smartphone radio bundling inoutdoor environments. In Proc. of WWW, pages809–819, 2015.

[21] C. Paasch, G. Detal, F. Duchene, C. Raiciu, andO. Bonaventure. Exploring mobile/WiFi handoverwith multipath TCP. In Proc. of ACM Cellnet,pages 31–36, 2012.

[22] Q. Peng, M. Chen, A. Walid, and S. Low. Energyefficient multipath TCP for mobile devices. InProc. of ACM MobiHoc, pages 257–266, 2014.

[23] T. Pering, Y. Agarwal, R. Gupta, and R. Want.Coolspots: reducing the power consumption ofwireless mobile devices with multiple radiointerfaces. In Proc. of ACM MobiSys, pages220–232, 2006.

[24] C. Pluntke, L. Eggert, and N. Kiukkonen. Savingmobile device energy with multipath TCP. InProc. of ACM MobiArch, pages 1–6, 2011.

[25] M.-R. Ra, J. Paek, A. B. Sharma, R. Govindan,M. H. Krieger, and M. J. Neely. Energy-delaytradeoffs in smartphone applications. In Proc. ofACM MobiSys, pages 255–270, 2010.

[26] A. Rahmati and L. Zhong. Context-for-wireless:Context-sensitive energy-efficient wireless datatransfer. In Proc. of ACM MobiSys, pages165–178, 2007.

[27] C. Raiciu, S. Barre, C. Pluntke, A. Greenhalgh,D. Wischik, and M. Handley. Improvingdatacenter performance and robustness withmultipath TCP. In Proc. of ACM SIGCOMM,pages 266–277, 2011.

[28] C. Raiciu, D. Niculescu, M. Bagnulo, and M. J.Handley. Opportunistic mobility with multipathTCP. In Proc. of ACM MobiArch, pages 7–12,2011.

[29] C. Raiciu, C. Paasch, S. Barre, A. Ford,M. Honda, F. Duchene, O. Bonaventure, andM. Handley. How hard can it be? Designing andimplementing a deployable multipath TCP. InProc. of USENIX NSDI, pages 399–412, 2012.

[30] P. J. Rockwell and R. A. Davis. Introduction toTime Series and Forecasting. Springer, 1994.

[31] A. Schulman, V. Navda, R. Ramjee, N. Spring,P. Deshpande, C. Grunewald, K. Jain, and V. N.Padmanabhan. Bartendr: A practical approach toenergy-aware cellular data scheduling. In Proc. ofACM MobiCom, pages 85–96, 2010.

[32] D. Wischik, C. Raiciu, A. Greenhalgh, andM. Handley. Design, implementation andevaluation of congestion control for multipathTCP. In Proc. of USENIX NSDI, pages 99–112,2011.

[33] F. Xu, Y. Liu, Q. Li, and Y. Zhang. V-edge: Fastself-constructive power modeling of smartphonesbased on battery voltage dynamics. In Proc. ofUSENIX NSDI, pages 43–55, 2013.

[34] L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P.Dick, Z. M. Mao, and L. Yang. Accurate onlinepower estimation and automatic battery behaviorbased power model generation for smartphones.In CODES+ISSS, pages 105–114, 2010.