Spider: Improving Mobile Networking withConcurrent Wi-Fi Connections

Hamed Soroush∗ Peter Gilbert† Nilanjan Banerjee4Mark Corner∗ Brian Neil Levine∗ Landon Cox †

∗Dept. of Computer Science, Univ. of Massachusetts Amherst, {hamed,brian,mcorner}@cs.umass.edu

4 University of Arkansas, Fayetteville nilanb@uark.edu

† Dept. of Computer Science, Duke Univ., {gilbert,lpcox}@cs.duke.edu

ABSTRACTWe present an in-depth analysis of the performance ofattempting concurrent AP connections from highly mo-bile clients. Previous solutions for concurrent Wi-Fi arelimited to stationary wireless clients and do not takeinto account a myriad of mobile factors. Through ananalytical model, optimization framework, and numerousoutdoor experiments, we show that connection duration,AP response times, channel scheduling, available andoffered bandwidth, node speed, and dhcp joins all affectperformance. Building on these results, we design, imple-ment, and evaluate a system, Spider, that establishes andmaintains concurrent connections to 802.11 APs in amobile environment. The system uses multi-AP selection,channel-based scheduling and opportunistic scanning tomaximize throughput while mitigating the overhead ofassociation and dhcp. While Spider can manage multiplechannels, we empirically demonstrate that it achievesmaximum throughput when using multiple APs on a sin-gle channel. Our evaluation shows that Spider provides a400% improvement in throughput and 54% improvementin connectivity over stock Wi-Fi implementations.

1. INTRODUCTIONAs wide-area cellular networks continue to strain un-

der the heavy load of data access, they are increasinglyreliant on offloading traffic to private, public, and openlyshared Wi-Fi networks. Most smart-phones are equippedwith both Wi-Fi and cellular data and prioritize Wi-Fiover cellular to take advantage of high bandwidth, lowerlatency, and higher per-bit energy efficiency. While of-floading traffic has been used by stationary users, recentmeasurement work has shown that it is also beneficialto offload mobile users’ data [2].

To realize the fullest extent of these gains, Wi-Fi sys-tems can aggregate a large number of access points con-currently to achieve improved network characteristics,unlike cellular, where devices are relegated to a single ac-cess point assignment. Recent virtualized Wi-Fi systems,such as Chandra et al. [5], FatVAP [11], and Juggler [18],have shown that stationary users connected to multiple

access points can achieve up to 3x greater bandwidththan users connected to a single access point [11]. Thesesystems work by switching between access points onmultiple channels rapidly, aggregating bandwidth at theclient.

Unfortunately, such multi-AP systems were built tosupport only nomadic access and not truly mobile use.These systems employ scheduling policies that assumethat the dhcp join has already completed and that theuser’s connection to the AP is without end. Thus, theyperform poorly in a mobile context, producing a schedulethat results in significantly lower performance.

The dhcp delays in mobile systems are relatively longand not handled by power-save mode, requiring any vir-tualized Wi-Fi system to dwell on a channel to wait fordhcp responses. As we show in this paper, through an-alytical study, measurement, and experimentation, thedwell times required to obtain dhcp leases from APs canswamp TCP round trip times, creating TCP timeouts,resulting in greatly reduced bandwidth. Our results showthat at higher speeds, mobile users receive better perfor-mance by connecting to multiple APs only if they appearon the same channel. Only at lower speeds can mobileusers recover from the throughput loss resulting fromdhcp joins to APs on separate channels. While these twoextremes are clear, the breaking point between them isnot predicted easily. One of our contributions is a generalmodel of this problem that isolates the critical factorsthat determine an optimal schedule using one or morechannels. These factors include the user’s speed, theAP’s dhcp response time, the AP’s offered bandwidth,and the attained bandwidth. For example, in a typicalenvironment, our model suggests that users that travelwith an average speed of 10 m/s (∼22 mph) or fastershould form concurrent Wi-Fi connections only within asingle channel. We also show empirically that link-layerassociation, dhcp and, TCP performance are affectednegatively by multi-channel solutions.

Building from the results of our analytical study, wedesign and implement a practical version of a mobile,virtualized Wi-Fi system called Spider that is designed

1

for high-speed mobile users. Spider solves the practicalissues of access point discovery and dhcp lease acquisi-tion while optimizing bandwidth using a single wirelesschannel. Through a set of extensive outdoor experimentswe show that we can maximize bandwidth using multipleAPs on a single wireless channel, achieving 122KBps,which is more than 400% improvement over a multi-channel approach. These results present Spider as aneffective supplement to cellular networks for highly mo-bile clients.

We also investigate empirically tradeoffs between through-put and connectivity. Spider can be used to manage andschedule joins to APs on multiple channels, and at aserious penalty to achieved bandwidth as our model pre-dicts. We demonstrate that if connectivity is a priority,then joining to multiple APs on multiple channels isbest: Spider achieves 44% connectivity (compared to35% in the single-channel case), lowering bandwidth to28KBps.

2. CHALLENGES OF MOBILE MULTI-APCONNECTIONS

Past research has shown the benefits of both mobileWi-Fi systems [2,8] and virtualized multi-AP bandwidthaggregation schemes in static wireless scenarios [5,11,18].In this work, we investigate whether a multi-AP solutionis possible and beneficial in truly mobile scenarios whereWi-Fi connections are both fleeting and intermittent.

An obvious starting point would be to take one ofthe existing virtualized multi-AP solutions and applyit in a mobile setting. However, a closer look at thedynamics of both static multi-AP solutions and mobileWi-Fi networks shows that the integration of the two isnot straightforward.

Since APs can be instructed by the client to bufferpackets, concurrent connections between a static clientand multiple APs [5, 11,18] are possible for Wi-Fi. Theclient falsely claims it is entering power-save mode (PSM),implicitly asking the AP to queue the incoming pack-ets, and then communicates with another AP. Giventhat the backhaul bandwidth is typically smaller thanthe wireless bandwidth, such a scheme results in higheraggregate throughput if switching delays are kept veryshort. Static multi-AP solutions are not concerned withthe delay incurred by the process of joining to the APs,and they do not need to be. In a static scenario joiningprocess (association and dhcp) happens once, and itsduration is negligible compared to the total connectiontime.

In a mobile Wi-Fi environment, on the other hand,clients must continuously associate and obtain dhcpleases from APs as they become available. In addition,the packets associated with the join process cannot bebuffered by the PSM request, and therefore, the clientcannot switch away without reducing its chances of

join request join response

AP on channel i

D DMobile Client

Figure 1: Depiction of a join failure due to untimely arrivalof the join response message in our simplified scenario.White regions represent the fraction (fi) of the schedulingperiod (D) spent on channel i to communicate with the AP.Gray regions depict the rest of the scheduling period spentaway from the AP on another channel. Switching delay (w)is shown in black. For simplicity, the model assumes thatjoin requests are sent in the beginning of intervals of lengthdDfi

c e where c is a constant. Join process becomes morecomplicated in reality, where it involves multiple steps toassociate and obtain a dhcp lease instead of one.

getting a dhcp lease.To understand the effect of mobility on the perfor-

mance of multi-AP systems, we design and validate amodel that predicts the probability of obtaining a dhcplease from an AP as a function of the amount of timespent in range. Based on this model, we then formulatean optimization framework to determine schedules thatmaximize aggregate throughput.

