Computer Communications 112 (2017) 73–92

Contents lists available at ScienceDirect

Computer Communications
journal homepage: www.elsevier.com/locate/comcom

Optimized neighbor discovery for 6LoWPANs: Implementation and

performance evaluation
Mohamed A.M. Seliem a, Khaled M.F. Elsayed b,∗, Ahmed Khattab b
a
The Web of Objects Project, Cairo University, Giza, 12613 Egypt
b
Dept. of Electronics and Communications Engineering, Cairo University, Giza, 12613 Egypt

a r t i c l e i n f o a b s t r a c t

Article history: In this paper, we provide an implementation and thorough performance evaluation of the RFC 6775 opti-
Received 31 May 2016 mized Neighbor Discovery (ND) protocol. RFC 6775 was developed by the Internet Engineering Task Force
Revised 21 August 2017
(IETF) to standardize IPv6 neighbor discovery over Low power Wireless Personal Area Networks (6LoW-
Accepted 22 August 2017
PAN). First, we investigate and analyze the basic RFC 4861 ND, developed for general networks running
Available online 24 August 2017
IPv6. We explain why such a basic ND protocol is inefficient and sometimes impractical for 6LoWPANs.
Index terms: This is because of (i) its heavy use of multicast transmission, and (ii) being originally not designed for
Neighbor discovery IEEE 802.15.4 non-transitive wireless environments in which all nodes are not necessarily within range of
Contiki OS each other. Second, we overview and explain the optimized RFC 6775 ND. Third, we implement such an
Performance evaluation optimized ND on the widely used Contiki OS. Finally, we evaluate the performance of our implementation
RFC 6775 of the optimized ND protocol and compare it with the current RFC 4861-based ND implementation. Our
6LoWPAN
results show that the implementation of the optimized ND protocol reduces the number of the exchanged
control messages in the network by up to 70% compared to RFC 4861-based ND. Moreover, multicast ND
control messages are reduced by 30% to 70%. We show that the RFC 6775 optimizations alleviate network
congestion, enhance the delivery ratio of ND packets to almost 100% and save more power. Even in the
case of variable node reachability, the optimized ND protocol shows a better performance compared to
the RFC 4861 basic ND.
© 2017 Elsevier B.V. All rights reserved.

1. Introduction WPAN (6LoWPAN) working group in 2007 to enable the use of

IPv6 over IEEE 802.15.4 networks [4]. IETF then formed the Routing
The Internet of Things (IoT) is a network of embedded physical Over Low power and Lossy (ROLL) networks working group that
objects that communicate and sense or interact with their environ- developed RPL, the leading IPv6 Routing Protocol for Low power
ment. It is expected that billions of physical objects will be con- and Lossy Networks (LLNs) [5].
nected to the Internet by 2020 [1]. The IoT was initially dependent Neighbor Discovery (ND) is one of the main protocols used with
on proprietary protocols at different layers of the protocol stack. IPv6 to perform functions analogous to the Address Resolution Pro-
Recently, significant efforts have been made towards standardiz- tocol (ARP), router discovery, and router redirect protocols devel-
ing the IoT protocol stack [2]. To enable low-power connectivity oped for IPv4. However, ND provides many improvements over its
among smart objects in IoT systems, the IEEE 802.15.4–2006 low- IPv4 counterparts such as enabling address auto-configuration, re-
power physical (PHY) layer and the IEEE 802.15.4e link layer based moving the need for extra packets exchange to resolve a router’s
on Time Synchronized Channel Hopping (TSCH) have been devel- link-local address and the need for a separate mechanism to con-
oped in 2006 [3]. The Internet Protocol version 6 (IPv6) stands out figure the network mask, advertising the MTU for hosts to assure
as a natural choice due to the huge address space it offers since the same usage of a well-defined MTU value, and improving the
the length of an IPv6 address is 128 bits. However, it is not directly packet delivery ratio by introducing the neighbor unreachability
applicable to the IoT resource-limited systems. Therefore, the Inter- detection mechanism.
net Engineering Task Force (IETF) has formed IPv6 over Low power The ND protocol provides solutions for a wide set of problems
related to the interaction between the nodes attached to the same
link. ND defines mechanisms for achieving the following purposes:
∗
Corresponding author.
router discovery, prefix discovery, parameter discovery, addresses
E-mail addresses: [email protected], [email protected]
(M.A.M. Seliem), [email protected], [email protected] (K.M.F. Elsayed),
auto-configuration, address resolution, neighbor unreachability de-
[email protected] (A. Khattab). tection, and duplicate address detection. ND functions are designed

http://dx.doi.org/10.1016/j.comcom.2017.08.013
0140-3664/© 2017 Elsevier B.V. All rights reserved.
74 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

to allow hosts to ascertain the ownership of an address or the reduction, etc. Furthermore, the draft used for that implementation
mapping between link-layer and IP-layer addresses. Neighbor dis- [12] is obsolete as three later drafts [13,14,15] were released before
covery messages (embedded in ICMPv6 messages) are needed to the final RFC. Our implementation is available on GitHub and in
implement the aforementioned functions. The RPL routing protocol the process of being merged with the Contiki source tree [16].
relies on some mechanisms performed by ND such as the Neigh- Our evaluation shows that for low number of hosts, the opti-
bor Unreachability Detection (NUD) and the ND prefix information mized ND sends around 70% less messages than the basic IPv6 ND
before generating the RPL control packets. protocol. As the number of hosts’ increases, this percentage is ap-
However, IPv6 neighbor discovery in its basic form specified by proximately 25%. Not only a reduction in the transmitted messages
IETF in RFC 4861 [6] was not designed for non-transitive wire- is realized, but also the optimized ND reduces the overhead of the
less environments wherein all nodes are not necessarily able to multicast mechanisms in sending those messages. Nodes multicast
communicate with each other and hidden nodes exist. IPv6 neigh- around 69% less packets compared to the original ND. This percent-
bor discovery specified in RFC 4861 assumes fully connected tra- age becomes 30% when the number of hosts increases. Optimized
ditional IPv6 links and relies heavily on multicasting. This renders ND shows a remarkable (almost 100%) delivery ratio for ND con-
RFC 4861 ND inefficient and sometimes impractical in Low-power trol packet even in the case of sleeping nodes. Even in the lack of
Wireless Personal Area Networks (LoWPAN) and their IPv6 based 100% reachability, our results showed that the optimized ND has a
counterparts known as 6LoWPAN [4]. A 6LoWPAN link [7] is char- significantly better performance compared to the basic ND by us-
acterized as lossy, low-power, low-bit-rate, short-range; with many ing fewer protocol messages while supporting the same functions
nodes attempting to save energy with long sleep periods along with added optimized features.
Thus motivated, IETF developed in 2012 an optimized neigh- The organization of this paper is as follows. In Section 2, we
bor discovery protocol as specified in RFC 6775 [8] that intro- review the related literature. Then, we introduce an overview of
duces the following optimizations to the basic IPv6 neighbor dis- the basic neighbor discovery protocol in Section 3. In Section 4, we
covery RFC 4861 [6]. The RFC 6775 specifically targets low-power present the optimized features defined for ND based on RFC 6775
and lossy networks such as 6LoWPANs through the following op- to handle 6LoWPAN. Then, we review the main components and
timized components: (1) Host-initiated interactions to allow for implementation details of the optimized ND protocol in Section 5.
sleeping hosts, (2) elimination of multicast-based address resolu- The performance evaluation results of our implementation of the
tion for hosts to minimize overhead when considering the limited optimized ND are presented in Section 6. Finally, Section 7 con-
capabilities of 6LoWPANs nodes, (3) a host address registration fea- cludes this paper.
ture using a new option in unicast Neighbor Solicitation (NS) and
Neighbor Advertisement (NA) messages to optimize the interface 2. Related work and literature review
between hosts and their default router, (4) a new neighbor discov-
ery option to distribute 6LoWPAN header compression context to Even though there exists many works analyzing important stan-
hosts as needed by 6LoWPAN header compression [4], (5) multi- dardized efforts for establishing IoT [2,17–20], they lack in-depth
hop distribution of prefix and 6LoWPAN header compression con- analysis of neighbor discovery protocol, upon which RPL routing
text to spread context information and prefix information from the functions are built. The authors of [17] provide an in-depth anal-
border router to all routers in a 6LoWPAN, and (6) multi-hop Du- ysis of the RPL protocol attributes and design choices that gen-
plicate Address Detection (DAD), which uses two new ICMPv6 mes- erate such unreliability issues, then they introduce a new imple-
sage types, to make it suitable for route-over topology. mentation of the RPL standard for the Contiki OS to improve data
In this paper, we explain, implement and evaluate the perfor- delivery reliability and to adopt a flexible cross-layering design
mance of the new ND optimization introduced in RFC 6775.1 We that provides simple routing optimizations, enhanced link estima-
present a detailed study of the original IPv6 ND protocol RFC 4861 tion capabilities and efficient management of neighbor tables. This
and its implementation in the Contiki OS network stack [10]. Then work optimizes route discovery in RPL networks. However, most
we analyze the new optimizations and divide them into distinct of the optimizations done in this work are already incorporated in
well-defined components. However, the main contribution of this the optimized ND protocol. In [18], RPL used trickle algorithm to
work is the implementation and subsequent evaluation of the op- control the DIO packets transmissions to detect neighbor unreach-
timized RFC 6775 ND protocol in Contiki OS. Our implementation ability and to discover new neighbors. Instead, RPL could use the
focuses on the most important and beneficial optimizations which optimized ND algorithm. This will reduce the responsiveness of the
are the host initiated interactions, the elimination of the effect of protocol and decrease overhead in terms of the number of packet
multicast, and the enhanced host address registration mechanism. exchanges, as we discuss later in this paper.
Finally, we perform an extensive set of experiments to evaluate the In [19], the authors review and classify the state-of-the-art of
reduction in the number of ND exchanged messages (NS, NA, RS, mobility management protocols in 6LoWPAN networks. The au-
and RA) and their performance implications. thors state clearly that neighbor discovery protocol can be used to
We believe that our ND implementation is the first complete ensure the movement detection. However, the periodic transmis-
implementation of RFC 6775, unlike the only available prior ND sion of messages affects the signaling cost in 6LoWPANs, which
implementation presented in [11] which implements one of the suggests other methods for the movement detection. However,
RFC 6775 drafts [12]. The work of [11] only outlines a methodology most of these issues are solved and incorporated in the optimized
for implementing neighbor discovery without actually implement- ND protocol. The authors of [20] provide fast and reliable mobility
ing many of the main ND optimization components such as ad- management framework in RPL, based on integrating a hand-off
dress registration, periodic RA, substitutable feature and multicast mechanisms without changing the standardized RPL. However, the
proposed framework does not solve the issue of discovering new
nodes or maintaining the route table status, which can be over-
1
In [9], we have presented the preliminary results of only optimizing the Router come through implementing the optimized ND protocol.
Solicitation (RS) and Router Advertisement (RA) part of RFC 6775 in single-hop sce- The work in [21] and [22] provide an important architecture of
narios. In this paper, we present the complete optimized ND based on RFC 6775 the end-to-end communication system based on 6LoWPAN gate-
which also includes the more important optimization of Neighbor Solicitation (NS)
and Neighbor Advertisement (NA) as well as substitutable features added in the
way. The proposed architecture consists of sensor nodes, routers,
RFC. Furthermore, we study multi-hop scenarios and the interaction between ND 6LoWPAN border routers (6LBRs), a resource management platform
and routing. and several IoT applications. A new address configuration method
 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 75

