ANALYSIS OF A GEOLOCATION-BASED FMIPv6 EXTENSION FOR

NEXT GENERATION WIRELESS LANS

1 1 1 2
Julien Montavont , Emil Ivov , Thomas Noel and Karine Guillouard
1
LSIIT UMR CNRS 7005
Louis Pasteur University Strasbourg, France
{montavontj,Ivov,Thomas.Noel}@dpt-info.u-strasbg.fr

2
France Telecom - 4 rue Clos Courtel, BP 91226
F-35512 Cesson Sevigne Cedex, France
[email protected]

ABSTRACT
Innovation in wireless technologies is changing the Internet and the way users
connect. It is now possible to communicate while on the move. However, the
standard procedures that enable user mobility across networks do not match the
requirements of real-time communications in terms of delay and packet loss. The
FMIPv6 protocol, lately accepted as standard for managing seamless mobility,
addresses most of the problems related to handover latency. Yet, certain issues
specific to wireless LAN, such as Access Point Discovery still prevent FMIPv6
from making the entire roaming procedure seamless for Wi-Fi networks. In this
article, we present an extension of the FMIPv6 protocol that addresses these
problems. Our proposal uses the geographical position of the devices in order to
anticipate their moves and make them attach to the wireless access points that best
fit their location and expected trajectory. We also present an evaluation of our
work based on the implementation of the proposal.

Keywords: Next Internet Generation, Network Mobility, wireless LANs, Fast

Handovers, Geolocation.

1 INTRODUCTION for rapid and seamless handovers. As a result, the

mechanisms introduced by the MIPv6 protocol may
IP version 4 (IPv4) [7], the protocol used over cause user-perceptible connection loss and breaks,
the Internet for data delivery between hosts, is now that degrade the quality of time-sensitive
nearly twenty years old. Even though it has been communication. During the last few years, there have
efficient during the past years, issues related to been many optimizations that address the handover
address shortage and route maintenance are latency related to the MIPv6 mechanisms. Among
beginning to appear. In the same time, the increasing these is the Fast Handovers for Mobile IPv6
popularity and improving characteristics of wireless (FMIPv6) [3] protocol which has lately been
technologies foster the appearance of new use cases standardized by the IETF community. Many
involving mobility and raise the demand for non- previous works and evaluations of this protocol,
interrupted Internet connectivity. The new version of including some of our own, have shown that FMIPv6
the Internet Protocol (IPv6) [6] is trying to resolve may be very efficient for achieving seamless
32 handover. However, as FMIPv6 remains a layer 3
these issues by extending the address space from 2
128 only solution (i.e. with no link layer dependencies), it
to 2 Internet addresses. It also defines a method
leaves unresolved various issues related to handovers
for adding new options or extensions to the IP
in wireless LANs such as the discovery of candidate
header. The Mobile IPv6 (MIPv6) [2] protocol,
Access Points (AP). During this part of the FMIPv6
which is the Internet Engineering Task Force (IETF)
procedure, an MN would discover APs available in
standard for managing IPv6 mobility, uses this
the vicinity. For wireless LANs this may introduce
extension mechanism. The protocol allows Mobile
significant delays and/or cuts in the ongoing
Nodes (MN) to roam among IPv6 subnets without
communication of the MN. In addition, the proposed
having to interrupt their communication with remote
method does not provide MNs with a way to choose
hosts. However, this protocol still suffers various
their next APs according to their location, or
limitations such as its poor support (or lack thereof)
available resources. In this document we present an

Ubiquitous Computing and Communication Journal 1