Our analytical framework allows us to find the divid-ing speed above which a mobile multi-AP solution shouldconsider APs only on a single channel for throughputmaximization. However, the framework is limited since itdoes not consider the complexities of the multi-phase al-gorithms running link-layer association, dhcp, and TCP.In order to isolate the effects of multi-channel switchingon these protocols, we also perform a series of real ex-periments (Section 2.2). The bottom line of the model,optimization framework, and empirical experiments isthat switching is detrimental to overall throughput foralmost any short-lived connection. This conclusion isfurther supported by a series of extensive experiments inSection 4 using a complete system in an outdoor setting.

2.1 Analytical FrameworkWe have designed our analytical framework with two

key questions in mind: First, how does channel switchingand node speed affect the time to associate and obtain adhcp lease? And second, at vehicular speeds, when is itdesirable to aggregate throughput from APs on multiple

2

channels?

2.1.1 Join ModelWe model the probability of a mobile node successfully

joining an AP operating on channel i during the firstt seconds that it is in range. We assume a round robinschedule, where the node spends a fraction of time fi onchannel i from the total scheduling duration of D. Toswitch channels, the node incurs a delay w during whichno packets can be received. We approximate t ' s×D,where s is a positive integer reflecting the speed of themobile node (note that s is larger when the node ismoving more quickly). We refer to each of the s timeintervals as a round. In sum, in each round, a durationof Dfi is spent on channel i. For simplicity, we assumethat the mobile node switches to channel i as soon as itenters the range of the AP.

While in practice, a Wi-Fi join event consists of sev-eral complimentary steps, for simplicity we assume thatassociation involves a single handshake. Further, we as-sume that in the absence of losses, the time between thetransmission of the single join request and the receptionof the single join response in a non-virtualized scenario isuniformly distributed in the interval [βmin, βmax]. Dur-ing a round, the mobile node can transmit a maximumof dDfi

c e join requests to the AP, where c is the timebetween two consecutive requests. In practice, the du-ration c is determined by dhcp and link-layer timeoutvalues, and we set it to a constant in the model. We letβm,k ∈ [βmin, βmax] denote the join time correspondingto a request transmitted in segment k of round m, where1 ≤ k ≤ dDfi

c e. We then compute the probability thata request made at the beginning of segment k in roundm leads to a successful join. Note that for a successfuljoin, the response from the AP must be received at themobile node within a time interval Dfi of the currentor later round (see Figure 1). The above constraint canbe mathematically formulated as follows.

w + (k − 1)c+ βm,k ≤ (n−m)D +Dfi (1)w + (k − 1)c+ βm,k ≥ (n−m)D (2)

These can be combined into one equation as

(n−m)D+c−w ≤ kc+βm,k ≤ (n−m+fi)D+c−w (3)

where n ≥ m is the round in which the response isreceived. Since βm,k ∈ [βmin, βmax], we have

kc+ βmin ≤ kc+ βm,k ≤ kc+ βmax (4)

Using the above equations, we can derive the proba-bility that a request sent during segment k of round m

0 0.2 0.4 0.6 0.8 10

0.2

0.4

0.6

0.8

1

fraction of time spent on channel

prob

abili

ty o

f joi

n su

cces

s

Model (βmax

=5)

Simulation (βmax

=5)

Model (βmax

=10)

Simulation (βmax

=10)

Figure 2: The probability of join success as a function ofthe fraction of time, fi, spent on the AP based on thepresented model (Eq. 7) and simulation. Mobile node witha scheduling period of D = 500ms spends t = 4s in thevicinity of the AP with βmin = 500ms, βmax = 5s and 10s.Switching overhead of the driver is w = 7ms. Join requestsare sent every c = 100ms and loss rate is h = 10%.

leads to a successful join for a lossless channel as

q(m,n, k) =0 if δminm,n > αmaxk

0 if δmaxm,n,fi < αminkmin{αmax

k ,δmaxm,n,fi}−max{αmin

k ,δminm,n}

αmaxk −αmin

k

otherwise

(5)

where

αmink = kc+ βmin

αmaxk = kc+ βmax

δminm,n = (n−m)D + c− wδmaxm,n,fi

= (n−m+ fi)D + c− w

Hence, the probability that no requests made in roundm leads to a successful join in round n in a lossy channelwith message loss probability h can be calculated fromthe previous equation as

q(m,n, h) =dDfi−w

c e∏k=1

(1− q(m,n, k)(1− h)2

)(6)

Thus, given that the mobile node spends a fraction fiof time on a channel i, the probability of obtaining atleast one lease in time t is the following:

p(fi, t) = 1−b t

D c∏m=1

b tD c∏

n=m

q(m,n, h) (7)

Validation. We validate our analytical model by usinga simulation with the same assumptions. Figure 2 showsthe probability of successfully joining an access point asa function of the fraction of time spent on the channelfor both the model (Eq. 7) and the simulation. Each

3

0 2 4 6 8 100

0.2

0.4

0.6

0.8

1

Bmax (s)

prob

abilit

y of

join

suc

cess

fi=.10fi=.25fi=.40fi=.50

Figure 3: The probability of join success as a function ofthe maximum time it takes the AP to respond. When a fixedfraction of time is spent on the channel, shorter maximumjoin times lead to higher chances of join success. Mobilenode with a scheduling period of D = 500ms spends t = 4sin the vicinity of the AP with βmin = 500ms. Switchingoverhead of the driver is w = 7ms. Join requests are sentevery c = 100ms and loss rate is h = 10%.

point on the simulation line represents an average ofhundred runs, and error bars represent one standarddeviation. Each run uses a different seed and represents100 trials where a join is attempted and the value ofβm,k is sampled from the given distribution. We setother input parameters to typical values we observedin practice (see Section 2.2). The simulation results arestatistically equivalent to the model and hence, internallyvalidate it.

2.1.2 DiscussionEq. 7 represents a non-linear relationship between

the fraction of time spent on the channel, fi, and theprobability of a successful join p(fi, t). For instance, inFig. 3, the probability of getting a lease during the firstt = 4 seconds falls from 75% to 20% when the percent-age of time devoted to the AP reduces from 30% to10%. Further, the node should spend nearly 100% ofits time on the channel for an assured successful join.These results motivate a channel switching approach toschedule concurrent Wi-Fi connections in mobile scenar-ios as opposed to the AP switching approach used instatic cases [11]. Spending all its time on one channel,the mobile node can aggregate bandwidth from severalAPs on that channel without affecting the probabilityof successful joins.

Another implication of our analysis is the relationshipbetween the maximum join time, βmax, and the probabil-ity of a successful join p(fi, t). Figure 3 graphs the valueof p(fi, 4) with βmax as the independent variable for fourdifferent values of fi, using Eq. 7 . Note that βmax repre-sents the maximum amount of time to join to an AP inthe absence of losses and in a non-virtualized scenario.When a fixed fraction of time is spent on the channel,

shorter maximum join times lead to higher chances of asuccessful join. While this is a known fact for single-APscenarios, our results demonstrate that techniques suchas caching dhcp leases, maintaining a history of APswith short join times, and decreasing link layer timeoutsthat reduce βmax are essential for multi-AP systems. Inother words, when these techniques are not available —when mobiles travel in areas they do not normally doand AP responses are slow — multi-AP systems will seesignificant drops in performance.

2.1.3 Throughput MaximizationA major objective of maintaining concurrent connec-

tions to multiple access points is bandwidth aggregation.To understand how channel schedules and node speedaffect bandwidth aggregation, we formulate an optimiza-tion framework for throughput maximization.

The objective function and the associated constraintsare shown in Equation 8. To construct it, we assume thatthe mobile node is in range of APs for T seconds. We letE[Xi] =

∑Tt=0 p(fi, t) be the expected amount of time to

