Collaborative Downloading for Multi-homed Wireless Devices

Ganesh Ananthanarayanan, Venkata N. Padmanabhan, Chandramohan A. Thekkath, Lenin RavindranathMicrosoft Research

Abstract— Mobile devices are increasinglyequipped with multiple network interfaces: WirelessLocal Area Network (WLAN) interfaces for localconnectivity and Wireless Wide Area Network(WWAN) interfaces for wide-area connectivity. TheWWAN typically provides much wider coverage butmuch lower speeds than the WLAN. To address thisdichotomy, we consider collaborative downloadingamong mobile devices in close proximity. Wedemonstrate the potential benefits of such anapproach and discuss the many challenges torealizing it in practice: incentivizing cooperationby adequately compensating nodes, effecting suchcooperation via an efficient protocol, and facilitatingit with a suitable user interface. We present ourcurrent thinking on these as we design a collaborativedownloading system called COMBINE.

I. INTRODUCTION

Mobile devices such as laptops, smartphones,and PDAs are increasingly being equipped withmultiple wireless network interfaces. These in-clude one or more wireless LAN interfaces(e.g., 802.11, Bluetooth) and wireless WANinterfaces (e.g., GPRS, UMTS). This allowsdevices to have a choice of radios to use sep-arately. Since the WLAN offers much higherspeeds (a few to tens of Mbps) than the WWAN(tens to hundreds of Kbps), the conventionalwisdom is to use the WLAN interface whenin range of a WLAN (e.g., at a WiFi hotspot),but settle for the much lower speeds offered bythe WWAN interface at other times. Despite theproliferation of WiFi hotspots, their coverage isstill quite limited (e.g., outside the city centeror on trains and buses). Furthermore, even inlocations with WiFi coverage, policy issues mayimpede a user’s ability to take advantage ofit (e.g., the user may not be a subscriber ofthe hotspot service provider and may have to

set up yet another billing relationship). Such amismatch is less likely to arise on the large foot-print WWAN because the user’s own provideris often within reach.

We take the position that the range-speeddichotomy between WLANs and WWANs canbe bridged by using both kinds of networksin combination. Specifically, nodes in closevicinity band together their WWAN links, withthe high-speed WLAN serving as the glue, toboost the effective wide-area bandwidth avail-able to the active nodes. While pooling to-gether WWAN links has been considered inprior work (Section II), doing so among a setof collaborating but uncoordinated nodes raisesseveral challenges that we believe have not beenadequately addressed:

1) Incentives: Both monetary costs (e.g.,WWAN charges) and energy costs shouldbe accounted for as peers provide or seekhelp to or from each other.

2) Collaboration protocol: We need aspeed- and energy-efficient protocol fornodes to discover each other and to sharetheir bandwidth resources effectively.

3) Security: Collaborative downloadingshould not compromise node security orprivacy.

4) User interface: While the system couldoperate autonomously for the most part,we need a simple and intuitive interfaceto enable users to exercise control whenthey so wish.

Here, we discuss these challenges and arguethe pros and cons of various design alterna-tives in the context of COMBINE, a collab-orative downloading system we are designing

Eighth IEEE Workshop on Mobile Computing Systems and Applications

1550-6193/07 $25.00 © 2007 IEEEDOI 10.1109/HotMobile.2007.19

79

Eighth IEEE Workshop on Mobile Computing Systems and Applications

1550-6193/07 $25.00 © 2007 IEEEDOI 10.1109/HotMobile.2007.19

79

Eighth IEEE Workshop on Mobile Computing Systems and Applications

1550-6193/07 $25.00 © 2007 IEEEDOI 10.1109/HotMobile.2007.19

79

and prototyping. We believe that collaborativedownloading is not only beneficial to usersbut is also likely to be of interest to WWANservice providers, since it allows them to boostthe effective download speeds experienced bytheir users without requiring expensive infras-tructural upgrades.

II. RELATED WORK