based on this architecture was proposed alongside a basic process

for interaction during neighbor discovery. Furthermore, a context
management and distribution strategy was developed to expand
6LoWPAN domain. A network control solution for 6LoWPANs was
proposed in [23] to prevent unauthorized nodes from using the
network to communicate either with the legitimate nodes or with
the Internet. This results in reducing the security attacks that can
be performed. The proposed solution can benefit from optimized
ND in minimizing the number of additional required control mes-
sages which leads to decreasing the overhead due to control traffic.
Consequently, it is crucial to implement the optimized 6LoW-
PAN ND protocol to minimize control traffic overheads, to assist
the RPL protocol in detecting movement change and to ensure
energy efficiency. This motivated us to have a dedicated work to
present the first complete implementation and performance eval-
uation of the optimized neighbor discovery protocol (over Contiki
OS).
Finally, it is worth mentioning that there exist few related
works that tackled the neighbor discovery problem in ad-hoc net-
work rather than IoT networks. Examples include the work pre-
sented in [24] which provides a general model to study and an-
Fig. 1. ICMPv6 headers for NS/NA messages.
alyze discovery protocols in ad hoc single broadcast channel net-
works. Using this model, the authors have described and com-
pared various discovery protocols. However, the models as well
as the studied protocols do not consider the energy consumption.
In [25], authors have extended their model to the case of ad hoc
multi-channel broadcast networks. In [26], authors have proposed
a polling-based MAC protocol that addresses the problem of neigh-
bor discovery with directional antennas. In [27], authors have stud-
ied the problem of neighbor discovery in static wireless ad hoc
networks with directional antennas. The authors in [28] propose
a complete evaluation of the stateless address auto-configuration
in LLNs. The proposed analysis is based on neighbor discovery op-
timizations especially designed for LLNs.

3. RFC 4861−basic neighbor discovery protocol

ND is a protocol in the Internet protocol suite that is used with

IPv6. ND operates in the link layer of the Internet protocol suite
and is responsible for address auto-configuration of nodes, address
prefix discovery, discovery of other nodes on the link, determin-
ing the link layer addresses of other nodes, duplicate address de-
tection, finding available routers and domain name system (DNS) Fig. 2. ICMPv6 headers for RA/RS messages.
servers, and maintaining the reachability information of the paths
to other active neighbors. In this section, we overview the basic
IPv6 ND protocol routers to generate router advertisements immediately rather
than at their next scheduled time.
3.1. Basic RFC 4861 ND messages and headers 4) Router Advertisement (RA) (Fig. 2b): Routers advertise their
presence together with various link and Internet parameters ei-
The basic IPv6 neighbor discovery protocol defines five differ- ther periodically, or in response to a Router solicitation mes-
ent ICMPv6 packet types to perform its functions. Basically a pair sage. Router advertisements contain prefixes that are used for
of router solicitation/advertisement (RS/RA) messages is used in determining whether another address shares the same link (on-
router-to-host messaging and dynamic address allocation, while link determination) and/or address configuration, a hop limit
a pair of neighbor solicitation/advertisement (NS/NA) messages is value, etc.
used in node-to-node messaging. Finally, the redirect message is 5) Redirect: A message that is used by the routers to inform hosts
used in next hop determination. of a better first hop towards a destination.
1) Neighbor Solicitation (NS) (Fig. 1a): Sent by a node to deter- Neighbor discovery messages, shown in Fig. 1 and Fig. 2, may
mine the link-layer address of a neighbor, or to verify that include some options – if needed – from a set of options. Some of
a neighbor is still reachable via a cached link-layer address. these options may appear multiple times in the same message:
Neighbor solicitations are also used for duplicate address de-
tection (DAD) and neighbor unreachability detection (NUD). • Source Link-Layer Address Option (SLLAO): contains the link-
2) Neighbor Advertisement (NA) (Fig. 1b): This is the response to layer address of the sender of the packet. It is used in the NS,
the NS message. A node may also send unsolicited neighbor ad- RS, and RA messages.
vertisements to announce link-layer address changes. • Target Link-Layer Address Option (TLLAO): contains the link-
3) Router Solicitation (RS) (Fig. 2a): When an interface becomes layer address of the target. It is used in NA and Redirect mes-
enabled, hosts may send out router solicitations that request sages.
76 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

• Prefix Information Option (PIO): provides hosts with on-link 3.3. Basic RFC 4861 ND conceptual data structure of a host
prefixes and prefixes for address auto-configuration. The PIO
appears in Router Advertisement messages. Hosts will need to maintain the following data structures for
• Redirected Header: is used in Redirect messages and contains each interface [30]:
all or part of the packet that is being redirected.
• The MTU Option: is used in Router Advertisement messages to 1) Neighbor cache: It is a set of entries about the individual
ensure that all nodes on a link use the same MTU value when neighbors to which traffic has been recently sent. Entries are
the link MTU is unknown. keyed on the neighbor’s on-link unicast IP address and con-
• Managed address configuration (M flag): If the M flag is set, it tain such information as its link-layer address, a flag indicat-
indicates that addresses are available via Dynamic Host Config- ing whether the neighbor is a router or a host, a pointer to
uration Protocol (DHCPv6). Otherwise, the address can be con- any queued packets waiting for address resolution to complete.
figured by any other means (software configured). A neighbor cache entry also contains the information used
• On-Link flag (L flag): When set, it indicates that this prefix can by the neighbor unreachability detection algorithm, including
be used for on-link determination. the reachability state (INCOMPLETE, REACHABLE, STALE, DELAY,
PROBE), the number of unanswered probes, and the time at
which the next NUD event is scheduled.
3.2. Basic RFC 4861 ND functions 2) Default router list: It is a list of routers to which packets
may be sent. The algorithm for selecting a default router favors
Here, we describe the neighbor discovery functions (dynamic routers known to be reachable over those whose reachability is
address allocation, address resolution, NUD, etc.). suspicious. Each entry also has an associated invalidation timer
IPv6 dynamic address allocation: IPv6 dynamic address allo- value (extracted from RA messages) used to delete the entries
cation is slightly different from its IPv4 counterpart. In IPv4, a that are no longer advertised.
host that is configured to obtain its address automatically requests 3) Prefix list: It is a list of prefixes that defines a set of addresses
the IPv4 addressing information directly from a DHCPv4 server. that are on-link. Prefix List entries are created from the in-
Then, the DHCPv4 server responds with all the required informa- formation received in RA messages. Each entry has an asso-
tion (IPv4 address, subnet mask, default gateway, and DNS servers). ciated invalidation timer value (extracted from the advertise-
However, a host in IPv6 sends a multicast router solicitation mes- ment) used to expire prefixes when they become invalid.
sage to locate routers that are capable of providing it with the For the interested reader, the finite state machine (FSM) of the
network address information. A router responds to this RS mes- basic ND based on RFC 4861, when performing address resolution
sage with a multicast router advertisement message. This RA mes- and neighbor unreachability detection using the above states and
sage informs the host how to obtain or create its IPv6 address. by applying the mentioned model of the data structure, and the
For example, routers can specify whether hosts should use DHCPv6 events that lead to state changes and the transitions taken in case
and/or autonomous stateless address configuration. When the host of each event are explained in [31] since the focus of this paper is
receives RA messages from different routers, it starts building a the optimized ND which is next explained in full detail.
list of default routers. These RA messages contain the informa-
tion about the network parameters such as the hop limits, the
link parameters such as the link MTU, and the prefix-related in- 4. RFC 6775−optimized neighbor discovery protocol
formation. The host uses these prefixes to build a list that is
used later to determine the neighbors residing on-link with this In this section, we describe the new features added by the op-
host. timized ND protocol according to RFC 6775. Then, we explain the
IPv6 address resolution: Address resolution in IPv6 is similar change in the transmission of control messages of the optimized
to ARP in IPv4. However, in IPv6 nodes use neighbor discovery ND protocol and their modified functions along with clarifying the
NS/NA messages to obtain the link local address of their neighbors. new protocol functions (e.g. registration).
First, nodes multicast NS messages that contain their link local ad-
dress to ask the target node to return its link local address (LLA). 4.1. Optimized neighbor discovery
Then, the target node responds with a unicast NA messages with
its LLA. Nodes use the LLAs of neighbors to build or maintain a 6LoWPAN is an adaptation layer to carry IPv6 packets over IEEE
neighbor cache list of the neighbors to which traffic has been sent 802.15.4 frames. Basic IPv6 ND (RFC 4861) was developed for wired
recently. traffic on the shared medium, and it uses periodic RA messages
IPv6 duplicate address detection: NS/NA messages are also for multicast addresses to find hosts by assuming that a subnet
used for Duplicate Address Detection (DAD) if more than one node prefix maps to one broadcast domain. While periodic multicast
has been assigned the same unicast address. DAD differs from ad- signaling is useful for network stability in the standard Ethernet-
dress resolution as the source address of the NS message will be based shared network, the limited-lifetime, battery-operated 6Low-
unspecified by setting it to zero. In the case of duplication, the PAN devices in IEEE 802.15.4 networks conserve energy by using
node that has the address responds with a multicast NA mes- less signaling and by sending broadcast messages only once in a
sage. As the NS sender does not use the desired IP address, it while. Recall that IEEE 802.15.4 supports broadcast at the link layer
cannot receive unicast messages. DAD is specified in RFC 4862 but does not specify multicast support. The multicast messages in
[29]. the IPv6 ND are hence translated to broadcast messages in 6Low-
IPv6 neighbor unreachability detection: Neighbor Unreach- PAN networks. Consequently, RFC 4861 based ND that extensively
ability Detection (NUD) is one of the main functions in IPv6 uses multicast is not desirable in wireless low-power and lossy
neighbor discovery. It is used to actively keep track of changes networks.
in neighbors. Then, it updates the status of these neighbors Several optimizations and extensions to neighbor discovery
stored in the neighbor cache. A node sends unicast NS mes- were needed for the wide deployment of IPv6 in such low-power
sages that solicit NA as reachability confirmation. The NUD pro- and lossy networks. The importance of these optimizations comes
cess is used with neighbors to whom the node is actively sending from the interactions between hosts and routers, which are not af-
packets. fected by the configuration of 6LoWPAN. As all ND messages are
 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 77