join an AP on channel i given fi and T . We let Bw be themaximum bandwidth of each channel. We distinguishcurrent and offered bandwidth: let Bij be the total end-to-end bandwidth from APs on channel i that the node hasalready joined to; let Bia be the end-to-end bandwidthavailable from APs that the node is attempting to jointo and would have during the duration (1 − E[Xi])T .We let k be the number of available channels and westate the objective function as follows.

maxfi

{T

i=k∑i=1

(fiBw)

}(8)

s.t. 0 ≤ fi ≤Bij + (1− E[Xi])Bia

Bw, ∀i (9)

i=k∑i=1

(fiD + dfiew) ≤ D (10)

The formulation is similar to the FatVap optimizationproblem [11] except the constraint on fi which considersthe additional bandwidth gained from APs that the nodeis associating with. Note that for simplicity, we haveassumed all APs are in range for a duration of T andthus have the same E[Xi].

We numerically solve the above optimization to deter-mine the optimal schedule as a function of the speed ofthe node. Specifically, we evaluate three scenarios for atwo-channel case:

1. B1j = 0.75Bw and B2

a = 0.25Bw

2. B1j = 0.25Bw and B2

a = 0.75Bw

3. B1j = 0.50Bw and B1

a = 0.50BwOur goal is to determine the speeds at which it is optimalto switch channels, given a practical Wi-Fi range of 100

4

2.5 3.3 5 6.6 10 200

2000

4000

6000

8000

10000

speed (m/s)

Band

widt

h (k

bps)

ch1 bwch2 bw

2.5 3.3 5 6.6 10 200

2000

4000

6000

8000

10000

12000

speed (m/s)

Band

widt

h (k

bps)

ch1 bwch2 bw

2.5 3.3 5 6.6 10 200

2000

4000

6000

8000

10000

12000

speed (m/s)

Band

widt

h (k

bps)

ch1 bwch2 bw

Figure 4: Maximum aggregated bandwidth for different speeds when only two channels are used. The offered bandwidthon the first and second channels are (25%,75%), (50%,50%), and (75%,25%) of the wireless bandwidth (Bw =11Mbps)respectively in each figure from left to right for βmax = 10s and βmin = 500ms. Wi-Fi range is assumed to be 100m.

meters. Figure 4 shows the results for the three scenariosin terms of the optimal bandwidth that can be extractedfrom each channel. For every scenario, there is a dividingspeed: when moving slower than the divide, the mobilenode should switch channels to maximize bandwidth.Quantitatively, this speed is less than 10m/s for mostscenarios. This result implies that for highly mobilenetworks (where the average node speed is greater than10m/s), the best policy to maximize bandwidth is tostay on a single channel. While we examined only threescenarios to produce Figure 4, we note that our modeland optimization framework solves all combinations ofinputs. We empirically validate and further explore thisresult in Section 4 using a mobile testbed.

2.2 Experimental AnalysisOur model shows that scheduling fractional time on

several channels has an adverse effect on the probabilityof successfully joining APs (see Fig. 3). Additionally, forhigh vehicular speeds, maintaining concurrent connec-tions to access points while staying on one channel leadsto optimal bandwidth aggregation. However, our modelmakes two simplifying assumptions. First, it assumesthat joining is a one-shot process, while in practice Wi-Fi joins involve a multi-phase bidirectional handshakeinvolving both association and dhcp. Second, it assumesthat the schedule is short enough so that TCP timeoutsare avoided. The assumptions cause the model to beoptimistic: multi-channel switching performs better inthe model than can be expected in a real scenario.

To quantify the affect of switching on link-layer as-sociations, dhcp and TCP, we performed two sets ofexperiments, one on an outdoor vehicular testbed andthe other on an indoor wireless testbed. Our resultsquantify the relationship between channel schedule, joinsuccess, and TCP throughput. In sum, successful link-layer association and dhcp joins have some tolerance forswitching, while TCP is more sensitive.

2.2.1 Association and dhcp

0 200 400 600 800 10000

0.2

0.4

0.6

0.8

1

time to associate (ms)fra

ctio

n of

suc

cess

ful a

ssoc

iatio

ns

25%50%75%100%

Figure 5: The rate of successful link-layer associations ona channel as a function of the amount of time the Wi-Fidriver spends on a single channel (out of 400ms for allchannels).

0 1 2 3 4 5 6 7 8 9 10111213141500.10.20.30.40.50.60.70.80.9

1

time to obtain dhcp lease (s)

fract

ion

of s

ucce

ssfu

l lea

ses

25% − 100ms50% − 100ms100% − 100ms100% − default

Figure 6: The rate of successful dhcp requests on a channelas a function of the amount of time the Wi-Fi driver spendson that channel as well as the dhcp timeout.

In our first set of experiments, we use a testbed ofvehicular nodes and a Wi-Fi driver that can simultane-ously associate with APs on different channels, just aswe modeled above — in fact, the driver is the core of ourfull system, and we provide full details of its operationin Section 3. The goal of our outdoor experiments isto quantify the affect of varying the fraction of time

5

spent on each channel on the failure rate of associatingand obtaining a dhcp lease. Moreover, these experimentsallow us to quantify the surprisingly detrimental effectof decreased link-layer response timeouts on a multi-AP driver, an approach shown by Eriksson et al. [8] toimprove single-AP/single-channel drivers.

To evaluate the effect of the driver’s schedule on thejoin success rate, we performed several experiments, eachlasting six hours on five vehicles moving around a smalltown, representing hundreds of trials. Each mobile nodespends a fraction f6 = x of D = 400ms on channel 6,and a fraction f1 = f11 = (1− x)/2 on channels 1 and11, applying terminology from our model and where0 ≤ x ≤ 1. Our results show the association delayson channel 6 and consider it as our primary channel.Since join delays are affected by link-layer timeouts, wereduced them from a standard of 1s to 100ms in theseexperiments1.

Figs. 5 and 6 plot the empirical cumulative distri-bution functions for durations of association and dhcprespectively for these experiments. Separate conclusionscan be drawn for association and dhcp.

Our analytical framework, which only evaluates a sim-ple join-request scenario, predicts that join success isdependent on the channel schedule. However, these realexperiments demonstrate that the performance of actuallink-layer joins are more complicated given the inter-actions of scanning and the four-way handshake used.As shown in Fig. 5, when the driver spends all its timeon one channel (f6 = 1), the median association timeis 200ms, and all associations complete within 400ms.However, when this fraction drops to f6 = 0.75, themedian association time increases to 300ms and only75% of associations are successful within 400ms. Inter-estingly, this performance does not degrade significantlyas f6 decreases to 0.50 and 0.25 suggesting that linklayer association is in some ways robust to switching.dhcp is a more complicated protocol. It relies on suc-

cessful association and involves at least four more framesbetween client and AP. Moreover, in default implementa-tions, the client attempts to acquire a lease for 3 seconds,and it is idle for 60 seconds if it fails. The performanceof this default scheme dedicated to a single channelis shown in Fig. 6 (as “100% default”) with a medianjoin time of 2.5s. The figure shows that reducing bothtimeouts above to 100ms [8] has a significant effect onperformance. For the same schedule of f6 = 100%, themedian join time reduces to 1.3s when a 100ms dhcptimeout is used. Once the schedule is set to f6 = 25%and D = 400ms, equal to the timeout, repeated failurescause the accumulated time to degrade performanceonce again. Hence, while reconfigured dhcp timers are a

1Note that the link-layer timeout reflects a timer for eachmessage in a multi-step protocol and not a timeout for theentire request-response process.

