Performance Evaluation of Routing Protocols
in Lossy Links for Smart Building Networks
Ion Emilian Radoi
Master of Science
Computer Science
School of Informatics
University of Edinburgh
2011
iii
Abstract
The volume of research performed in the domain of Wireless Sensor Networks has increased
substantially in recent years. This is due to the advancement of fabrication technology of low-power
devices containing various sensors along with a wireless interface, allowing costs to be reduced.
However, the deployment of large-scale sensor networks, which could consist of several thousand
nodes, still represents a challenge to researchers.
This thesis aims to evaluate the performance of routing protocols in lossy links for smart building
networks. Special attention is directed towards the RPL protocol which is the IETF candidate for a
standard routing protocol in wireless sensor networks.
RPL was compared against other protocols (DSDV and the four versions of SimpleP) using several
metrics in the SpeckSim simulation environment for four topologies of different sizes.
The results reveal that RPL is suitable for use in large networks (over 200 nodes) because it does not
present any scalability limitations as opposed to the other protocols tested in this thesis. However, for
small to medium-sized networks (less than 100 nodes), RPLs performance does not outclass that of
the other protocols that were tested. Each protocol has proven to have its strengths, thus when
choosing a protocol for a wireless sensor network deployment, the decision has to be based on the
specific requirements of the WSN application.
iv
Acknowledgements
I would like to thank my supervisor Prof. D.K. Arvind for his constant help and guidance and for
supporting my ideas.
Nevertheless, I would like to thank Mat Barnes for helping me understand the SpeckSim simulator,
guiding me through the implementation process of the routing protocols and statistics gathering
modules, and helping me to move on with the project whenever I got stuck.
v
Declaration
I declare that this thesis was composed by myself, that the work contained herein is my own except
where explicitly stated otherwise in the text, and that this work has not been submitted for any other
degree or professional qualification except as specified.
(Ion Emilian Radoi)
vi
Table of Contents
Introduction ........................................................................................................................ 1
1.1. Wireless Sensor Networks ......................................................................................... 1
1.2. Routing in WSN ......................................................................................................... 2
1.3. Motivation ................................................................................................................ 2
1.4. Previous Work ........................................................................................................... 3
1.5. Outline ...................................................................................................................... 3
Background and Related Work ............................................................................................ 5
2.1. RPL ............................................................................................................................ 5
2.2. SpeckSim ................................................................................................................... 6
2.3. Literature Survey ....................................................................................................... 8
2.4. Routing protocols relevant for comparing to RPL ..................................................... 11
2.4.1. DSDV [15],[17] ....................................................................................................... 11
2.4.2. AODV [13],[14] ...................................................................................................... 12
2.4.3. DSR [18],[19] ......................................................................................................... 12
2.5. Smart Buildings ....................................................................................................... 13
2.5.1. Scenarios [11] where routing protocols are needed for smart building networks 13
Design and Implementation .............................................................................................. 17
3.1. Attempt to integrate ContikiRPL into SpeckSim ....................................................... 17
3.2. RPL .......................................................................................................................... 21
3.2.1. Types of RPL messages ..................................................................................... 22
3.2.2. RPL routing ....................................................................................................... 23
3.2.3. Objective Function............................................................................................ 24
3.2.4. Trickle timer ..................................................................................................... 24
3.2.5. RPL in SpeckSim ................................................................................................ 25
3.3. SimpleP ................................................................................................................... 25
3.3.1. SimplePv1 ......................................................................................................... 26
3.3.2. SimplePv2 ......................................................................................................... 26
3.3.3. SimplePv3 ......................................................................................................... 26
3.3.4. SimplePv4 ......................................................................................................... 26
3.3.5. Limitations of SimpleP ...................................................................................... 28
vii
3.4. DSDV .......................................................................................................................28
3.4.1. DSDV features that differ from SimplePv4 .........................................................31
Validation ..........................................................................................................................33
4.1. Validation Scenario ..................................................................................................33
4.1.2. Cooja ................................................................................................................34
4.1.3. SpeckSim ..........................................................................................................35
4.2. Validation Results ....................................................................................................35
4.2.1. Favourable case ................................................................................................36
4.2.2. Detrimental case ...............................................................................................37
4.3. Conclusions .............................................................................................................38
Testing ...............................................................................................................................39
5.1. Simulation Environment ..........................................................................................39
5.2. Topology types ........................................................................................................40
5.2.1. Random ............................................................................................................40
5.2.2. Grid ..................................................................................................................40
5.2.3. Tree ..................................................................................................................41
5.2.4. Building ............................................................................................................41
5.3. Metrics ....................................................................................................................43
5.3.1. Protocol Overhead ............................................................................................43
5.3.2. Size of table ......................................................................................................43
5.3.3. Coverage ..........................................................................................................43
5.3.4. Delivery Ratio / Packet loss ...............................................................................43
5.3.5. Latency .............................................................................................................44
5.3.6. Power consumption ..........................................................................................44
5.3.7. Fault tolerance (Recovery time) ........................................................................44
5.3.8. Route propagation time within the network .....................................................45
5.3.9. Implementation complexity ..............................................................................46
5.3.10. CPU load .........................................................................................................46
5.4. Types of Traffic ........................................................................................................46
5.5. Statistics gathering process in SpeckSim ..................................................................46
Results and Critical Analysis ..............................................................................................49
6.1. Protocol Overhead...................................................................................................49
6.1.1. Control packet generation flow .........................................................................49
viii
6.2.2. Overhead Size ................................................................................................... 52
6.2. Size of Table ............................................................................................................ 52
6.2.1. Number of Entries ............................................................................................ 52
6.2.2. Memory Usage ................................................................................................. 54
6.3. Coverage ................................................................................................................. 56
6.4. Delivery Ratio .......................................................................................................... 58
6.5. Latency ................................................................................................................... 59
6.6. Power Consumption ................................................................................................ 59
6.7. Fault Tolerance........................................................................................................ 60
6.7.1. Scenario ........................................................................................................... 60
6.7.2. Results .............................................................................................................. 61
6.8. Implementation Complexity .................................................................................... 62
6.9. Overall Results Interpretation.................................................................................. 63
Conclusions and Further Work .......................................................................................... 65
7.1. Conclusions ............................................................................................................. 65
7.2. Future work............................................................................................................. 66
Bibliography ...................................................................................................................... 67
Appendix ........................................................................................................................... 71
A. How to use the Cooja Simulator ................................................................................. 71
B. NoComments Script ................................................................................................... 71
ix
List of Figures
Figure 2.1: SpeckSim GUI Screenshot [9]
.......................................................................................... 7
Figure 2.2: SpeckSim Architecture [9] ............................................................................................... 7
Figure 3.1: Cooja simulator - 1 sink, 6 senders running ContikiRPL ............................................... 18
Figure 3.2: Cooja simulator - Sensor Map and Network Graph ....................................................... 19
Figure 3.3: Solution for ContikiRPL in SpeckSim .......................................................................... 20
Figure 3.4: Why NAK is needed .................................................................................................... 27
Figure 3.5: DSDV periodic updates ................................................................................................ 29
Figure 3.6: Forwarding and Advertised Tables for node 1 (4-node topology - SpeckSim) ................ 30
Figure 4.1: Validation topology Informatics Forum floor plan 11 node network deployment ..... 34
Figure 4.2: ContikiRPL Test Topology The RPL Root in favourable position (Cooja Simulator) .. 34
Figure 4.3: RPL Validation Topology (SpeckSim) .......................................................................... 35
Figure 4.4: Hops to DODAG Root ................................................................................................. 36
Figure 4.5: RPL DODAG .............................................................................................................. 36
Figure 4.6: Overhead ..................................................................................................................... 36
Figure 4.7: Hops to DODAG Root ................................................................................................. 37
Figure 4.8: RPL DODAG .............................................................................................................. 37
Figure 4.9: Overhead ..................................................................................................................... 37
Figure 5.1: Random Topology in SpeckSim ................................................................................... 40
Figure 5.2: Grid Topologies in SpeckSim ....................................................................................... 40
Figure 5.3: Tree Topologies in SpeckSim ....................................................................................... 41
Figure 5.4: Building Topology (Informatics Forum 24 nodes) in SpeckSim.................................. 42
Figure 5.5: Building Topology (Informatics Forum 11 nodes) in SpeckSim.................................. 42
Figure 5.6: Fault Toleration Example ............................................................................................. 45
Figure 6.1: RPL Overhead ............................................................................................................. 50
Figure 6.2: DSDV Overhead .......................................................................................................... 50
Figure 6.3: SimplePv1 Overhead .................................................................................................... 50
Figure 6.4: SimplePv2 Overhead .................................................................................................... 50
x
Figure 6.5: SimplePv3 Overhead .................................................................................................... 50
Figure 6.6: SimplePv4 Overhead .................................................................................................... 50
Figure 6.7: Overhead Flow ............................................................................................................. 51
Figure 6.8: Overhead Size .............................................................................................................. 52
Figure 6.9: Table Size (Number of Entries) .................................................................................... 53
Figure 6.10: Table Size Building ................................................................................................. 53
Figure 6.11: Table Size Grid ....................................................................................................... 53
Figure 6.12: Table Size Random.................................................................................................. 54
Figure 6.13: Table Size Tree ....................................................................................................... 54
Figure 6.14: Memory Usage 11-node Building Topology (Informatics Forum) ............................. 56
Figure 6.15: Coverage 11-node Building Topology (Informatics Forum) ...................................... 56
Figure 6.16: Coverage Building ................................................................................................... 57
Figure 6.17: Coverage Grid ......................................................................................................... 57
Figure 6.18: Coverage Random ................................................................................................... 57
Figure 6.19: Coverage Tree ......................................................................................................... 57
Figure 6.20: Delivery Ratio Building ........................................................................................... 58
Figure 6.21: Delivery Ratio Grid ................................................................................................. 58
Figure 6.22: Delivery Ratio Random ........................................................................................... 58
Figure 6.23: Delivery Ratio Tree ................................................................................................. 58
Figure 6.24: Latency 11-node Building Topology (Informatics Forum) ........................................ 59
Figure 6.25: Power Consumption ................................................................................................... 60
Figure 6.26: Fault Tolerance Topology (SpeckSim) ........................................................................ 60
Figure 6.27: Fault Tolerance .......................................................................................................... 61
Figure 6.28: Complexity (Lines of Code) ....................................................................................... 62
Figure 6.29: Complexity (Number of Classes) ................................................................................ 62
xi
List of tables
Table 3.1: DSDV SimplePv4 differences ..................................................................................... 31
Table 6.1: Protocols Metrics Summary ........................................................................................ 63
xii
List of Abreviations
WSN
LLN
MANET
IETF
ROLL
RPL
DSDV
AODV
DSR
RIP
OSPF
EIGRP
IS-IS
MAC
DODAG
DIO
DAO
CPU
MCU
ACK
NAK
Wireless Sensor Network
Low power and Lossy Network
Mobile Ad hoc Network
Internet Engineering Task Force
Routing Over Low power and Lossy networks
Routing Protocol for Low power and Lossy networks
Destination-Sequenced Distance Vector
Ad hoc On-Demand Distance Vector
Dynamic Source Routing
Routing Information Protocol
Open Shortest Path First
Enhanced Interior Gateway Routing Protocol
Intermediate System to Intermediate System
Medium Access Control
Destination Oriented Directed Acyclic Graph
DODAG Information Object
Destination Advertisement Object
Central Processing Unit
Microcontroller Unit
Acknowledgement
Negative Acknowledgement
1
Chapter 1
Introduction
The main aim of this project is to investigate the performance of the RPL (IPv6 Routing Protocol for
Low power and Lossy Networks) routing protocol in 6lowPAN (IPv6 low Power wireless Area
Networks) networks, analysing its strengths and weaknesses.
RPL is a routing protocol defined by the IETF Routing Over Low power and Lossy (ROLL) networks
Working Group, and is being promoted as the standard for use in wireless sensor networks. A number
of situational requirements for RPL have been identified by the ROLL group for building services and
industrial automation. The goal of this project is to evaluate the performance of the protocol in
meeting the complex requirements of such applications. The project evaluates the performance of the
RPL protocol against existing wireless sensor network and MANET routing protocols in the
SpeckSim network simulation environment.
The project was developed according to the following three phases: selection of protocols and criteria
for evaluation, implementation of the selected protocols and network traffic models in the simulator,
and performance evaluation and analysis.
1.1. Wireless Sensor Networks
Wireless Sensor Networks (WSN) consist of distributed sensors connected as a mesh, with the
purpose of monitoring an area of interest and the surrounding environment. The sensors are able to
capture various factors of the environment such as temperature, sound, pressure, movement and air
composition, among others. Usually, the sensors are dispersed in large numbers in the area of interest.
Information collection is often transmitted to a central collection point during, or after, an experiment.
Today, sensors hold a wide area of usage such as in industry (for monitoring and controlling the
industrial process), environmental monitoring, healthcare applications and military applications. More
advanced networks support bidirectional communication so that the activity of the sensors can be
controlled.
2 Chapter 1. Introduction
The nodes in a WSN are multi-functional, low-power and low-cost devices. Each node can have one
or more sensors, a radio transceiver, a microcontroller and runs on a battery. The range of the radio
communication between the nodes is usually up to 30 meters.
An important challenge is represented by the scalability of network protocols when dealing with a
large number of nodes. However, an equally important challenge is developing simple and efficient
protocols to be used for various operations within a WSN. These design requirements are necessary in
order for the protocols to be suitable to run on the network nodes, which are limited in terms of
hardware (processing power, memory and battery size).
1.2. Routing in WSN
Routing within mesh-connected wireless sensor networks is important as most applications designed
to run over these types of networks are based on the process of intra-node communication, as well as
the process of transferring data from individual nodes to a central collection point (sink).
Routing within wireless sensor networks differs from routing in IP networks in the following ways:
The addressing scheme is often not important for data driven applications
For most of the applications, data is collected from multiple sensors and sent to a central control point
WSN nodes have serious resource constraints such as processing power, memory size, energy storage and communication bandwidth
Frequently, nodes in a WSN are deployed statically, requiring low mobility. Thus, compared to
Mobile Ad hoc Networks (MANET) deployments (high rates of mobility that translates to frequent
topological changes), there are very few changes in the topologies.
1.3. Motivation
The need for a standard for wireless sensor network routing led the IETF organization to promote the
RPL protocol as its candidate. The results of this dissertation are a contribution to the consultation
process.
The main aims of the project are discussed next.
The goal of the project is to investigate the behaviour and evaluate the performance of RPL in WSNs.
The project also evaluates the performance of RPL against existing WSN and MANET routing
protocols in the SpeckSim network simulator.
1.4. Previous Work 3
In respect to the proposed goal, the RPL implementation provided in SpeckSim was validated against
the ContikiRPL implementation from the Cooja network simulator. After the validation stage, RPL
was tested and evaluated against the DSDV protocol and the four versions of the SimpleP protocol in
the SpeckSim simulator.
1.4. Previous Work
This project has benefited from the previous work conducted in the same domain as it. The simulation
environment used was the SpeckSim simulator [9] which was developed by the Speckled Computing
group [9], an early version of the RPL implementation in the SpeckSim simulator was provided by
Ryan McNally, and the Cooja simulator along with the ContikiRPL [24] implementation was developed
by the Swedish Institute of Computer Science [24].
The bulk of the previous and related work that was considered for this project is presented in Chapter
2 - Background and Related Work.
1.5. Outline
The rest of the thesis is structured as follows:
Chapter 2: Background and Related Work the RPL protocol and the SpeckSim network simulator are described; a brief literature survey is presented, along with routing protocols
that are relevant for comparison to RPL; introduces the concept of Smart Buildings and
offers examples of Smart Building scenarios to show the importance of routing in Smart
Building networks.
Chapter 3: Design and Implementation presents an early attempt to integrate the ContikiRPL into the SpeckSim simulator, and describes the implementation of the tested
routing protocols: RPL, SimplePv1, SimplePv2, SimplePv3, SimplePv4 and DSDV.
Chapter 4: Validation provides a validation for the SpeckSim RPL implementation against the ContikiRPL implementation (which was used as a benchmark). ContikiRPL was
tested with the help of the Cooja simulator.
Chapter 5: Testing describes the testing process and methods used in this project; it describes the settings of the simulation environment, the types of topologies and the metrics
used for evaluation, the types of traffic generated and how the statistics are gathered from the
SpeckSim simulator.
Chapter 6: Results and Critical Analysis presents the results obtained, along with a short discussion for each of the metrics tested; it concludes with an overall interpretation of the
results in the form of protocol comparisons.
Chapter 7: Conclusions and Future Work presents the final remarks, conclusions and observations, along with possible extensions to the project.
4
5
Chapter 2
Background and Related Work
This section sets the context of the project, provides a description for RPL and for other protocols that
are considered relevant for comparison to RPL, describes the simulator used for evaluation and
presents a survey of past research regarding routing protocols in Wireless Sensor Networks. It finally
describes the concept of Smart Building networks and provides examples of several applications for
such networks.
2.1. RPL
RPL has been proposed by the IETF ROLL (Routing Over Low power and Lossy networks) Working
Group as a standard routing protocol for IPv6 routing in low-power wireless sensor networks.
According to Tripathi et al [21], existing routing protocols such as OSPF, IS-IS, AODV, and OLSR
have been extensively evaluated by the working group and have been found to not satisfy, in their
current form, all specific routing requirements for LLNs (Low power and Lossy Networks)[21]. These
networks (LLNs) are mainly characterized by high loss rates, low data rates and instability and can
consist of up to several thousand nodes. The nodes in these networks are constrained in terms of
processing power, memory and energy.
The RPL routing protocol is tree-oriented, with RPL topologies generated starting from the Root
nodes and organized as directed acyclic graphs. RPL forms non-transitive, non-broadcast, multiple
access network topologies. RPL offers flexibility in building a topology, but is complex as described
in detail in the specification of the IETF draft [1].
The predominant traffic patterns in LLNs are point-to-multipoint and multipoint-to-point. The RPL
protocol supports these traffic flows, as well as point-to-point.
Point-to-point traffic is used between the devices within the LLN; point-to-multipoint pattern is used
between a central control point and a set of sensor nodes; multipoint-to-point pattern is used between a
set of sensor nodes and a central control point.
6 Chapter 2. Background and Related Work
RPL separates the process of routing optimization (such as minimizing energy consumption and
latency) from the process of packet routing (packet processing and forwarding). Bidirectional links are
required in order for a LLN to run the RPL protocol, because RPL has to verify whether a router is
reachable before using it as a parent. (During the parent selection process, an external mechanism is
used to verify the neighbour reachability and link properties)
An instance defines a topology built with a unique metric within a network. A network can run one
or more instances of RPL. Each such instance may serve different and potentially antagonistic
constraints or performance criteria.[1]
In compliance with the layered architecture of IP, RPL does not rely on any particular features of a
specific link layer technology. RPL is designed to be able to operate over a variety of different link
layers, including ones that are constrained, potentially lossy, or typically utilized in conjunction with
highly constrained host or router devices, such as but not limited to, low power wireless or PLC
(Power Line Communication) technologies. [1]
2.2. SpeckSim
The simulator chosen for this project is the SpeckSim network simulator. It was developed in Java by
the Speckled Computing group at the University of Edinburgh and is dedicated for simulating wireless
sensor networks. SpeckSim is designed to perform algorithm-level simulations on the behaviour of a
field of numerous mobile computing devices called Specks. The main design goal was to make it as
easy as possible for new behaviours and capabilities to be added to the simulator. [9] On the
SpeckSim website, documentation is provided for using the SpeckSim GUI, Extending SpeckSim,
Configuration, Visualisation and Logging.
Figure 2.1 represents a preview of SpeckSims graphical user interface.
2.2. SpeckSim 7
Figure 2.1: SpeckSim GUI Screenshot [9]
The simulator has three main components: the SpeckSim kernel which deals with communication, the
simulator state which holds/gathers data that can be used for generating simulation statistics, and the
graphical user interface which provides the user with the means to interact with the simulator.
The core of the simulator is event based, and the simulator holds a queue of these events with a
timestamp. (An example of such an event may be a change in the state of a device.) All events are
held in the queue, and are processed at appropriate times. The simulator time is advancing from one
such event to the other. Thus it is safe to say that the core of the simulator is actually based on this list
of queues of events.
Figure 2.2: SpeckSim Architecture [9]
8 Chapter 2. Background and Related Work
Figure 2.2 presents a diagram showing the components of the simulator. As shown in the diagram, the
simulator is made up of:
Specks any simulation entity
Environments used by devices for communication, such as a radio channel
The Movement Model positions the specks in the environment (3D space) and its movement (if any) over time
For further details and specifications refer to the SpeckSim website [9].
2.3. Literature Survey
According to A survey on routing protocols for wireless sensor networks [2] almost all routing
protocols for WSNs can be classified as data-centric, hierarchical or location-based. Even though the
majority of routing protocols should fit in one of the above mentioned categories, some of them
pursue slightly different approaches. Thus, a fourth category was created: Network flow and QoS-
aware protocols. The paper provides a classification for the WSNs routing protocols as follows:
Data-centric protocols A data-centric protocol is query based and depends on the naming
of the data. The process works like this: a node, which is a central control point, queries
particular regions and then expects to receive data from these sensors. As most of the data
collected will be redundant, it is up to the routing protocol to save energy by eliminating the
redundant data. Data-centric routing differs from traditional routing (which is address-based)
because routes are not created between addressable nodes. Due to the large number of nodes,
for many applications for WSNs it is not practical to assign global identifiers (such as IP
addresses).This makes it difficult to query a particular set of nodes. Since there is great
redundancy of the data transmitted, routing protocols capable of data aggregation help by
saving a significant amount of energy.
Example of data-centric protocols: SPIN (Sensor Protocols for Information via Negotiation),
Directed Diffusion, Rumor routing, GBR (Gradient-based routing), CADR (Constrained
anisotropic diffusion routing), COUGAR and ACQUIRE (ACtive QUery forwarding In
senoR nEtworks).
Hierarchical protocols Hierarchical protocols mainly address the issue of scalability. A
single gateway architecture is not scalable because increasing the density of sensors may lead
to an overload of the gateway, thereby resulting a high latency for the communication within
the network. Hierarchical routing decreases energy consumption by using multi-hop
2.3. Literature Survey 9
communication within a cluster and afterwards aggregating and performing fusion on the
collected data in order to eliminate any redundant data.
Example of hierarchical protocols: LEACH (Low-Energy Adaptive Clustering Hierarchy),
PEGASIS (Power-Efficient Gathering in Sensor Information Systems), TEEN (Threshold
sensitive Energy Efficient Network protocol) and APTEEN (Adaptive Threshold sensitive
Energy Efficient Network protocol).
Location-based protocols These protocols use location/position information to determine a
particular region based on the collected data, so that queries are diffused only in that specific
region.
Example of location-based protocols (some of the protocols mentioned are designed for ad-
hoc networks, but are applicable to WSNs): MECN (Minimum Energy Consumption
Network), SMECN (Small MECN), GAF (Geographic Adaptive Fidelity) and GEAR
(Geographic and Energy-Aware Routing).
Network flow and QoS-aware protocols This category consists of protocols that pursue
slightly different approaches such as network flow and QoS. (QoS-aware protocols are
concerned with end-to-end delay requirements when selecting paths in WSNs).
This paper [2] surveys recent routing protocols and discusses each under their appropriate category.
The aim is to provide a better understanding of the domain and to highlight outstanding open issues.
The paper Routing Techniques in Wireless Sensor Networks: A Survey [4] focuses on
routing techniques and provides classification and comparison of routing protocols in WSNs. It
reveals design challenges for routing protocols in wireless sensor networks such as: node deployment,
energy consumption without losing accuracy, data reporting model, node/link heterogeneity, fault
tolerance, scalability, network dynamics, transmission media, connectivity, coverage, data
aggregation, and quality of service.
This paper structures routing protocols in a manner similar to [2], and it presents about the same
protocols. It divides the protocols into two major categories: Network Structure Based Protocols
and Routing protocols based on Protocol Operation. The first category is divided into three
subcategories which coincide with the classification provided by [2]. This paper provides well
referenced future directions for routing in wireless sensor networks.
10 Chapter 2. Background and Related Work
A paper highly relevant to this project is Low-Power Wireless IPv6 Routing with ContikiRPL [3].
The paper aims to test the RPL protocol, and is based on an implementation of RPL for the Contiki
operating system, called ContikiRPL. This implementation was tested both in simulation and in a low-
power wireless network. The protocol was evaluated in terms of power efficiency and implementation
complexity. The results show that the lifetime of the network with RPL routing on Tmote Sky motes
can be several years. Additionally, the protocol has proven to be lightweight and power-efficient. This
dissertation presents a different approach for evaluating RPL by taking into account other metrics than
the ones mentioned in paper [3], and thereby providing a more comprehensive evaluation. It also
provides a comparison between RPL and other relevant routing protocols in order to highlight RPLs
strengths and weaknesses.
The paper A Performance Evaluation Study of RPL: Routing Protocol for Low Power and
Lossy Networks[21] provides an evaluation of the RPL protocol, simulated using the OMNET++
simulator with the Castalia2.2 framework that allows for wireless sensor networks simulation within
the OMNET++ simulator. The nodes in the simulator used TelosB CC2420 radio and the 802.15.4
MAC protocol. The scenario simulated an outdoors network of medium size (with a total of 86
nodes). The topology was inspired from a real-life deployment and the metrics that were used for
RPLs evaluation are the following:
Path quality metrics
Control plane overhead
Ability to cope with unstable situations (link churns, node dying)
Required resource constraints on nodes (routing table size, etc.)
The paper concludes by stretching out the usefulness of the Trickle timer used by RPL which keeps
the control overhead to a lower level than the actual data packet count. Also, Global repair was used
for managing broken links, which turned out to have a significant effect on the number of control
packets, which may be used to upper bound the overhead for trade off with time with no
connectivity[21]. In other words, Global repair provides a trade off between amount of control traffic
generated and the time for loss of connectivity. Since this paper provided the evaluation of the RPL
protocol based on an outdoor network, it is relevant to mention that the paper also concluded that the
protocol operation has to be modified to better adapt to this type of networks.
2.4. Routing protocols relevant for comparing to RPL 11
2.4. Routing protocols relevant for comparing to RPL
2.4.1. DSDV [15],[17]
Destination-Sequenced Distance-Vector (DSDV) is a highly dynamic routing protocol for ad-hoc
networks. It is classified as a distance-vector protocol and is based on multi-hop routing and the
Bellman-Ford algorithm. By definition, an ad-hoc network comprises of mobile devices/nodes called
hosts that communicate within the network without the intervention of any centralised Access Point.
To form such a network, each device/host has to operate as a specialized router. When the DSDV
protocol was created it has been taken into account that the topologies in ad-hoc networks may be
highly dynamic and that most users will desire not to have to perform any administrative actions in
order to set up the network.
The protocols main aim is to solve the routing loop problem. The solution that it provides regarding
this problem is the usage of a sequence number for each of the routes within the routing table. For
differentiating between valid and non-valid links the protocol uses even (valid link) and odd (invalid
link) numbers. These sequence numbers are generated by the destination.
Since wireless sensor networks can be quite dynamic, it seemed logical to compare the RPL protocol
to a MANET routing protocol such as DSDV. Other routing protocols (such as RIP, EIGRP, OSPF,
IS-IS) that are used by regular computer networks could not be taken into account for comparison
with RPL because they place too heavy a computational burden on the device running them, thus they
are not suitable for use on wireless sensors (which have very limited resources). Even though RIP is
somewhat similar to DSDV, since both are rather simplistic distance vector protocols and both use the
number of hops as a metric, RIP will not be suitable for an ad-hoc environment because its design
cannot handle highly frequent topology changes. And, according to Perkins and Bhagwat [17], the
split horizon and poison reverse techniques used by RIP were appropriate for use in wired networks,
and do not work in a wireless environment where the packets are sent via broadcast. DSDV avoids the
looping problem by tagging each route with a sequence number. Based on the sequence number,
nodes will be able to differentiate old and new routes.
DSDV, being a distance vector protocol, in order to keep the distance estimates up-to-date, each node
monitors the cost of its outgoing links and periodically broadcasts, to each one of its neighbours, its
current estimate of the shortest distance to every other node in the network[17].
Before the work of Perkins and Bhagwat [17], there were numerous objections concerning the use of
the Bellman-Ford algorithm as the basis for routing protocols. These objections targeted the poor
looping properties of the algorithm caused by link failures. They provided the specification for the
DSDV protocol which addresses some of these objections. Besides the thorough description of the
protocol and useful and comprehensive use examples, the paper also provides a theoretical
12 Chapter 2. Background and Related Work
demonstration as to why DSDV guarantees loop-free paths to each destination and a comparison of
DSDV to several other routing protocols.
DSDV is described as an innovative approach which models the mobile computers as routes which
are cooperating to forward packets as needed to each other. It makes good use of the properties of the
wireless broadcast medium and it can be utilized at either the network layer (layer 3), or below the
network layer but still above the MAC layer software in layer 2[17]. The papers findings is that
mobile computers (modelled as routers) can effectively cooperate to build ad-hoc networks. This
dissertation aims to discover how DSDV performs in wireless sensor networks and to compare its
performances with that of RPL.
2.4.2. AODV [13],[14]
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is designed for ad hoc mobile
networks. The protocol manages to adapt to low processing and low available memory conditions and
to the high dynamic nature of networks. It enables mobile devices that are part of the network to
quickly acquire routes to new destinations.
As it is a distance vector protocol, it uses multi-hop routing. However, it avoids the counting to
infinity problem of the Bellman-Ford algorithm and provides loop-free routing by using destination
sequence numbers for each route entry in the routing table. The destination sequence number is seen
as a local route metric, thus in case of multiple routes for one destination, the route that holds the
greatest destination sequence number is preferred. AODV offers quick convergence in case of
network changes.
AODV and RPL have several similarities, as they are both distance vector routing protocols, and tree
based.
2.4.3. DSR [18],[19]
Dynamic Source Routing (DSR) is a beacon-less routing protocol for ad hoc mobile networks. It
uses source routing, implying that the sender specifies the route that a packet takes through the
network. The sender deposits the address of the intermediate nodes (which are part of the route that
the packet must follow) in the packets.
The protocol is based on two mechanisms: Route Discovery and Route Maintenance. These
mechanisms have the purpose of discovering and maintaining routes to arbitrary nodes within the
network.
2.5. Smart Buildings 13
DSR is a simple and efficient protocol, which provides loop-free routing and can run on networks
with unidirectional links. It is intended to have low overhead and be able to react quickly to network
changes. The protocol determines and maintains all routing within its network, thereby enabling the
network to be self-organizing and self-configuring. DSR is designed to scale to hundreds of nodes and
is suitable for networks with a high degree of mobility.
2.5. Smart Buildings
A Smart Building network consists of spatially distributed autonomous devices to monitor and react
to physical or environmental conditions such as temperature, vibration, pressure, motion or pollutants.
Collaborative processing between the distributed nodes allows for fault tolerant and robust networks.
The potential benefits include maximising energy efficiency and assistive services for people with
disabilities. Within Smart Buildings, the people and the environment are equipped to be part of a
network of devices which combine sensing, processing and wireless networking capabilities.
Smart building networks can cost-effectively provide detailed monitoring of the conditions inside a
building. This allows for the environmental systems of a building to deliver just enough heat, air, or
cooling when and where it is needed. Smart buildings equipped with an integrated array of sensors
can also monitor such things as the amount of sunlight coming into a room and adjust indoor lighting
accordingly. Advanced smart buildings can know who is visiting a building after hours (based on the
key swipe from the security system) and turn on the appropriate lights, equipment, and environmental
controls. [11]
Smart buildings are occurring as a result of major financial, technical and environmental changes.
HOBNET represent an example of a research project in this domain that has the main objective to
ease and maximize the use of FIRE platforms by multidisciplinary developers of Future Internet
applications focused on automation and energy efficiency for smart/green buildings. [11]
The HOBNET scenario analysis report document [11] presents a number of scenarios along with their
description. Some of these scenarios have been selected for simulation this dissertation.
2.5.1. Scenarios [11] where routing protocols are needed for smart
building networks
2.5.1.1 Local adaptation to presence
This scenario adapts the room environment on detection of human presence. The room environment
consists of lighting, temperature and electric appliances. Thus, motion/presence sensors, temperature
and light sensors are necessary.
14 Chapter 2. Background and Related Work
In this scenario the routing protocol is tested for its reliability and its latency.
2.5.1.2. Emergency management
In case of a fire emergency, the building occupants will have to be provided with a safe path to exit
the building. This application will analyze information provided by the sensors to build a safe path to
an exit by using visible or audible output devices to guide people. The guidance information can also
be received on an occupants mobile device.
The sensors necessary for this process are temperature and smoke detection sensors.
The routing protocol, for this scenario, should have the following qualities:
Low latency (fast routing is required)
Fault tolerance (in the case of failure of some of the nodes, alternative routes to the safe exit has to be found quickly)
Short time for updating the routing table
Short time for a route to propagate in the network
2.5.1.3. CO2 monitoring
By using CO2 sensors, it is intended to adapt the heating, ventilating, and air-conditioning system to
renew the air based on the CO2 level. This approach is considered more appropriate for meeting rooms
and office spaces. (CO2 level low no need for ventilation, CO2 level high increase ventilation)
This scenario requires a network of CO2 sensors to be distributed in the space. The sensors sense the
CO2 level and send it to a central sink node. Based on the results of comparing the CO2 level to the
established thresholds for personal comfort, the HVAC system is adjusted. The routing protocol is
tested for reliability and latency.
2.5.1.4. Maintenance control
This scenario uses sensors to detect abnormal activities and provide alerts to the maintenance team.
According to [11], some examples of abnormal activities are:
Lights not working
A leak is detected
An abnormal electricity consumption is detected
A window remains open in an empty room
A tap remains open in an empty room
An abnormal temperature is detected
2.5. Smart Buildings 15
2.5.1.5. Resources tracking and monitoring
This scenario requires the tracking of high-value portable items and sending an alert should the item
leave the building (either the item is misplaced or has been borrowed without permission). For the
notification in case an item leaves the building to be as close as possible to real time, it is required for
the routing protocol to have a low latency.
The next chapter presents an early attempt to integrate the ContikiRPL into the SpeckSim simulator,
and describes the implementation of the tested routing protocols.
16
17
Chapter 3
Design and Implementation
This chapter presents the rationale for attempting to integrate ContikiRPL into the SpeckSim
simulator and the reason why this path was not pursued further. It also provides details regarding the
design and implementation of the tested protocols (RPL, SimplePv1-v4 and DSDV).
3.1. Attempt to integrate ContikiRPL into SpeckSim
I was made aware early in the project that the Swedish Institute of Computer Science (SICS) provided
an open-source RPL implementation in compliance with the ROLL IETF draft [1] that was integrated
with the Contiki operating system, and ran on the Tmote Sky platform. The ContikiRPL
implementation can be tested in conjunction with the Cooja network simulator.
According to [23], In March 2010, an interoperability event hosted by the IPSO Alliance took place
in Anaheim, CA. ContikiRPL participated in this event and was tested against a number of emerging
RPL implementations. Since ContikiRPL had been tested it was reasonable to treat it as a trustworthy
and reliable implementation of the protocol.
This led me to use this RPL implementation in SpeckSim instead of creating a new one. For achieving
this, the natural course of action was to first understand the ContikiRPL code and then port it into
SpeckSim. ContikiRPL was implemented in C using the APIs of the Contiki operating system. (All
parts of the implementation except for the uIP-specic ICMP message processing are portable to other
operating systems and the routing protocol uses Contikis modular IPv6 routing interface.[3])
The first problem that was encountered was that the ContikiRPL is implemented in C whereas the
SpeckSim simulator was written in Java. However, when I tried to run the ContkiRPL, the most
convenient way was to run it in the Cooja simulator which was also written in Java. This led to the
idea of finding out how the Cooja simulator (Java) called the ContikiRPL code (C) and try to do the
same for the SpeckSim network simulator.
18 Chapter 3. Design and Implementation
The easiest way to get Cooja along with the ContikiRPL implementation is to download a virtual
machine that comes with all installations of Contiki software, development tools which can be
downloaded from [24].
Different examples (rpl-udp, rpl-collect, rpl-border-router) that use ContikiRPL can be found in
the virtual machine in /contiki-2.x/examples/ipv6. When Cooja starts, it automatically loads some
projects including these examples. Unfortunately, at this stage a problem appears due to the fact that
Cooja is trying to load its project files from a different directory than the one they are stored in. This
can be resolved by copying the needed files into the directory required by Cooja (this is more simple
than changing the required directory in Cooja). When opening the ContikiRPL scenario examples,
Cooja first compiles them. This also raises a problem. In order to not get errors at compilation, some
small changes to the Makefile files for each of the examples are required. These changes consist of
modifying the paths provided in the first line of the Makefile files to match the actual intended
location/path. These problems were encountered after performing the update of the virtual machine in
June 2011. It is possible that later/subsequent updates have solved these problems.
Figure 3.1: Cooja simulator - 1 sink, 6 senders running ContikiRPL
3.1. Attempt to integrate ContikiRPL into SpeckSim 19
Figure 3.2: Cooja simulator - Sensor Map and Network Graph
Figures 3.1 and 3.2 are screenshots of the GUI of the Cooja simulator while running a small scenario
consisting of a7-node topology running the RPL protocol.
After looking through a Cooja tutorial [25] for setting a low-power IPv6/RPL network, I could
observe that when starting a new project and loading sink and sender nodes, the sources for these
types of nodes need to be compiled and created in the simulator. The user interface provides a
Compile button that changes into a Create button if the source file is compiled successfully. I
have noticed that the files that the simulator loads in order to create sink and sender nodes were the
ones linking the simulator to the ContikiRPL code. Both files were written in C and were calling the
ContikiRPL code. I figured that I should find the answer of how Cooja uses the ContikiRPL code by
understanding how these files are compiled when loaded in the simulator. In order to do this I first
needed to find where the code for Coojas Compile button is. After analyzing Coojas source files, I
noticed that the main method is in the GUI.java file, and afterwards I searched for the Create and
Compile buttons. The code for these buttons can be found in AbstractCompile.java file. This had the
purpose of finding out how the udp-sink.c and udp-sender.c are compiled and further used in the
simulator.
After researching the ContikiRPL and the Cooja simulator I came to the following conclusions:
In Cooja, the complete firmware of a device is loaded and used within the simulator; there is no
interaction between network layers or device behaviour coded for the Cooja simulator and those coded
for Contiki. The best approach in this case consists in extracting the RPL layer and creating a library
containing it. The library should contain sufficient JNI implementation to make its functions available
to SpeckSim. The approach of using a library developed for a hardware platform requires two
20 Chapter 3. Design and Implementation
components: one in Java in the simulator and a wrapper in C that provides the JNI calls. The C
wrapper is required to expose the functions of the library without modifying the library itself. The
Java class then maps between the simulator APIs and the exported JNI calls. The issue of storing and
loading fields from, and to, the native library would also need to be addressed. This is handled in
Cooja by storing the entire memory of the mote device (ContikiMote.java). This would not be needed
in the case of SpeckSim.
Even thought comments within the source files of the Cooja network simulator mention the use of JNI
to call C code, I could not find any trace of JNI code in Coojas source files (nor in the ContikiRPLs
.c files). I have noticed that the files that use ContikiRPL (such as udp-sink.c and udp-sender.c from
/contiki-2.x/tools/examples/ipv6/rpl-collect) which are loaded by the Cooja simulator, are kernel
modules or pieces of code that run in kernel space and are compiled together with the Contiki kernel /
operating system.
A possible solution for achieving this (by using JNI calls) can be seen in the following example:
Consider the 3 layers of behaviour: application, routing (RPL) and MAC. The application and MAC
are implemented in SpeckSim and the network layer would consist of a native compiled RPL (from
Contiki). Sending a packet would have the flow presented as in Figure 3.3:
Figure 3.3: Solution for ContikiRPL in SpeckSim
3.2. RPL 21
Some additional parameters would be required to keep track of which device is active but the
approach is feasible.
However, I chose not to go through with this approach because of the fact that I would end up
spending far too much time to understand and use Contiki rather than the SpeckSim simulator. Also,
the approach is rather complex and complicated, the code is difficult to follow and it requires deep
knowledge of Contiki and the simulator architecture. Even though this is possible to achieve, since the
time to complete this project is quite limited, there was no guarantee of success.
Compilation of the Contiki RPL implementation into a usable native library may also be a problem as
the standard Contiki build setup will use cross compilers for microprocessors, although it is
expected to be gcc compliant.
My original reasoning for considering the integration of ContikiRPL into SpeckSim in the first place,
was that I could obtain a validated RPL implementation (the ContikiRPL) in SpeckSim quickly and I
could spend more time in testing the protocol instead of dealing with its implementation. Since this
proved to be far more challenging than expected, and also more time-consuming, I took the decision
not to pursue this goal any further.
3.2. RPL
RPL was developed to be used as a standard routing protocol in WSNs deployed in different
environments such as: urban networks, smart grid networks, industrial networks, building and home
networks[21].
It is optimised for collection networks (which are based on Multipoint-to-Point (MP2P) and Point-to-
Multipoint (P2MP) traffic) with occasional Point-to-Point (P2P) traffic. The collection networks have
multiple nodes which report periodically to few collection/sink nodes, and the sink nodes choose to
communicate with one of the sender nodes in a P2P fashion.
RPL uses MP2P traffic for the process of collecting data (measurements) and uses P2MP traffic for
configuration purposes for the nodes that have to report to the sink nodes.
Starting from a node called Root (a sink node), RPL builds a DODAG (Destination Oriented Directed
Acyclic Graph) with the help of the DIO (DODAG Information Object) messages generated by the
Root. The DODAG has the role of minimising the cost of reaching the Root from any node in the
network. Each node within the DODAG holds a rank value which is calculated based on the
information received in DIO messages. The rank for a node increases as the node is further away from
22 Chapter 3. Design and Implementation
the Root node. The routing towards the DODAG Root is based on the rank values, as a node roughly
picks the neighbour with the lowest rank when sending a packet up the DODAG.
Nodes within a RPL network exchange information with the purpose of maintaining the DODAG. The
messages that carry DODAG information are called DIO (DODAG Information object) messages.
(All the nodes in the network regularly issue a DIO which serves as a heartbeat to indicate their rank.
The instant at which a node issues a DIO is governed by a Trickle timer which is reset only when an
inconsistency arises. This way, when the topology is stable, very few DIOs are exchanged.[22])
RPL uses another type of messages called DAO (Destination Advertisement Object) messages, which
are sent from each node in the network towards the Root node. Based on the information contained in
these messages (a list of node identifiers from all nodes that were traversed by this message), the Root
node knows which nodes a packet has to go through in order to reach a certain destination.
3.2.1. Types of RPL messages
DIO DODAG Information Object. DIO messages are sent periodically by the Root node and carry
information that allows a node to discover a RPL Instance, learn its configuration parameters, select
a DODAG parent set, and maintain the DODAG.[1] The most important information contained by this
message is the DODAG-ID, the Objective Function and the rank of the broadcasting node (which is
used by the receiving node to calculate its own rank). The DIO messages are sent periodically with an
increasing sequence number in order to trigger the parent selection process (described in Section
3.2.2.1. Upward routing) that leads to recalculation of the DODAG that further leads to repairing
existing broken links.
DIS DODAG Information Solicitation. It is used to trigger a DIO transmission from a RPL node.
This type of message is usually used when nodes join a network. As an alternative to waiting to
receive a DIO message, a node can choose to broadcast a DIS message so that other nodes will
immediately trigger a DIO transmission upon receiving the DIS message.
DAO Destination Advertisement Object. DAO is used to propagate information up the DODAG
towards the Root node. Depending on the type of routing, DAO messages can be unicast messages
sent from children to selected parents (storing mode) or unicast messages sent to the DODAG Root
(non-storing mode). In either case, the DAO messages follow a common structure. The most
significant information that is carried by a DAO message is the Reverse Route Stack. As a DAO
message travels up the DODAG towards the Root node, each node that it passes through appends its
unique ID to this stack.
3.2. RPL 23
DAO ACK Destination Advertisement Object Acknowledgement. This type of message is
optional and is sent as an unicast message to a DAO recipient which can either be a DAO parent or the
DODAG Root.
CC Consistency Check. The CC message is used to check secure message counters and issue
challenge/responses. A CC message MUST be sent as a secured RPL message.[1]
3.2.2. RPL routing
3.2.2.1. Upward routing
RPL provides routes up the DODAG towards the DODAG Root, constructing a DODAG optimized
according to an Objective Function. This is accomplished by sending DIO messages from the
DODAG Roots down the DODAG, towards the leaf nodes. With the help of these messages the
DODAGs are formed and maintained. A node is able to join a DODAG by discovering neighbours
that are already part of the DODAG of interest and by having built a parent set. The parent set
represents a subset of the candidate neighbour set (which contains the nodes reachable via link-local
multicast). Any neighbour with a lower rank than the node itself is considered as a candidate parent.
From the parent set, a preferred parent is elected which will be used as the next hop for all upward
routes.
This allows for Multipoint-to-Point communication within a WSN that runs RPL.
Regarding the Upward routing process, the construction of the DODAG is of great importance. The
process of the DODAG construction is based on the Distributed Algorithm Operation and it involves
assigning / configuring some nodes as DODAG Roots. These nodes send DIO messages (link-local
multicast) to all the RPL nodes with the intention of advertising their presence, affiliation with a
DODAG, routing cost and related metrics [1]. The nodes always listen for DIO messages and they use
the information provided by these messages to join a new DODAG or maintain the existing one.
(Nodes provision routing table entries, for the destinations specified by the DIO message, via their
DODAG parents in the DODAG Version. Nodes that decide to join a DODAG can provision one or
more DODAG parents as the next-hop for the default route and a number of other external routes for
the associated instance.[1])
3.2.2.2. Downward routing
RPL can also provide routes down the DODAG in order to reach certain nodes (that are not DODAG
Roots). This is accomplished by sending DAO messages up the DODAG towards the DODAG Root.
Usually downward routes are Point-to-Multipoint routes (from a DODAG Root towards leaf nodes),
but with the help of the DAO messages, Point-to-Point routing can also be supported. (Point-to-
24 Chapter 3. Design and Implementation
Point messages can flow toward a DODAG Root (or a common ancestor) through an upward route,
then away from the DODAG Root to a destination through a downward route.)
The downward routes can be maintained in two modes, called storing and non-storing. In
storing mode, all non-root and non-leaf nodes store a routing table for the downward routes for
their sub-DODAG. The routing tables are formed based on the information provided by the DAO
messages. When a message is travelling on a downward route in storing mode, routing decisions
(determine the packets next hop) are taken at every hop (based on each hops stored routing table).
In non-storing mode, the non-root nodes do not have to store a routing table. Only the DODAG
Root has to store and maintain a routing table, thus making it responsible for all downward routing
decisions. The messages are routed down the DODAG based on source routes provided by the
DODAG Root. This mode is highly dependent on the DODAG Root node (if the Root node fails to
store some information, then some of the destinations may not be reached).
Point-to-Point routing can be supported by both storing and non-storing modes.
3.2.3. Objective Function
The Objective Function (OF) indicates the method that must be used to construct the DODAG. Nodes
become aware of the OF when receiving a DIO message. (An OF defines how nodes translate one or
more metrics and constraints into a value called Rank, which approximates the node's distance from a
DODAG Root. An OF also defines how nodes select parents.[1])
RPL supports a variety of Objective Functions, due to its large number of applications. The OF allows
customising the way RPL builds the routing topology based on various metrics and constraints. RPL
was developed offering this flexibility in order to be able to better accommodate networks used by a
wide range of applications.
The Objective Function used by the RPL implementation in the SpeckSim simulator mainly consists
in calculating a nodes rank based on simple hop counting.
3.2.4. Trickle timer
(The Trickle algorithm allows wireless nodes to exchange information in a highly robust, energy
efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to
spread new information on the scale of link-layer transmission times while sending only a few
messages per hour when information does not change. A simple suppression mechanism and
transmission point selection allows Trickle's communication rate to scale logarithmically with
density.[6])
3.3. SimpleP 25
Trickle is an efficient algorithm for propagating data changes in a network. RPL uses Trickle to
ensure that nodes in a given neighbourhood have consistent, loop-free routes.
The RPL implementation (in SpeckSim) uses the Trickle timer for the DIO transmissions. The
transmission of this type of message is periodic and it is triggered by the Trickle timer. The timer
requires setting two intervals between two DIO transmissions: a minimum interval and a maximum
interval. It starts from the minimum interval and with every transmission it doubles its duration until
it reaches the maximum interval. When the maximum interval is reached, the transmissions will be
maintained at a constant rate (which is dictated by this maximum interval). However, the timer is
forced to reset to the minimum interval with any change that occurs in the DODAG structure.
3.2.5. RPL in SpeckSim
In SpeckSim two different specks were used: one to simulate a RPL Root node (called RPLRoot) and
another that can take the place of both a router node or a leaf node (called RPLRelay). The routing
logic for the RPL protocol was implemented as a behaviour (called RPLRouting).
3.3. SimpleP
SimpleP is a basic routing protocol. It is regardless of the memory possessed by the nodes or the
machine that runs a simulation environment for this protocol.
It sends triggered updates. The trigger is represented by the occurrence of a change in a nodes routing
table. The important fields carried by this message are the source ID, a sequence number and the
sending nodes entire routing table. In order to avoid routing loops, the protocol uses the number of
hops as the main (and single) metric. The routing table stores only one route to a destination, the best
route (the route with the lowest number of hops to the destination).
A routing table entry contains the following fields: Destination, Next Hop and Hops.
Destination holds the ID of the speck that needs to be reached
Next Hop represents the next hop to which packets for the specified destination should be forwarded
Hops represents the number of hops that the packet has to pass through to get to the destination
The SimpleP protocol has three versions based on the number of update messages that it sends. Since
the update messages carry a nodes entire routing table, and for a large number of nodes the routing
tables become very large in terms of routing table entries, memory and bandwidth consumption, the
number of such packets exchanged by the nodes of a network is very important.
26 Chapter 3. Design and Implementation
3.3.1. SimplePv1
The first version of SimpleP, SimplePv1 enables nodes to send an update message every time a
change of a routing table entry occurs. This is the version with the worst performance.
3.3.2. SimplePv2
The second version of the SimpleP protocol provides a slight improvement over the first version.
When a node receives an update message, it makes all the necessary changes (imposed by the received
update) to its routing table before it sends out an update message. These changes could consist in
modifying, adding or deleting several routing entries from the routing table. Since all these changes
are sent out in a single message, it reduces the number of update messages exchanged in the network.
3.3.3. SimplePv3
The third version is an optimized version of the SimplePv2. It uses a timer for delaying the
transmission of an update message for five seconds after a change in the nodes routing table occurs.
In this case, if in those five seconds the node receives other update messages from its neighbours and
its routing table is changed several times, the protocol sends only one update that contains all these
changes.
3.3.4. SimplePv4
3.3.4.1. Bidirectional Links
Since unidirectional links exist in reality and some of the channel models will also have them in
simulation, a small adaptation to the previous versions of SimpleP (because they are building tables
based on reception) consists in only using bidirectional links for routes. An example of how this can
be done is the following: Consider 2 nodes (Node_A and Node_B), if Node_A receives from Node_B,
it does not add Node_B to the routing table but instead sends an acknowledgement to Node_B.
Node_B can then add Node_A to its table. Then Node_B sends an acknowledgement back to Node_A.
When Node_A receives the acknowledgement from Node_B, it adds Node_B to the routing table.
This process is used only for establishing connections between neighbouring nodes (nodes that are in
radio range of each other).
3.3.4.2. Routing Table Maintenance
Another important improvement that SimplePv4 has over its previous version consists in the process
of maintaining the routing tables. This process consists of verifying if the routes learned from a
3.3. SimpleP 27
neighbour still exist in that neighbours table. When node A receives an update from node B, it checks
for each destination that has B as the next hop, if B still has a route to that destination in its table. If B
no longer has a route to that destination in its table, then A will also remove it from its table. In this
way, when a broken link occurs, the information can propagate through the network.
3.3.4.3. Dealing with Broken Links
This process is based on the relationship between neighbouring nodes. If a node doesnt receive any
messages from a neighbour in period of time, it assumes that his neighbour is inactive and it deletes it
from its routing table as well as all the routes that have this neighbour as the next hop. In order to
avoid this from happening, all nodes send periodic hello messages. In the current implementation of
SimplePv4, a node has to miss three hello messages from a neighbour in order to consider it inactive.
The protocol also considers the case when two nodes (A and B) establish a neighbour adjacency and
after that, one of the nodes (A) moves and settles in a position so that it can still receive messages
from its neighbour (B), but B cannot receive any messages from A. An illustrative example can be
observed in Figure 3.4.
Figure 3.4: Why NAK is needed
In this case, B will remove A from its routing table, as well as all routes that have the next hop A, but
A will still keep B as a neighbour and all routes through B. The solution for correcting this behaviour
is to make B send a negative acknowledgement (NAK) to A when it erases A from its routing table.
When A receives the NAK, it removes B and every route that had B as a next hop from its routing
table.
In order to achieve all of these improvements in SimplePv4, the protocol no longer sends only one
type of message (the update message), but is also exchanges three other types: Hello messages (send
periodically), ACK messages (used for establishing neighbour adjacencies/connections) and NAK
messages (used for terminating neighbour connectivity).
28 Chapter 3. Design and Implementation
By having these last features in SimplePv4, the protocol can also be tested in fault tolerance
scenarios along side of RPL.
3.3.5. Limitations of SimpleP
SimpleP does not scale well with the size of the topology due to the following limitations:
Node Memory: As the topology increases in size, the routing tables get larger. In a WSN the nodes
are sensors which are constrained in terms of most resources, especially memory. Thus, every node
storing a routing table containing every other node in the network is not the best approach for a WSN.
Bandwidth consumption: Since SimpleP sends the entire routing table in every update message, for
a large number of nodes in a topology, thus a large routing table, the protocols overhead will have a
significant bandwidth usage.
Processing power and time consumption: When a SimpleP node receives an update, it has to
sequentially go through all routes in the table received in the update message. For each route in the
received routing table it has to iterate through its own table to see if it already knows that route, or if it
is a new route. For very large routing tables and a large number of updates received by a node, this
proves to be costly in terms of processing time and processing power.
3.4. DSDV
The routing information is sent in broadcast messages to all neighbours of a node. These messages are
sent periodically once every few seconds (periodic updates) and when topology changes are detected
(immediate or triggered updates).
The broadcast update message contains the following information:
Message Sequence Number (used to identify the update message, each update message generated by one node contains a new sequence number)
Source Address (the address of the node that is sending the update message)
The Advertised Routing Table (which can be incremental (contains just the routes that changed since the last full dump update) or full (contains all the routes stored by the nodes Forwarding Table)) which contains route entries with the following information:
o Destination Address
o Metric = Number of Hops (the number of hops required to reach the destination)
o Route Sequence Number (the sequence number for the route to the specified destination, as originally stamped by the destination)
3.4. DSDV 29
DSDV uses as a main/primary metric the Route Sequence Number. This helps nodes to distinguish
if a route is more recently generated than another one regarding a specific destination. Even sequence
numbers are assigned to valid routes and odd numbers to the invalid ones. The route with the larger
sequence number is preferred for making forwarding decisions, but not necessarily advertised.
The secondary metric used by DSDV is the number of hops to reach a destination. If a node has to
choose between routes for a destination that have the same sequence number, than the route with the
smaller number of hops is preferred.
When a node adds a route into its forwarding table, it increases the number of hops by 1.
DSDV has four types of update messages: periodic and triggered, full dump and incremental.
Periodic updates are scheduled as can be observed in Figure 3.5.
Figure 3.5: DSDV periodic updates
Periodically, between each full dump update are sent incremental updates (as mentioned earlier,
incremental updates contain just the information that changed since the last full dump update).
Both full dump and incremental updates can be periodic and both can be triggered.
Incremental updates are triggered when significant changes occur. These significant changes
consist in adding a new route in the table or changing the next hop or the metric (= number of hops)
for a destination. Just changing the sequence number for a route in the table (with the next hop and
metric remaining the same) does not count as a significant change, and can wait to be advertised with
the next periodic scheduled update.
Full dump updates are triggered when due to the information that should be sent in an incremental
update, the update packet exceeds the NPDU (Network Protocol Data Unit) size. This usually happens
when movement of nodes becomes frequent.
Broken links. The adjacency between neighbour nodes is maintained through the periodic broadcast
messages. If a node does not receive any broadcasts from one of his neighbours for a defined period of
30 Chapter 3. Design and Implementation
time, it considers the link with its neighbour to be broken. The process that needs to be followed this
case has three phases:
1. Changing the metric for the route to the inactive neighbour and for all routes that have this neighbour as the next hop to ".
2. Assign a new odd sequence number for these routes
3. Trigger an immediate update
An invalid route can be replaced when an update that contains a route with a greater sequence number
for that destination is received.
All DSDV nodes deal with two types of tables: Forwarding Table and Advertised Table. Figure 3.6
exposes both these tables. The Advertised table is sent in the update messages and it is generated from
the Forwarding Table before an update is sent. The Forwarding Table is used by each node in its
forwarding decisions. All changes caused by information received in update messages are made in this
table (the Forwarding Table).
Figure 3.6: Forwarding and Advertised Tables for node 1 (4-node topology - SpeckSim)
This implementation of DSDV contains a feature not specified in the paper [17]. This was previously
described for the SimplePv4 protocol with the intention of using only bidirectional links for routes.
This small adaptation was implemented because the protocol is building tables based on reception.
(This problem was previously explained in Section 3.3.4.1. Bidirectional Links.) The solution consists
of establishing the neighbour adjacencies by exchanging acknowledgement (ACK) messages and
terminating it by using negative acknowledgement (NAK) messages.
3.4. DSDV 31
3.4.1. DSDV features that differ from SimplePv4
DSDV SimplePv4
1. Type of updates (periodic - triggered)
Periodic update messages
Triggered update messages
Periodic hello messages (to maintain neighbour adjacencies)
Triggered update messages (triggered by topology changes)
2. Metric
Uses 2 metrics:
Main metric sequence number
Secondary metric number of hops
Uses only one metric
Number of hops
3. Type of updates (full dump - incremental)
Incremental updates
Full dump updates
Full dump updates
4. Broken links
Uses something close to poison reverse (when
a node detects a broken link, it keeps the
routes to and through that neighbour with a
changed metric of and a new odd sequence number, and then triggers an immediate
update in order to advertise the routes as
invalid)
When a node detects a neighbour as inactive,
it removes the route to and through that
neighbour from its table, and sends an update
message. Neighbours that receive the update
message from this node will perform the
routing table maintenance process as
described previously in Section 3.3.4.2.
Table 3.1: DSDV SimplePv4 differences
According to [15] [16], DSDV is one of the earliest algorithms available. It provides loop-free routing
and it is suitable for creating small-size ad hoc networks.
The next chapter describes the validation of the RPL implementation in the SpeckSim simulator
against the ContikiRPL implementation.
32
33
Chapter 4
Validation
This chapter describes the validation of the SpeckSim RPL implementation against the ContikiRPL
implementation provided by the Swedish Institute of Computer Science. It presents the validation
scenario, the results that were obtained and the conclusion drawn from them.
4.1. Validation Scenario
The first step in RPLs evaluation was to validate the implementation in SpeckSim against a correct
RPL implementation before further testing, evaluation and comparisons with other protocols. In this
regard, the ContikiRPL protocol provided in the Cooja simulator was chosen to play the role of a
validation benchmark for RPL.
The ContikiRPL is a trustworthy RPL implementation since it was tested successfully against other
RPL implementations in 2010 at an interoperability event hosted by the IPSO Aliance.
The validation process works as follows: the same network topology (see Figure 4.1), inspired by a
real-life scenari