Professional Documents
Culture Documents
RPL Client Server
RPL Client Server
Master of Science
Computer Science
School of Informatics
University of Edinburgh
2011
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.
iii
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.
iv
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.
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
vi
vii
viii
List of Figures
Figure 2.1: SpeckSim GUI Screenshot [9].......................................................................................... 7
Figure 2.2: SpeckSim Architecture [9] ............................................................................................... 7
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
ix
List of tables
xi
List of Abreviations
WSN
LLN
MANET
IETF
ROLL
RPL
DSDV
AODV
DSR
RIP
OSPF
EIGRP
IS-IS
MAC
DODAG
DIO
DAO
CPU
MCU
Microcontroller Unit
ACK
Acknowledgement
NAK
Negative Acknowledgement
xii
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.
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).
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.
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.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 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.
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.
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
Figure 2.2 presents a diagram showing the components of the simulator. As shown in the diagram, the
simulator is made up of:
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]
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 QoSaware 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).
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).
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.
[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
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 lowpower 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:
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.
11
12
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.
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.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
In this scenario the routing protocol is tested for its reliability and its latency.
Fault tolerance (in the case of failure of some of the nodes, alternative routes to the safe exit
has to be found quickly)
A leak is detected
15
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
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).
17
18
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.
19
20
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:
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-toMultipoint (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
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. RPL
23
24
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.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.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.
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
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. 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.
28
By having these last features in SimplePv4, the protocol can also be tested in fault tolerance
scenarios along side of RPL.
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
Metric = Number of Hops (the number of hops required to reach the destination)
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.
30
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.
3.
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
1.
SimplePv4
2.
Metric
Uses 2 metrics:
3.
Number of hops
Incremental updates
4.
Broken links
The next chapter describes the validation of the RPL implementation in the SpeckSim simulator
against the ContikiRPL implementation.
32
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.
33
34
Chapter 4. Validation
Figure 4.1: Validation topology Informatics Forum floor plan 11 node network deployment
4.1.2. Cooja
The ContikiRPL data was collected after running the protocol on the topology presented in Figure 4.2.
For this topology two sets of data were gathered: one having the RPL Root node placed in the most
favourable position and another having it placed in the most detrimental position. In Figure 4.2 the
Root node (node 11) is placed in the most favourable position because it will form a well balanced
DODAG. The second test has the Root node placed in the most detrimental position which is the
position of node 5. This position is the most detrimental because it leads to forming the most poorly
balanced DODAG that can be formed based on this topology.
Figure 4.2: ContikiRPL Test Topology The RPL Root in favourable position (Cooja Simulator)
35
Section A of the Appendix describes how to use the Cooja simulator in order to build RPL
simulations.
4.1.3. SpeckSim
The same topology was built in SpeckSim and can be viewed in Figure 4.3. When the RPL data was
collected, the RPL Root once took the position of node 6 and once the position of node 11, thus
achieving both the most favourable and most detrimental RPL scenarios based on this topology.
36
Chapter 4. Validation
SpeckSim Overhead
6898 packets / 350 sec
37
SpeckSim Overhead
6958 packets / 350 sec
38
Chapter 4. Validation
The figures presenting the ContikiRPL data were generated by the Cooja Simulator and imported in
this document. The figures presenting the SpeckSim RPL implementation were separately built
based on the data gathered from the simulator.
4.3. Conclusions
As can be seen in the previous section (4.3. Validation Results), the results obtained for the two
implementations of RPL are fairly similar. When looking over the figures presenting the results, keep
in mind that the nodes numbers differ for the topologies used in Cooja and the topologies used in
SpeckSim. Thus, relate the nodes numbers with those in the corresponding topology figure.
The number of hops from every node in the topology to the RPL Root is identical for both RPL
implementations. The graphs presented in the left part of figures 4.4 and 4.7 were generated by the
Cooja simulator, and the tables presented in the right part of these figures were created based on data
gathered from the SpeckSim simulator.
The RPL DODAG formed by the Root node is also identical for both RPL implementations. The trees
presented on the left side of figures 4.5 and 4.8 were generated by the Cooja simulator. The trees
presented on the right side of figures 4.5 and 4.8 were built based on the data gathered from the
SpeckSim simulator (each nodes preferred parent and rank value).
The overheads of the two RPL implementations are similar. In the favourable case, the overhead is
almost the same (the difference is less than 1%). For the detrimental case, the overhead for the two
protocol implementations differs slightly, but it does not raise a concern because this can be dependent
on various aspects of the implementation. It is expected that two separate implementations of the same
protocol cannot have identical results, yet they may have similar ones. A 22% difference in the
generated overhead still makes the overhead of the ContikiRPL similar to that of the SpeckSim RPL
implementation (in the detrimental case). It can also be observed that in the detrimental case, both
RPL implementations generate a larger number of control packets compared to the favourable case.
These results conclude the validation of the SpeckSim RPL implementation against the ContikiRPL.
Since the SpeckSim RPL implementation has quite similar behaviour to that of the ContikiRPL when
tested on an 11-node Building topology, it can be considered to be a faithful implementation of the
RPL protocol.
The next chapter describes the testing process and methods used for evaluating the protocols in
wireless sensor networks.
Chapter 5
Testing
This chapter provides details about the methods used to test the protocols. It presents the simulation
environment, the topology types used for the different testing scenarios, the metrics used to evaluate
the protocols, the types of network traffic generated and the process of gathering statistics in the
SpeckSim simulator.
Specks position: the positions of the specks in the simulator are taken from an external input
file: Movement Models Current Model File Position InputFile.txt. InputFile.txt holds
the coordinates of the specks in the following format: every line represents the coordinates of
a speck and it contains three numbers separated by commas x, y, z with x, y, z having
values between 0 and 1.
Sensor/Speck characteristics:
MCU: Configurable MCU (Active current: 0,005; Sleep current: 0,001; Off current: 0)
39
40
Chapter 5. Testing
5.2.2. Grid
The grid topologies shown in Figure 5.2 ensure that all nodes are within reach (there are no isolated
nodes). Different grid topologies may be observed in Figure 5.2. Even though the topologies differ
based on the number of specks, the distance between any two adjacent specks is 0.2 units.
41
5.2.3. Tree
Since RPL is a treeoriented protocol, testing the protocol on tree-shaped networks represents a
natural step in RPLs performance evaluation. It is expected that RPLs performance should be
enhanced on these types of networks compared to the SimpleP and DSDV protocol. Several treeshaped topologies built in SpeckSim can be seen in Figure 5.3.
5.2.4. Building
Building topologies are meant to simulate real-life deployments of wireless sensor networks. As a test
example, the floor structure of the Informatics Forum was chosen. As can be observed in Figure 5.4, it
is supposed that the corridor (suggested by the thick green line) is equipped with wireless sensors
placed at approximately equal distance between them. It is possible to simulate this scenario in
SpeckSim by limiting the radio ranges of the nodes so that each node can reach just its closest
neighbours. This is suggested by the purple circles which represent the radio ranges of the nodes. The
topology built in SpeckSim can be observed in the right part of the figure. The distance between the
nodes is of approximately 0.1 units and the nodes ranges are 0.11 units.
All topologies/scenarios except the Building ones were tested with the speck configurations described
in section 5.1. Simulation Environment. In this case (Building scenarios), the radio ranges of the nodes
had to be altered in order to better accommodate these topologies.
42
Chapter 5. Testing
5.3. Metrics
43
5.3. Metrics
Choosing the metrics for evaluation is important and should be relevant to routing in wireless sensor
networks.
5.3.3. Coverage
The purpose of a routing protocol is to find a route (or multiple routes) from a source to a destination.
The Coverage metric indicates the percentage of the total devices/nodes in the network that each node
can reach. This metric is calculated based on the number of routes towards different destinations in the
network that each node has in its routing table.
44
Chapter 5. Testing
5.3.5. Latency
This metric is of great concern to almost any types of networks, not just WSNs. In some WSNs (even
Smart Building Networks) applications, immediate/fast responsiveness of the network is quite crucial.
An example is the Emergency management scenario described in section 2.5.1.2.
The latency in the Routing layer is different from the latency in the MAC layer. In the case of the
MAC layer, it can be calculated as an average latency per hop, but the latency in the Routing layer has
to be calculated over several hops. The Routing layer latency is strongly related to the number of hops
a packet has to go through and the time that a node takes to search its routing table (which is based on
the size of the table).
Its overhead affects the power consumption by using the transceiver to send control packets
(Update/Hello/ACK/NAK packets)
Its processing of the information received in Update packets (for maintaining the routing
tables) affects the power consumption by intensively using the CPU
5.3. Metrics
45
Environments Failure
o
Cause ID failure
46
Chapter 5. Testing
other nodes in the network learn about its presence. However, in RPLs case it is measured the time
that passes until the information about the new node reaches the Root node.
Unfortunately, there wasnt enough time allocated to the project to measure this metric, therefore the
evaluation based on this metric is left for future work.
MP2P (MultiPoint-to-Point)
P2MP (Point-to-MultiPoint)
The full test of Peer-to-Peer traffic pattern consists in any random node trying to
send to every other node.
47
The State class takes the state of the simulator which is a snapshot with everything at that instant.
Everything (a speck, a protocol, a behaviour) has a getState method. The state of the simulator is all
handled and done automatically; its only needed to specify in the state the information of interest.
The Statistics class is used to calculate and generate statistics based on the information gathered in the
state object.
For gathering statistics for the routing protocols, RoutingState.java and RoutingStatisticsModule.java
were implemented in SpeckSim. These classes are used for calculating and generating the following
statistics:
1.
2.
3.
4.
The coverage percentage (how many nodes can it reach of the total nodes in the network) for
each node in the topology
5.
The average size of the routing table for each node in the topology
6.
For measuring other features such as Power Consumption and the number of control packets
generated by the protocol, the simulator already had the necessary Statistics classes implemented.
In order to use the State and Statistics classes, the user has to go through the following menus of the
SpeckSim GUI: Interface Generate Data X Variable (Variable name: Time; Start value: 0; Data
points: 40; Stop value: 200; Output name: <a_name>).
The mentioned settings lead to 40 different measures to be taken within the first 200 seconds since the
nodes are activated and the protocol is started. These settings were used for almost all test scenarios.
For processing the gathered data and generate the statistics: Interface Data post process:
Run processes
The next chapter 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 a protocol comparison
48
Chapter 6
Results and Critical Analysis
This chapter presents the results gathered from running the tests described in Chapter 5, and is
structured on the metrics that are evaluated for each of the protocols. After presenting the results and
their interpretation for each metric, the chapter concludes with an evaluation of all the tested
protocols.
49
50
7000
6000
5000
4000
3000
2000
1000
0
0
20
41
61
82
102
123
143
164
184
300
250
200
150
100
50
0
DSDV Overhead
0
20
41
61
82
102
123
143
164
184
RPL Overhead
Time (s)
64 nodes
Time (s)
27 nodes
8 nodes
64 nodes
SimplePv2 Overhead
2500
2000
1500
1000
500
0
0
20
41
61
82
102
123
143
164
184
0
20
41
61
82
102
123
143
164
184
12000
10000
8000
6000
4000
2000
0
Time (s)
Time (s)
8 nodes
64 nodes
SimplePv4 Overhead
No. of Control Packets
184
164
143
123
102
82
61
41
20
70
60
50
40
30
20
10
0
0
8 nodes
SimplePv3 Overhead
200
150
100
50
0
Time (s)
27 nodes
27 nodes
0
20
41
61
82
102
123
143
164
184
27 nodes
64 nodes
8 nodes
SimplePv1 Overhead
64 nodes
27 nodes
Time (s)
8 nodes
64 nodes
27 nodes
8 nodes
51
From the graphs presented in this section, it can be seen that RPL and the SimplePv4 protocol have a
similar behaviour. This consists of a high overhead in the initial stage due to the fact that the nodes
exchange a large number of control messages in order for the network to converge. After the network
converges, the nodes still exchange control messages between them, but the number of messages
exchanged in the network is significantly reduced. However, SimplePv4 has a higher overhead than
RPL after the network converged because it sends periodical keep-alive messages (Hello messages).
SimplePv1, SimplePv2 and SimplePv3 have similar behaviours amongst themselves, but they do not
compare with RPL and SimplePv4 because even if they generate a high initial overhead, after the
networks converged SimplePv1-v3 nodes stop sending any control packets. These protocols send only
update messages triggered by the occurrence of topology changes.
DSDVs behaviour is different from all of the other protocols. DSDV has constant high control
packet burst intervals due to the generation of new sequence numbers assigned to the routes. These
new sequence numbers are periodically advertised in incremental and full dump updates.
Overhead
3200
SimplePv1
DSDV
800
SimplePv2
200
SimplePv4
SimplePv3
50
0
10
20
30
41
51
61
71
82
92
102
112
123
133
143
153
164
174
184
194
12800
Time (s)
Figure 6.7: Overhead Flow
RPL
52
Overhead
100000
10000
1000
100
10
RPL
DSDV
8 nodes
64 nodes
53
Table Size
15
RPL_Storing_F
10
RPL_Storing_D
RPL_NonStoring_F
RPL_NonStoring_D
DSDV
SimplePv1
SimplePv2
SimplePv3
Figure 6.9: Table Size (Number of Entries)
It can be observed that RPL in storing mode has a considerable lower average table size (measured in
terms of the number of entries of the table) than the other protocols, even for this small 11-node
topology. This is due to the fact that the size of the routing table for RPL nodes decreases towards the
leaf nodes, because each node stores routes only towards the nodes that are below it in the DODAG.
RPL in non-storing mode has a very low average table size due to the fact that only the Root node
stores routes towards the other nodes in the topology. This saves up a lot of memory for all the nodes
in the topology except the Root node, but will lead to an increase in the networks latency because all
packets will have to be routed through the Root node.
The following graphs (Figures 6.10 6.13) reveal how the average table size increases with the
number of nodes in the network for each of the protocols, in the different types of topologies.
20
10
0
B_11 nodes
B_24 nodes
200
100
0
G_8 nodes
G_27 nodes
G_64 nodes
G_125 nodes
54
150
100
50
0
R_27 nodes
R_64 nodes
R_125 nodes
100
50
0
T_21 nodes
T_91 nodes
55
2.
3.
2.
3.
4.
Sequence Number
a.
b.
2.
Path metrics values for each DODAG parent 32 bits (the size of this field can change for
different topologies; it depends on the number of parents of a node; for the topology used
(Building topology Informatics Forum 11 nodes), each node has only one parent)
2.
3.
4.
a.
DAO-Sequence 32 bits
b.
Path Sequence 104 bits (this has a variable size, but for the topology used, the
value was calculated based on the height of the DODAG)
c.
d.
Destination Prefix (or Address or Multicast Group IPv6 Address) 128 bits
56
Memory (bits)
Memory Usage
RPL_Storing_F
4000
3500
3000
2500
2000
1500
1000
500
0
RPL_Storing_D
RPL_NonStoring_F
RPL_NonStoring_D
DSDV
SimplePv1
SimplePv2
SimplePv3
6.3. Coverage
A nodes coverage of the network is strongly related to the size of the table in terms of the number of
route entries. The results presented in this section were gathered from different types and sizes of
topologies.
Coverage
100
80
60
40
20
0
RPL_Storing_F
RPL_Storing_D
RPL_NonStoring_F
RPL_NonStoring_D
DSDV
SimplePv1
SimplePv2
Figure 6.15: Coverage 11-node Building Topology (Informatics Forum)
6.3. Coverage
57
The graphs presented in Figures 6.16 6.19 reveal how the average coverage of each protocol varies
for different types and sizes of topologies.
Coverage (%)
100
50
0
B_11 nodes
50
0
B_24 nodes
G_8 nodes
G_27 nodes
G_64 nodes
G_125 nodes
100
100
Coverage (%)
Coverage (%)
100
50
0
R_27 nodes
95
90
R_64 nodes
R_125 nodes
T_21 nodes
T_91 nodes
The results suggest that a better coverage is obtained for networks with a larger number of nodes.
RPLs average coverage in non-storing mode is given by the following formula:
_ =
1
Topology_Size(Number_Of_Nodes)
This means that RPLs average coverage in non-storing mode decreases with the size of the topology.
In all the cases, DSDV appears to have a higher coverage than the other protocols.
58
50
B_11 nodes
100
50
0
B_24 nodes
G_8 nodes
G_27 nodes
G_64 nodes
G_125 nodes
60
40
20
0
R_27 nodes
R_64 nodes
R_125 nodes
60
40
20
0
T_21 nodes
T_91 nodes
6.5. Latency
59
6.5. Latency
The latency was measured on the 11-node Building Topology. The amount of traffic generated was
the same as in the case of measuring the delivery ratio (after the network converged, each node sends
a data packet to every other node in the network).
Latency
0.07
0.06
0.05
0.04
0.03
0.02
0.01
0
RPL_Storing_F
RPL_Storing_D
RPL_NonStoring_F
RPL_NonStoring_D
DSDV
SimplePv1
SimplePv2
SimplePv3
SimplePv4
Figure 6.24: Latency 11-node Building Topology (Informatics Forum)
The graph in Figure 6.24 reveals that RPL has a higher latency than the other protocols. This is due to
the fact that RPL is a hybrid protocol; it does not store full routing tables (i.e. that every RPL node
does not store a route to every other node in the topology). In the case of RPL there is a trade-off
between the memory that the protocol uses and the latency of the network. It is interesting to test the
latency metric for RPL because the Root node has very good routes to every other node, but non-root
nodes may have very bad routes to the other nodes depending on their position in the tree. (A bad
route is considered a route that will have a large number of hops for its advertised destination.)
The latency for the DSDV and SimplePv1-v4 protocols is about the same due to the fact that every
one of these protocols stores full/complete routing tables (having a route for all the other nodes in the
topology).
60
The power consumption was calculated from the current consumption and the voltage drawn by the
node. The current consumption was determined from the batterys capacity and the lifetime of the
battery.
PowerConsumption
80
60
40
20
0
RPL
DSDV
61
packets to node 2, node 3 fails. Node 1 still forwards packets to node 3 with the destination node 2
until it detects node 3s failure. When this happens, it stops sending packets and tries to find another
route to 2. Thus, the route through node 4 is established, and then node 1 continues to send packets.
All packets transmitted after node 3 failed and until node 1 detected the failure are lost. Since the
packets were sent at a constant rate of 1 packet / second, the packet loss also represents the time
(measured in seconds) that it took the network to reconverge.
This time and the packet loss will increase with the distance (in terms of number of hops) between the
sending node and the node that fails. This is due to the additional delay necessary for the information
regarding the failure to propagate through the network in order to reach the sending node so it will
stop transmitting.
6.7.2. Results
The results for the fault toleration scenario are presented in Figure 6.27.
Fault Tolerance
60
40
DSDV
SimplePv4
20
0
DSDV
SimplePv4
Figure 6.27: Fault Tolerance
SimplePv1, SimplePv2 and SimplePv3 were not designed to cope with the occurrence of failures, thus
they were not included in this test.
According to the IETF Draft for RPL, by contrast with other routing protocols, RPL does not define
any 'keep-alive' mechanisms to detect routing adjacency failures: this is because in many cases such a
mechanism would be too expensive in terms of bandwidth and even more importantly energy (a
battery operated device could not afford to send periodic Keep alive). Still RPL requires an external
mechanism to detect that a neighbour is no longer reachable. Such a mechanism should preferably be
reactive to traffic in order to minimize the overhead to maintain the routing adjacency and focus on
links that are actually being used.[1] The current RPL implementation available in SpeckSim is able
62
to detect when a node fails, but the DODAG is not automatically readjusted. Thus, the SpeckSim RPL
implementation is not fault tolerant.
The only two protocols which are able to detect and handle failures successfully are DSDV and
SimplePv4. The results for them are presented in Figure 6.27, and can be observed that DSDV
performs better than SimplePv4 for this scenario because it has a lower packet loss. This is probably
due to the following reasons:
1.
2.
The time in which a node does not receive messages from a neighbour and still keeps the
connection active is different for DSDV and SimplePv4.
Implementation Complexity
Number of Classes
Lines of Code
Implementation Complexity
1500
1000
500
0
30
20
10
0
RPL
DSDV
SimplePv1
RPL
DSDV
SimplePv1
SimplePv2
SimplePv3
SimplePv4
SimplePv2
SimplePv3
SimplePv4
Figure 6.28 presents the complexity of the protocols in terms of lines of code and Figure 6.29
presents the complexity in terms of the number of classes. It can be observed that RPL is by far the
most complex, followed by DSDV and SimplePv4.
63
No
1
2
3
4
5
6
7
Metric
Overhead Size
(125node Topology)
Avg. Table Size
(11node Topology)
Avg. Coverage
(11node Topology)
Avg. Latency
(11node Topology)
Power Consumption
(64node Topology)
Fault Tolerance
(4node Topology)
Implementation
complexity
Protocol
RPL
DSDV
SimplePv1
SimplePv2
SimplePv3
SimplePv4
900
54578
9972
1996
337
2558
1.9
11
10
10
9.7
10
19.3
100
100
100
92.7
100
0.041
0.026
0.025
0.025
0.022
0.025
61
33.75
30
30
30
32.72
36
48
1406
823
362
360
378
621
64
The evaluation of the average coverage for the DSDV and SimplePv1-v4 protocols was done in an
ideal case in which the specks that were running the protocols were not constrained in terms of
memory. This is the reason why the average coverage of these protocols turned up to be this high.
As for RPL, it has 100% coverage across the RPL instance because there should always be a route
through the tree. However, the average coverage of all the RPL nodes is significantly lower compared
to the results of the other protocols that were tested.
DSDV and SimplePv1-v4 protocols do not scale with the size of the network for the following
reasons:
The table size, measured in terms of the number of bytes, which affects the coverage of the
protocols
The table size, measured in terms of the number of entries in the table, which affects the
latency and CPU power
With this taken into account, the RPL protocol is the only protocol (from the ones that this project
tested) suitable for use in networks with a large number of nodes.
The next chapter presents the final remarks, conclusions and observations, along with suggestions for
future work.
Chapter 7
Conclusions and Further Work
This chapter summarises the conclusions drawn based on the results presented in Chapter 6 and ends
with some suggestions for future work.
7.1. Conclusions
This dissertation has presented the implementation, characterisation and comparison of a selection of
routing protocols for wireless sensor networks in terms of protocol behaviour and performances. Its
focus has been on the RPL routing protocol which is the proposed IETF candidate for a standard
routing protocol in wireless sensor networks.
Based on the results obtained in the previous chapter it was argued that RPL is the only protocol from
the ones that were tested which is suitable for use in networks with a large number of nodes (over 200
nodes). The other protocols (DSDV, SimplePv1, SimplePv2, SimplePv3 and SimplePv4) are not
scalable with the size of the network due to their table sizes which grow linearly with the number of
nodes in the topology.
When considering small to medium-sized networks (less than 100 nodes), RPLs performance does
not outclass that of the other protocols that were tested. Table 2 in Chapter 6 reveals that each
protocol has its strengths. Thus when choosing a protocol for a wireless sensor network deployment,
the decision should be based on the specific requirements of the WSN application, in order to choose
the protocol with the most suitable qualities for the application. For instance, in the case of the
Emergency management scenario described in Section 2.5.1.2, low latency and fault tolerance are
the most important qualities that the routing protocol should posses. Therefore, DSDV or SimplePv4
would be the appropriate protocols to use in this scenario (if the size of the network does not cause the
routing tables to exceed the nodes memory).
This thesis tested the mentioned protocols behaviour and performance only in the case of static
wireless sensor networks. The RPL protocol is targeted for use in static networks. However as the
65
66
need for mobile wireless sensor networks increases, it may be appropriate for the chosen standard
routing protocol for wireless sensor networks to be able to cope with both static and mobile networks.
In this regard, a very recent paper [26] claims to provide a study of an extension which allows RPL to
handle the presence of nodes mobility and also an implementation of a mobility-aware RPL version.
If this will be proven to satisfy the needs of both static and mobile wireless sensor networks
applications, it will make RPL a complete protocol for use in wireless sensor networks.
From all protocols evaluated in this thesis, only DSDV and SimplePv4 may be suitable to run in
mobile networks. However, in order for the DSDV protocol to adequately run in real-life wireless
sensor networks, the protocol has to support a feature that is not included in its original specification.
This feature involves establishing only bidirectional links between DSDV neighbours, due to the fact
that real-life radio shells are not perfect spheres.
The aim of this thesis was to evaluate the behaviour and performance of the RPL protocol and
compare it to other protocols suitable for use in wireless sensor networks. The project managed to
achieve its goal by simulating the protocols in the SpeckSim simulator in various WSN scenarios and
by providing valid analysis and interpretation for the data that was collected.
Testing and evaluating the protocols with respect to other metrics such as CPU load and
route propagation time in the network, as mentioned in Chapter 6.
2.
Implement other MANET protocols relevant to compare to RPL such as AODV and DSR,
and evaluate RPL against them for statics scenarios.
3.
Evaluate the performance of the protocols regarding the delivery ratio metric using
different MAC protocols in order to reveal which is the most suitable MAC protocol.
4.
Re-evaluate the comparison of the overhead size of the protocols considering the different
types and sizes of the control packets exchanged by the protocols (not only the number of
packets).
5.
Reconsider the integration of ContikiRPL into the SpeckSim simulator, due to the fact that
the current RPL implementation provided in SpeckSim is not fault tolerant. As an alternative
to this approach, the current SpeckSim RPL implementation could be improved to become
fault tolerant.
6.
Use real devices (sensors) to deploy a small-size real-life wireless sensor network in order
to validate the results collected so far from the simulator. This can be done by deploying the
same scenario both in reality and in the simulator, and then observing the extent of the
results similarity. It can be assumed that if for small topology scenarios the results are
considerably similar, then this similarity might scale with increases in number of nodes.
Bibliography
[1]
T. Winter (Ed.), P. Thubert (Ed.), and the ROLL Team. RPL, Internet-Draft, RPL: IPv6
Routing Protocol for Low power and Lossy Networks, draft-ietf-roll-rpl-19, March 13, 2011
[2]
[3]
Nicolas Tsiftes , Joakim Eriksson , Adam Dunkels, Low-power wireless IPv6 routing with
ContikiRPL, Proceedings of the 9th ACM/IEEE International Conference on Information
Processing in Sensor Networks, April 12-16, 2010, Stockholm, Sweden
[4]
[5]
[6]
Networking Working Group, Internet-Draft, The Trickle Algorithm, draft-ietf-roll-trickle01, January 10, 2011
[7]
[8]
C.S. Raghavendra, Krishna M. Sivalingam and Taieb Znati, Wireless Sensor Networks, 2004
[9]
[10] Charles Waltner, Smart Buildings Offering Clever Ways to Reduce Energy Consumption,
July 21, 2008, http://newsroom.cisco.com/dlls/2008/ts_072108.html [Online; accessed 13August-2011]
[11] FIRE/STREP ICT 257466, HOBNET, Holistic Platform Design for Smart Buildings of the
Future Internet, Deliverable D1.1, Scenario Analysis Report, http://www.hobnetproject.eu/files/D1.1.PDF [Online; accessed 13-August-2011]
[12] http://www.smart-buildings.com [Online; accessed 13-August-2011]
67
68
Bibliography
[13] Charles E. Perkins, Elizabeth M. Belding-Royer, and Samir R. Das, Ad Hoc On-demand
Distance Vector (AODV) Routing, IETF Internet draft, draft-ietf-manet-aodv-09.txt,
November 2001
[14] http://moment.cs.ucsb.edu/AODV, [Online; accessed 13-August-2011]
[15] Khushboo Tripathi, Tulika Agarwal and S. D. Dixit, Performance of DSDV Protocol over
Sensor Networks, 2010
[16] Abdul Hadi Abd Rahman, Zuriati Ahmad Zukarnain, Performance Comparison of AODV,
DSDV and I-DSDV Routing Protocols in Mobile Ad Hoc Networks, 2009
[17] Charles E. Perkins, Pravin Bhagwat, Highly dynamic Destination-Sequenced DistanceVector routing (DSDV) for Mobile Computers, Proceedings of the conference on
Communications architectures, protocols and applications, p.234-244, August 31-September
02, 1994, London, United Kingdom
[18] D. Johnson, D. Maltz, Y. Hu, The Dynamic Source Routing Protocol for Mobile Ad Hoc
Networks (DSR), Internet draft, draft-ietf-manet-dsr-09.txt, Apr 15, 2003
[19] David B. Johnson, David A. Maltz, Josh Broch, DSR: The Dynamic Source Routing Protocol
for Multi-Hop Wireless Ad Hoc Networks, Ad hoc networking, Addison-Wesley Longman
Publishing Co., Inc., Boston, MA, 2001
[20] D. B. Johnson, D. A. Maltz, Dynamic Source Routing in Ad-hoc Wireless Networks. In T.
Imielinksi and H. Korth, editors, Mobile Computing, pages 153-181. Kluwer Academic
Publishers, 1996
[21] J. Tripathi, J. C. de Oliveira, J. P.Vasseur, A performance evaluation study of RPL: Routing
Protocol for Low power and Lossy Networks, Information Sciences and Systems (CISS),
March 2010
[22] OpenWSN, Implementing the Internet of Things, http://openwsn.berkeley.edu/wiki/OpenRpl,
[Online; accessed 13-August-2011]
[23] ContikiRPL: the new Default Contiki IPv6/6lowpan Routing Protocol, 05 May 2010,
http://www.sics.se/contiki/tutorials/contikirpl-the-new-default-contiki-ipv6/6lowpan-routingprotocol.html, [Online; accessed 13-August-2011]
[24] Instant Contiki, 25 August 2008, http://www.sics.se/contiki/instant-contiki.html, [Online;
accessed 13-August-2011]
Bibliography
69
70
Appendix
A. How to use the Cooja Simulator
How to start the Cooja Simulator
1.
2.
3.
Once the simulator has started, it is possible to create a new simulation by accessing the File menu.To
add nodes into the simulation: Mote Add mote of type (and choose a mote type).
Create and add RPL nodes in the simulation
Access the upper-left menu bar: Mote Types Create mote type Sky Mote Type. This will trigger
the appearance of a pop-up menu. In the Contiki process / Firmware field of the pop-up menu, it has
to be chosen either the udp-sender.c file (for creating a RPL router or leaf) or udp-sink.c (for
creating a RPL Root) file from the rpl-collect project that can be found at the following path
~/contiki-2.x/examples/ipv6/rpl-collect. After selecting one of these files, it needs to be compiled by
using the Compile button, and if the compilation is successful, a Create button will appear that
can be used to import the desired type of speck into the simulator. The next step is to choose the
number of the selected type of sensors and the type of positioning and the position interval of the
sensors.
B. NoComments Script
This script was used to eliminate the Java comments and the empty lines from the source code files.
#!/bin/bash
TOTAL=$((0))
for file in $@
do
LINES=`cat ${file} | grep -v ^$ | grep -v /\*.*?\*/ | grep -v
^[[:blank:]]*'\*'.*$ | wc -l`
echo ${file}: ${LINES}
TOTAL=$((${TOTAL}+${LINES}))
done
echo
echo "Total lines: "${TOTAL}
71