and route-over (which places all routing functions at the IP layer

with every physical hop appearing as an IP hop) [32,33].

4.2. Optimized ND functions

The optimized ND protocol inherits all the functions defined is

RFC 4861 based ND protocol such as: router discovery, prefix dis-
covery, duplicate address detection, address resolution, and neigh-
bor unreachability detection. However, some of these functions are
entirely changed and others are just slightly modified to make ND
efficient and suitable for 6LoWPAN networks. Moreover, the opti-
mized ND protocol proposes some new functions such as: the ad-
dress registration process and the distribution of context informa-
tion over the network. In what follows, we discuss these new and
modified functions.
Address registration process: This is the process during which
a host node sends NS message with an address registration option
to a router creating a neighbor cache entry for the host with a spe-
cific timeout. This will allow hosts to sleep and reduce the usage
of multicast signaling. In the registration process response, a router
sends an NA message with ARO containing the status field. A host
processes the ARO to determine the result of the registration pro-
cess, which will be one of the following: Status = 0 indicates the
success of the registration process; Status = 1, indicates a duplicate
address detected; while status = 2 indicates the router cache is full.
Moreover, the registration process is combined with the NUD pro-
cess to reduce the usage of ND messages.
Fig. 3. The new optional headers of the optimized ND protocol.
Address re-registration process: This process is considered as
a sub-function of the registration process, which happens when a
initiated by the hosts, the hosts are allowed to sleep and avoid us- host needs to re-register with a router before the registration life-
ing multicast ND messages except when necessary. The optimiza- time expires. Re-registration is important even if the host does not
tion of ND protocol adds new optional headers to be used in the have data to send, as other nodes might try to send packets to the
ND messages. These new headers will be helpful in implementing host. In all cases, when a host knows it will no longer use a router
the new features of ND protocol over 6LoWPAN Networks. it is registered to, it should unregister with the router by sending
an NS message with an ARO containing a zero lifetime.
• Address Registration Optional (ARO) Header (Fig. 3a): this is Prefix and context information distribution: Hosts send RS
used to represent the main structure for the address registra- messages to solicit information about the network from neighbor-
tion optional header. ARO is introduced since routers need to ing routers. RS message must include the SLLAO of the host to en-
know the set of host IP addresses that are directly reachable able unicast RA messages in response. Hosts process the RA mes-
and their corresponding link-layer addresses. sage to extract the data received from the router, and then each
• 6LoWPAN Context Optional (6CO) Header (Fig. 3b): this is used host maintains the context information data in the context table,
to represent the main structure for the 6LoWPAN Context Op- and maintains the prefixes information in the prefix list. Hosts use
tional header. The 6LoWPAN Context Option (6CO) carries pre- the information in the 6LoWPAN context table for the decompres-
fix information for 6LoWPAN header compression and is similar sion process when receiving packets. A 6CO header received in an
to the prefix information option (PIO). RA message is used to add or update the information in the con-
• Authoritative Border Router Optional (ABRO) Header (Fig. 3c): text table. If the context identifier field matches one of the entries
this is needed when RA messages are used to disseminate pre- in the existing context table, then that entry is updated with the
fixes and context information across a route-over topology. information in the 6CO.
In addition to these new functions, some ND functions have
The optimized ND protocol is designed such that the host to modified behaviors such as:
router interaction is not affected by the configuration of the 6LoW-
PAN. The new optimized protocol functions are: host initialization Network parameter discovery: No need for periodic multicast
of the interaction with the router, neighbor unreachability detec- of RA messages. Only unicast RA messages are used to dis-
tion, address registration process, and the use of solicited unicast tribute the network information in response to RS messages
RA messages. Furthermore, there are parts of the ND optimization sent by the host. This will reduce the periodic multicast sig-
that can be substituted with a routing protocol such as multi-hop naling in the network. Note that multicast is still used at the
distribution of prefix and 6LoWPAN header compression context, beginning of interface initialization.
and multi-hop duplicate address detection. Thus, if substitution is Address resolution: Address resolution is not needed, as the
intended then multi-hop prefix distribution (the ABRO) and the address registration process and the SLLAO within the ex-
6LoWPAN Context Option (6CO) for distributing header compres- changed messages provide sufficient information to resolve
sion must be substituted (RFC 6775 [8] section 1.4). Applying the an IPv6 address. This will prevent transmitting multicast NS
optimized ND protocol over 6LoWPAN will minimize signaling, re- messages to resolve IPv6 address.
duce the use of multicast messages, and support sleeping hosts. Duplicate address detection: Nodes do not need to separately
The optimized neighbor discovery is also designed to operate suc- perform the DAD function. In the optimized ND protocol,
cessfully in both mesh- under (which places routing function at DAD is a part of the address registration process. This will
the link layer to maintain the deterministic link characteristics) reduce the number of exchanged NS/ NA messages.
78 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

Fig. 4. Basic Router Solicitation/Router Advertisement Exchange between hosts and Fig. 5. Neighbor Discovery Address Registration.
router.

the router must delete the cache entry. Any changes in registered
Neighbor unreachability detection: The NUD algorithm used NCEs would result in notifying the routing protocol. Routers should
in the optimized ND is similar to the NUD algorithm used not send redirect messages, because a router cannot tell whether
in RFC 4861 based ND protocol. However, the NS/NA mes- the host can reach the redirected to- target or not. Exceptionally,
sage pair, responsible for checking reachability, also carries redirect messages are sent.
the ARO to do the registration or un-registration processes. This optimizes the interfaces between hosts and their default
The combined NUD and registration process enables new or- routers and provides support for sleeping hosts, and removes the
thogonal registration states with a new FSM. The new states need for routers to use multicast NS to find hosts and allows for
for the registration process (registered, tentative, etc.) are in- the support of sleeping hosts. An implementation that adheres to
dependent of the reachability states (reachable, stale, etc.). RFC 6775 must implement these behaviors.
For example, a host can be “unreachable” at a certain mo-
ment but still be in the “registered” state at its router as its 5. Optimized neighbor discovery: behavior analysis and
registration lifetime has not expired, or a host can be “reach- implementation
able” but needs to unregister with the default router.
In this section, we present the main contributions of this work
4.3. Optimized ND operation which is the analysis, design, implementation and deployment of
the optimized ND protocol over Contiki OS. First, we develop and
The optimized ND protocol has two main components. The first analyze the optimized ND finite state machine. Then, we explain
component handles the RS/RA message pair as shown in Fig. 4. It the behavior of hosts and routers that implements the optimized
targets minimizing the overhead by avoiding the use of multicast ND protocol. We also investigate applying such optimized proto-
flooding, and reducing the use of link-scope multicast messages. col in multi-hop networks. Finally, we summarize the main com-
The router’s behavior is slightly different than its counterpart in ponents of our implementation of the optimized ND protocol in
RFC 4861 ND. In the optimized ND, the router does not send pe- Contiki OS.
riodic RA messages. Instead, it only responds with an RA message
upon receiving an RS message. A router processes the RS messages 5.1. Optimized ND finite state machine
as specified in RFC 4861. A router must check the source of the
solicitation message, as it might be from a host that has not yet The features added to the optimized ND protocol will lead to a
registered its address. In this case, the router may create a ten- new finite state machine (FSM). The new ND FSM is different from
tative NCE based on the SLLAO included in the RS message, then the old ND FSM (please see [31]) as it takes into consideration the
the router waits for the host to register its address for TENTA- following changes:
TIVE_NCE_LIFETIME seconds, if this timer times out, then the NCEs First, the optimized neighbor discovery prevents hosts from
will become garbage collectable. Routers must not set the L flag sending multicast NS messages. Hosts in a 6LoWPAN use the ARO
in the PIOs attached to the transmitted RAs, to prevent hosts from in the NS messages they send as a way to maintain the neigh-
transmitting multicast NS messages. bor cache in the routers, thereby removing the need for multicast
The second component handles the NS/NA messages as shown NSs to do address resolution. Unlike RFC 4861, the hosts initiate
in Fig. 5. When a router receives an NS message, it will be pro- updating the information they receive in RA messages by send-
cessed as specified in RFC 4861. However, it must also process the ing RS messages before the information expires. However, when
new attached ARO header. First, the routers validate the received NUD indicates that one or all of the default routers have become
NS message and its options. The routers check the validation of the unreachable, the host uses RS messages to find a new set of de-
ARO header as follow: if the source address of the NS is an unspec- fault routers. Therefore, hosts do not need to join the solicited-
ified address, or if no SLLAO is included in the NS message, then node multicast address, since nobody multicasts NSs in this type
any included ARO is invalid and must be ignored. Consequently, of network.
the NS is processed as if it did not contain an ARO. In the case Second, the hosts need to intelligently retransmit RS messages
of the NS message has a valid ARO, the router checks its neighbor whenever the default router list is empty, one of its default routers
cache for duplication. If the ARO did not result in a duplicate ad- becomes unreachable, or the lifetime of the prefixes and contexts
dress, then if the registration lifetime is non-zero the router creates in the previous RA are about to expire. This is because hosts do
or updates an NCE for the IPv6 source address of the NS. However, not depend on multicast RA messages to discover routers.
if ARO contains a zero Registration Lifetime, then any existing NCE Third, address auto-configuration depends on the managed ad-
for the IPv6 source address of the NS must be deleted and an NA dress configuration (M) flag. If the M flag is set, it indicates that
is sent. Also, if the Registration Lifetime in an NCE expires, then addresses are available via Dynamic Host Configuration Protocol
 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 79

