25-08-2017, 09:32 PM
1453959017-1s2.0S1570870513002357main2.pdf (Size: 1.03 MB / Downloads: 6)
abstract
The IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) standard allows
heavily constrained devices to connect to IPv6 networks. This is an important step towards
the Internet of Things, in which most of the physical objects will be connected to the Internet.
Among them, a large number is likely to be mobile and therefore requires a mobility
management protocol to maintain IP connectivity. Layer 3 mobility is commonly managed
by Mobile IPv6 but this protocol is categorized as too complex for constrained devices in
the literature. Such conclusions are based on simulations or experimentations in which
several aspects of the protocol remain insufficiently detailed nor evaluated. In this article,
we propose a complete evaluation of Mobile IPv6 over 6LoWPAN. For this, we have implemented
Mobile IPv6 in the Contiki operating system and have performed intensive experimentations
on a real testbed. We also propose a new mechanism for movement detection,
as the standard procedure cannot be applied as is. This new mechanism, referred to as
Mobinet, is based on passive overhearings. The results highlight that Mobile IPv6 can be
a practical solution to manage layer 3 mobility on 6LoWPAN.
Introduction
The Internet of Things promises a world of networked
and interconnected devices that provide relevant content
and information whatever the location of the user. In addition
to the well-known access networks (e.g. wifi hotspot,
4G cell), the Internet of Things includes a new kind of networks
known as low power and lossy networks. Such networks
are composed of devices with limited energy
resources, memory and computational power. Recently,
the research community enabled IPv6 connectivity in
those networks by the means of an adaptation layer [1,2].
Such network is referred to as IPv6 over Low-Power Wireless
Personal Area Network (6LoWPAN). Section 2 presents
a brief overview of 6LoWPAN.
Due to the pervasive nature of IP networks, it is likely
that a host will move across different networks, especially
when the Internet of Things will be a reality. Layer 3 mobility
(i.e. moving from one IPv6 network to another) requires
a specific support to enable session continuity. The IETF
standard to manage layer 3 handover is the Mobile IPv6
protocol [3]. This well-known protocol is briefly presented
in Section 3. So far, the literature considers that this protocol
is too complex for low capacity and resource devices
[4,5]. Results obtained so far show that Mobile IPv6 increases
RTT, reduces the throughput and adds a significant
overhead while frame size is already limited in low power
and lossy networks. However, those observations result
from simulations or experimentations in which several aspects
of the protocol remain insufficiently detailed nor
evaluated. In addition, an adaptation of Neighbor Discovery
and Mobile IPv6 for 6LoWPAN are proposed at the IETF
[6,7] but are not considered in the previous evaluations. In
addition, due to the revision of Neighbor Discovery for
6LoWPAN, the movement detection cannot be applied as defined in Mobile IPv6. It is well known that the performance
of Mobile IPv6 is closely tied up with the reactivity
of the movement detection procedure [8].
In this article, we propose a new mechanism for movement
detection, as the standard procedure cannot be applied
as is. This new mechanism, referred to as Mobinet,
is based on passive overhearings and is presented in Section
4. Mobinet is generic and can be used over a large
set of MAC layers. Mobinet was introduced in [9] to passively
identify the neighborhood of a mobile sensor in order
to determine the best neighbor to transmit data. Its
application to movement detection in Mobile IPv6 is therefore
entirely new. Then, we propose a complete experimental
analysis of Mobile IPv6 coupled with Mobinet
over 6LoWPAN. Many previous works in this field, including
some of our own, have been based on results obtained
by simulation and/or emulation. In this document we
chose an entirely empiric approach that we find most suitable
for the present analysis. When evaluating a handover
mechanism, it is particularly important to take into account
the characteristics of wireless communications.
Due to their instability, wireless links may lead to a constantly
changing network topology, making organization
of nodes a very difficult task and endangering MAC and
network layer operations. It is quite delicate (and in most
cases impossible) to do so properly when simulating or
evaluating mobility. Furthermore, many of the reasons
why handover latency occurs in the first place are closely
related to implementation, platform or operating system
specifics that are most often ignored in simulators. This
is even more true considering heavily constrained devices
such as wireless sensors.
Our preliminary work [10] showed that Mobile IPv6 has
no significant impact on both downstream and upstream
transmissions. The present study extends this work and focuses
on the handover delay resulting from each step of the
Mobile IPv6 operations, especially our new movement
detection mechanism. We also evaluate the impact of the
number of hops between the mobile node and its router
on the performance of Mobile IPv6. The details of our Mobile
IPv6 implementation for the Contiki operating system,
experimentation set up and results are presented in Section
5. This work is put into perspective of various proposals
for mobility support available in the literature in
Section 6. Finally, conclusions and future work are presented
in Section 7.
2. IPv6 over low power and lossy networks
6LoWPAN [1,2] is a simple low cost communication
network that allows IPv6 connections over low power
and lossy networks. Each node of the network uses short
range transmission and relies on its neighbors to forward
data towards the destination. 6LoWPAN mainly introduces
a new compression mechanism [1] in order to reduce the
size of the IPv6 header from 40 bytes to a minimum of 2
or 3 bytes. This compression mechanism is referred to as
LOWPAN_IPHC. The idea behind LOWPAN_IPHC is to omit
specific fields of the IPv6 header because those fields could
be retrieved either implicitly (e.g. the version field is always 6) or from other layers (e.g. the length could be
computed from the MAC header). In addition, 6LoWPAN
provides a fragmentation and a reassembly adaptation
layer below IP. Packets that do not fit within a single layer
2 frame shall be broken into link fragments that are multiples
of 8 bytes in length (except the last fragment).
6LoWPAN can rely on an adaptation of Neighbor Discovery
[6] which introduces two actors: the border router
and the router. The border router (6LBR) connects the network
to another IP network (being a 6LowPAN or a standard
IP network) and is responsible for spreading IPv6
prefixes inside the 6LoWPAN network. It also maps
6LoWPAN to IPv6 header and vice versa. The router (6LR)
is an intermediate equipment extending the range of the
network. 6LoWPAN supports two routing mechanisms:
route-over and mesh-under. In a route-over mechanism,
the routing is done at the network layer and thus each
hop inside the 6LoWPAN network is considered as one IP
hop. In such configuration, hosts can only communicate
via routers. By contrast, mesh-under routing enables a
layer 2 routing. As a result, each host is one IP hop away
from the 6LBR regardless the number of layer 2 transmissions
needed to reach the 6LBR. In the rest of this article,
we focus on the mesh-under routing.
3. Mobile IPv6
3.1. Protocol basics
Mobile IPv6 [3] is the IETF standard to manage IPv6
mobility. This protocol uses a relay station to redirect
IPv6 packets destined to or originated from mobile nodes.
This relay station is referred to as the home agent and is
located in the primary (home) network of a mobile node.
While in the home network, a mobile node uses its home
address and would communicate with its peers according
to the standard IPv6 protocol. Once it moves to a visited
network, the mobile node would acquire a new locally valid
care-of address and notify its home agent that its location
changed. The home agent could then start to relay
traffic between the mobile node and its correspondents.
For this, a bidirectional IPv6-in-IPv6 tunnel is established
between the mobile node and its home agent. The mobility
is totally transparent for the correspondents since the mobile
node is always reachable through its home address. To
keep the current location of each mobile node updated, the
home agent maintains a binding cache between the home
address and the care-of address. This cache is updated by
periodically exchanging binding update/binding acknowledgment
messages with mobile nodes.
In conclusion, Mobile IPv6 basic operations consist of
the following steps. First, the mobile node should detect
the arrival in a new IPv6 network. This step is known as
movement detection and is based on the reception of a
new router advertisement. Then, the mobile node can create
a new care-of address and perform a duplicated address
detection procedure to ensure that this address is
unique on the link. Finally, the mobile node registers this
new care-of address to the home agent by the means of
binding update and binding acknowledgment messages
Mobile IPv6 also defines an alternative to bidirectional
tunnel known as route optimization. In this mode, the mobile
node and its correspondents directly communicate
without the help of the home agent. For this, the mobile
node registers its current binding at the correspondents
by exchanging binding update and acknowledgment. Once
the registration with a correspondent is complete, the mobile
node sends its data to this correspondent by using its
care-of address as source address and adding its home address
in a destination option extension header. Similarly,
the correspondent sets the care-of address of the mobile
node as the destination address and adds the home address
in a routing type 2 header. The route optimization mode allows
the shortest communications path to be used between
the mobile node and its correspondents and
reduces the congestion potentially experienced by the
home agent. However, each correspondent is required to
implement additional mechanisms to support the route
optimization of Mobile IPv6. At each handover, the mobile
node is also required to update its bindings at all of its correspondents
which may generate a large control traffic
overhead. Due to those limitations, we only consider bidirectional
tunnel in the following.
Any network protocol should protect itself against misuses
of its features and mechanisms. In Mobile IPv6, binding
updates with the home agent should use an IPsec
Encapsulating Security Payload (ESP) security association
to protect the integrity and authenticity of the binding updates
and acknowledgments. Similarly, the binding updates
with correspondents are secured by the return
routability procedure which ensures that the sender of a
new binding update is reachable through both its home address
and claimed care-of address. Security consideration
in 6LoWPAN is currently investigated by the research community
[11]. However, when IPsec ESP is used, the following headers (i.e. mobility header, inner IPv6 header,
transport header, etc.) are encrypted and as such cannot
be compressed by 6LoWPAN [11]. Resulting packets would
only leave few bytes for data and the overall system is
likely to generate fragmentation. Security consideration
in Mobile IPv6 for 6LowPAN is therefore really challenging
and is part of our ongoing work.
3.2. Mobile IPv6 in 6LoWPAN
Similarly to native IPv6 networks, Mobile IPv6 could be
considered to support layer 3 mobility in 6LoWPAN. Mobile
IPv6 uses native IPv6 features such as header extension and
IP encapsulation that remain compliant with the 6LoWPAN
adaptation layer. However, the frames generally exchanged
over low power and lossy networks have a relatively limited
size (e.g. frame size is limited to 127 bytes in IEEE
802.15.4 [12]). Packet encapsulation used by Mobile IPv6
(when tunneling packets between a mobile node and its
home agent) reduces the frame size left for data and thus
may generate fragmentation. This may be seen as a first
limitation which prevents Mobile IPv6 from being adopted
in 6LoWPAN. However, the compression mechanism introduced
by 6LoWPAN allows the reduction of both IPv6 headers
(inner and outer headers). In addition to IPv6 header
compression, 6LoWPAN also provides the mechanisms to
compress next headers referred to as IPv6 Next Header
Compression (LOWPAN_NHC) [1]. LOWPAN_NHC adds an
additional header of 1 byte in which the first 7 bits serve
as an identifier for the extension header (e.g. IPv6 is referred
to as 119). The remaining bit indicates whether or
not the following header also uses LOWPAN_NHC encoding.
In IPv6-in-IPv6 tunneling, putting the next header flag to 1
in the LOWPAN_IPHC header indicates the use of
LOWPAN_NHC for the inner IPv6 header. The outer IPv6
header is therefore followed by a LOWPAN_NHC header
and the inner IPv6 header encoded using LOWPAN_IPHC.
As presented in Fig. 1, the overall packet header can be reduced
from 80 to 54 bytes thanks to the standard mechanisms
of 6LoWPAN. Nevertheless, the reduction is limited
because the home agent address, the final destination address
and the home address do not belong to the 6LoWPAN
network and as such cannot be compressed. In conclusion,
Mobile IPv6 encapsulation generates fragmentation only
for data greater than 48 bytes. Similarly to IPv6 packets,
the two consecutive 6LoWPAN headers included in tunneled
packets are translated by the 6LBR in two IPv6 headers
(and vice versa).
Mobile IPv6 relies on Neighbor Discovery for movement
detection and care-of address creation. Movement detection
is achieved upon reception of a router advertisement
with a new IPv6 prefix. In IPv6, router advertisements are
sent by routers periodically or by request from hosts
(when a host sends a router solicitation). However, 6LoWPAN
introduces a revision of Neighbor Discovery [6] in
which router advertisements are only sent upon reception
of router solicitation. As a result, a mobile node requires a
mechanism to trigger the transmission of a new router
solicitation in order to perform movement detection. Such
issue is not yet tackled by the research community. By default,
we can use the expiration of the default router lifetime
to trigger the transmission of a router solicitation as
suggested in [10]. However this timer could be set to a
maximal value of 18 h. In the worst case, if a mobile node
moves right after updating the default router lifetime, it
would have to wait for 18 h before performing movement
detection. Unfortunately, such long disconnection cannot
be distinguished from a failure of the mobile node and
may lead to severe underachievements.
Once the movement detection is complete, a mobile
node can configure a new care-of address. Regarding the
revision of Neighbor Discovery [6], the mobile node is not
required to perform a duplicated address detection procedure
but has to register its new care-of address on the
6LBR. This registration only consists in exchanging neighbor
solicitation and neighbor advertisement messages between
the mobile node and the 6LBR. Upon address registration,
the mobile node updates its home agent by exchanging
binding update and binding acknowledgment messages