0 20 40 60 80 1000

1000

2000

3000

4000

% of time on primary channel

aver

age

thro

ughp

ut (K

b/s)

Figure 7: Average TCP throughput as a function of thepercentage of time spent by the Wi-Fi driver on the primarychannel. Since the cumulative time spent on all the channelsis 400 ms (which is less than two RTTs) the throughput isproportional to the percentage of time spent on the primarychannel.

0 100 200 300 4000

1000

2000

3000

4000

time spent on each channel (ms)

aver

age

thro

ughp

ut (K

b/s)

Figure 8: Average TCP throughput as a function of theabsolute time spent on each channel. For time x spent onthe channel, time 2x is spent away from it. The throughputis very sensitive to the amount of time spent by the driveron each channel due to TCP timeouts and TCP slow start.

boost to performance, we could not make dhcp robustto low fractions of scheduled time. This result suggeststhat the driver’s time cannot be divided among morethan two channels at 50% each in a mobile setting wherethe duration of time in range of an AP is limited.

2.2.2 TCP performanceOur throughput maximization framework assumes

that the schedule does not lead to TCP timeouts. How-ever, in a practical setting, if the channel schedule isskewed towards spending a large fraction of the timeon a single channel, TCP connections on an orthogonalchannel can timeout, potentially strangling performance.There is an inherent tension between the probability ofsuccessfully associating with APs on one channel andsustaining TCP connections on another channel.

To quantify this tradeoff, we performed a set of con-trolled experiments in an indoor setting. We configuredan AP on one channel (the primary channel) and variedtwo parameters, the fraction of time spent on the pri-

6

mary channel for a fixed scheduling period of D = 400msand the total scheduling time equally distributed acrosschannels 1, 6, and 11 (f1 = f6 = f11 = 1/3). When thefraction of time spent on the primary channel is variedfor a 400 ms schedule (equal to two typical RTTs), theTCP throughput increases monotonically, as shown inFig. 7. However, when the total scheduling time is variedinstead, the throughput increase is non-monotonic, asshown in Fig. 8. This behavior is a result of increasingthe total schedule which increases the amount of timespent away from the channel which can lead to TCPtimeouts.

2.3 Main Result of AnalysisOur analytical model, throughput maximization frame-

work, and experimental analysis point to the followingconclusion: At vehicular speeds, the best channel schedul-ing policy for throughput maximization is to spend allof the time on a single channel that provides maximalbandwidth.

Several observations from our analytical and exper-imental framework substantiate this result. First, asshown in Figs. 2, 5, and 6, our model predicts that theprobability of successfully joining to APs within a shorttime is high only when the node spends close to 100%of the time on the channel. Note that continuously as-sociating with APs is mandatory in mobile scenariosto sustain connectivity, given short encounters at vehic-ular speeds (median of 8 s and average of 22 s in ourtown). Second, link-layer association, dhcp joins, andTCP throughput (shown in Figs. 5, 6, and 8) are alladversely affected if the card spends a large amount oftime away from the channel. Therefore, when the mobilenode spends a small amount of time in vicinity APs,it should aggregate bandwidth from one channel whilesimultaneously associating with APs on that channel.

3. SPIDERBased on the results of our analytical framework and

experimental analysis in Section 2, we have designedand implemented Spider, a system that leverages con-current 802.11 connections to improve performance inhighly mobile networks. Our implementation is a freelyavailable, open source Linux kernel module2.

3.1 DesignOur analytical framework suggests that leveraging

multiple APs to maximize bandwidth in a highly mobilescenario requires a system that is different from multi-AP Wi-Fi drivers designed for static environments [5,11].Hence, we have made several design choices in Spiderthat are different from stock virtual Wi-Fi drivers [18].

Design Choice 1: Channel-based switching. Incontrast to previous work that slices time across indi-2URL removed for anonymity.

vidual APs [5, 11, 18], Spider schedules a physical Wi-Fi card among 802.11 channels. Spider maintains onepacket queue per channel that is swapped in and out ofthe driver. As shown in the previous section, the timeto join with access points can be long. Therefore, in anAP scheduling scheme such as FatVAP [11], the queuecorresponding to an AP can reserve the driver for a longtime. This implies that the card cannot communicatewith other APs on the same channel, which as we dis-cussed in Section 2 degrades performance. Per-channelqueues mitigate the above problem since they allow thedriver to communicate with all APs on the same chan-nel simultaneously. Additionally, it incurs no switchingoverhead for interfaces on the same channel.

Design Choice 2: AP selection based on JoinSuccess. A multi-AP solution in a highly mobile sce-nario requires a low-overhead AP selection algorithm.Unfortunately, selecting multiple APs while maximiz-ing a given system utility function is NP-hard (see Ap-pendix A for a proof). While an optimal dynamic pro-gramming approach can be formulated, its complexityincreases exponentially in the size of the power set ofaccess points, making a real-time solution infeasible inmobile scenarios where the node is within range of anaccess point for only a few seconds.

Spider uses a simple heuristic to select APs. Theheuristic is driven by our observations in Section 2 thatjoin times with APs is the critical factor for performancein highly mobile scenarios. Therefore, instead of choosingAPs with maximum end-to-end bandwidth, we selectAPs that have the best history of successful joins.

Stated formally, each AP m is assigned a utility Umwhich is a function of the number of successful joinattempts the client has made with the AP previously.A successful join comprises of three steps: i) link-layerassociation, ii) dhcp lease acquisition, and iii) end-to-end connectivity testing. Spider assigns fixed values va,vb, or vc (where va < vb < vc) to each specific joinattempt depending on how far it succeeds in the joiningprocess. Joins that fail during link layer associationsare assigned a zero value. The intuition behind suchweighing of values is that APs that have completed thejoin process are more reliable than those that have onlybeen successful in link-layer associations or obtaining adhcp lease. The utility Um of each AP m is the weightedaverage of previous and recent join attempts—the re-cent joins are given larger weights. To bootstrap theprocess, every new open AP that has sufficient signalstrength is assigned the maximum utility so that theAP is considered for association at least once. Signalstrength is used to break ties when APs have the sameutility. Additionally, to reduce the time to join to theAPs, Spider uses dhcp caches and fine-tunes link-layerand dhcp timeout values.

Design Choice 3: One Linux interface per AP.

7

ApplicationsLMM

ath1

ch1 ch6 ch11 ch6

ath2 ath3 ath4

Transport LayerNetwork LayerWireless Driver

Q6Q1 Q11

Wi-Fi Card

Figure 9: An illustration of Spider’s components.

Spider exposes a separate Linux network device interfacefor each connection, allowing maximal flexibility in theway that applications may use concurrent Wi-Fi connec-tions. Consequently, Spider does not require any custommodifications to the kernel socket data structure (unlikeJuggler [18]). As a result, Spider remains a completelystandalone loadable module that is compatible with off-the-shelf wireless utilities such as iwconfig, iwlist,iwspy and iptables, making link management and net-work debugging much easier.

3.2 ImplementationSpider consists of two components: a custom Wi-Fi

device driver responsible for opportunistic scanning andchannel switching, and a user-space link managementmodule (LMM) that implements connection establish-ment and policies for channel switching and AP selection.The overall design of Spider is illustrated in Figure 9.

3.2.1 Wireless DriverSpider is implemented as a modified MadWiFi driver

that provides multiple “virtual” network interfaces. Spi-der’s wireless driver schedules multiple APs on a singlechannel concurrently. It also supports opportunistic scan-ning, allowing new APs to be discovered in the back-ground without sacrificing foreground data-transfers.The driver exposes configurable parameters such as thechannel-switching schedule and link-layer timeouts tothe link management module using a proc interface.