FMIPv6 extension that enhances the discovery of association. These steps are illustrated in Fig. 1.
candidate APs in wireless LANs. We use geolocation
information in order to anticipate the trajectory of
MNs and select their next APs accordingly. This way
MNs would obtain the parameters of their next APs
(and the layer 3 parameters of the IPv6 subnet behind
them) without having to interrupt their ongoing
communications. Do notice that our method could be
easily extended to other wireless technologies.
Performance evaluation of network mobility
protocols or optimizations available in related
literature is often based on theoretical studies, and
simulations. We do believe, however, that many of
the reasons why handover latency occurs are closely
related to implementations and operating system
specifics that are most often ignored in simulators or
theoretical studies. Furthermore, simulation models
tend to over simplify the wireless link and ignore the
effects of interference and the complexity of
propagation effects. These are the reasons why in
this article, we have completed an entirely empirical
study based on real experiments that evaluate our Figure 1: Standard IEEE 802.11 handover
FMIPv6 extension. This analysis uses the new
FMIPv6 Open Source Implementation Suite [21] for Once an MN is required to attach to a new AP, it
the GNU/Linux operating systems. would first have to discover the surrounding APs and
The rest of this document is organized as follow. select the one that best suits its need. To discover
First, we describe the mobility mechanisms surrounding APs, an MN would perform either
introduced by the MIPv6 and the FMIPv6 protocols passive or active (or both) scanning. The active
and provide a brief overview of the layer 2 handover scanning consists in broadcasting Probe Requests
management in wireless LANs. Section 3 describes and listening for responses. In passive scanning, the
our geolocation based FMIPv6 extension followed MN just listens to the beacon frames sent
by Section 4 where we present the testbed that we periodically (approximately every 100ms) by APs.
have set up and used for experiments. All our The standard defines the MinChannelTime and
measurement results are presented in Section 5, MaxChannelTime parameters which are respectively
followed by a conclusion in Section 6. the minimum and the maximum amount of time that
an MN has to scan (either actively or passively) a
2 EXISTING STANDARDS FOR MOBILITY 802.11 radio channel. If an MN does not detect any
MANAGEMENT APs on a specific radio channel during
MinChannelTime, it switches its channel and starts
This Section provides an overview of the scanning the new one. If at least one AP is detected,
mechanisms and protocols related to the support of the MN remains on the radio channel for
handovers in IPv6 wireless LANs. MaxChannelTime in order to detect any other APs
that might be using it. After scanning all (or a subset
2.1 IEEE 802.11 of the) 802.11 radio channels, the MN selects its new
AP and starts an authentication process. Note that the
The first version of the IEEE 802.11 standard [1] IEEE 802.11 standard does not define any numerical
was released in 1997 and describes wireless LANs as values for MinChannelTime or MaxChannelTime
they are currently known. Since, the IEEE has been and therefore they may vary from one hardware
constantly improving this technology (also known as manufacturer to another.
Wi-Fi), its throughput, reliability and security. The second part of the layer 2 handover consists
Today, the IEEE 802.11 networks are very popular in an exchange of Authentication Request / Response
and are one of the most popular ways for connecting frames between the MN and the new AP. The MN
to the Internet. sends its identity to the AP which may accept or
Given the relatively limited coverage area of reject its request. Upon successful authentication, the
802.11 access points, roaming Mobile Nodes are MN starts the association process and completes the
likely to often switch from one AP to another. The layer 2 handover. It is important to note that an MN
procedure that a node would go through during such is not able to communicate while performing a layer
reconnections (referred to as layer 2 handover) is 2 handover.
defined by the IEEE 802.11 standard and consists in According to results presented in [9], the layer 2
three major steps: discovery, authentication and handover would generally take between 58.7ms and
396.7ms to complete. Approximately 90% of this

Ubiquitous Computing and Communication Journal 2

time is taken by the discovery part [9]. According to address and before actually being able to use it an
[10], delays or cuts above 150ms cannot be MN needs to perform Duplicate Address Detection
compensated by jitter buffers and would generally (DAD) in order to verify the uniqueness of this
cause user perceptible quality degradation. address. This detection may take several seconds to
complete (approx. 1.5s for RFC default values) [4],
2.2 Mobile IPv6 [5]. Finally, the delay necessary for updating the
binding with the HA depends on the Round Trip
After attaching to the new AP an MN might in Time (RTT) between the MN and the HA.
some cases be able to directly reestablish Considering all of the above, total connection
communication. Often however, the new AP would loss time during a handover would often be longer
not belong to the same IPv6 subnet as the previous than 1 second [11], [12] which would probably be
one. In such cases the MN would have to update its unacceptable for any kind of communication, and
IPv6 address and default router, and make sure that even more so for real-time traffic.
flows initiated from its previous network location
would be properly redirected to its current subnet.
This is commonly handled by the Mobile IPv6
protocol.
The Mobile IPv6 (MIPv6) [2] protocol is an
IETF standard that allows managing the mobility of
IPv6 nodes. MIPv6 allows MNs to remain reachable
at a primary IP address while roaming through
different IPv6 networks. The protocol adopts the
notion of a dedicated node, called a Home Agent
(HA). The HA keeps up-to-date bindings between a
primary Home Address (HoA, an address which
belongs to the same IPv6 subnet as the HA itself)
and a Care-of Address (CoA, an address valid only
for the current network location of the MN). The HA
acts as a relay station intercepting and forwarding all
traffic bound for the MN to its current location (i.e.
to its CoA).
In a wireless environment, once an MN roams to
an AP that turns out to be on a new IPv6 subnet, the Figure 2: Layer 3 handover managed by the MIPv6
MN has to acquire a new CoA and then update its protocol
binding to the HA. These procedures are referred to
as layer 3 handover. The discovery of the properties 2.3 Fast Handovers for Mobile IPv6
of an IPv6 subnet (also known as movement
detection) is based on the reception of Router The Fast Handovers for Mobile IPv6 (FMIPv6)
Advertisements that the local Access Router (AR) [3] protocol is one of the most promising solutions
periodically broadcasts or sends in response to a that the IETF proposes in order to reduce the
Router Solicitation. Upon reception of a Router duration of the layer 3 handover and minimize the
Advertisement, the MN can determine whether it has number of lost packets. The idea lying behind this
moved to a new IPv6 subnet in which case the MN protocol is to provide the MN with all properties of
would configure a new locally valid CoA. Most often the IPv6 subnet it is going to move to, before it has
it would do so through the IPv6 stateless actually done so. Moreover, FMIPv6 makes it
autoconfiguration mechanism [4]. Next, the MN possible for the next AR (the one the MN is moving
would inform the HA about its new location by to) to buffer all MN bound packets that arrive while
sending its new CoA in a Binding Update (BU) the MN is disconnected because of the handover.
message. When a corresponding Binding FMIPv6 defines a way for an MN to request
Acknowledgement (BACK) with a successful status from its current AR all layer 3 parameters of the
code is received, the layer 3 handover is complete. IPv6 subnets behind neighboring APs. It also defines
This procedure is illustrated in Fig. 2. semantics that allow the optimization of the
Each stage of the layer 3 handover may handover itself. If an MN is able to detect (e.g.
introduce significant delays in the overall connection through the use of link layer information) the need of
loss time during a handover. First, the minimal a handover it could send a Fast Binding Update
allowed delay between two consecutive Router (FBU) to it's current AR. This message contains
Advertisements is between 0.03 and 0.07 seconds MN's current CoA and the AR that the MN is
[2]. Therefore, in many cases, an MN would have to planning to switch to (referred to as NAR for Next
wait for 0.07 seconds before detecting layer 3 subnet Access Router). At that point the PAR (previously
change. In addition, after configuring its new IPv6 referred to as the current AR) sends to the NAR a
Handover Initiate (HI) message containing the

