Towards WiFi Mobility without Fast Handover

Andrei Croitoru, Dragos

,
Niculescu, Costin Raiciu
University Politehnica of Bucharest
ABSTRACT
WiFi is emerging as the preferred connectivity solution for
mobile clients because of its low power consumption and
high capacity. Dense urban WiFi deployments cover entire
(central) areas, but the one thing missing is a seamless mo-
bile experience. Mobility in WiFi has traditionally pursued
fast handover, but we argue that this is the wrong goal to
begin with. Instead, we propose that mobile clients should
connect to all the access points they see, and split trafc over
them with the newly deployed Multipath TCP protocol. We
show via detailed experiments and simulation that this solu-
tion is highly promising.
1. INTRODUCTION
Mobile trafc has been growing tremendously to the point
where it places great stress on cellular network capacity, and
ofoading trafc to the ubiquitous WiFi deployments has
long been touted as the solution. The potential for ofoad
is tremendous, especially in highly dense urban areas, where
almost always there exist deployments from several hotspot
providers: for instance, only in the Bucharest city center
there are at least three wide-area deployments, and more are
being planned. In fact, in dense WiFi deployments WiFi to
cellular transitions are not needed at all: entire areas are cov-
ered entirely by WiFi, so mobiles should rely only on WiFi
because it offers higher capacity and lower energy consump-
tion. That is why we believe that WiFi mobility is not only
back in fashion, but will likely be the determining factor in
deciding whether WiFi ofoad is feasible.
Traditional WiFi mobility techniques (as with all other L2
mobility mechanisms) are based on the concept of fast han-
dover: when a mobile client exits the coverage area of one
Access Point (AP), it should very quickly nd another AP
to connect to, and quickly associate to it. There is a great
wealth of research into optimizing fast handover including
scanning in advance, re-using IP addresses to avoid DHCP,
synchronizing access points via a backplane protocol, even
the use of an additional card to reduce the association delay
- see section 2 for more details. However, we think this is
the wrong approach, for multiple reasons:
i. To start the handover mechanism, a client has to lose
connectivity to the AP, or break before make
ii. There is no standard way to decide which of the many
APs to associate with for best performance.
iii. Once the decision has been made, there is no way to dy-
namically adjust to changes in AP signal strength.
We conjecture that the emerging standard of Multipath
TCP enables radical changes in how we use WiFi: use of
multiple APs becomes natural, whether on the same channel
or different ones, and the perennial handoff problem at layer
2 gets handled at layer 4 allowing for a clean, technology
independent, end-to-end solution for mobility.
In this paper we test the following hypothesis:
All WiFi clients should connect to all the access
points in their vicinity for better performance.
We carefully analyze the performance experienced by a
mobile client locked into using a single WiFi channel and as-
sociating automatically to all the access points it sees, with-
out using any explicit layer 2 handover. We run a mix of
testbed experiments to test a fewkey use-cases and ns2 simu-
lations to analyze the generality of our testbed ndings across
a wide range of parameters and scenarios.
We nd that, surprisingly, the performance of this very
simple solution is very good out of the box for a wide range
of scenarios and for many WiFi avours (802.11a/b/g/n): a
WiFi client connecting to all visible APs will get very close
to the maximum achievable throughput. We discuss in de-
tail the reasons for this performance, namely the WiFi MAC
behaviour and its positive interaction with Multipath TCP.
We also nd that performance is not very good for 802.11n
and some (hypothetical) rate control algorithms: in such cases
the client downloads too much data from APs far away, re-
ducing total throughput. To address this issue, we implement
and test a simple and very effective client-side modication
that helps the Multipath TCP congestion controller nd
the right access points by setting a low rate of ECN marks
on packets from APs sending at low WiFi rates.
We ran a mobility experiment in our CS building, com-
paring our proposal to using regular TCP connected to the
individual APs. The results show a true mobile experience:
our clients throughput closely tracks that of a TCP client
connected to the best AP at any given location.
2. BACKGROUND
Fast Handover. The 802.11 standards were originally de-
signed for uncoordinated deployments, and are not particu-
larly amenable for high speed handovers. The handover is
performed in three phases: scanning, authentication, and as-
sociation. The rst phase has been empirically shown [1]
to be 95% of the handover time, and has been the target for
most optimizations proposed in the literature.
One approach to reduce the scanning delay is to probe for
nearby APs before the mobile loses its current link. Sync-
Scan [2] goes offchannel periodically to perform the scan,
so that the mobile has permanent knowledge about all APs
on all channels. DeuceScan [3] is a prescan approach that
1
uses a spatiotemporal graph to nd the next AP. Mishra et al.
[4] uses neighbor graphs to temporarily capture the topology
around the mobile and speed up the context transfer between
APs using IAPP. When additional hardware is available, [5]
delegates the task of continuous probing to a second card.
For enterprise networks there are several opportunities to
optimize the handover process. The rst one is the use of
a wireless controller that has a global view of all the APs
and the associated mobiles in the entire network. This archi-
tecture is supported by all major vendors, because it offers
many other advantages in addition to controlled association
and guided handover. Another avenue for optimizing fast
handover is to eliminate it altogether, with the adoption of
a single channel architecture [6] where multiple coordinated
APs pose as a single AP by sharing the MAC; this archi-
tecture is currently in use by Meru, Extricom and Ubiquiti.
In these architectures, the wireless controller routes the traf-
c to and from the appropriate AP, so that a mobile never
enters the handover process.
802.11r [7] optimizes the last two components of the han-
dover ensuring that the authentication processes and encryp-
tion keys are established before a roam takes place. Authen-
tication occurs only once, when a client enters the mobility
domain. Subsequent roams within a mobility domain use
cryptographic material derived from the initial authentica-
tion, decreasing roam times and reducing load on back-end
authentication servers. 802.11k [8] provides for roaming as-
sistance from the AP: when it perceives the mobile moving
away, it sends a notication and possibly a site report with
other AP options to maintain connectivity.
Finally, a survey of handover schemes [9] mentions sev-
eral other efforts in this direction and classies them based
on the incurred overhead, necessity of changes (mobile, AP,
or both), compatibility with standards, and complexity.
All these layer 2 solutions do improve handover perfor-
mance, but their availability depends on widespread support
in APs, as well as in the client. More fundamentally, doing
a handover is a decision that locks the client into one AP for
a certain period of time, which leads to poor performance
when truly mobile: there is no good way of predicting the
throughput the client will obtain from one AP in the very
near future. By using a transport layer mobility solution, we
sidestep the need to upgrade all APs / client hardware for
mobility and, more importantly, we allow a client to utilize
multiple APs at the same time.
Multipath TCP is a recently standardized extension of TCP
[10] that has been implemented by Apple in the IOS 7 mo-
bile operating system; more mobile phone manufacturers are
expected to follow suit. Multipath TCP is enticing to mobile
devices because it can effectively use the multiple interfaces
available in a single transport connection: it allows users to
use both cellular and WiFi links be it concurrently or alter-
natively, as an ofoading solution.
Multipath TCP works with unmodied applications that
use the well-known socket API. A Multipath TCP connec-
Figure 1: Instead of fast handovers, we propose that
wireless clients associate to all the APs in range and
use Multipath TCP to spread trafc across them.
tion contains one or many subows, where each subow
looks to the network like a regular TCP connection, and is
bound to one interface on the mobile device. Multipath TCP
takes care of splitting data across these subows and putting
it back in order at the receiver, and resending data fromfailed
subows over alternative ones (see [11] for details).
A key component of Multipath TCP is its congestion con-
troller, that was built to ensure fairness to TCP and to load-
balance trafc, pushing more trafc onto less congested links
[12]. Another congestion controller that has been proposed
recently is OLIA, which performs a more aggressive load
balancing [13]; this is the controller we use in this paper un-
less mentioned otherwise.
3. SINGLE CHANNEL MOBILITY
We observe that the emergence of Multipath TCP enables
a radically different approach to WiFi mobility: instead of
using only one AP at a time and doing handovers, mobile
clients should connect to all APs at any given time. The
solution is conceptually very simple, and is shown in Figure
1: we have the client associate to multiple APs, obtaining
one IP address fromeach, and then rely on MPTCP to spread
data across all the APs, with one subow per AP. As the
mobile moves, new subows are added for new APs, while
old ones expire as the mobile loses association to remote
APs. In this paper, we focus on the case when the wireless
NIC is restricted to use a single channel (e.g. 1,6 or 11 in
the 2.4Ghz range). Multi-channel solutions can be devised
by extending our ndings, as we discuss in 5.
If we disregard WiFi interference between APs, the the-
oretically optimal mobility solution is to always connect to
every visible AP, and let MPTCP handle load balancing at
the transport layer: if an AP has poor signal strength, the
bytes will simply migrate to the APs with better connectiv-
ity to the client. This way, handover delays are eliminated
and the mobile enjoys continuous connectivity.
Interference, of course, can be a major issue. We imple-
mented a prototype client that is locked in on a single chan-
nel and continuously looks for beacons of known APs; when
a such an AP is found, the client creates a new virtual wire-
less interface and associates to the AP. We ran this code on
our 802.11a/b/g/n testbed without external interference, as
well as in simulation to understand the feasibility of our pro-
posal. We discuss our experiments next, wrapping up with a
mobility trace of our client roaming through our building.
2
0
0.2
0.4
0.6
0.8
1
0 5 10 15 20 25 30 35
T
h
r
o
u
g
h
p
u
t