Table 1
Events and actions of the registration process FSM.

Name Event Action

U1 Registration timer Expired, Registration in progress, Max no. of Delete the default router; all registrations with that router must be deleted.
retransmissions.
U2 Registration timer Expired, Registration in progress, Less than max no. of Reset Registration timer, Retransmit NS message.
retransmissions.
U3 Received NA, Status= success. Registration process succeeded, update NCE.
U4 Host does not need router(e.g. Router lifetime about to expired) Transmit NS message with an ARO containing a lifetime of 0.
U5 Transmitted RS/Received RA. First interaction with the router. Tentative NCE for the Router. Start the registration process by transmitting
NS message.
U6 Received RA. Router already registered. Garbage Collectable NCEs, as there can only be one kind of NCE for an IP
address at a time.

NCEs for an IP address at a time (router’s NCEs or host’s NCEs).

Table 1 specifies the events and the actions that explain the above
FSM.

5.2. Host behavior in the optimized ND protocol

We demonstrate the behavior of a host node that uses the opti-

mized ND protocol. Code 1 summarizes the sequence of the promi-
nent processes performed by the host. First, a host obtains a link-
layer to assign a link-local IPv6 address to itself. A link-local IPv6
address is configured based on the host’s EUI-64 link-layer address.
The host determines one or more default routers in the net-
work by sending an RS message to the all-routers multicast ad-
dress with the SLLAO set to its link-local address. If the host is
able to obtain the link-layer address of a router through its link-
layer operations, then the host may form a link-local destination
IPv6 address for the router and send it a unicast RS. A host should
inspect the various lifetimes to determine when it should next
Fig. 6. Registration process FSM of the optimized ND protocol. send an RS to ask for any updates to the information. The life-
times that matters are the Default Router Lifetime and the Valid
Lifetime in the PIO. The host sends one or more unicast RS mes-
(DHCPv6). If the M flag is not set, that means that the address is sage to the router well before the shortest of those lifetimes ex-
not configured by DHCPv6, and hence, duplicate address detection pires and then switches to multicast RS messages if there is no
need to be performed. However, unlike in RFC 4861, DAD will be response to the unicasts. Since hosts do not depend on multicast
performed as part of the registration process. RAs to discover routers, the hosts need to retransmit the RS mes-
Finally, the neighbor cache entries (NCEs) will be managed dif- sage. The retransmission rate is to initially set to send up to 3
ferently from RFC 4861 ND. This will result in three different types (MAX_RTR_SOLICITATIONS) RS messages separated by at least 10
of NCEs which also specify how those entries can be removed: seconds (RTR_SOLICITATION_INTERVAL) as specified in RFC 4861,
• Idle state (OS0): No entry is created, as no interaction happened and then is switched to a slower retransmission rate. After the ini-
yet. tial retransmissions, the host should do truncated binary exponen-
• Registered (OS1): Entries that have an explicit registered life- tial back-off of the retransmission timer for each subsequent re-
time and are kept until this lifetime expires or they are explic- transmission, truncating the increase of the retransmission timer at
itly unregistered. 60 seconds (MAX_RTR_SOLICITATION_INTERVAL). In all cases, the
• Garbage collectable (OS2): Entries that are subject to the nor- RS retransmissions are terminated when a router responds with a
mal rules of cache management related to ND and address res- unicast RA to the IP source address using the SLLAO from the RS
olution functions in RFC 4861, that allow for garbage collection after creating a tentative NCE.
when low on memory. The processing of RA messages is as in RFC 4861 in addition to
• Tentative (OS3): Entries that are temporary with a short life- handling the new features and triggering address registration when
time, and are typically get converted to “Registered” entries. a new address has been configured. Furthermore, the SLLAO must
• To be unregistered (OS4): Auxiliary registration entry state. be included in the RA. Unlike RFC 4861 Section 6 that limits the
timer value to 90 0 0 seconds, the optimized ND allows the max-
These NCE types are orthogonal to the states, used for NUD pro- imum value of Router Lifetime field to be up to 0xFFFF seconds,
cess, specified in RFC 4861. Fig. 6 shows the relation between the which is the largest value of the 16- bit router lifetime size.
types of NCEs, referred to as OS0, OS1, OS2, OS3, OS4, respectively. Next, the host registers its address with one or more of its de-
The transition between the four states can be explained as follows: fault routers by sending a unicast NS message with an ARO con-
When a router receives RS message from a host, it creates a taining its tentative global IPv6 address to register, the Registra-
tentative NCE for this host. A registered NCE is created once a tion Lifetime, and its EUI-64. An SLLAO is also included with the
router has a node successfully registered with it. When a router link-layer address corresponding to the address being registered.
changes its status from a router that sends RAs to a host that If a successful NA message (Status 0) is received, the address can
receives RA messages or receives multicast NS messages, the re- then be used, and the host assumes that it has been successfully
sult is garbage collectable NCEs. There can be only one type of checked for duplicates.
80 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

Code 1
Pseudo-code for host behavior in optimized ND protocol.

The address registration procedure may fail for two reasons: message (Status 2) is received, the host attempts to register with
when no response to NS messages is received (NUD failure), or an another default router.
ARO with a failure Status (Status > 0) is received. In the case of The host needs to perform maintenance by sending a new NS
NUD failure, the entry for that router will be removed. Thus, ad- address registration before the lifetime expires. A host handles NA
dress registration is no longer of importance. If a duplicate address messages as specified in RFC 4861, with added logic described in
(Status 1) NA message is received, the host removes the tempo- this section for handling the ARO. In addition to the normal vali-
rary IPv6 address. Moreover, if the host has valid registrations with dation of an NA and its options, the ARO is verified as follows. If
other routers, these must be removed by registering with each of the length field is not equal to two, the option is silently ignored.
these routers using a zero ARO lifetime. If a neighbor cache full If the EUI-64 field does not match the EUI-64 of the interface, the
 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 81

option is silently ignored. The router’s behavior is slightly different

than its counterpart in RFC 4861 ND protocol and is available in
[31] for interested readers.

5.3. Router behavior in the optimized ND protocol

We demonstrate the behavior of a router node that uses the

optimized ND protocol, which will be different than its counterpart
in RFC 4861 ND protocol. In optimized ND, routers perform the
following functions:

1. Construct/update network data structure containing informa-

tion about neighbors, which is used to construct routing tables.
2. Update neighbors with information about the network parame-
ters and prefix configuration.
3. Checking for duplicates
4. Returning address registration errors
5. Next hop determination
6. Address resolution between routers

First, we explain how the router node handles the received ND

control messages (NS, NA, RS, and RA). Then, we discuss how the
router node triggers an action using one of the ND control mes-
sages. Finally, we explain the overall behavior of a router node.

1. A router node receives NS message from hosts and routers:

Fig. 7. Optimized ND interaction between nodes (hosts or 6LRs) and 6LBR.
a. A host: In this case, the router processes the message as fol-
lows: 1) it validates the received NS message and its op-
tions. A message will be discarded if the source address Routers must not set the L flag in the PIOs attached to RA mes-
of the NS is an unspecified address, or the message does sages in order to prevent hosts from transmitting multicast NS.
not include SLLAO, and consequently, the successive optional 4. A Router node receives RA messages only from another router
header will be ignored. 2) When the NS message contains to get information about network parameters.
valid optional SLLAO, ARO headers, the router checks its
neighbor cache for duplication. In case of no duplication, it
checks the registration lifetime field in the ARO. If the reg- 5.4. 6LoWPAN border router (6LBR) behavior for multiple hop
istration lifetime has a non-zero value, then the router cre- networks
ates or updates an NCE for the IPv6 source address of the
NS. However, if the ARO contains a zero registration lifetime, The optimized neighbor discovery protocol introduces two
any existing NCE for the IPv6 source address of the NS must types of routers, which are known as the 6LoWPAN border router
be deleted. (6LBR) and the 6LoWPAN router (6LR). The 6LBR is used to connect
b. A router: In this case, the router processes the message as a 6LoWPAN network to another IP network. 6LBR is mainly respon-
specified in RFC 4861. sible for spreading the IPv6 prefixes inside the 6LoWPAN. However,
Generally, router node responds to the valid NS message with the 6LR is an intermediate node that extends the range of the net-
a valid NA message. The NA response must contain information work. Consequently, the optimized ND suggests two topologies for
that will satisfy the purpose of received NS (e.g. NUD, DAD, ad- interconnecting hosts and routers. In the mesh-under topology, the
dress resolution). hosts are connected to a 6LBR through a mesh using link-layer for-
warding. Each host is therefore one IP hop away from the 6LBR
2. A Router node receives NA messages (only from other routers) regardless of the number of layer 2 transmissions needed to reach
in response to NS messages. The router is responsible for check- the 6LBR. In other words, this topology simulates the traditional
ing reachability, detecting duplicate addresses, and performing IP subnet topology with one router and multiple hosts in the same
address resolution. subnet. By contrast, the route-over topology has hosts directly con-
3. A Router node receives RS message from either router or host nected to routers (either 6LR or 6LBR). Each link is considered as
nodes: an IP hop and packets are transmitted using IP routing. In this
a. If received from a host, the router must check the source topology, router-to-router interaction is applied wherever 6LRs are
of the solicitation message, as it might be from a host that present. During system start up or at interface initialization, 6LRs
has not yet registered its address. In this case, the router are expected to initially behave like normal hosts by sending RS
may create a tentative NCE based on the SLLAO included in to 6LBR to obtain network parameters and auto-configuring their
the RS message, and then the router waits for the host to IPv6 addresses. Unlike the basic ND, only hosts transmit RS mes-
register its address for TENTATIVE_NCE_LIFETIME seconds. If sages while routers are responsible for sending RA messages. Fig. 7
this timer expires, then the NCEs will become garbage col- briefly describes the interaction steps between nodes in the route-
lectable. over topology as follows.
b. If received from a router, it will be processed as specified in
RFC 4861. 1) Node (A) forms the source link local address option by generat-
Generally, router node responds to the valid RS message with a ing LLA via the link layer EUI-64.
valid RA message. The RA response contains the network pa- 2) Node (A) multicast RS message carrying SLLAO option to ac-
rameters, prefix information, and the 6LoWPAN compression quire the routers’ LLAs, prefix information, and network param-
information to be spread among all of the network nodes. eters.
82 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

In case of network initialization, multicast RS is used to get in- 5.5. Implementation of the optimized ND in the Contiki OS
formation from neighbor routers (router discovery). However, in environment
subsequent communication processes, a unicast RS message is
sent to update the previously acquired information. This uni- We implement the new functions of optimized ND protocol, ac-
cast message transmission is triggered by approaching the valid cording to RFC 6775. The main guidelines of our implementation
lifetime of the information (prefix, context), or by approaching can be summarized as follows:
the router reachable time.
3) Node (B) receives the RS message and responds with a unicast 1- Optimized ND features for hosts:
RA message carrying SLLAO, 6CO, PIO, and ABRO. o Host-initiated RA: We removed the function that imple-
4) Node A only receives the prefix and context that is not only ments the transmission of unsolicited (periodic) RA mes-
consistent with the default ABRO message but also sent by the sages, and updated the function [SEND_RA_SOLICITED ()] to
border router. The prefix denotes the prefix of the 6LoWPAN allow hosts to initiate RA refreshment.
domain and is carried by the PIO option. The context message o Supporting two addressing modes (EUI-64-based IPv6 ad-
carries the prefix for address compression. If the IPv6 host (C) is dress, 16-bit MAC-based address): In our implementation,
from the external network, then the RA message may carry the we restrictively use the (M)anaged address configuration
prefix (i.e. context(C)) of the network where the host C is lo- flag as explained earlier.
cated. Therefore, an RA message can carry several 6CO options o Host-initiated RS: We added the timer [uip_ds6_timer_rs] to
simultaneously. schedule RS sending according to Section 4.2.
5) Node (A) creates a temporal global unique IPv6 address (Net- o Processing ABRO header: We added the [uip_nd6_opt_ABRO]
work prefix+ EUI-64). structure to hold the information contained in the ABRO
6) Node (A) registers the address, checks duplicity, and checks Header. This header is used in RFC 6775 to disseminate pre-
reachability by sending the ARO option in the NS message to fixes and context information across a route-over topology.
the 6LBR, o Registration with ARO header: We added the
7) Node (B) records Node (A) IP and checks its neighbor cache ta- [uip_nd6_opt_ARO] structure to hold the information
ble. If the table is not full and no similar address is in the table, contained in the ARO Header. This header is used in RFC
a new item is added to the neighbor cache table and makes a 6775 to maintain the set of host IP addresses that are di-
reply to the successfully registered ARO option via the NA mes- rectly reachable by a default router and their corresponding
sage. Otherwise, a reply to the ARO option that fails in registra- link-layer addresses in this default router.
tion is sent. o Processing 6CO header: We added the [uip_nd6_opt_6CO]
structure to hold the information contained in the 6CO
Header. This header is used in RFC 6775 to carry the pre-
Next, we explain the optimized ND behavior for router to router
fix information for LoWPAN header compression. The 6CO
interaction in a multihop scenario. We consider a topology of one
header is similar to the PIO header in RFC 4861 based ND.
border router node (A) and two 6LR nodes (Node B and Node C).
o Hosts join all-nodes multicast address, and do not join
We assume that router node (C) reaches the border router (A)
solicited-node multicast address, as no nodes multicast NS
through the router Node (B).
message in 6LoWPANs.
2- Optimized ND features for 6LRs:
1) During system start-up, Node (B) acts as a host by sending o Routers do not transmit periodic RA messages: This is im-
RS to 6LBR Node (A) to obtain network parameters and auto- plemented to assure that only hosts initiate RA refreshment.
configure its IPv6 addresses. o Supporting two addressing modes (EUI-64-based IPv6 ad-
2) Node (B) stores the ABRO, 6CO, and prefix information received dress, 16-bit MAC-based address): Unlike routers in RFC
directly from the 6LBR Node (A). 4861, 6LRs MUST act like a host during system start-up and
3) Node (B) redistributes this information by sending an RA mes- prefix configuration. We added 6LRs functions to allow RS
sages to Node (C) and all other 6LRs. When hosts are present, transmission, and auto-configuring IPv6 addresses based on
the RA is sent in response to a RS received from the host. the M flag and other flags contained in the received RA mes-
4) Node (B) and Node (C) must check the Version Number field in sage from 6LBR.
the ABRO to limit the flooding of updated information between o Processing ABRO/6CO headers received from 6LBR, and
them. sending ABRO/6CO Headers to other nodes (hosts or
5) Node (C) can perform DAD against Node (A) using the new Du- routers): We added a 6LRS data structure to store the ABRO,
plicate Address Request (DAR) and Duplicate Address Confirma- 6CO, and prefix information received (directly or indirectly)
tion (DAC) messages, which includes the same information as from the 6LBR. Moreover, we added 6LRs functions to redis-
ARO. The DAR and DAC messages will be forwarded by Node tribute this information in the RA they send to other 6LRs
(B). and hosts in response to a Router Solicitation. Moreover, we
added [version_number] in the [uip_nd6_opt_ABRO] struc-
For address resolution between routers, the ARO option is used ture that is needed in RFC 6775 to limit the flooding of up-
to allow the routers to register their link layer address with each dated information between the 6LRs.
other. Our implementation also assures no flood of ARO-carrying o ARO support: we added the function handlers to verify the
messages sent to the 6LBR as each router hears an ARO from their validation of received NS message, in addition to the valida-
neighboring routers. Alternatively, the two routers can use mul- tion of its options.
ticast NS messages to resolve each other’s link-layer addresses as 3- Optimized ND features for 6LBRs:
used in the basic ND. Thus, routers multicast NS messages to other o 6LBRs have the same features as 6LRs, in addition to the fol-
routers as a result of receiving routing protocol update. Routers lowing implemented features:
also respond to multicast NSs. This implies that routers join the o Border routers do not perform address autoconfiguration on
solicited-node multicast addresses as specified in [8]. When RPL is router interface.
used, the DIO messages are used to populate the neighbor table. o Border routers support EUI-64 MAC on 6LoWPAN interface.
Therefore, there is no need for the routers to exchange the ARO. o Multihop prefix distribution.
 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 83

Fig. 8. Optimized neighbor discovery software architecture.

In Fig. 8, we show the relationship between the different neigh-

bor discovery functions and the related modules such as (uip-ds6,
uip-ds6-route, uip-ds6-nbr) modules, and the newly added uip-
ds6-reg module. More details about functions and code implemen-
tation are explained in [31]. We omit such details for space con-
sideration and ease of readability. Our source code is available via
[34], our code is, also, available in [16].

6. Evaluation of the optimized ND protocol

In this section, we present an exhaustive set of experiments

that does not only evaluate the performance of the optimized ND
protocol but also demonstrates that the existing implementation of
ND protocol can benefit from the gains of implementing this opti-
mization for various network types.

6.1. Simulation setup