The driver follows a number of steps to switch be-tween channels. First, it buffers outgoing packets on thevirtual interfaces of the current channel. Next, it sendsa management frame with the PSM bit set to each APwith which it is associated on the current channel, indi-cating that it is entering power-save mode. This causesthe APs to buffer all frames destined for the client untilit returns to the channel. After deactivating the virtualinterfaces on the previous channel, the driver changesthe state of the wireless card to the new channel. A

hardware reset is required to apply the change. Finally,the set of interfaces that are associated or attemptingto associate with APs on the new channel are activated.

Opportunistic Scanning. To maximize the timeavailable for useful work, the driver scans opportunis-tically in the background without disrupting ongoingconnections. While associated with an AP, a client oftenreceives beacons and probe responses transmitted byother APs on the same channel. Spider accepts theseframes and maintains a list of APs which it has heardfrom recently. Spider can also be configured to periodi-cally broadcast probe requests.

3.2.2 Link Management ModuleSpider’s link management module is responsible for

applying AP selection policies, managing concurrent con-nections, detecting lost connections and establishing newones, as well as notifying applications of the availabilityof a link.

The link management module creates a configurablenumber of virtual interfaces on boot-up and sets an ap-propriate channel schedule akin to an operation mode.An operation mode is defined by the total amount oftime to be scheduled among channels and the fractionof time spent on each channel. The link managementmodule provides support for dynamically changing theschedule when needed. Since operation modes are con-figured from user-space, applications can easily changethese settings without any modification to the driver orthe linux kernel. We present results from experimentsusing different operation modes in Section 4.

After the initial setup phase, the link managementmodule performs link discovery and management opera-tions for that interface. Our synchronization mechanismensures that no two interfaces are bound to the sameAP. As soon as an interface joins a network and obtainsan IP address, corresponding iptables rules are set toallow routing traffic to and from that specific interface.While in practice, IP address collisions are rare, if thesame IP address is assigned to different virtual inter-faces by different APs, we only use the most recentlyassigned interface. For each interface, the module selectsthe AP with the highest utility which is not already inuse. In case of ties, signal strength is used as the finaldeterminant.

Upon a successful link-layer association, per-BSSIDdhcp caches are used to speed up the process of obtain-ing a lease. Additionally, after a successful join, Spidercontinuously uses end-to-end pings to determine whetherthe connection is alive. In case an AP does not allowicmp pings to propagate, Spider pings the gateway totest connectivity. If thirty consecutive pings fail (sentat a rate of 10 pings per second), Spider assumes thatthe connection is dropped, notifies applications usinga shared flag resident on the system’s RAM disk, and

8

tries associating with another AP on that interface.

4. SYSTEM EVALUATIONWe intend Spider to complement cellular data services.

Wi-Fi solutions like Spider are a natural supplement tocellular networks due to their higher capacity. Theirdrawback, however, is that they do not provide continu-ous connectivity by themselves.

Spider aims at improving throughput and connectivityfor mobile clients using open Wi-Fi access by synergisti-cally using multi-AP selection, channel switching, oppor-tunistic scanning, and parallel per-channel association.Here, we evaluate the performance of Spider by focusingon the following key questions:• What improvement in throughput and connectivity

does Spider provide over stock Wi-Fi access?

• What is the effect of AP density on Spider’s per-formance?

• Does Spider meet connectivity needs of commonwireless users?

While answering these questions, we also present sev-eral micro-benchmarks and explore trade-offs availablewhen setting different dhcp and link-layer timeouts.

4.1 Experimental SetupWe evaluated Spider on a vehicular platform in two

different cities: our town and Boston, MA. We choseBoston because it was the site of Cabernet [8] experi-ments and is a major urban area.

During experiments in our town, almost all APs wereon channels 1 (28%), 6 (33%), or 11(34%). Cabernet [8]reported comparable numbers for the Boston area with83% of the APs on either of the three channels and39% on channel 6. Since majority of APs dwell on thesethree channels, we configured Spider to schedule at mostamong these three channels.

We test four configurations of Spider. (1) Single-channel, Single-AP: Spider mimics off-the-shelf Wi-Fion a single channel. (2) Single-channel, Multiple-AP:Spider stays on one channel (channel 1, 6, or 11) andjoins to as many APs on the channel as possible. (3)Multiple-channel, Multiple-AP: Spider switches betweenthe three orthogonal channels using static schedules. (4)Multiple-channel, Single-AP: Spider switches channelsbut is associated with one AP at a time. We also testedthe unmodified MadWiFi driver as a point of comparisonto configuration 1.

The equipment used in the experiments was comprisedof a 1GHz Intel Celeron M system running Ubuntu Linux2.6.18 and Atheros 802.11abg MiniPCI wireless card. Theduration of each experiment was 30–60 minutes with themobile node following the same route multiple times.

4.2 Driver Micro-benchmarks

Num. of interfaces0 1 2 3 4

Mean 4.942 4.952 5.266 5.546 5.945Std Dev 0.009 0.009 1.236 0.823 1.121

Table 1: Channel switching latency (ms) of the Spiderdriver.

0 1 2 3 4 50

200

400

600

800

1000

1200

backhaul bandwidth per AP (Mbps)

aver

age

thro

ughp

ut (

KB

ps)

one card, stocktwo cards, stockSpider, (100,0,0)Spider, (50,0,50)Spider, (100,0,100)

Figure 10: Throughput micro-benchmark. Spiders through-put when dedicated to two APs on a single channel isequivalent to two cards running stock drivers.

We ran two micro-benchmarks designed to measure (1)the latency overhead incurred when switching channels,and (2) the ability of our driver to aggregate bandwidthacross connections through multiple APs.

Table 1 shows the mean latency and the standarddeviation of a channel switch operation. The channelswitching latency is the time required to send a PSMframe to each associated AP on the old channel, performa hardware reset to apply the channel change, and thensend a PSM poll frame to each associated AP on thenew channel. The latency is typically in the range of5-6ms, increasing proportional to the number of APs,because a separate PSM frame must be sent to each AP.The largest contributor to the latency is the hardwarereset step, which can vary depending on the model of thecard. The latency is within a few ms of that achievedby other multi-AP drivers [11,18].

Fig. 10 shows the ability of the driver to utilize thebandwidth offered by multiple APs. We measured meanaggregate throughput achieved while downloading largefiles over HTTP for a number of configurations: a hostwith a single card running stock MadWiFi, for compari-son; a host with two physical cards running stock drivers;Spider connected to two APs on the same channel; andSpider associated with one AP on channel 1 and one onchannel 11, with a schedule of 50ms on each channel;and the previous configuration while spending 100ms oneach channel. The APs and servers were connected viaLANs in our lab, and a traffic shaper was used to adjust

9

(Config) Parameters Throughput Connectivity

(1) Channel 1, Multi-AP 121.5 KB/s 35.5%(2) Channel 1, Single-AP 28.0 KB/s 22.3%(3) Multi-channel, Multi-AP 28.8 KB/s 44.6%(4) Multi-channel, Single-AP 77.9 KB/s 40.2%(2) Channel 6, single-AP∗ 90.7 KB/s 36.4%MadWiFi driver ∗ 35.9 KB/s 18.0%