[
%
]
Position
TCP via AP1
TCP via AP2
MPTCP over AP1+2
(a) Throughput of a client moving between AP
1
and
AP
2
: the MAC favors the sender with the better
channel. Max throughput is 22Mbps.
0
10
20
30
40
50
60
70
80
90
100
0 1 2 3 4 5 6 7 8 9
P
a
c
k
e
t

d
e
l
i
v
e
r
y

r
a
t
i
o

[
%
]
Time [s]
Channel to AP1
Channel to AP2
(b) Axed node has channels with a raw PDR50%
to each AP. The quality of the two channels varies
independently in time.
0
10
20
30
40
50
60
70
80
90
100
1 10
C
D
F

[
%
]
Packet interarrival time[ ms]
AP1
AP2
AP1+2
shorter tail = fewer retries
(c) Packet interarrival rate exhibits a longer tail
when a single AP is used. When both APs are
sending, the tail is much shorter.
Figure 2: Carrier sense experiments: the client using MPTCP gets the throughput of the best TCP connection when close
to either AP, and better throughput when in-between.
3.1 Carrier-sense experiments
The rst case we test is when a client connects to two
APs on the same channel in 802.11a and within carrier sense
range of each other, so that the WiFi MAC will prevent both
APs sending simultaneously. The mobile associates to both
APs and then we move the client from one AP to the other
in discrete steps. We measure the throughput of an MPTCP
connection through both APs and compare it with that of
using a TCP via either AP, which represents the status-quo.
The results are given in Fig. 2a, and they show that the
throughput of the MPTCP client connected to both APs is as
high as the maximum offered by any of the two APs.
The reasons for this behaviour are not obvious. Consider
rst the cases when the client is closer to one AP; in such
cases the most efcient use of airtime is to use only the AP
thats closest to the client. In fact, the Linux WiFi rate selec-
tion algorithm (Minstrel) favours higher bitrates even at low
signal strengths with lower frame delivery rate, which leads
to more retransmissions per packet for the far away AP. Each
retransmission imposes an exponentially larger backoff time
on the transmitter, which allows the AP with better signal
strength to send more packets. This behaviour is strictly en-
forced by the L2 conditions, and we veried that the choice
of TCP congestion control has no effect on the distribution
of packets over the two paths. In fact, the same results were
obtained in an experiment using UDP. We also veried in the
ns2 simulator that the MAC preference for the better sender
holds regardless of the maximumnumber of retransmissions
allowed (0 - 10).
When in-between the two APs, the client sometimes ob-
tains slightly more throughput (10% - 20%) by using both
APs than if we were using either AP in isolation. This is
very surprising, and the explanation is more involved.
The fundamental reason lies at the physical layer: due to
fading effects, individual channel quality varies quickly over
time, despite both channels having a roughly equal longer-
term capacity. To test this hypothesis, we simultaneously
sent a low rate broadcast stream fromeach AP and measured
their delivery ratio at the client. As broadcast packets are
never retried, their delivery ratio captures the channel quality
accurately; the low rate is used to ensure the two APs dont
ght each other over the airtime, while still allowing us to
probe both channels concurrently. The instantaneous packet
delivery ratios computed with a moving window are shown
in Figure 2b, conrming that channels from the two APs are
largely independent.
What mechanism manages to exploit this channel diver-
sity? Our rst guess was the MPTCP congestion controller,
but this turned out to be wrong: both subows had fairly
large congestion windows, and the buffers at the APs where
never empty during our experiment. It turned out it is the
802.11 MAC that exploits physical channel diversity, which
is a form of multiuser diversity: the sender that sees a better
channel will decrease its contention window, and will be ad-
vantaged even more over the sender with a weaker channel.
This behaviour is experimentally veried by previous work
[14] with several clients and bidirectional trafc to/from the
AP. For our client downloading fromtwo APs, when one has
a slightly worse channel, it will lose a frame and double its
contention window before retrying, leaving the other AP to
better utilize the channel.
To check this hypothesis, we analyzed interarrival times
between packets for the client using either AP or both at
the same time, and the CDF is plotted in Figure 2c. The
data shows that most packets arrive 1ms apart, and that AP1
prefers a higher PHY rate (24Mbps) while AP2 prefers a
lower PHY rate (18Mbps) when used alone. Using both
APs leads to interarrival times in between the two individ-
ual curves for most packets. The crucial difference is in the
tail of the distribution, where using both APs results in fewer
retries per packet. When one AP experiences repeated time-
outs, the other AP will send a packet, thus reducing the tail.
We conclude that in this carrier-sense scenario, bandwidth
is harvested optimally by the combination of 802.11 MAC
preference for the better channel, rate adaptation (minstrel),
and MPTCP that streams packets across APs.
3.2 Hidden terminal experiments
When the two APs are outside of CS range and the client
is connected to both, the CSMA mechanism no longer func-
tions and the frames coming fromthe two APs will collide at
the client. In fact, each AP is a hidden terminal for the other.
To run this experiment, we reduced the power of our two
APs until they were out of carrier sense, but the client is still
able to achieve full throughput to at least one of them at all
3
0
0.2
0.4
0.6
0.8
1
1 2 3 4 5 6 7 8
T
h
r
o
u
g
h
p
u
t