Prior work has explored the idea of aggre-gating bandwidth across multiple WWAN links.Some of it has focused on mechanisms for in-verse multiplexing (i.e., striping packets) acrossmultiple WWAN links to avoid problems suchas TCP packet reordering (e.g., [11], Horde [8]).These systems assume that the multiple WWANlinks are attached to the same device, so theissues of how to accomplish local communica-tion and provide incentives for cooperation arenot considered. Other systems have consideredsharing WWAN links across devices. However,these have again side-stepped the issue of in-centives and simplified the local communicationproblem by assuming that the same user ownsall devices (e.g., MOPED [2]), the presence ofa separate aggregation router (e.g., MARS [9]),or that the improved performance alone is suffi-cient incentive for cooperation (e.g., HandheldRouters [10], PRISM [6]). However, the merepromise of improved performance may not bea sufficient incentive for cooperation becauseof the ephemeral association between mobilenodes (see Section IV). While UCAN [7] con-siders secure crediting, it uses the WLAN toincrease the reach of the WWAN rather than forbandwidth aggregation, and more importantly, itignores a key resource, viz. energy. Finally, allof the above systems operate at the network ortransport layer. While this offers the advantageof application independence, it also requiresinfrastructure proxies to split and splice flows,which may be a deployment hurdle.

III. ESTIMATING COST

We consider a setting where a requester(termed initiator) seeks to utilize the WWAN

links of one or more collaborators. Since col-laborator nodes contribute network and compu-tational resources, we must provide incentivesto offset their cost of using these resources. Weenvisage a dynamic market where nodes selltheir (unused) WWAN bandwidth resources inreturn for compensation from the initiator. Thisimplies that, at minimum, each collaboratormust be able to calculate its cost and commu-nicate it as its price to the initiator. In turn,the initiator must be able to compare the pricesoffered by multiple collaborators. It is importantfor the cost to be modeled appropriately, so thatthe offered price is high enough to adequatelycompensate the collaborator but not so high asto be unattractive to the initiator.

There are two principal costs that a collabora-tor incurs in helping the initiator. The first is thecost of transferring data on the WWAN link forwhich the WWAN service provider extracts afee. Given a tariff structure, one can estimate thecost of WWAN usage for transferring a givenamount of data, although some projection ofanticipated future usage may be needed (say,based on past usage patterns) to account fortiered pricing.

The second cost that we must account for isthe battery drain on the collaborator. We believeit is vital to account for battery drain, because itis a meager resource on the nodes and there maybe significant opportunity cost in squandering iton helping others. Intuitively, as the battery en-ergy remaining decreases, the more valuable itbecomes and the cost of collaboration increases.

The (incremental) battery drain on the collab-orator corresponds to transferring data from thesource over the WWAN and relaying it on to theinitiator over the WLAN. Using experimentaldata, each collaborating node can, a priori,calculate the amount of battery required for agiven amount of data transfer. (Our measure-ments on an iMate Pocket PC equipped withWiFi and GPRS interfaces confirm that thebattery drain is roughly linear in the amount ofdata transferred in a sustained burst.) Knowingthe amount of battery it has at the beginningof the transfer and the amount of data to be

808080

downloaded on behalf of the initiator, a nodecan calculate the fraction of the battery that willremain at the end of the proposed collaboration.

Thus, our initial plan is to have the collabo-rator estimate a cost that is directly proportionalto the tariff imposed by the service provider andinversely proportional to the estimated fractionof battery remaining at the end of the transfer.Note that this cost has the same units as thatimposed by the service provider (typically mon-etary units). We believe that this simple modeladequately captures our basic intuition about thecost of using a scarce resource.

IV. ACCOUNTING

For an incentive scheme based on the costmodel from Section III to work, we need anaccounting mechanism to keep track of pay-ments made by initiators to the collaboratorsthey recruit. There are several challenges that apractical accounting scheme must address:

1) Ephemeral association: Given the mobil-ity of nodes and the ephemeral associ-ation between them, a collaborator whoprovides help cannot count on the initiatorbeing available to return the favor at adifferent time and place. So the account-ing mechanism should be able to storecredits for future use; a real-time tit-for-tat scheme as in BitTorrent would notsuffice.