We use Contiki OS v2.7 and Cooja [35] simulator tools in our Fig. 9. Network topology used to test ND protocol.
performance evaluation. We use CSMA-based Contiki MAC [36] as
common radio duty cycling, which is energy and throughput ef-
ficient, for evaluating both protocols. Also, we use CSMA protocol in Table 2, and the same type of nodes that are used to evaluate
which will be helpful in collecting results data, as it keeps a list the basic IPv6 ND protocol and the implementation of the opti-
of packets to each of the neighbors and calculate statistics such as mized ND protocol. These configurations are made to assure the
number of retransmissions, collisions, deferrals, etc. In our simu- reachability of nodes.
lation, we consider a network that contains a variable number of In the topology shown in Fig. 9, we consider a single central
hosts and one router centered between these hosts, while nodes router around which several hosts exists. The topology shown in
use simple UDP packets for communication and data exchange. Fig. 9 will allow nodes to discover more than one neighbor. This
Nodes use unit disk graph medium (UDGM) to set radio transmis- allows for testing the basic criteria of neighbor selection in isola-
sion range as circles, which uses two different range parameters: tion of any topology-induced factors. In basic ND, hosts can main-
one for transmissions and one for interfering with other radios tain NCEs for other on-link hosts. However, in the optimized ND,
and transmissions. Briefly, we use the same configuration, shown hosts do not maintain NCEs for other hosts. Instead, routers only
84 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

Table 2
Network configuration.

Parameter Value

Network Area 100 m x 100 m

Data Rate 1/6 Packet/second
Packet Length 127 Bytes
Radio propagation and interference model Unit disk graph medium (UDGM): distance loss
Transmission Range 50 m radius
Interference Range 100 m radius
Physical layer parameters RDC channel check rate: 8
Radio: cc2420 driver
Framer: framer-802,154
MAC layer CSMA_driver
Radio Duty Cycle Contiki_mac_driver

maintain the hosts’ addresses in its registration cache. As one of

our metrics to assess the optimized use of multicast messages
and avoid using excessive response messages, we use this network
topology, fully mesh, which supports the use of multicast to test
how the multicast will be reduced without affecting the optimized
ND Functions and without use excessive multicast responses to do
so. The results of the conducted experiments are obtained by tak-
ing the average of 10 runs per experiment with confidence interval
95% based on standard deviation and constant experiment time in-
terval of two hours of simulation time.
Our objective is to evaluate the performance of ND processes
without overlapping with any routing protocol. In our experiments,
we turn off RPL functions to prevent the duplication of RPL and ND
protocols functions as explained in Section 4.1. In router nodes, we
disable the functionalities of RPL, and enable the transmission of
RAs to allow dynamic address allocation and other functionalities Fig. 10. The number of NA messages of both RFC 4861 and RFC 6775 implementa-
tions for different number of host nodes.
discussed in Section 3.2. In host nodes, we disable the router con-
figuration to allow transmission of Router Solicitation messages.
Other configuration like Cooja’s power trace will be set to investi-
gate the power behavior of network nodes. Our performance met-
ric are 1) the reduction in ND control messages, 2) the optimized
use of multicast messages, 3) the enhancements in network life-
time, power consumption, and packets delivery ratio, 4) impact of
nodes reachability in the network traffic, and number of messages
exchanged in the network.

6.2. Reduction of exchanged ND messages

The first experiment aims to show the number of exchanged

ND messages for the optimized ND protocol versus the original im-
plementation of the ND protocol as the number of hosts vary. We
compare the numbers for each type of messages (RS, RA, NS, and
NA), and then we will combine the overall messages in order to Fig. 11. The number of NS messages of both RFC 4861 and RFC 6775 implementa-
tions for different number of host nodes.
show the overall reduction in the number of exchanged messages.
During interface initialization of the basic IPv6 ND, routers have to
wait (uip_ds6_timer_ra= 2 seconds) to have a link local IP address
before transmitting first RA message, the router node must wait ND protocol reduces the transmission of neighbor advertisement
(MinRtrAdvInterval= (MaxRtrAdvInterval/3) + random time) before messages by around 30% compared to the basic ND protocol. This
retransmitting another RA message. By default MaxRtrAdvInterval reduction is mainly due to: the increased retransmission timer pe-
is set to 600 seconds. When uip_ds6_timer_ra expires, the trans- riod increased an NA message is sent in response to an NS mes-
mission of RA message is triggered. However, there is another pe- sage, and duplicate address detection is eliminated in the opti-
riodic timer (uip_ds6_periodic_timer) with a duration of 100 ms, mized ND. Even in router to router interaction, there is no need
which is used to update IPv6 data structures. The uip_ds6_timer for old address resolution as it became part of the Registration pro-
expiration is checked each time the uip_ds6_periodic_timer ex- cess (Section 4.1). However, this will lead to the slight increase in
pires. The Registration Lifetime in the optimized ND must be suit- transmitting NS messages as shown in Fig. 11.
ably low to handle the case when a host loses connectivity with For the RS/RA pair, Fig. 12 shows that the number of router ad-
the default router involuntarily. However, the registration lifetime vertisements increases with the number of nodes for RFC 6775. In
is also related to the sleep time, which must be appropriate for its RFC 6775, each node should solicit a router advertisement (e.g. to
energy characteristics. Consequently, we set the Registration Life- refresh the lifetime of the prefixes and contexts) as they are sent
time to 4 minutes to be larger than the sleep time to ensure that in unicast. So if X nodes are present, X router advertisements will
the registration is renewed successfully. In Fig. 10, the optimized be sent.
 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 85

the difference between the RS and RA messages to be much bigger

compared to the basic ND (except for the case of few number of
hosts below 3).
Next, we count all the ND messages in order to assess the over-
all behavior of optimized ND protocol. Fig. 14 shows a reduction of
(25% to 70%) in the total number of transmitted ND messages. This
is a significant indication that optimizing the ND control packet
transmissions and minimizing the signaling through the network,
besides multicast schemes are reduced in this optimized version of
ND protocol.

6.3. Reduction in using multicast messages

The second experiment aims to inspect the number of multi-

cast messages for the optimized ND protocol versus the original
Fig. 12. The number of RA messages of both RFC 4861 and RFC 6775 implementa- ND protocol implementation. One of the main goals of the opti-
tions for different number of client nodes. mization is to reduce the multicast IPv6 packets transmitted be-
tween network nodes. As we mentioned earlier, the original ND is
based on sending multicast messages.
Multicast messages are not favorable in 6LoWPANs due to the
lossy nature of this type of networks as explained in Section 4.
Optimized ND reduces the effect of multicasting. Fig. 15 shows the
reduction in the number of transmitted multicast messages around
(30% to 69% depending on the number of the hosts in the net-
work). Increasing the number of hosts will reduce this percentage
due to the essential transmission of multicast RS messages at the
interface initialization.

6.4. Network lifetime and power consumption

The optimized ND allows hosts to sleep for power saving pur-

poses. However, a host has to wake-up before its registration life-
time expires to update its status at the default router, or else the
Fig. 13. The number of RS messages of both RFC 4861 and RFC 6775 implementa-
host will be removed from router’s NCEs. In this case, the host
tions for different number of client nodes. will start the registration process from the beginning. This effect
might add overhead due to the multiple use of NS/NA transmis-
sion in the re-registration process. The third experiment aims to
However, our implementation of the optimized ND protocol re- test the worst case when hosts fail to update its registration life-
duces the transmission of RA messages by 90% as shown in Fig. 12. time. Consequently, optimized ND algorithm is reapplied from the
This is achieved by disabling the periodic RA messages and the fast beginning. This experiment is divided into two steps:
termination of the solicitation process after receiving RA message. First, we assess the lifetime of the network. We build a bat-
Fig. 12 also indicates that the number of RA messages in the ba- tery model mainly based on using and processing the optimized
sic ND is constant as it does not depend on the number of hosts. ND messages to show the effect of nodes communications (trans-
As we assume only one router, periodic multicast RA messages are missions, receiving, etc.) on the network lifetime. By changing the
sent to update nodes with network parameters. nodes reachability to trigger failure in updating the registration
We next evaluate the change in the number of RS messages lifetime, we will test the optimized ND protocol and how it affects
with the number of host nodes. Fig. 13 shows the number of RS the network lifetime.
messages for both ND protocol implementations. The number of RS Fig. 16 shows the effect of NUD reachability process on the en-
messages increases with increasing number of host nodes. How- ergy consumption of the nodes and network lifetime. We use the
ever, the optimized ND protocol shows a better behavior in trans- time needed until all the hosts in the network drain their batter-
mitting and receiving RS/RA messages. The terminating process of ies as a measure of the network lifetime [37–39]. Such a measure
RS messages transmissions is tightly controlled in the new opti- of the network lifetime represents the operational time of the basic
mizations as explained in Section 5.2. topology illustrated in Fig. 9 that is used to assess the performance
Comparing Fig. 12 and Fig. 13, a significant difference between of ND without any topology-induced factors. Furthermore, we nor-
the number of RS messages and the number of RA messages is malize the network lifetime with respect to the case in which the
observed in both protocols. One reason behind such a difference node reachability is 100%. In other words, the normalized network
is that the used network topology contains 10 hosts (RS sources) lifetime given by Eq. 1 is the network lifetime for a given reacha-
and only one router (RA source). However, the main reason behind bility level (below 100%) normalized to the network lifetime in the
such a difference is the fact that the RS messages are sent to serve ultimate case where all node are reachable as shown in Fig. 16
several purposes such as whenever the default router list is empty,
one of its default routers becomes unreachable, or the lifetime of Normalized Network li f etime(% )
the prefixes and contexts in the previous RA are about to expire. Network lifetime for specific reachability percentage (msec )
Recall that, RA messages in the basic ND are multicast, periodic, = ∗ 100 (1)
Network lifetime for 100 percentage reachability (msec )
and do not depend on the number of hosts, whereas RA messages
in the optimized ND are sent in response to valid received RS mes- In the full reachability scenario, hosts will successfully be able
sages. This reduction in RA messages in the optimized ND causes to update their registration lifetimes. However, when we decrease
86 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