Table 2: Avg. throughput and connectivity for Spider con-figurations. Staying on a single channel and leveragingmultiple AP connections provides best avg. throughput.The multi-channel, multi-AP approach provides the bestconnectivity. (Multi-channel scenarios use a static scheduleof 200 ms on ch. 1, 6, and 11. ∗ denotes experimentsperformed in Cambridge, where channel 6 was the best.)

the backhaul bandwidth available through each AP.The host with two physical interfaces and the host

with Spider running on a single channel (connected totwo APs) both achieved an aggregate throughput equalto twice that achieved by the host with a single cardand stock driver—this is expected, as Spider incurs nochannel-switching overheads in this configuration anddoes not run the risk of causing TCP timeouts whenusing one channel. The results for the multi-channel Spi-der configurations show the trade-off between exploitingnew connectivity opportunities and extracting through-put from connected APs. When high-bandwidth linksare available, a schedule which switches more rapidlybetween channels is able to achieve greater throughputby reducing the risk of TCP timeouts.

4.3 Connectivity and ThroughputWe analyze throughput and connectivity of Spider us-

ing four key metrics. (1) Average throughput: the amountof data transferred to a sink per unit time during anexperiment. (2) Average connectivity: the percentage oftime that a non-zero amount of data was transferredto a sink. The average throughput and connectivity arebounds on open Wi-Fi performance using multi-AP so-lutions. (3) Disruption length: the contiguous periodof time when there is no connectivity. This distribu-tion indicates whether interactive applications such asVoIP or web search can be supported. (4) Instantaneousbandwidth: the amount of data per second transferredby a Spider node when there is connectivity. This met-ric indicates whether multi-AP solutions can supportapplications that require bursts of high throughput con-nectivity.

We present the average throughput and average con-nectivity for a Spider node in its four configurationsin Table 2. These experiments were performed using apassenger car in our downtown area. A static scheduleof D = 600ms and f1 = f6 = f11 = 1/3 was used inmulti-channel scenarios.

0 50 100 150 200 2500

0.2

0.4

0.6

0.8

1

connection duration (s)

frequ

ency

single AP (ch1)multiple APs (ch1)single AP (multi−channel)multiple APs (multi−channel)

Figure 11: CDF of the Internet connectivity duration forSpider configurations.

0 100 200 3000

0.2

0.4

0.6

0.8

1

disruption length (s)fre

quen

cy

single AP (ch1)multiple APs (ch1)single AP (multi−channel)multiple APs (multi−channel)

Figure 12: CDF of disruptions for Spider configurations.

Two conclusions can be drawn from the results. First,the single-channel multi-AP configuration performs bestin terms of throughput. It has an average throughput ofmore than 4 times that of the single-AP counterpart. Theuse of multiple channels incurs an additional overheadof switching and associating on orthogonal channels,strangling throughput. This is in agreement with the ob-servation made from another analytical framework wherewe demonstrated that at vehicular speeds, aggregatingbandwidth from one channel leads to optimal perfor-mance. Second, the multi-channel multi-AP solution hasthe best performance in terms of connectivity. Althoughthe average throughput is lower, multiple channels hosta larger pool of APs for Spider to choose from.

Figs. 11 and 12 are the CDFs of the disruption andconnection lengths for different configurations of Spiderrespectively. The results demonstrate several trade-offs.The longest periods of Internet connectivity are obtainedby staying on one channel and maintaining concurrentconnections to several APs. However, that strategy alsoexperiences the longest disruptions due to areas wherethere is no Wi-Fi coverage on the chosen channel. Incontrast, the multiple-channel multi-AP solution experi-ences the shortest connections due to disruptions causedjoins to APs on separate channels. However, such anapproach has the shortest disruptions due to larger set of

10

0 200 400 600 800 1000 12000

0.2

0.4

0.6

0.8

1

bandwidth (KBps)

frequ

ency

single AP (ch1)multiple APs (ch1)single AP (multi−channel)multiple APs (multi−channel)

Figure 13: CDF of KB/s transferred (during connectiv-ity) for Spider configurations. Single-channel configs. pro-vide the best instantaneous throughput. Multi-AP, multi-channel reduce throughput due to the overhead of joining.

possible APs that the node can transfer data with. Thesingle-AP configurations provide trade-offs between thetwo extremes. We compare these results with usabilityneeds of wireless users in subsection 4.7.

Fig. 13 shows the instantaneous bandwidth that Spi-der provides when actively transferring data. The single-channel, multi-AP configuration performs best in termsof per-connection throughput. The 60th percentile isaround 300 KBps and the 90th percentile is around 1000KBps — comparable to the throughput provided by Fat-VAP in a static environment (see Figure 13 in [11]). Spi-der’s multi-channel, multi-AP solution performs poorlyin terms of instantaneous bandwidth due to the overheadof association and dhcp on separate channels, clearlyillustrating (as in our analytical framework) the impor-tance of staying on a single channel if high throughputis the design goal.

4.4 Effect of AP DensityWe evaluated the effect of AP density on the perfor-

mance of Spider using the same set of experiments listedin Table 2. Here, we compare the case in which Spideris allowed to associate with one AP with the case whereit maintains connection with multiple APs. During ourexperiments, Spider associated with a maximum of threeAPs 5% of the time, 2 APs 10% of the time, and is asso-ciated with one AP around 85% of the time. It is notablethat, even with such a meager open Wi-Fi density inour town, multi-AP Spider has an average throughputthat is four times that of a single AP case.

For external validation, we ran a similar set of experi-ments in the city of Cambridge, an environment with adifferent mobility pattern and AP density from ours. Thelast two entries in Table 2 are results for those experi-ments. Interestingly, on Channel 6, Spider has an averagethroughput that is 800% more than the throughput re-ported by Cabernet for the same city (a throughput

parameters Failed dhcpchan 1, linklayer: 100ms,dhcp: 600ms, 7 interfaces

23.0% ±6.4%

channel 1, linklayer: 100ms,dhcp: 400ms, 7 interfaces

27.1% ±5.4%

chan 1, linklayer: 100ms,dhcp: 200ms, 7 interfaces

28.2% ±4.0%

3 Chans, static 1/3 schedule,linklayer: 100ms, dhcp: 200ms,7 interfaces

23.6% ±10.7%

Chan 1, default timer,7 interfaces

13.5% ±6.3%

3 Chans, static 1/3 schedule,default timer, 7 interfaces

21.8 % ±6.9%

Table 3: dhcp failure probabilities for different timeoutconfigurations for Spider. Primary differences are bolded.

0 1 2 3 4 5 6 7 8 9 10111213141500.10.20.30.40.50.60.70.80.9

1

time to join (association+dhcp) (s)

fract

ion

of p

ing

conn

ectio

ns

200ms, channel 1400ms, channel 1600ms, channel 1default, channel 1default, 3 channels200ms, 3 channels

Figure 14: The rate of successful joins as a function ofdhcp timeout. The cost of switching among channels over-shadows the benefit of quickly establishing connectionswhen timeouts are reduced.

of 10.75 KBps [8])3. Additionally, when comparing theresults with the stock MadWiFi driver, we find thatSpider provides 2.5x improvement in throughput and2x improvement in connectivity.

4.5 Effect of Join TimeoutsAs discussed in section 2, one of the primary challenges

in designing multi-AP solutions for mobile Wi-Fi accessis the overhead associated with dhcp and association. Away to minimize this overhead is to reduce the timeoutsassociated with dhcp and link layer retries. Table 3 andFig. 14 show the effect of reducing these timeouts onSpider. Table 3 presents the increase in failure rate ofdhcp requests with reduced timeouts while maintainingconcurrent connections on multiple channels. Comparedto the default timers, reducing timeouts can lead to a two-3It is of course impossible to set up the exact conditions inwhich Cabernet was tested: 802.11G is now widely availableand it is not possible to determine if more or less open APsare available.