2) Cheat-Proof: The accounting schemeshould be able to limit the damage causedby an initiator who fails to provide thepromised compensation to a collabora-tor (e.g., by using counterfeit money forpayment) or a collaborator who fails toprovide the promised help.

3) Privacy: The accounting scheme shouldnot leak information on the identities ofthe collaborator and the initiator to eachother, or to a third party.

4) Efficiency: The computational andcommunication overhead of accountingshould be low.

There are various alternatives for designingthe accounting system. Electronic funds transfer

(EFT), which is widely supported by banks,is a possibility. However, EFT is cumbersomein practice (e.g., the collaborator would haveto share its bank account information with theinitiator). It also imposes a significant over-head on the collaborator (especially when fine-grained payments are made) in confirming theEFT with its bank online, to prevent cheatingby the initiator.

An alternative would be to use digital cash(e.g., [1]), possibly adapted for efficient mi-cropayments (e.g., [3]). The main advantage ofsuch systems is their privacy, which is equiv-alent to that of paper cash. However, doublespending is a serious risk, preventing whichrequires either the overhead of online commu-nication with the bank that issued the cash orthe provision of a secure hardware device (e.g.,smartcard) at the clients to detect or preventduplication.

In COMBINE, we are considering an alter-native, credit-based scheme that leverages acentral authority (e.g., a WWAN provider orthe purveyor of COMBINE software) to certifya fixed number of public/private key pairs foreach user. When a payment needs to be made,the initiator signs an IOU for the appropriateamount, also embedding a nonce provided bythe collaborator. The collaborator can satisfyitself of the authenticity and the freshness ofthe IOU without needing to communicate withthe central authority. Such communication isonly needed once in a while to redeem theIOUs. This credit-based scheme offers the ad-vantage of efficient and duplication-resistantmicropayments without requiring online WANcommunication. Furthermore, it allows us to usearbitrary virtual money (e.g., energy credits)instead of real money. However, compared todigital cash schemes, we trade off some privacy,in particular allowing the authority to link theIOUs to the payer. We believe that this maybe acceptable, especially if we can effectivelyobfuscate the identity of the payee using aforwarding chain (Section VI).

The assumed identity infrastructure also en-ables the construction of a reputation system

818181

to flag collaborators who fail to provide thepromised service in return for an IOU.

V. PROTOCOL DESIGN

A system that supports collaborative down-load in the setting we envisage requires atten-tion to three components: a protocol for mobiledevices to form groups, a scheme to distributework amongst the group, and a mechanism forlow-level data transport and connection man-agement to fetch data from servers, which areoblivious of the collaboration.

A. Group Formation ProtocolGroup formation is the process by which the

initiator identifies a set of collaborators. This isclearly a critical first step in doing collaborativedownloads, but to the best of our knowledge,prior work has largely ignored it.

Group formation in the absence of Wi-Fiaccess points is tricky because mobile devicestend to switch off their 802.11 cards or put themin a power saving mode to conserve battery.Thus, the protocol cannot depend on WLANcards being switched on in anticipation of groupformation.

Furthermore, group formation must work cor-rectly in an environment where mobile devicesmove in and out of range: it must tolerate non-responsive initiators and collaborators, as wellas multiple simultaneous initiators.

The COMBINE prototype implements a sim-ple robust and energy efficient protocol by let-ting collaborators put their WLAN cards ina new power saving mode called the Waitingmode. Collaborators in this mode wake upperiodically, like in the standard 802.11 PowerSaving Mode [5] (although at a much lowerfrequency), and broadcast an I-am-Alive mes-sage. This message contains a bid reflecting thethe price of using this node as a collaborator(see Section III) and the bandwidth it is willingto offer. The initiator collects all the bids andselects the list of nodes with prices less than acertain threshold to be its collaborators.

Even the Waiting mode might be wastefulof energy if there are very few collaborative

downloads happening. We are exploring the useof low-power radios (e.g., Bluetooth) to serve asa signaling channel for group formation. Thusa nodes would switch on its 802.11 radio onlyafter it has been being enlisted as a collaborator.Our experiments show that the battery life of amobile device with its Bluetooth radio turnedon continuously is comparable to its standbylife.