[
%
]
Position
UDP1
UDP2
UDP1+2
MPTCP1+2
(a) Experimental results with 802.11a, 6Mbps:
UDP ows systematically collide each other, while
MPTCP subows take turns on the medium.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 20 40 60 80 100 120 140 160
T
h
r
o
u
g
h
p
u
t

[
%
]
Distance [m]
UDP1
UDP2
UDP1+2
TCP1+2
(b) ns2 simulation of the same situation in 3a. In
the middle region MPTCP exhibits higher variability
because one subow starves the other.
0
20
40
60
80
100
0 2 4 6 8 10 12 14
P
a
c
k
e
t
s

l
o
s
t

(
%
)
Number of retransmissions
Subflow 1
Subflow 2
(c) The subow sending packets infrequently expe-
riences a much higher loss rate. This makes it hard
for a (MP)TCP ow to escape its slowstart.
Figure 3: Hidden terminal (HT) experiments: using Multipath TCP results in very good throughput because one subow
monopolizes the air, while the other is starved.
locations. To test this setup, each AP broadcasts packets as
fast as possible. When sending alone, each of the two AP
can send a maximum 1000 575B UDP packets per second
with a MCS of 6Mbps. When in CS and sending simultane-
ously, each AP will send roughly half that number of pack-
ets. As we further decrease the power of the APs, the two
APs can simultaneously send 1000 packets/s each, indicat-
ing they cant hear each other.
Then, we move our client between the APs, and measure
throughput for UDP, TCP and Multipath TCP. As shown in
gure 3a, the graph exhibits three distinct areas. In the two
areas close to either AP, neither UDP nor TCP throughput is
affected: here the capture effect of WiFi can be seen, where
packets coming from the closer AP are much stronger, and
the effect of a collision is very smallthe client will just
decode the stronger packet as if no collision took place, and
the subow via the furthest AP will reduce its rate to almost
zero because of repeated packet losses.
The area in the middle is more interesting. As we ex-
pected, the combined UDP throughput of two simultaneous
iperf sessions is greatly diminished by the hidden terminal
situation. However, by running two simultaneous MPTCP
subows, the combined throughput is surprisingly good. Re-
peated runs showed this result is robust, and we also con-
rmed this via ns2 simulation (see gure 3b). MPTCP con-
nection statistics show that the high-level reason for the high
throughput is that trafc is owing entirely over one of the
two subows, while the other one is starved, experiencing
repeated timeouts. This would suggest that the starved sub-
ow is experiencing (much) higher loss rates, which would
explain why it never gets off the ground properly. However,
as the two channels have roughly the same quality, it is not
obvious at rst why this would be the case.
To understand the reason of this behaviour, we used sim-
ulation to measure the loss probability of the two subows
when contending for the medium. Say subow 1 is sending
at full rate, while subow 2 sends a single packet which col-
lides with a packet of subow 1. The WiFi MACs will then
backoff repeatedly until the max retransmission count has
been reached, or until one or both packets are delivered. We
run the simulation for a long time to experience many such
episodes, and show the percentage of episodes each subow
experiences a loss in Fig. 3c as a function of the retry count.
When fewretransmissions are allowed, both subows lose
a packet each when a collision happens, but the effect of the
loss is dramatic for the second subow pushing it to another
timeout. As we allow more retransmissions, the loss prob-
ability is reduced dramatically: the second subow loses
around 40% of its packets if 6 or more retransmissions are
allowed. The reason for the attening of the line at 40%
is the fact that the rst sender always has packets to send,
and when subow 1 wins the contention for the rst packet,
its second packet will start fresh and again collide with the
retransmissions from the second subow, further reducing
its delivery ratio. This also explains why subow 1 experi-
ences no losses after six retransmissions: either it wins the
contention immediately, or it succeeds just after the second
subow successfully sends its packet.
In effect, we are witnessing a capture effect at the Mul-
tipath TCP level triggered by the interaction with the WiFi
MAC. Luckily, this behaviour is ideal for our MPTCP client.
3.3 Rate Control with packet-level fairness
Our experiments so far have relied on the 802.11a/g proto-
cols, which cover most of the deployed WiFi base, and used
the default rate control algorithm of Linux (Minstrel). A
valid question is whether our ndings also hold for 802.11n
or for different rate control algorithms. In order to verify the
validity of our proposal, we tested it on APs and clients run-
ning 802.11n in the 5GHz frequency band. We repeated the
experiment with the client in different positions between the
APs; in-between the APs MPTCP gave throughput compa-
rable to that of the TCPs. However, when the client is close
to one of the APs, the results differed from 802.11a/g: the
throughput obtained with MPTCP was only approximately
half the throughput obtainable via the closest AP.
We investigated the reasons for this behaviour by mon-
itoring the PHY bitrates used by the transmitters and ob-
served that the rate control algorithmLinux uses for 802.11n
(Minstrel-ht) differs from Minstrel signicantly: instead of
using aggressive bitrates and many retransmissions, Minstrel-
ht chooses the rates to ensure maximum delivery probability
of packets. The block ACK feature of 802.11n is likely the
main factor in this decision, as the loss notication now ar-
rives at the sender after a whole block of frames has been
4
transmitted (as much as 20): the sender cant afford to ag-
gressively use high bitrates because feedback is scarce.
In fact, the block ACK mechanism together with the cau-
tious choice of bitrates by the transmitters ensures block-
level fairness between the two APs: the client will receive
one block fromAP1 at high bitrate, then one block fromAP2
at lower bitrate, and so on.
This issue is not limited to 802.11n: any WiFi rate control
algorithm that offers packet-level fairness between multiple
senders in Carrier Sense range greatly harms the combined
throughput achievable by MPTCP when utilizing multiple
APs. Rate control is a modular element and is not regulated
by the 802.11 standard, thus wireless NIC manufacturers can
implement different algorithms in their drivers. Linux, by
default, uses the Minstrel algorithm implemented in the ker-
nel, but that algorithm can be overridden by the WiFi driver.
Also, most types of commercial APs are not Linux-based,
and the rate control is handled in the NIC driver.
Solution. WiFi load balancing is not working well for our
proposal in this setup, and the most obvious solutions are
either a) rely on changes at APs (e.g different rate control
mechanisms) or b) try to associate to fewer APs when we
suspect we are in this situation. The former is not only dif-
cult to deploy but will also impact other clients of the APs.
The latter is against our philosophy of using many APs.
Instead, we have devised a heuristic solution that we be-
lieve is both efcient and simple. Our key idea is to use the
ability of the MPTCP congestion controller to direct traf-
c to the most efcient access points. For this to happen,
MPTCP must observe a higher loss rate on the subowcross-
ing the less efcient AP. Unfortunately, in the current sce-
nario, the loss rates on both paths are equal as both APs
send an equal number of packets per second, and the MPTCP
sender cannot choose between them.
Note that the MPTCP client can tell which AP sends at
higher rates, and is preferable. To relay this information to
the sender we could drop packets but this is rather crude, so
we rely on ECN instead. The server then shifts trafc away
from this path, but it will still probe it in case it gets better.
We have implemented this approach in the 802.11 sub-
system of the Linux kernel by maintaining an exponential
moving average of the bitrates of incoming packets on the
different virtual interfaces. When the average bitrate of one
interface is signicantly smaller than the other (20% less),
the client code marks 1% of its incoming packets with the
CE (congestion experienced) ECN codepoint. This marking
happens before the L2 packets get delivered to L3 processing
code at the client.
Our heuristic performs very well for 802.11n when the
client is close to one AP: within a couple of seconds, traf-
c is shifted by MPTCP to the better AP, and throughput
reaches 90% of TCP using that AP alone. We reran all the
experiments presented so far (including 802.11a/g) with our
client-side load balancing algorithm on. We found that the
marking made no difference to the actual results: in particu-
!
"
$!% &'()*+
!
,
$!% &'()*+
-%
"
-%
,
!