11

Parameters Throughput Connectivity

3-channel (equal schedule) 28.8 KB/s 44.7%2-channel (equal schedule) 25.1 KB/s 35.8%Single-channel 121.5 KB/s 35.5%

Table 4: Average throughput and average connectivity seenwhen applying different static schedules for multi-channelconfiguration for Spider.

fold increase in dhcp failure rates. Similarly, switchingamong multiple channels while trying to associate withmultiple APs leads to high probability of failure (as highas 30–35%).

Although the number of failed dhcp attempts increaseswith timeout reduction, in Fig. 14 we find that themedian time to successfully obtain a lease improves—similar to the observation made in Cabernet [8]. However,the absolute median time to join is still 2–3 seconds,which increases by 2x when using multiple channels.Such long join times imply that is best to stay on onechannel to maximally aggregate throughput.

4.6 Effect of Number of ChannelsTo understand the effect of number of channels on

throughput, connectivity, and join overhead, we presentFig. 15 and Table 4. We tested three scenarios (1) threechannels with a equal schedule (200 ms) and (2) twochannels with an equal schedule (200 ms each), and (3)a single channel. Fig. 15 shows that the single channelmode with reduced timeouts performs best in terms ofjoin time–however, the reduced timeouts lead to a largenumber of dhcp failures. Moreover, the three channelschedule performs worse than the dual channel schedul-ing. Hence, switching between channels during asso-ciation is a primary source of overhead in multi-APsolutions. Table 4 presents throughput and connectiv-ity results for the different configurations—as expectedthroughput is maximized when Spider uses a single chan-nel and connectivity is maximized when it uses an equalschedule on three channels.

4.7 Matching Usability NeedsAn open question that is widely asked is whether open

Wi-Fi access can cater to connectivity needs of mobileusers? To answer this question, we performed a studyusing data from a permanent Wi-Fi mesh we deployed inour downtown. The mesh consists of 25 nodes and coversan area of about 0.50 km2. We collected performancedata on all TCP flows from 161 wireless users for anentire day. Although, all users might not be mobile, thedata provides us with a plausible baseline. Overall, therewere 128,587 completed TCP connections in the collecteddata and a total number of 13,645,161 packets (1.7 GB)were sent by the users. Of these, 86,838 connectionswere made to the http port (68% of the connections).

0 1 2 3 4 5 6 7 8 9 10111213141500.10.20.30.40.50.60.70.80.9

1

time to join (association+dhcp) (s)

fract

ion

of p

ing

conn

ectio

ns

1 iface. ch. 1(100%), def. TO.7 ifaces. ch. 1(100%), def. TO.7 ifaces. ch. 1(100%), dhcp=200ms, ll=100ms7 ifaces. ch. 1(50%), ch. 6(50%), def. TO.7 ifaces. 3 chns., eq. sched., def. TO.7 ifaces. 3 chns. eq. sched., dhcp=200ms, ll=100ms

Figure 15: Delay in obtaining a dhcp lease and link layerassociation for different scheduling policies in Spider. Thefigure also considers reduced timeouts.

0 20 40 60 80 1000

0.2

0.4

0.6

0.8

1

connection duration (s)

frequ

ency

multiple APs (ch1)users connection durationmultiple APs (multi−channel)

Figure 16: Comparison of connection lengths for wirelessusers and Spider.

0 100 200 3000

0.2

0.4

0.6

0.8

1

disruption length (s)

frequ

ency

multiple APs (ch1)user inter−connectionmultiple APs (multi−channel)

Figure 17: Comparison of disruption lengths for wirelessusers and Spider.

We compare the traffic needs of wireless users withthose provided by Spider based on two key metrics: (1)distribution of the duration of TCP connections, and(2) distribution of inter-connection time.

Fig. 16 compares the TCP flow lengths gathered from

12

actual users using our mesh network and Spider inits multi-channel and single-channel modes. The fig-ure shows that Spider can support all the TCP flowsthat users need. Additionally, in Fig. 17 we compare thetime between two connections for the mesh users anddisruption time for Spider. When Spider uses multiplechannels and multiple APs, it experiences disruptionscomparable to what real users can sustain.

These results present Spider as a plausible complementto cellular data services. However, more data on mobileuser’s connectivity needs and network usage pattern isrequired in order to find out the degree to which Spidercan align itself with the needs of each individual user.Conducting this study forms part of our future workwith Spider.

4.8 Limitations and Future WorkThe primary limitation of our work is largely with

the design of Spider. First, the system is not adaptive.Specifically, it does not change its scheduling policy dy-namically based on speed and AP density. An augmenteddesign would encompass both mobile and nomadic sce-narios by alternating between staying on one channelat high speeds and managing multiple channels whenmoving slowly. Although we have evaluated the effect ofsuch schedules in separate experiments, as future work,we are extending Spider to dynamically adapt schedulesbased on these parameters. To facilitate such integra-tion, Spider’s AP selection has to incorporate a suite ofother criteria such as end-to-end bandwidth estimatesin addition to the past successful joins. Current designonly considers throughput maximization as an objective.We are planning to extend the design to minimize con-nectivity outages by dynamically exploiting connectionson multiple channels.

5. RELATED WORKSpider builds on previous work on Wi-Fi access from

mobile nodes, fast Wi-Fi and cellular hand-offs, andusing multiple APs for throughput aggregation. Here,we compare and contrast Spider with the most relevantliterature.

Wi-Fi Access from Moving Vehicles: Severalchallenging problems such as lossy wireless mediums [4,8, 9, 13], tuning TCP performance for mobility [1], andAP selection [17] are well studied. The feasibility ofusing cached history to reduce association and dhcpoverheads [6] has been demonstrated. Directional an-tennas have also been used to improve throughput [15].However, this body of work concentrates on using a stockWi-Fi model—association and data transfer with one APat a time. However, as we have demonstrated, using a ag-gregation of APs can provide high aggregate throughputand better connectivity in a mobile environment.

Performance through diversity: Using technolog-ical and spatial diversity to improve Wi-Fi connectivityhas also been studied in the past. This class of relatedwork can be broadly classified by either infrastructure-end or client-end modifications. Infrastructure-end mod-ifications includes coordination or selection amongstmultiple open APs [3, 12–14,14,22]. In contrast to theseapproaches, Spider is a purely client-side solution thataims at improving a mobile user’s performance in anorganic Wi-Fi setting. Client-side diversity-based so-lutions rely on aggregating bandwidth across multipleAPs [5,11,18]. However, these solution are tuned to workefficiently only in a static, stationary wireless environ-ment.

An orthogonal approach to aggregating bandwidthin mobile nodes is using additional hardware—the as-sumption is that each client has more than one Wi-Ficard and data can be striped across concurrent con-nections to APs. PERM [21] is a multi-homed solutionthat aggregates throughput across multiple residentialISPs, profiles on-going connections, and assigns flowsto interfaces to minimize delay. MAR [20] exploits het-erogeneity of existing wide-area wireless networks byusing a router architecture that aggregates independentcellular links into one fat reliable virtual data transferpipe. Horde [19] is a middleware solution on mobilenodes that performs network striping over diverse cellu-lar links tuned to application needs. Most of these datastriping approaches can be built into Spider to enhancemobile user performance.