B. Work DistributionWe view work distribution as a policy deci-

sion that relies on a lower level mechanism toactually effect the transfer the data. We are con-sidering multiple policies for work distribution.A simple one, whose performance is illustratedin this paper, uses a work-queue.

The initiator determines the size of the fileto be downloaded from the server, partitionsit into fixed chunks, and appends them toa work-queue, which the collaborators query.Collaborators pick up more work when theyare done with their current work item; thuswe dynamically adjust to a collaborator’s speedvariations without requiring perfect knowledgeof its future speed. In addition to varying linkcharacteristics, a collaborator’s speed could alsovary due of increased local network activity.COMBINE continuously monitors the amountof local activity in a device and backs off whenthat increases beyond a threshold.

C. Data Transfer and Connection Manage-ment

One technique to fetch data from an obliviousserver is to interpose a special-purpose proxyto multiplex traffic from collaborators over asingle connection to the server, and vice versa.This approach has been explored in prior work;however, we believe that the need for a special-purpose proxy can be a significant detrimentagainst adoption because of the need to engineerit to handle the potentially heavy data pathworkload of collaborative downloads. Our goalis to make collaboration transparent to serversand place minimal demands on the infrastruc-ture, albeit at the cost of slightly increased

828282

complexity on the mobiles. Our strategy is touse an HTTP level solution, but this raises atleast two challenges.

First, if the server does not support byte-range HTTP requests, it is difficult to imple-ment a solution. Second, if access to servercontent requires session establishment or au-thentication by the client, it is more difficultto have an untrusted collaborator act on behalfof an initiator.

The current prototype assumes that servershave byte-range support and they don’t needsession level information. We are investigatinga different data transport mechanism, whichrelaxes these assumptions by treating collabo-rators as multi-homed HTTP proxies.

D. PerformanceWe implemented our prototype in a commu-

nity consisting of up to five members, eachof which is a Pentium 4 laptop with 1GB ofRAM, running Windows XP SP2. The laptopsuse a PCMCIA Sierra Atlantic GPRS card astheir WWAN NIC and a D-Link WG132A USB2.0 802.11b dongle as their WWAN NIC. Wemeasured throughput by transferring an 8MBfile from a server on the Internet to one ofthe laptops, using HTTP byte-range requests tofetch parts of the file [4]. Figure 1(a) shows themeasured speed up as well as the ideal speedup. Measured speed up includes the overheadof forming a group, while the ideal speed upignores this cost.

VI. SECURITY

While collaborative downloading offers a sig-nificant performance benefit, it also raises sev-eral security issues. We briefly discuss these andour approach to addressing them in COMBINE.

First, there is the issue of privacy, with regardto leaking information on a user’s activity tocollaborators and/or the accounting system. Forexample, a collaborator might learn the URLaccessed by the initiator. However, the initiatorcan still effectively remain anonymous, sincethe certificate presented with an IOU in Sec-tion IV need not identfy the user it was issued

to. Furthermore, by issuing multiple certificatesto each user, any of which can be used inan IOU, we make it harder to track the ini-tiator across multiple collaborative downloadsessions.

The central authority where client’s redeemtheir IOUs can, of course, learn the identity ofthe issuer of each IOU. However, to preventit from also identifying the payee (and therebylearning that the payer and the payee were likelyin each other’s vicinity), we are investigatingthe use of a random forwarding chain over theWAN, wherein the IOU is eventually redeemedby a node that has nothing to do with its originalissuer.

Second, there is the issue of confidentiality.For example, the initiator might be downloadinga music file that is only available to subscribers.While COMBINE by itself does not include anymechanism to maintain confidentiality, existingend-to-end encryption, if any, would help (e.g.,SSL would shut out the collaborators just as itshuts out any other web proxy).