.%$!% &'()*+
Figure 4: Experimental setup to test fairness
lar, we veried that marking was not triggered in the channel
diversity setup we discussed before.
Finally, note that we can construct articial scenarios where
this mechanism hurts throughput. Say AP1 is using a small
bitrate (e.g. 12Mbps, no retries) but has higher overall through-
put than AP2 which uses a high bitrate but many retransmis-
sions (e.g. 54Mbps with 5 retries per packet). In such cases,
our mechanism will introduce a 1% loss rate on AP1, which
might affect its throughput. Luckily, the effect should be
rather small: a 1% loss rate will result in a congestion win-
dow of around 10 packets, which at 20ms RTT leads to a
throughput of 6Mbps - far from a catastrophe. However, for
sane rate control algorithms this situation is highly unlikely
in practice. More experiments are needed, though, to test the
sensitivity of our algorithm in many different scenarios with
different rate control algorithms used in practice.
3.4 Fairness
We have focused our analysis so far on the performance
experienced by a client connecting to multiple access points,
and showed that there are signicant benets to be had from
this approach. We havent analyzed the impact this solu-
tion has on other WiFi clients: is it fair to them? Does our
solution decrease the aggregate throughput of the system?
In answering these questions, our goals are neither absolute
fairness (since WiFi is a completely distributed protocol and
also inherently unfair, this goal in unattainable) nor maxi-
mizing aggregate throughput (which may mean some distant
clients are starved). Rather, we want to ensure our solutions
impact on other clients is no worse than that of a TCP con-
nection using the best available AP.
The theory of Multipath TCP congestion control reassures
us that two or more MPTCP subows sharing the same wire-
less medium will not get more throughput than a single TCP
connection would. Also, if an AP has more customers, Mul-
tipath TCP will tend to steer trafc away from that AP be-
cause it sees a higher packet loss rate.
We used the simple setup shown in Figure 4 to test the
behaviour of our proposal. There are two access points each
with a TCP client in their close vicinity, using 802.11a, and
an MPTCP client C using both APs.
The rst test we run has both APs using maximumpower:
when alone, all clients will achieve the maximum rate in
802.11a, around 22Mbps. The results of the experiment are
shown in table 1: when the client connects to both APs, the
system achieves perfect fairness. In comparison, connecting
to either AP alone will lead to an unfair bandwidth alloca-
tion. In this setup, MPTCP congestion control matters. If
we use regular TCP congestion control on each subow, the
5
C conn.
to
AP1-C1 AP2-C2 C
AP1 5Mbps 10Mbps 5Mbps
AP2 10Mbps 5Mbps 5Mbps
AP1&AP2 7Mbps 7Mbps 7Mbps
Table 1: APs and clients in close
range: MPTCP provides perfect
fairness
C conn.
to
AP1-C1 AP2-C2 C
AP1 3.5Mbps 13Mbps 3.5Mbps
AP2 10Mbps 5Mbps 5Mbps
AP1&AP2 10Mbps 5Mbps 5Mbps
Table 2: Client close to AP
2
:
MPTCP client behaves as TCP con-
nected to AP
2
C conn.
to
AP1-C1 AP2-C2 C
AP1 3.5Mbps 13.5Mbps 3Mbps
AP2 14Mbps 3Mbps 3Mbps
AP1&AP2 8.5Mbps 6.5Mbps 5Mbps
Table 3: Client in-between APs:
MPTCP client improves overall fair-
ness
resulting setup is unfair: the MPTCP client receives 10Mbps
while the two TCP clients each get 5Mbps.
We next study another instance of the setup in Fig. 4
where the APs, still in CS, are farther away, and while the
TCP clients remain close to their respective APs, they get a
lesser channel to the opposite AP.
First, we place C close to AP
2
. When C connects to AP
1
,
which is farther, it harms the throughput of C
1
, and the over-
all fairness is greatly reduced. When C connects to both
APs, its trafc ows via the better path through AP
2
, offer-
ing optimal throughput without harming fairness (table 2).
When the client is between the two APs, trafc is split on
both paths and the overall fairness is improved, while also
increasing the throughput obtained by our client (table 3).
In summary, by connecting to both APs at the same time
and splitting the downlink trafc between them, MPTCP
achieves better fairness in most cases, and never hurts trafc
more than a TCP connection would when using the best AP.
4. A MOBILITY EXPERIMENT
We now discuss a mobility experiment we ran in the CS
building of our university: the user starts from our lab situ-
ated on the second oor of the building, goes down a ight of
stairs and then walks over to the cafeteria. En route, the mo-
bile client (a laptop) is locked on channel 6 and can associate
to ve different access points, each covering different parts
of the route. We repeat the experiment by doing consecutive
runs (each run takes around 1 min or so), and in each run
the client is either locked into using a single AP, or is using
MPTCP and associating to all APs it sees all the time.
The results are shown in Figure 5. In the beginning of the
walk, the client has access to the two APs in our lab (named
UberAP), and these are also accessible briey on the stairs
(in the middle of the trace). The tempus access points are
our departments deployment of uncoordinated access points
(Fortinet FAP 220B), available both in our lab (at very low
strength), on the stairs and closer to the cafeteria. Our mo-
bile client connects to at most three APs simultaneously.
Throughout the walk, the throughput of our MPTCP mo-
bile client closely tracks that of TCP running on the best AP
in any given point, showing that our careful coordinated ex-
periments do capture the crux of the interesting behaviours
noticed in practice. There is however an area around 65s
where TCP outperforms MPTCP; we believe this is due to
repeated timeouts experienced by the subow running over
the Tempus2 AP before the signal improves. The easy x is
to cap the RTO to some reasonable value (e.g. 1s).
0
0.2
0.4
0.6
0.8
1
0 10 20 30 40 50 60 70 80
T
h
r
o
u
g
h
p
u
t