Ubiquitous Computing and Communication Journal 3

identity of the MN (link layer address, current CoA Service Set Identifiers, etc.). The solution proposed
and, if known, desired next CoA). The NAR by the IETF suggests that MNs periodically perform
confirms (or rejects) the handover with a Handover partial or complete scanning procedures in order to
Acknowledge (HACK) message that may provide discover candidate APs for pending handovers [13].
further NAR specific details. Upon HACK reception, However, in the case of Wi-Fi, such periodic scans
PAR sends a Fast Binding Acknowledgement may have a significant negative impact. Fig. 4
(FBACK) back to the MN which (in this particular presents the results of a preliminary analysis of the
case) receives it on PAR's link. The MN is then mechanism presented in [13]. This study was
ready to actually switch links. Once on NAR's link it performed with a wireless LAN card that supports
sends a Fast Neighbor Advertisement (FNA) IEEE 802.11b/g standards. The card is managed by
message which is supposed to update respective the MADWiFi driver [14]. As we can see, a
neighbor cache entries on the NAR so that it could complete scanning procedure performed to discover
stop buffering MN's packets and complete handover the candidate APs takes, in this particular case,
signaling. 1368ms to complete. As a result, the MN has lost 69
The FMIPv6 protocol also defines a reactive packets during this phase, which is unacceptable
handover scenario which basically represents the regarding the quality of an ongoing media flow and
case where an MN could not anticipate a handover so makes the seamless handover pointless.
it was able to only react once it was already in
progress (hence the name). In that case the FBU is
sent from NAR's link after layer 2 handover has
completed and is usually encapsulated in the FNA.
NAR then forwards that FBU to PAR, the HI/HACK
message exchange follows as in the predictive case
and PAR starts tunneling packets. Both FMIPv6
predictive and reactive modes are illustrated in Fig.
3.
Figure 4: Packet loss and latency during a scanning
for discovery of candidate access points

As we have mentioned earlier the seamless

handover problem over wireless LANs has been
addressed by a significant number of papers. Many
of these provide optimization techniques that reduce
the time necessary for a scan to complete. Some of
them use geolocation information during the
handover which we find especially well suited for
assisting FMIPv6 and resolving the candidate AP
discovery problem.

3 FMIPv6 ASSISTED BY GEOLOCATION

INFORMATION