Fig. 14. The number of total ND messages of both ND (RFC 4861) and Optimized ND (RFC 6775) implementations for different number of host nodes.

Fig. 15. Multicast and unicast Messages sent by nodes for both optimized ND and basic version of ND protocol.

Fig. 16. Normalized Network lifetime for various percentages of nodes’ reachability.
 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 87

Fig. 17. Average power consumption for group of nodes versus time.

the reachability percentage, we find that the probability of failure ND packets exchange between hosts and routers in 6LoWPAN net-
in updating the registration lifetime increases. Consequently, ex- works.
tra transmission of NS/NA messages will take place for reachability
confirmation and node registrations. The over use of ND messages 6.6. Impact of nodes unreachability
will drain the nodes’ batteries faster. Consequently, it will degrade
the network lifetime. We conclude that both optimized ND proto- Some of the previous results are obtained when all nodes in the
col and RFC 4861 based ND affect the network lifetime when the network are assumed to be reachable for all the simulation time. In
reachability decreases due to the retransmissions of ND messages. the case of one of the default routers is unreachable as discussed
In optimized ND, we find that the network lifetime decreases only in Section 5.2, the RS message will be retransmitted. NS/NA mes-
6% when network suffers low level of reachability (50%). On the sages as a part of NUD process are used to update the node’ neigh-
other hand, the RFC 4861 based ND suffers from 27% drop in the bor cache. We next study the impact of reachability of the nodes in
network lifetime. the network and how it affects the number of ND messages. Fig. 19
In the second part of this experiment, we assume that each shows the total number of ND messages for a range of (100% to
node has 50 0 0 units of power. This amount of power is related 90%) reachability of the nodes. During an hour-long simulation,
to transmission of IPv6 packets. We measure the average power the host nodes cannot reach its default router for 60∗ (100-X)/100
of the nodes in the network every 5 seconds. Fig. 17 shows the minutes, where X is the reachability percentage. Fig. 19 shows the
drop in the network average power level in both basic and opti- slight increase in the number of ND messages with the decrease
mized ND protocols. As expected the more ND messages are sent, in the reachability percentage. The default router unreachability is
the more energy are consumed. This increase is due to the mul- the main reason for this increase as nodes need to transmit the
tiple uses of ND functions such as NUD, and address resolution. RS messages in such a case as we mentioned in Section 3.1. In ad-
However, the optimized ND protocol enhance the power curve, and dition, NS messages will be transmitted as hosts need to update
gives a better performance as nodes register their addresses and their neighbor cache entries.
then sleep which saves nodes power and increase network lifetime.
Fig. 17 shows that basic ND consumes power faster than optimized 6.7. The multi-hop networks case
ND. We found that after 16,0 0 0 time unit the network with basic
ND already dead, while the network with optimized ND still has In this section, we first evaluate how the optimized ND behaves
20% of its average power. in the case of multi-hop 6LowPAN with RPL as the router-over net-
work protocol. In our simulation, we use a random topology with
1 server node acting as root of the DODAG and a variable num-
6.5. Delivery ratio ber of client nodes (between 9 and 59) as depicted in Fig. 20. The
server is using a sample application udp-server.c and configured as
This experiment aims to assess the delivery ratio between hosts the network border router (6LBR), while all other nodes are using
and router when the nodes sleep for periods less than their reg- udp-client.c and configured as a normal routers (6LRs). We use a
istration lifetimes. This experiment is to insure that the sleeping Cooja plugin called Contiki Test Editor to measure the simulation
process does not affect the delivery ratio of ND control packets. We time and stop the simulation after the specified time. This plu-
vary number of hosts in the network for this experiment. Fig. 18 gin also creates a log file for all the outputs from the simulation
shows that the delivery ratio of ND packets decreases by increas- which is analyzed at the end of the simulation using a Perl script.
ing number of nodes in both protocols. However, the optimized ND In order to induce losses in the wireless medium we use the Cooja
achieves a better delivery ratio than the basic ND even with a large Unit Disk Graph Medium (UDGM) which introduces losses in ac-
number of hosts. cordance with the relative distances of nodes in the Radio Medium.
This happens due to the heavy use of multicast messages be- The parameters for the simulation and its environment are shown
tween network nodes, and the short periods between two succes- in Table 3. Other simulation parameters are the same as before.
sive transmissions of ND messages in the case of the basic RFC The obtained result is the average of 10 runs per one simulation
4861 implementation. We conclude from this experiment that the setup. We use three performance metrics of interest: network con-
optimized ND protocol consumes energy wisely and optimize the vergence time, control traffic overhead, network latency.
88 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

Fig. 18. Delivery ratio of ND protocol packets through Network with different number of host nodes.

Fig. 19. The variable reachability percentage effect on number of transmitted ND messages with 8 host nodes.

Table 3
Simulation parameters.

Parameter Value

Start Delay 65 s
Randomness 2s
RPL MOP NO_DOWNWARD_ROUTE
OF OF0, ETX
Interference Range 100 m
Simulation Time 1 hr
DIO Min 12
DIO Doublings 8
RDC Chanel Check Rate 16
Send Interval 4s

_ Control traffic overhead for the network: this includes DIO, DIS
and DAO messages generated by each node and it is impera-
tive to confine the control traffic keeping in mind the scarce
resources in LLN.
Fig. 20. Network model with random topology to assess the behavior of RPL over
6LoWPAN ND. _ Packet latency: the amount of time taken by a packet from
node to reach the sink and is the average of the latencies of
The three metrics are defined as follows: all the packets in the network from all the nodes.

_ Network convergence time of the RPL DAG: the amount of time The nodes in a sensor network need to form a topology in or-
needed by all the reachable nodes in the network to join the der to communicate. Therefore, the network convergence time is a
DAG. crucial metric that needs to be evaluated for any routing protocol.
 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 89

Fig. 21. Network convergence time for different number of nodes with random topology.

Fig. 22. Number of RPL control messages exchanged for different number of nodes.

The convergence time of the RPL should be considered as the ini- course by the help of trickle timers (the main mechanism to avoid
tial convergence time in a RPL network with static nodes. As the loops and redundancy in RPL)
nodes can be mobile and the links are lossy in LLN, the absolute In Fig. 23, we assess the packet latency. The Network Latency
Convergence Time cannot be defined for a mobile network. can be computed using the following equation.
We recall here that RPL expects that the NUD process is trig-
gered during the parent selection process to verify the neighbor 
n
reachability and link properties. As depicted in the Fig. 21, the net- Total Latency = (recv timek − sent timek ) (2)
work convergence time is reduced when OND is combined with k=1
RPL due to the implementation of such optimized ND scheme.
DIO messages are sent by nodes to advertise information, DAO where n is the total number of packets received successfully. The
messages are sent by nodes to provide routing information in the timing information is provided by Cooja Simulator. To compute the
down direction, while DIS messages are sent by nodes to discover average Latency we divide the Total Latency from Eq. (2) by the
DODAGs in the neighborhood and solicit DIOs from RPL nodes in number of total received packets. The Total number of received
the neighborhood. packets is counted at the sink node.
Fig. 22 shows that the old ND gives a better performance in
case of low number of nodes, while OND gives a better perfor- Total Latency
mance in case of dense network (at least 50 nodes), which suits
Average Latency = (3)
TotalPackets Recieved
the LLNs as it consists of large number of nodes. Even in low num-
ber of nodes still OND gives almost same results as old ND. As shown in Fig. 23, the average packet latency is slightly re-
The OND updates neighbor cache in a faster way than old ND duced in the case of OND. Even this slight decrease (few millisec-
which will be clearly seen in dense network. These updates will onds) affect the whole network setup (network convergence time),
give RPL a better control on the redundant control messages, of DAG maintenance, fast recovery in case of failure.
90 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

Fig. 23. Average packet latency for different number of nodes.

Fig. 24. Overhead associated with ND protocol for different number of nodes.

Fig. 25. Network traffic for different number of nodes.

 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92 91

Fig. 26. Network throughput for different number of nodes.

6.8. Overhead associated with neighbor discovery protocol ND, and then we elaborated on the added optimizations such as
new registration mechanism, disturbing the context and prefixes
Let OND and BND denote the optimized ND protocol and the over the network. The main contribution of the paper is the first-
basic ND protocol, respectively. We define the following metrics of-its kind implementation of the optimized ND over Contiki OS
over a period of observation t: 2.7. Simulation results have shown that our implementation of the
optimized ND results in reducing the number of exchanged ND
1- OND-CTRLB: denotes the total amount of control bytes using
control messages and reducing the use of multicast messages as
OND.
compared to the implementation of the original ND. Through our
2- BND-CTRLB: denotes the amount of control bytes using BND.
implementation, the optimized ND has shown better performance
3- OND-USERB: denotes the amount of user traffic bytes using
even in case of low reachability (90%). The Optimized ND has also
OND.
resulted in enhanced delivery ratio of ND control packets. This en-
4- BND-USERB: denotes the amount of user traffic bytes using
hanced behavior of the optimized ND protocol leads to a better
BND.
network lifetime, and more energy savings, as the optimized ND
5- T (OND): denotes the network throughput using OND.
protocol allows nodes to sleep without the need to go all over
6- T (BND): denotes the network throughput using BND.
again of ND processes. Finally, we test the RPL performance, and
The network throughput is calculated as follows: testing the implementation of optimized ND functions effects on
such routing protocol. The results show a better performance in
 