[
%
]
Time (s)
MPTCP
uberAP1
uberAP2
tempus 1
tempus 2
Figure 5: Mobility experiment: indoor client walk
(max throughput is 22Mbps)
We also noticed that in the beginning of the trace our
ECN-based load balancing algorithm penalizes the subow
over the Tempus2 APif we disable it, the throughput of
MPTCP in that area drops dramatically.
5. DISCUSSION
In this paper we have proposed a paradigm shift for wire-
less mobility: instead of using a single AP at any one time
and racing to quickly change to the next when signal fades,
we propose to use all APs in range and use Multipath TCP
to spread trafc amongst them.
Our experiments have shown that, in many cases, the load
balancing job is done by the WiFi MAC (our carrier-sense
experiments) or by interactions of the MAC and Multipath
TCP congestion control (hidden terminal). Our ECN-based
heuristic algorithm triggers the MPTCP congestion control
when WiFi load balancing reduces the clients throughput.
Beyond our controlled experiments, our mobility experiment
is strong indication that our ndings hold in real-life.
This is preliminary work. More experiments are needed
to understand interactions with other rate control algorithms
deployed in practice, as well a wider range of mobility exper-
iments. Finally, we need to quantify the energy consumption
of our proposal and contrast it to using TCP on the best path.
A major direction of future work is extending our solution
to multiple channels. So far, we have assumed our client uses
a single channel out of the three channels in wide-spread use
today (1, 6 and 11 in the 2.4Ghz band). At the minimum,
the client needs to decide which channel to use, which will
depend on the density of APs on the channels. A more inter-
esting direction is to use channel switching as proposed by
FatVap [15] or Juggler [16], and associate to all APs on all
channels. Within a channel we will apply the solutions dis-
cussed in this paper; additionally, a multi-channel solution
must decide how long to spend on each channel, depending
on the throughput received.
6
6. REFERENCES
[1] A. Mishra, M. Shin, and W. Arbaugh, An empirical
analysis of the IEEE 802.11 MAC layer handoff
process, SIGCOMM Comput. Commun. Rev., vol. 33,
April 2003.
[2] I. Ramani and S. Savage, SyncScan: practical fast
handoff for 802.11 infrastructure networks, in
INFOCOM 2005. 24th Annual Joint Conference of the
IEEE Computer and Communications Societies.
Proceedings IEEE, vol. 1, pp. 675684, IEEE, 2005.
[3] Y.-S. Chen, M.-C. Chuang, and C.-K. Chen,
Deucescan: Deuce-based fast handoff scheme in
IEEE 802.11 wireless networks, Vehicular
Technology, IEEE Transactions on, vol. 57,
pp. 11261141, March 2008.
[4] M. Shin, A. Mishra, and W. A. Arbaugh, Improving
the latency of 802.11 hand-offs using neighbor
graphs, in Proceedings of the 2Nd International
Conference on Mobile Systems, Applications, and
Services, MobiSys 04, (New York, NY, USA),
pp. 7083, ACM, 2004.
[5] V. Brik, A. Mishra, and S. Banerjee, Eliminating
handoff latencies in 802.11 WLANs using multiple
radios: Applications, experience, and evaluation, in
Proceedings of the 5th ACM SIGCOMM Conference
on Internet Measurement, IMC 05, (Berkeley, CA,
USA), pp. 2727, USENIX Association, 2005.
[6] Virtual cells: The only scalable multi-channel
deployment. MERU white paper, 2008.
[7] IEEE standard for information technology local and
metropolitan area networks specic requirements
part 11: Wireless LAN medium access control (MAC)
and physical layer (PHY) specications amendment 2:
Fast basic service set (BSS) transition, IEEE Std
802.11r-2008 (Amendment to IEEE Std 802.11-2007
as amended by IEEE Std 802.11k-2008), pp. 1126,
July 2008.
[8] IEEE standard for information technology local and
metropolitan area networks specic requirements
part 11: Wireless LAN medium access control (MAC)
and physical layer (PHY) specications amendment 1:
Radio resource measurement of wireless LANs,
IEEE Std 802.11k-2008 (Amendment to IEEE Std
802.11-2007), pp. 1244, June 2008.
[9] S. Pack, J. Choi, T. Kwon, and Y. Choi, Fast-handoff
support in IEEE 802.11 wireless networks, IEEE
Communications Surveys and Tutorials, vol. 9,
no. 1-4, pp. 212, 2007.
[10] A. Ford, C. Raiciu, M. Handley, and O. Bonaventure,
TCP Extensions for Multipath Operation with
Multiple Addresses, rfc6824, IETF, 2013.
[11] C. Raiciu, C. Paasch, S. Barre, A. Ford, M. Honda,
F. Duchene, O. Bonaventure, and M. Handley, How
hard can it be? designing and implementing a
deployable multipath TCP, in Proceedings of the 9th
USENIX Conference on Networked Systems Design
and Implementation, NSDI12, (Berkeley, CA, USA),
pp. 2929, USENIX Association, 2012.
[12] D. Wischik, C. Raiciu, A. Greenhalgh, and
M. Handley, Design, implementation and evaluation
of congestion control for multipath TCP, in Proc.
Usenix NSDI 2011.
[13] R. Khalili, N. Gast, M. Popovic, and J.-Y. Le Boudec,
MPTCP is not Pareto-optimal: Performance issues
and a possible solution, Networking, IEEE/ACM
Transactions on, vol. 21, pp. 16511665, Oct 2013.
[14] S. Choi, K. Park, and C.-k. Kim, On the performance
characteristics of WLANs: Revisited, SIGMETRICS
Perform. Eval. Rev., vol. 33, pp. 97108, June 2005.
[15] S. Kandula, K. C.-J. Lin, T. Badirkhanli, and
D. Katabi, FatVAP: aggregating AP backhaul
capacity to maximize throughput, in Proceedings of
the 5th USENIX Symposium on Networked Systems
Design and Implementation, NSDI08, (Berkeley, CA,
USA), pp. 89104, USENIX Association, 2008.
[16] A. J. Nicholson, S. Wolchok, and B. D. Noble,
Juggler: Virtual networks for fun and prot, IEEE
Transactions on Mobile Computing, vol. 9, pp. 3143,
Jan. 2010.
7