Figure 3: FMIPv6 protocol operation: Predictive The goal of the proposed solution is to provide
mode (left) and Reactive mode (right) an optimized method for discovering candidate APs
and remove the delay inherent to the standard
Previous performance evaluations of FMIPv6, procedure (i.e. periodically performing complete or
including some of our own, have shown that FMIPv6 partial scanning [13]). Following result from some
is very efficient regarding the duration of connection previous work [8], we decided to extend the FMIPv6
disruption and the number of packets lost due to a mechanisms in a way that would allow taking into
handover. Our previous analysis has shown that account the geographical position of an MN in order
FMIPv6 allows handover to remain transparent to to anticipate its trajectory and choose its next AP
users with no packet loss even when using real-time accordingly. This way, based on its position, velocity
applications such as video streaming or conferencing and direction, an MN would be able to request from
[8]. Although we have noticed small delays on the its current AR the parameters of the AP it is most
reception of the buffered packets, these delays have likely to switch to. We also define several ICMPv6
no impact on the perception of the users. However, options that an AR could use with a PrRtAdv
FMIPv6 is conceived as a layer 3 solution only and message in order to send L2 connection parameters
there is no mechanism designed to provide or to an MN so that it won't need to discover them
efficiently discover the layer 2 parameters of through a scan. The actual handover (i.e. the way
surrounding APs (such as operating channels, FBU, FBAck, HI, and HAck messages are
exchanged) remains unchanged and follows the

Ubiquitous Computing and Communication Journal 4

procedure defined by FMIPv6. ICMPv6 option, called Position Information Option,
Our FMIPv6 extension requires MNs to be able that allows the MN to also send its coordinates inside
to determine their geographical coordinates using a the RtSolPr. It contains the coordinates of the MN
generic geolocation system. In order to do this, and the identifier of its current AP (i.e. the link layer
existing geolocation systems generally use address).
triangulation based on radio signal strength as "seen" In order to limit the signaling overhead that may
by fixed or mobile nodes with a known location. be generated by frequent transmissions of RtSolPr,
There are three major kinds of geolocation systems: the MN would only be sending periodic updates if
mobile-based, mobile-assisted and network-based the signal quality of its radio connection with the AP
[16], [17]. We consider that for assisting mobility has fallen below a certain level. We define a first
using a geolocation system in wireless LAN, it is signal quality threshold S a corresponding to an
best to use a mobile-based solution such as the GPS average quality. Whenever the signal quality drops
System or the wireless LAN infrastructure itself as below S a , the MN would start sending the results of
suggested by [18]. This is the approach we have
its position checks to the AR which would update its
adopted for our experiments. In all tests scenarios
Mobility Cache. The AR would then try to determine
MNs use a mobile-based geolocation system, i.e.
if the MN would soon have to perform a handover.
each MN is aware of its own position.
This assessment is based on the AP range parameter
R , that we store in the extended AR database. R
3.1 Database extension for Access Routers corresponds to the maximum distance between the
AP and an MN that still allows for a relatively good
In order to support our new candidate AP signal quality. As long as the distance D between
detection mechanism, we had to extend FMIPv6 the MN and its AP is shorter than R , we assume that
routers. As previously mentioned, FMIPv6 defines the MN is still well covered by its current AP.
the semantics that allow sending to an MN the Otherwise (i.e. when R < D ), the AR would try to
properties of IPv6 subnets behind the surrounding select a new AP for the MN according to its
APs before it has actually engaged in a handover. trajectory. The combination of signal quality and
For this purpose, every AR manages a database that distance allows ARs to overcome temporary signal
maps APs to IPv6 subnets, including the layer 3 degradations or geolocation errors which may disturb
parameters of these IPv6 subnets. We have extended the algorithm behavior when taken separately.
this database to include some extra layer 2 According to the results presented in [19], we have
parameters related to APs. In addition to the link
set S a between [-75dBm;-78dBm] and R to the half
layer addresses (already stored in the database), the
APs are registered together with their operating of the maximum range of the corresponding AP.
channel, Service Set Identifier (SSID), radio range,
and position (either with relative or geodesic 3.3 Next Access Point determination
coordinates). As this information does not change
often, the database is populated manually. As previously mentioned, the selection of the
next APs is based on the trajectory of the MNs. To
3.2 Mobility Cache do this, we determine a trajectory by applying a
linear interpolation on the two last known positions
In addition to the database described in the of the MN. This gives us the following parametric
previous section, every AR also monitors the MNs representation:
currently connected to its subnet and keeps their last
known status in a so called Mobility Cache. Every x(t) = Ox + t × U x
(1)
record in this cache contains the link layer address of y(t) = Oy + t × U y
the corresponding MN, its last coordinates, the link
layer address of its current AP, and a context. A
context is a collection of layer 2 and 3 data related to where Ox and Oy are the coordinates a point, and
the APs that the MN may move to. Section 3.3 U x and U y the coordinates of the director vector U
describes the way we create such contexts.
The Mobility Cache of an AR is dynamically of a line that passes through that point. Let (x 0 , y 0 )
updated by RtSolPr messages. In FMIPv6, an MN and ( x1, y1 ) be the two last known positions of an
would generally send an RtSolPr message to its MN. The equation of the trajectory would then be:
current AR when it needs to resolve one or more
Access Point Identifier (generally the link layer x(t) = x1 + t × ( x1 − x 0 )
address) to subnet specific information (see Section (2)
2.3). We have slightly extended the purpose of y(t) = y1 + t × (y1 − y 0 )
RtSolPr-s and in our solution an MN would also use
them to periodically update its geographic position We assume that the coverage area of an AP is a
with its AR. For this reason, we have defined a new circle. Let us denote the radius of this circle as G

Ubiquitous Computing and Communication Journal 5

and let (a,b) be the coordinates of its center (the AP. Do notice that FMIPv6 already defines options
geographical position of the AP). The equation of the to provide in PrRtAdv all other parameters necessary
boundary of its coverage area would then be: for the handover (link layer address of AP, new IPv6
prefix, new AR’s link layer and IP address). The way
G 2 = ( x − a) 2 + (y − b) 2 (3) options are ordered in PrRtAdv-s has to follow the
AP order in the list (i.e. the first options are related to
the first AP of the list). Upon reception, the MN will
Then, if we replace x and y in Eq. (3) by Eq.
save the context until it starts a handover or until a
(2), we obtain a polynomial equation of second new context is received.
degree:
3.4 Handover Management
At 2 + Bt + C = 0 (4)
This section describes the handover process
in which: when initiated by MNs. Note that FMIPv6 also
2
defines a mechanism for an AR to initiate a handover
A= U - a network-initiated handover [3], initially
previewed for purposes like load sharing. We have
B = 2 × MO.U (5) defined a second signal quality threshold Sw , which
2 corresponds to the lowest acceptable signal level.
C = MO − G 2 Once the signal quality drops under Sw , the MN
would start the handover process. Layer 3 handover
where U is the line’s director vector for the MN’s is carried out exactly as described in FMIPv6. If a
trajectory, O is a point of the MN’s trajectory, and context is set, the MN begins an FMIPv6 predictive
M is the center of the circle defined by Eq. (3). handover by sending an FBU to its current AR
including the parameters related to the first AP of the
In order to select a new AP for an MN, the AR context. Once the MN receives the corresponding
will resolve Eq. (4) for every AP that is FBACK, it starts the layer 2 handover by switching
geographically adjacent to the current one (i.e. the its radio channel to that of the new AP and sends a
zones covered by both APs intersect). When the Probe Request to its SSID. Upon reception of a
discriminant is negative, the Eq. (4) has no real roots, Probe Response from the destination AP (identified
this means that the MN is probably not headed for by its link layer address), the MN moves directly to
the coverage area of the AP. If the discriminant is the authentication stage. If the authentication is
zero, the Eq. (4) has exactly one root, this means that successful, the MN goes through the association
the trajectory of the MN is tangent to the coverage stage and completes the layer 2 handover. As a
area of the corresponding AP. Finally, if the result, in case of a successful anticipation the delay
discriminant is positive, the Eq. (4) has two distinct of the layer 2 handover is significantly reduced , as
roots, this would mean that the MN seems to be the MN does not have to scan several channels to
moving right into the zone covered by the discover its next AP and neither does it have to wait
corresponding AP. When resolving Eq. (4), the AR for MinChannelTime or MaxChannelTime before
will create a list of adjacent APs sorted in ascending completing the handover process.
order by the value of t . This way the first AP of the
list would be the one that is likely to cover the MN
for the longest distance according to its trajectory.
Once the handover begins, the MN will try to
connect to the first AP in the list. If it is not
reachable it will go on with the second, and so on
(see Section 3.4). As the selection of the next AP
consumes resources on the AR, we try to maintain
the AP list as long as possible. If a context is already
set for the current association of the MN, the AR
would check if the first AP of the list is still a valid
target for the pending handover. If this is no longer
the case, the AR has to select a new one as described
previously. Figure 5: Protocol overview when the anticipation is
successful
Once the context is calculated, the AR would
send it to the MN using a PrRtAdv message. We The rest of the handover follows the FMIPv6
have also defined a new option for PrRtAdv, that we specifications. During the layer 2 handover, the data
call the Access Point Information Option. It allows packets sent to the MN are forwarded by the
transporting the SSID and the radio channel of an

Ubiquitous Computing and Communication Journal 6

Previous AR (PAR) to the Next AR (NAR) which are running a modified version of the FMIPv6 Open
buffers them. After associating with its new AP, the Source Implementation Suite (fmipv6.org [21]). The
MN sends an FNA to the NAR so that it would modifications are related to our protocol specifics. In
deliver all buffered packets and start routing the New order to modify the behavior of the MN’s wireless
CoA (NCoA) of the MN. Finally, the MN sends a LAN device, we have used a 3com 802.11 a/b/g
BU to update its binding with the HA. Fig. 5 PCMCIA wireless card managed by the MADWiFi
illustrates the entire procedure. driver [14].
If the MN does not receive a Probe Response
from the targeted AP, this could either mean that
there was a collision on the wireless link, or that the
AP was out of range. The latter may occur as a result
of a wrongful projection of the MN trajectory (e.g.
due to geolocation errors or change of the direction
of the MN). As the probability for an AP to fall out
of range is quite high, we have decided to limit the
time the MN waits for a Probe Response from an AP
to 5ms. After 5ms, the MN considers that the target
AP is not reachable and tries the next one in the AP
list and so on.
When a layer 2 handover completes, and the AP
that the MN has attached to was the second one it
tried (i.e. the attempt to connect to the first one has
failed) two cases may occur. If the new AP is
connected to the same IPv6 subnet as the first one it Figure 7: Testeb used in the experiments
tried, no further considerations are necessary and the
MN can pursue the handover process as defined in Concerning the geolocation system, the MN is
the case of a successful anticipation. Otherwise, the equipped with a GPS device. We have chosen GPS
MN would find itself in a situation where its packets for its ease of use and installation. Other systems
are being tunneled to and buffered by a different with similar (or better) characteristics, such as [18],
router (referred to as AAR for Anticipated Access could also be used. As the experiments take place in
Router in the following) and not the NAR. In this an indoor environment, we first recorded GPS
case the MN would perform a specific reactive output generated by a moving MN in an open area.
handover by sending to AAR an FNA which We then used the recorded GPS positions while
contains the FBU corresponding to its current performing the real experiments inside. The position
location. As a result, two tunnels will be set up and range of the APs are derived from indoor
simultaneously, the first one from PAR to AAR, and measurements and are configured statically in all
the second one from AAR to the actual NAR. Upon ARs.
reception of data packets addressed to the MN, the
NAR delivers them directly to the MN. Finally, the 4.2 Evaluation Scenario
MN updates its binding to the HA. This case is
referred to as enhanced reactive mode. For the evaluation of our proposal we have
defined the following scenario: the MN would move
4 EXPERIMENTATION from AP1 to AP2 (see Fig. 7). While the MN is
moving, a correspondent node sends a video stream
4.1 The Testbed to it using the well known VideoLAN application
[22]. Data is encapsulated and sent in Real-time
In order to evaluate the performance of our Transport Protocol (RTP) [23] packets, with an
proposal, we implemented it and set up a testbed average length of approximately 1336 bytes and sent
composed of two APs, one HA, two ARs, one MN every 30ms.
and one correspondent node. The testbed contains
three IPv6 subnets. The top AR provides IPv6 5 PERFORMANCE EVALUATION
Internet connectivity to the rest of the testbed and is
also configured as a HA. Each AP is connected to a Results presented in this section are obtained by
different IPv6 subnet and AR. Fig. 7 illustrates the running the network analyzer tool Wireshark [24] on
testbed. the MN. Additional wireless sniffers are also used to
All network entities are running the GNU/Linux collect the results. The evaluation scenario was run
operating system, except for the APs which are 10 times.
802.11b Cisco AP 1200 devices. The HA is running Fig. 8 presents one significant run illustrating the
the new MIPv6 daemon for the GNU/Linux entire handover procedure. When the signal quality
operating system (MIPL [20]). The MN and the ARs of the MN is below the S a threshold, it starts

Ubiquitous Computing and Communication Journal 7

sending periodic RtSolPr messages to its AR in order Upon reception of FBACK, the current AR starts
to update its status and position. Upon reception of tunneling data packets to the NAR while the MN
the fourth RtSolPr, the AR detects that the distance starts the layer 2 handover procedure. As we can see,
between the MN and its current AP is greater than the MN completes the layer 2 handover in 20.4ms on
the R threshold. Therefore, the AR calculates a new average. This time is significantly reduced in
context and sends it to the MN using PrRtAdv. The comparison to the standard layer 2 handover latency
reception of a new RtSolPr request (e.g. between which may vary between 58.7ms and 396.7ms
seconds 9.5 and 12) does not initiate the calculation according to the results described in [9]. Compared
of a new context because the previous one remains to the method defined in the IEEE 802.11 standard
valid until the actual handover occurs. Once the [1] in which MNs have to scan several 802.11
signal quality of the MN drops below Sw , the MN channels to detect surrounding APs, our scheme
starts a predictive handover as described in the allows the MN to directly send Probe Requests over
FMIPv6 specifications. The MN has thus obtained the radio channel of the pre-selected AP. When a
the parameters of the candidate APs (i.e. the context) Probe Response is received from the pre-selected
without loosing a single data packet. Executing the AP, the MN proceeds with authentication and
standard scanning procedure [13] MN would have completes the layer 2 handover with the association
been scanning several 802.11 channels in order to stage. Do notice that the size of the NAR’s buffer is
discover candidate APs, which, as we have already limited and therefore such layer 2 optimization is
mentioned, would have caused significant loss of necessary to avoid buffer overflow and packet loss.
data packets. In addition, regarding the time at which Simply augmenting the buffer size would not resolve
the scanning occurs, there is no guarantee that the set this problem as real-time communications would still
of candidate APs discovered during the last scan suffer the delays accumulated while packets were
would still be pertinent (i.e. still in the radio being buffered.
coverage of the MN) when the MN actually begins Once the layer 2 handover is complete, the MN
its handover. Furthermore, by sorting the list of sends an FNA to the NAR. After receiving it, the
candidate APs according to the length of the NAR, delivers all buffered packets, and starts routing
trajectory segment that they are expected to cover, the NCoA. As we can see from Fig. 9, the NAR has
our solution also reduces the number of performed only buffered two data packets during the entire
handovers. procedure. Although there is a delay in the reception
of buffered packets, this delay remains imperceptible
to the application user and the handover is
completely seamless with no packet lost and no
perceptible delays.
While the MN does not update its binding with
the HA, the data packets are still sent to the Previous
CoA (PCoA) of the MN and are therefore forwarded
through the FMIPv6 tunnel between the PAR and the
NAR. The lifetime of this tunnel is specified by the
MN at the transmission of the FBU. During our
experiments, we configured the MN to request the
minimal allowed tunnel lifetime, i.e. 4 seconds
according to [3]. As shown in Fig. 9, the data packets
Figure 8: Candidate access points discovery are sent to PCoA until the time 310.6ms at which the
followed by an FMIPv6 predictive handover MN sends a BU to the HA. After receiving it, the HA
updates the tunnel endpoints with the NCoA and
Fig. 9 presents the complete handover procedure. sends back to the MN a BACK message with a
Each dot represents the reception or the transmission successful status code which completes the MIPv6
of a packet by the MN at the time indicated on the X- signaling. Then, the following data packets are
axis. As previously mentioned, the MN moves while directly sent to the NCoA and thus do not use the
receiving a video stream (data packets are sent every FMIPv6 tunnel. 4 seconds later, the FMIPv6 tunnel
30ms). Once its signal quality drops below the Sw between the PAR and NAR is removed.
threshold, the MN starts the FMIPv6 procedure by
sending a FBU to its current AR including the Note that the procedure defined for the enhanced
parameters of the NAR, i.e. the AR related to the reactive mode (i.e. when the anticipation is not
first AP of the context. Then, it takes approximately successful) is still being implemented and thus we
25.8ms for the current AR to get handover can not yet provide results for this particular case.
confirmation from the NAR (HI/HACK exchange)
and to send the FBACK back to both MN and NAR.

Ubiquitous Computing and Communication Journal 8

Figure 9: Impact of the Predictive FMIPv6 handovers on a video stream

6 CONCLUSIONS dependencies, and therefore leave unresolved issues

related to handovers in wireless LAN like for
The development of wireless technologies and example the discovery of candidate APs. The
their wide-scale deployment have allowed for new FMIPv6 extension proposed in this article provides
use cases and types of user behavior. Users are a reliable mechanism to select the next APs and
beginning to expect Internet connectivity to be obtain their link layer parameters without disturbing
available anywhere, and anytime. This demand is ongoing communications. This extension uses the
also related to the development and availability of geographical position of MNs to deduce their
small communicating devices supporting various trajectories and thus anticipate their next APs. Our
wireless technologies. The pending deployment of proposal has been implemented and tested on a
the new version of the Internet Protocol (IPv6) [6] GNU/Linux operating system using the new MIPv6
will allow providing globally routable addresses for daemon for Linux (MIPL [20]) and the new
all of these new devices. In an effort to guarantee FMIPv6 Open Source Implementation Suite
uninterrupted IPv6 connectivity, the Internet (fmipv6.org [21]). To measure the impact of our
Engineering Task Force (IETF) has defined the mechanisms on applicative flows, the MN receives
Mobile IPv6 (MIPv6) [2] protocol which enables a video stream while performing handovers.
IPv6 nodes to communicate while on the move. On The results presented in Section 5 have shown
the other hand, the increasing performance of that our scheme allows the entire FMIPv6
wireless technologies, wireless LANs in particular, procedure to remain imperceptible to users, from
allow the transmission of broadband traffic over the the discovery of candidate APs to the completion of
air, and enables support for real-time applications the handover. Based on the trajectory of an MN
such as voice calls (VoIP). Real-time access routers are able to select its next APs and
communications need to satisfy a set of specific provide the related parameters. The proposed
requirements regarding delay and packet loss in method allows the MNs to avoid scanning prior to a
order to achieve guarantee acceptable transmission handover and thus does not disturb
quality. However, the mechanisms supported in communications. Moreover, use of our various
wireless LAN and proposed by MIPv6 to support thresholds on signal quality or geographical
mobility do not match these requirements as the distance reduces the signaling overhead introduced
time needed for a Mobile Node (MN) to roam from by our additional mechanisms. The actual handover
an Access Point (AP) to another is too long. To is also seamless due to the optimized layer 2
address this problem, the IETF has defined the Fast handover and the buffering of data packets defined
Handovers for Mobile IPv6 (FMIPv6) [3] protocol, by the FMIPv6 specification. As a result, the
which allows achieving efficient and seamless quality of the video stream transmission is not
handovers. However, this protocol is a network affected by the movement of the MN.
layer only solution without any link layer Encouraged by the results presented here, we

Ubiquitous Computing and Communication Journal 9

plan to extend the present analysis to large scale Networks, IEEE Communication Magazine,
experiments and error cases, especially to evaluate Vol. 40, No. 8, pp. 38-43 (2002).
the enhanced reactive mode. We expect to be able [12]N. Montavont, and T. Noel: Analysis and
to use Louis Pasteur University wireless LAN Evaluation of Mobile IPv6 Handovers over
network deployment and design more realistic Wireless LAN, Mobile Networking and
scenarios. We are also planning on evaluating our Applications (MONET), special issue on
proposal using other geolocation systems, such as Mobile Networking through IPv6 or IPv4, Vol.
systems based on wireless LAN [18], and extending 8, No. 6, pp. 643-653 (2003).
it to other wireless technologies in order to design a [13]P. MacCann: Mobile IPv6 Fast Handovers for
global solution for heterogeneous mobility. 802.11 Networks, Internet Engineering Task
Force Request for Comments (RFC) 4260
7 REFERENCES (2005).
[14]G. Chesson, M. Renzmann, and S. Leffler:
[1] IEEE Std. 1999 Edition (R2003) (ISO/IEC Multiband Atheros Driver for WiFi
8802-11), IEEE Standard Part 11: Wireless (MADWiFi), http://madwifi.org
LAN Medium Access Control (MAC) and [15]S. Shin, A.G. Forte, A. S. Rawat, and H.
Physical Layer (PHY) Specifications (1999). Schulzrinne: Reducing MAC layer handoff
[2] D. Johnson, C. Perkins, and J. Arko: Mobility latency in IEEE 802.11 wireless LANs, in
Support in IPv6, Internet Engineering Task Proceedings of the 2nd International Workshop
Force Request for Comments (RFC) 3775 on Mobility Management and Wireless Access
(2004). Protocols (MobiWac’04), ACM press, pp. 19-
[3] R. Koodly (ed.): Fast Handovers for Mobile 26 (2004).
IPv6, Internet Engineering Task Force Request [16]S. S. Soliman, and C. E. Wheatley: Geolocation
for Comments (RFC) 4068 (2005). technologies and applications for third
[4] S. Thomson and T. Narten: IPv6 Stateless generation wireless, Wireless Communications
Address Autoconfiguration, Internet and Mobile Computing, Vol. 2, No. 3, pp. 229-
Engineering Task Force Request for Comments 251 (2002).
(RFC) 2462 (1998). [17]P. Prasithsangaree, P. Krishnamurthy, and P. K.
[5] T. Narten, E. Nordmark, and W. Simpson: Chrysanthis: On Indoor Position Location with
Neighbor Discovery for IP version 6 (IPv6), Wireless LANs, in Proceedings of the 13th
Internet Engineering Task Force Request for IEEE International Symposium on Personal,
Comments (RFC) 2461 (1998). Indoor and Mobile Radio Communications
[6] S. Deering, and R. Hinden: Internet Protocol (PIMRC’02), Vol. 2, pp. 720-724 (2002).
Version 6 (IPv6) Specification, Internet [18]Ekahau Positioning Engine for wireless LAN
Engineering Task Force Request for Comments based navigation, http://www.ekahau.com
(RFC) 2460 (1998). [19]N. Montavont, and T. Noel: Anticipated
[7] J. Postel: Internet Protocol, Internet Handover over IEEE 802.11 Networks, in
Engineering Task Force Request for Comments Proceedings of the IEEE International
(RFC) 791 (1981). Conference on Wireless and Mobile
[8] J. Montavont, E. Ivov, and T. Noel: Analysis of Computing, Networking and Communications
Mobile IPv6 Handovers Optimizations and (WiMob’05), Vol. 2, pp. 64-71(2005).
their Impact on Real-Time Communications, in [20]V. Nuorvala, H. Petander, and A. Tuominen:
Proceedings of the IEEE Wireless Mobile IP for Linux (MIPL), http://mobile-
Communications and Networking Conference ipv6.org
(WCNC’07), pp. 3244-3249 (2007). [21]E. Ivov, and M. Andre: The FMIPv6 Open
[9] A. Mishra, M. Shin, and W. Arbaugh: An Source Implementation Suite, http://fmipv6.org
empirical analysis of the IEEE 802.11 MAC [22]A. Cellerier and Al.: VideoLAN – VLC media
layer handoff process, ACM SIGCOMM player, http://www.videolan.org
Computer Communication Review, Vol. 33, [23]H. Schulzrinne, S. Casnet, R. Frederick, and V.
No. 2, pp. 93-102 (2003). Jacobson: RTP: A Transport Protocol for Real-
[10]International Communication Union (ITU), Time Applications, Internet Engineering Task
Transmission Systems and Media, Force Request for Comments (RFC) 3550
Recommendation G.714: One-way (2003).
Transmission Time (1996). [24]G. Combs and Al.: The Network Protocol
[11]N. Montavont, and T. Noel: Handover Analyser Wireshark, http://wireshark.org
Management for Mobile Nodes in IPv6

Ubiquitous Computing and Communication Journal 10