Finally, there is the issue of ensuring theauthenticity of the content downloaded throughthe collaborators. For example, a collaboratorcould cheat by returning bogus content insteadof expending WWAN bandwidth to downloadthe real content, but still collect a payment fromthe initiator. Addressing this problem requiresa combination of certification of content blocksby the source (as systems such as BitTorrentwould need) and a reputation system to blacklistcheaters.

VII. USER INTERFACE

It is desirable for COMBINE to operate au-tonomously, without requiring user input on anongoing basis. However, since users may ex-pend valuable resources and/or accrue monetarycharges, we would still want to give them theoption of exercising control. We present hereour initial ideas on the design of a simple userinterface for COMBINE.

Figure 1(b) shows a mock-up of the COM-BINE UI. It comprises elements that inform theuser and those that allow the user to exercise

838383

Fig. 1. (a) Speedup versus collaboration group size, and (b) a mockup of the COMBINE user interface.

control. In the former category are “dials” thatshow users (a) how much credit/dues they haveaccrued, (b) the speedup obtained by usingCOMBINE, and (c) the amount of resourcesexpended (or remaining), in particular batterypower. Users can view the information pre-sented to drive how they control the operationof COMBINE.

To enable user control, the UI includes twosliders, one each to control the aggressivenessof selling and buying resources, respectively.The slider settings are translated to numericalfactors, Ks and Kb, to control the buying andsetting of resources, respectively. These factorsare initially set to a neutral value (say 1) toensure reasonable operation by default. The Ks

factor is used to scale down or up the pricecomputed in Section III, to make a collaboratormore or less willing sell its resources. At theextreme, Ks is set to infinity, which means thatthe seller is unwilling to sell for any price. Thefactor Kb operates analogously, with the baseprice that the buyer (viz., the initiator) is willingto pay pegged to the cost it would incur (interms of bandwidth and battery) were it to dothe download by itself. At the extreme, Kb isset to zero, which means that the initiator isunwilling to pay any price, effectively optingout of collaborative downloading.

We could also overlay demand/bid informa-tion from the neighborhood on the sliders sothat the user knows how aggressive they wouldneed to be to make a deal. This could be thebasis of a game for (idle) users looking to earn

some extra money by parlaying their unusedresources.

VIII. CONCLUSION

Collaborative downloading offers the poten-tial of significant performance gains by utiliz-ing WLAN and WWAN links in combination.However, as we have discussed in the context ofCOMBINE, a number of challenges need to beaddressed in realizing this potential in practice.

REFERENCES

[1] ECash. http//www.ecash.com.[2] C. Carter and R. Kravets. User Devices Cooperating to

Support Resource Aggregation. In IEEE WMCSA, June2002.

[3] S. Glassman et al. The Millicent Protocol for InexpensiveElectronic Commerce. In Fourth WWW Conference, Dec.1995.

[4] Hypertext transfer protocol – HTTP/1.1: RFC 2616. http:-//www.w3.org/Protocols/rfc2616/rfc261 6.html.

[5] IEEE Std 802.11: Wireless LAN Medium Access Con-trol and Physical Layer Specifications. IEEE ComputerSociety LAN MAN Standards Committee., Aug. 1999.

[6] K.-H. Kim and K. G. Shin. Improving TCP Performanceover Wireless Networks with Collaborative Multi-homedMobile Hosts. In ACM/Usenix MobiSys, June 2005.

[7] H. Luo et al. UCAN: A Unified Cellular and Ad-hocNetwork Architecture. In ACM MobiCom, Sept. 2003.

[8] A. Qureshi et al. Horde: Separating Network StripingPolicy from Mechanism. In ACM/Usenix MobiSys, June2005.

[9] P. Rodriguez et al. MAR: A Commuter Router Infrastruc-ture for the Mobile Internet. In ACM/Usenix MobiSys,June 2004.

[10] P. Sharma, S.-J. Lee, J. Brassil, and K. G. Shin. HandheldRouters: Intelligent Bandwidth Aggregation for MobileCollaborative Communities. In IEEE BROADNETS, Oct.2004.

[11] A. C. Snoeren. Adaptive Inverse Multiplexing for Wide-Area Wireless Networks. In IEEE Global Internet, Dec.1999.

848484