[xND − CTRLB + xND − USERB] ∗ 8
1024 (in bytes) important metrics such as network convergence time, control traf-
T (xND ) = in (kbps ) fic packets, and average packet latency. In our future work, we in-
t (in seconds )
(4) vestigate a combined RPL objective function based on 6lowpan ND.
The suggested objective function might benefit from the feature
where t is the total network operating time. of host-initiating the interaction which allows nodes to sleep and
To assess the overheads, we ran several simulations varying save more energy.
number of nodes with each node transmitting 5 packets/min. The
RFC 6775 ND protocol employs the optimized mechanism, ex-
plained in Section 4.3, in the transmission of control messages that Acknowledgments
is more effective than RFC 4861 basic ND. Since the optimized ND
is specifically designed for 6LoWPANs, it results in significantly re- This work was part of the ITEA2 Web of Objects Project funded
duced control traffic overhead, which is depicted in Fig. 24. in Egypt by the Egyptian Ministry of Communication and Informa-
Fig. 25 shows the user traffic for both ND protocols. The user tion Technology.
traffic of OND is higher than the network traffic of BND which val-
idates the optimized interaction between network nodes in OND.
References
Finally, we assess the network throughput as shown in Fig. 26
which indicates a better overall throughput when the optimized [1] Gartner Report, Forecast: The Internet of Things, Worldwide, 2013.
neighbor discovery is used. [2] M.R Palattella, N. Accettura, X. Vilajosana, T. Watteyne, L. Grieco, G. Boggia,
M. Dohler, Standardized protocol stack for the Internet of (important) Things.,
IEEE Commun. Surv. Tutorials 15 (3) (2013) 1389–1406.
7. Conclusions
[3] IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Phys-
ical Layer (PHY) Specifications For Low-Rate Wireless Personal Area Networks
The basic IPv6 neighbor discovery protocol was designed for (LR-WPANs), Standard for Information Technology Std., September 2006.
[4] Z. Shelby and C. Bormann, 6LoWPAN: The wireless embedded Internet,
traditional IPv6 links. Considering the limited capabilities of de-
November 2009.
vices used in 6LoWPAN, optimized ND protocol is essential to be [5] T. Winter, P. Thubert, RPL: IPv6 Routing Protocol For Low Power and Lossy
used in 6LoWPAN networks in order to minimize the IPv6 over- Networks, RFC 6550, IETF ROLL, Mar. 2012.
head, save energy, and ensure resource efficiency. In this paper, we [6] T. Narten, E. Nordmark, W. Simpson, H. Soliman, Neighbor Discovery For IP
Version 6 (IPv6), RFC 4861, IETF Network Working Group, Sep. 2007.
have presented a detailed analysis of both the basic and the opti- [7] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, Transmission of IPv6 Packets
mized ND protocols. We have explained the baseline functions of Over IEEE 802.15.4 Networks, IETF Network Working Group, September 2007.
92 M.A.M. Seliem et al. / Computer Communications 112 (2017) 73–92

[8] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann, Neighbor Discovery Opti- [24] G. Alonso, E. Kranakis, R. Wattenhofer, P. Widmayer, Probabilistic protocols
mization For IPv6 Over Low-Power Wireless Personal Area Networks (6LoW- for node discovery in ad-hoc, single broadcast channel networks, International
PANs), Internet Engineering Task Force, RFC6775, Nov. 2012. Parallel and Distributed Processing Symposium (IPDPS), April 2003.
[9] M. Seliem, K. Elsayed, A. Khattab, Performance evaluation and optimization [25] G. Alonso, E. Kranakis, C. Sawchuk, R. Wattenhofer, P. Widmayer, Randomized
of neighbor discovery implementation over Contiki OS, in: Proceedings of the protocols for node discovery in ad-hoc multichannel broadcast networks, Con-
2014 Forum on Internet of Things (WF-IoT), March 2014. ference on Adhoc Networks and Wireless (ADHOCNOW), October 2003.
[10] A. Dunkels, B. Grönvall, V. Thiemo, Contiki a lightweight and flexible operating [26] G. Jakllari, W. Luo, S. Krishnamurthy, An integrated neighbor discovery and
system for tiny networked sensors, in: Proc. of IEEE Workshop on Embedded mac protocol for ad hoc networks using directional antennas, IEEE Symposium
Networked Sensors, Tampa, FL, Nov. 2004. on a World of Wireless, Mobile and Multimedia Networks (WOWMOM), June
[11] https://github.com/lcmaqueda/6lowpan-nd. 2005.
[12] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann, Neighbor Discovery Opti- [27] S. Vasudevan, J. Kurose, D. Towsley, On neighbor discovery in wireless net-
mization For Low-Power and Lossy Networks (6LoWPAN), Internet Engineering works with directional antennas, in: Proc. of IEEE Conference on Computer
Task Force, draft-ietf-6lowpan-nd-18, October 24, 2011. Communications (INFOCOM), Miami, USA, March 2005.
[13] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann, Neighbor Discovery Opti- [28] J. Montavont, C. Cobârzan, T. Noel, Theoretical analysis of IPv6 stateless ad-
mization For Low-Power and Lossy Networks (6LoWPAN), Internet Engineering dress autoconfiguration in low-power and lossy wireless networks, The IEEE
Task Force, draft-ietf-6lowpan-nd-19, July 16, 2012. http://tools.ietf.org/rfcdiff? RIVF International Conference on Computing and Communication Technologies
url2=draft- ietf- 6lowpan- nd- 19.txt. Research, Innovation, and Vision for Future (RIVF), 2015.
[14] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann, Neighbor Discovery Opti- [29] S. Thomson, T. Narten, T. Jinmei, IPv6 Stateless Address Autoconfiguration, IETF
mization For Low-Power and Lossy Networks (6LoWPAN), Internet Engineer- Network Working Group, RFC 4862, Sep. 2007.
ing Task Force, draft-ietf-6lowpan-nd-20, August 20, 2012. http://tools.ietf.org/ [30] T. Narten, E. Nordmark, W. Simpson, Neighbor Discovery For IP Version 6
rfcdiff?url2=draft- ietf- 6lowpan- nd- 20.txt (IPv6), IETF Network Working Group, RFC 2461, December 1998.
[15] Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann, Neighbor Discovery Opti- [31] M. Selim, K. Elsayed, and A. Khattab, Optimized neighbor discovery for 6LoW-
mization For Low-Power and Lossy Networks (6LoWPAN), Internet Engineer- PANs envrionments, Cairo University Technical Report, Available from: http:
ing Task Force, draft-ietf-6lowpan-nd-21, August 24, 2012. http://tools.ietf.org/ //woo.4gpp-project.net/OND_RFC6775.pdf.
rfcdiff?url2=draft- ietf- 6lowpan- nd- 21.txt [32] J.-G. Ko, A. Terzis, S. Dawson-Haggerty, D.E. Culler, J.W. Hui, P. Levis, Connect-
[16] M. Seliem, |K. Elsayed, and A. Khattab, https://github.com/contiki-os/contiki/ ing low-power and lossy networks to the Internet, IEEE Commun. Mag. (April
pull/1765. 2011) 96–101.
[17] E. Ancillotti, R. Bruno, M. Conti, Reliable data delivery with the IETF routing [33] D. Sturek, Z. Shelby, D. Lohman, M. Garrison Stuber, and S. Ashton, "Smart en-
protocol for low-power and lossy networks, IEEE Trans. Ind. Inf. 10 (3) (2014) ergy requiements for 6LowApp", IETF Draft, October 2009.
1864–1877. [34] M. Selim, K. Elsayed, and A. Khattab, Source code for the optimized neigh-
[18] P. Levis, et al., Trickle: A self-regulating algorithm for code propagation and bor discovery for 6LoWPANs, Available from: http://woo.4gpp-project.net/
maintenance in wireless sensor networks, in: Proc. of the 1st USENIX/ACM ndrfc6675.zip.
Symp. on Networked Systems Design and Implementation, 2004. [35] J. Eriksson, Detailed simulation of heterogeneous wireless sensor networks, IT
[19] M. Bouaziz, A. Rachedi, A survey on mobility management protocols in wire- Licentiate theses, April 2009.
less sensor networks based on 6LoWPAN technology, J. Comput. Commun. 74 [36] A. Dunkels, The ContikiMAC radio duty cycling protocol, SICS Technical Report
(2016) 3–15. T2011:13,ISSN 1100-3154, December 2011.
[20] H. Fotouhi, et al., mRPL+: A mobility management framework in [37] D. Tian, N.D. Georganas, A coverage-preserving node scheduling scheme for
RPL/6LoWPAN, Comput. Commun. 104 (2017) 34–54. large wireless sensor networks, proceedings of the 1st ACM International
[21] B. Luo, S. Tang, and Z. Sun, Research of neighbor discovery for IPv6 over low- Workshop on Wireless Sensor Networks and Applications (WSNA), 2002.
power wireless personal area networks, Heterogeneous Networking for Quali- [38] A. Elleithy, G. Liu, and A. Elrashidi. A new model of the lifetime of wireless
ability, Reliability, Security and Robustness (QSHINE), Aug. 2015. sensor networks in sea water communications, arXiv preprint arXiv:1209.4133,
[22] B. Luo, Z. Sun, Enabling end-to-end communication between wireless sensor 2012.
networks and the Internet based on 6LoWPAN, Chin. J. Electron. 24 (3) (2015) [39] I. Dietrich, F. Dressler, On the lifetime of wireless sensor networks, ACM Trans.
633–638. Sens. Netw. (TOSN) 5 (1) (2009).
[23] L. Oliveira, et al., Network admission control solution for 6LoWPAN networks
based on symmetric key mechanisms, IEEE Trans. Ind. Inf. 12 (6) (2016)
2186–2195.