Soft hand-off and AP selection: Spider also buildson related work on fast cellular hand-offs and AP se-lection in mobile Wi-Fi networks. Fast hand-off is usedto mitigate the adverse effects of disruptions in cellularnetworks [7]. While fast soft hand-off is plausible in a cel-lular network where the cell towers are under the controlof one central authority, it is not feasible in Wi-Fi net-works laid down by third-party users. The only practicalsoft hand-off solution using client side modifications isSpider that virtualizes the Wi-Fi card and maintainsconcurrent AP connections. Access point selection hasalso been an active area of research in Wi-Fi mobilenetworks. Several techniques including RSSI [10] andhistory-based techniques [16] have been proposed. How-ever, multi-AP selection, solved by Spider is a harderproblem (as we demonstrate in the Appendix) since itinvolves selection of a set of APs.

6. CONCLUSIONWe presented an in-depth analysis of the performance

of attempting concurrent AP connections from highlymobile clients. Through an analytical model, optimiza-tion framework, and numerous indoor and outdoor ex-periments, we isolated several factors that affect the poorperformance of multi-channel networking in contrast to

13

single-channel, multi-AP networking and conventionalapproaches. We found that connection duration, APresponse times, channel scheduling, and attained andoffered bandwidth all affect performance. Moreover, linkassociation, dhcp joins, and TCP are all negatively af-fected by fractional channel scheduling.

Building off these results, we designed and imple-mented a novel multi-AP driver. Spider uses utility-based multi-AP selection, channel-based scheduling, andopportunistic scanning to maximize throughput whilemitigating the overhead of association and dhcp. WhileSpider manages multiple channels if desired, we showempirically that using multiple APs on a single channelachieves higher throughput than scheduling on multiplechannels, as predicted. Our evaluation of Spider on avehicular testbed shows that it provides a significantimprovement in throughput, making it an effective sup-plement to cellular data services for highly mobile nodes.

7. REFERENCES[1] H. Balakrishnan, V. Padmanabhan, S. Seshan, and R. Katz.

A comparison of mechanisms for improving TCPperformance over wireless links. In ACM SIGCOMM, pages256–269, 1996.

[2] A. Balasubramanian, R. Mahajan, and A. Venkataramani.Augmenting Mobile 3G Using WiFi: Measurement, Design,and Implementation. In Proc. ACM Mobisys, 2010.

[3] A. Balasubramanian, R. Mahajan, A. Venkataramani,B. Levine, and J. Zahorjan. Interactive wifi connectivity formoving vehicles. Proc. ACM SIGCOMM, 2008.

[4] V. Bychkovsky, B. Hull, A. K. Miu, H. Balakrishnan, andS. Madden. A Measurement Study of Vehicular InternetAccess Using in situ 802.11 Networks. In Proc. ACMMOBICOM, pages 50–61, Sept 2006.

[5] R. Chandra, P. Bahl, and P. Bahl. MultiNet: Connecting toMultiple IEEE 802.11 Networks Using a Single WirelessCard. In Proc. IEEE INFOCOM, March 2004.

[6] P. Deshpande, A. Kashyap, C. Sung, and S. Das. PredictiveMethods for Improved Vehicular WiFi Access. In Proc.ACM Mobisys, 2009.

[7] N. Ekiz, T. Salih, S. Kucukoner, and K. Fidanboylu. Anoverview of handoff techniques in cellular networks. In Intl.Journal of Information Technology, 2006.

[8] J. Eriksson, H. Balakrishnan, and S. Madden. Cabernet:Vehicular Content Delivery Using WiFi. In Proc. ACMMobiCom, Sept. 2008.

[9] B. Hull, V. Bychkovsky, Y. Zhang, K. Chen, M. Goraczko,A. Miu, E. Shih, H. Balakrishnan, and S. Madden. CarTel: ADistributed Mobile Sensor Computing System. In ACMSenSys, pages 125–138, October 2006.

[10] G. Judd and P. Steenkiste. Fixing 802.11 access pointselection. In ACM CCR, 2002.

[11] S. Kandula, K. C.-J. Lin, T. Badirkhanli, and D. Katabi.FatVAP: aggregating AP backhaul capacity to maximizethroughput. In Proc NSDI, pages 89–104, 2008.

[12] V. Leung and A. Au. A wireless local area networkemploying distributed radio bridges. Wirel. Netw.,2(2):97–107, 1996.

[13] A. Miu, A. Miu, H. Balakrishnan, C. Emre, K. Mit, andC. Science. Improving Loss Resilience with Multi-RadioDiversity in Wireless Networks. Proc. ACM Mobicom, pages16–30, 2005.

[14] A. Miu, G. Tan, H. Balakrishnan, and J. Apostolopoulos.Divert: fine-grained path selection for wireless LANs. InProc. ACM MobiSys, pages 203–216, 2004.

[15] V. Navda, P. Subramanian, K. Dhanasekaran, A. Timm-giel,

and S. Das. Mobisteer: Using steerable beam directionalantenna for vehicular network access. In Proc. ACMMobisys, 2007.

[16] A. Nicholson, Y. Chawathe, M. Chen, B. Noble, andD. Wetherall. Improved access point selection. In Proc.MobiSys, pages 233–245, 2006.

[17] A. Nicholson and B. Noble. BreadCrumbs: forecastingmobile connectivity. In Proc. ACM Mobicom, 2008.

[18] A. Nicholson, S. Wolchok, and B. Noble. Juggler: VirtualNetworks for Fun and Profit. In IEEE Trans. MobileComputing, 2009.

[19] A. Qureshi and J. Guttag. Horde: separating networkstriping policy from mechanism. In Proc. ACM MobiSys,pages 121–134, 2005.

[20] P. Rodriguez, R. Chakravorty, J. Chesterfield, I. Pratt, andS. Banerjee. Mar: a commuter router infrastructure for themobile internet. In Proc. ACM MobiSys, pages 217–230,2004.

[21] N. Thompson, G. He, and H. Luo. Flow Scheduling forEnd-host Multihoming. In Proc. IEEE INFOCOM, 2006.

[22] A. Viterbi, A. Viterbi, K. Gilhousen, and E. Zehavi. SoftHandoff Extends CDMA Cell Coverage and Increase ReverseLink Capacity. In Proc. Intl. Zurich Seminar on DigitalCommunications, pages 541–551, 1994.

APPENDIXA. PROOF OF NP-HARDNESS

We assume that the mobile node spends T secondson a road segment that has n open WiFi access points.We also assume that the driver has n virtual interfaces,thus, it is possible to establish concurrent connections tothe n APs. Let Si be subset i of the power-set of n APs.We define a value Vi for each subset Si. Vi is a functionof the APs in the subset and quantifies connectivity orthroughput. For example, if cumulative throughput isour desired metric, and the wireless bandwidth that Sican provide is Wi then Vi = Ti ×Wi, where Ti is thetime spent by a Spider node within the range of the APsin Si. We also define a cost Ci associated with Si. Ci isthe sum of the time that Spider spends within range ofthe APs in Si, the association time, and the switchingoverhead among channels and processing per channelqueues. If Di is this overhead, Ci = Ti + dTi/T e ×Di.

With these parameters as input, the goal of the multi-AP optimization problem is to select a set of subsets Si,such that the sum of their values is maximized subjectto the following constraints: (1) the total cost shouldnot exceed the total time T and, (2) each Ti must bepositive and less than T . Formally stated:

maxX

i

TiWi (11)

such thatX

i

(Ti + dTi/T eDi) ≤ T (12)

∀i, 0 ≤ Ti ≤ T (13)

The above problem is equivalent to the 0-1 knapsackproblem, which is known to be NP-hard.

14