Performance Evaluation of Routing Protocols in Lossy Links for Smart Building Networks

Transcription

1 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

2

3 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), RPL s 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

4 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

5 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) v

6 Table of Contents Introduction Wireless Sensor Networks Routing in WSN Motivation Previous Work Outline... 3 Background and Related Work RPL SpeckSim Literature Survey Routing protocols relevant for comparing to RPL DSDV [15],[17] AODV [13],[14] DSR [18],[19] Smart Buildings Scenarios [11] where routing protocols are needed for smart building networks 13 Design and Implementation Attempt to integrate ContikiRPL into SpeckSim RPL Types of RPL messages RPL routing Objective Function Trickle timer RPL in SpeckSim SimpleP SimplePv SimplePv SimplePv SimplePv Limitations of SimpleP vi

7 3.4. DSDV DSDV features that differ from SimplePv Validation Validation Scenario Cooja SpeckSim Validation Results Favourable case Detrimental case Conclusions...38 Testing Simulation Environment Topology types Random Grid Tree Building Metrics Protocol Overhead Size of table Coverage Delivery Ratio / Packet loss Latency Power consumption Fault tolerance (Recovery time) Route propagation time within the network Implementation complexity CPU load Types of Traffic Statistics gathering process in SpeckSim...46 Results and Critical Analysis Protocol Overhead Control packet generation flow...49 vii

8 Overhead Size Size of Table Number of Entries Memory Usage Coverage Delivery Ratio Latency Power Consumption Fault Tolerance Scenario Results Implementation Complexity Overall Results Interpretation Conclusions and Further Work Conclusions Future work Bibliography Appendix A. How to use the Cooja Simulator B. NoComments Script viii

9 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 Figure 3.2: Cooja simulator - Sensor Map and Network Graph Figure 3.3: Solution for ContikiRPL in SpeckSim Figure 3.4: Why NAK is needed Figure 3.5: DSDV periodic updates Figure 3.6: Forwarding and Advertised Tables for node 1 (4-node topology - SpeckSim) Figure 4.1: Validation topology Informatics Forum floor plan 11 node network deployment Figure 4.2: ContikiRPL Test Topology The RPL Root in favourable position (Cooja Simulator).. 34 Figure 4.3: RPL Validation Topology (SpeckSim) Figure 4.4: Hops to DODAG Root Figure 4.5: RPL DODAG Figure 4.6: Overhead Figure 4.7: Hops to DODAG Root Figure 4.8: RPL DODAG Figure 4.9: Overhead Figure 5.1: Random Topology in SpeckSim Figure 5.2: Grid Topologies in SpeckSim Figure 5.3: Tree Topologies in SpeckSim Figure 5.4: Building Topology (Informatics Forum 24 nodes) in SpeckSim Figure 5.5: Building Topology (Informatics Forum 11 nodes) in SpeckSim Figure 5.6: Fault Toleration Example Figure 6.1: RPL Overhead Figure 6.2: DSDV Overhead Figure 6.3: SimplePv1 Overhead Figure 6.4: SimplePv2 Overhead ix

10 Figure 6.5: SimplePv3 Overhead Figure 6.6: SimplePv4 Overhead Figure 6.7: Overhead Flow Figure 6.8: Overhead Size Figure 6.9: Table Size (Number of Entries) Figure 6.10: Table Size Building Figure 6.11: Table Size Grid Figure 6.12: Table Size Random Figure 6.13: Table Size Tree Figure 6.14: Memory Usage 11-node Building Topology (Informatics Forum) Figure 6.15: Coverage 11-node Building Topology (Informatics Forum) Figure 6.16: Coverage Building Figure 6.17: Coverage Grid Figure 6.18: Coverage Random Figure 6.19: Coverage Tree Figure 6.20: Delivery Ratio Building Figure 6.21: Delivery Ratio Grid Figure 6.22: Delivery Ratio Random Figure 6.23: Delivery Ratio Tree Figure 6.24: Latency 11-node Building Topology (Informatics Forum) Figure 6.25: Power Consumption Figure 6.26: Fault Tolerance Topology (SpeckSim) Figure 6.27: Fault Tolerance Figure 6.28: Complexity (Lines of Code) Figure 6.29: Complexity (Number of Classes) x

11 List of tables Table 3.1: DSDV SimplePv4 differences Table 6.1: Protocols Metrics Summary xi

12 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 xii

13 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 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. 1

14 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) 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 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.

15 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 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 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.

16 4

17 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 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. 5

18 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 SpeckSim s graphical user interface.

19 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]

20 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] 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 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). 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

21 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 adhoc 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.

22 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 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 RPL s 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 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 RPL s 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.

23 2.4. Routing protocols relevant for comparing to RPL Routing protocols relevant for comparing to RPL 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 protocol s 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

24 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 paper s 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 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 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.

25 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 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 Scenarios [11] where routing protocols are needed for smart building networks 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.

26 14 Chapter 2. Background and Related Work In this scenario the routing protocol is tested for its reliability and its latency 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 occupant s 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 CO 2 monitoring By using CO 2 sensors, it is intended to adapt the heating, ventilating, and air-conditioning system to renew the air based on the CO 2 level. This approach is considered more appropriate for meeting rooms and office spaces. (CO 2 level low no need for ventilation, CO 2 level high increase ventilation) This scenario requires a network of CO 2 sensors to be distributed in the space. The sensors sense the CO 2 level and send it to a central sink node. Based on the results of comparing the CO 2 level to the established thresholds for personal comfort, the HVAC system is adjusted. The routing protocol is tested for reliability and latency 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

27 2.5. Smart Buildings 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.

28 16

29 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) 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-specific ICMP message processing are portable to other operating systems and the routing protocol uses Contiki s 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. 17

30 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 It is possible that later/subsequent updates have solved these problems. Figure 3.1: Cooja simulator - 1 sink, 6 senders running ContikiRPL

31 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 Cooja s Compile button is. After analyzing Cooja s 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

32 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 Cooja s source files (nor in the ContikiRPL s.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

33 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 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

34 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 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 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.

35 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] RPL routing 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] ) 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-

36 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 packet s 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 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 node s rank based on simple hop counting 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] )

37 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 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) 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 node s routing table. The important fields carried by this message are the source ID, a sequence number and the sending node s 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 node s 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.

38 26 Chapter 3. Design and Implementation 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 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 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 node s 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 SimplePv 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) 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

39 3.3. SimpleP 27 neighbour still exist in that neighbour s 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 Dealing with Broken Links This process is based on the relationship between neighbouring nodes. If a node doesn t 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).

40 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 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 protocol s 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 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 node s Forwarding Table)) which contains route entries with the following information: o o 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)

41 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

42 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 Bidirectional Links.) The solution consists of establishing the neighbour adjacencies by exchanging acknowledgement (ACK) messages and terminating it by using negative acknowledgement (NAK) messages.

43 3.4. DSDV 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: Uses only one metric Main metric sequence number Number of hops Secondary 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 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.

44 32

45 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 Validation Scenario The first step in RPL s 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 scenario in the deployment of a wireless sensor network in the Informatics Forum, was implemented in both SpeckSim and Cooja simulators. In both simulators (SpeckSim and Cooja) will be deployed the same network topology. This topology is inspired from a real-life scenario, consisting in the deployment of wireless sensors on one of the floors of the Informatics Forum. This topology is illustrated in Figure 4.1. It is possible to have this topology design in both SpeckSim and Cooja by limiting the radio ranges of the nodes so that they can only reach their closest neighbours. 33

46 34 Chapter 4. Validation Figure 4.1: Validation topology Informatics Forum floor plan 11 node network deployment 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)

47 4.2. Validation Results 35 Section A of the Appendix describes how to use the Cooja simulator in order to build RPL simulations 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. Figure 4.3: RPL Validation Topology (SpeckSim) 4.2. Validation Results In both simulators, for both test cases (the most favourable and most detrimental), the deployed RPL network was monitored for the first 350 seconds since all nodes started. The results gathered from this simulation are presented in this section.

48 36 Chapter 4. Validation Favourable case Number of hops from every node to the RPL Root Figure 4.4: Hops to DODAG Root RPL DODAG Figure 4.5: RPL DODAG Protocol Overhead Cooja Overhead SpeckSim Overhead 6964 packets / 350 sec 6898 packets / 350 sec Figure 4.6: Overhead

49 4.2. Validation Results Detrimental case Number of hops from every node to the RPL Root Figure 4.7: Hops to DODAG Root RPL DODAG Figure 4.8: RPL DODAG Protocol Overhead Cooja Overhead SpeckSim Overhead 9031 packets / 350 sec 6958 packets / 350 sec Figure 4.9: Overhead

50 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 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 node s 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.

51 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 Simulation Environment The simulation environment is the SpeckSim network simulator. SpeckSim was configured to simulate a wireless sensor network with the following characteristics: Environment characteristics: Specks movement: static (not mobile) 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: Battery: Configurable Capacity Battery (mah capacity: 1; Voltage: 3) MCU: Configurable MCU (Active current: 0,005; Sleep current: 0,001; Off current: 0) MAC Protocol: CarrierSenseMAC ( CSMA MAC protocol) Radio: Selectable Shell Radio (Perfect Radio Shell; Range 0,35) Power up delay: Min=0, Max=1 Application Start delay: 0 39

52 40 Chapter 5. Testing 5.2. Topology types Random Many real world applications use random topologies. Such applications use wireless sensors scattered / dispersed in certain areas of interest with the intention of collecting data from that environment. A random topology built in SpeckSim can be observed in Figure 5.1. Figure 5.1: Random Topology in SpeckSim 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. Figure 5.2: Grid Topologies in SpeckSim

53 5.2. Topology types Tree Since RPL is a tree oriented protocol, testing the protocol on tree-shaped networks represents a natural step in RPL s performance evaluation. It is expected that RPL s 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. Figure 5.3: Tree Topologies in SpeckSim 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.

54 42 Chapter 5. Testing Figure 5.4: Building Topology (Informatics Forum 24 nodes) in SpeckSim The protocols were tested on two topologies that are based on the Informatics Forum floor plan. These topologies differ in terms of the number of nodes. The topology in Figure 5.5 has only 11 nodes. In reality, if one were to equip the corridor of a floor in the Informatics Forum with wireless sensors, the deployment in Figure 5.5 would have been chosen due to cost considerations. Thus the deployment presented in Figure 5.5 is closer to reality than the one in Figure 5.4. However, the topology presented in Figure 5.4 was used for the purpose of testing the protocols on a denser network in order to reveal if their behaviour or performance change when the number of nodes of the network is increased. Figure 5.5: Building Topology (Informatics Forum 11 nodes) in SpeckSim For both Building topologies (presented in Figures 5.4 and 5.5) the RPL protocol was tested when the Root node was placed once in the most favourable position and once in the most detrimental one. The most favourable position to place the Root node is where it allows the forming of the most balanced DODAG. The most detrimental position is one in which the DODAG formed by the Root is as poorly balanced as possible. For the topology in Figure 5.4, the most favourable position for placing the RPL Root is the position of node 12, and the most detrimental one is the position of node 24. For the topology in Figure 5.5, the most favourable position for placing the RPL Root is the position of node 6, and the most detrimental one is the position of node 11.

55 5.3. Metrics Metrics Choosing the metrics for evaluation is important and should be relevant to routing in wireless sensor networks Protocol Overhead This metric is measured in terms of the number of control packets exchanged by the nodes in the topology. Since WSNs are highly constrained networks, a high protocol overhead could place a heavy burden on the network. This being the case, the protocol overhead is an important metric to be taken into account when evaluating a routing protocol for WSNs Size of table Since nodes of WSNs are constrained in terms of memory, a metric that measures the memory usage per node should be taken into account. And since the routing table is the most memory consuming, this metric is solely based on the size of the routing table 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 Delivery Ratio / Packet loss The Delivery Ratio is defined as the ratio between the number of packets received by a destination node and the number of packets sent to this destination by a source node. The routing layer does not really discard a packet; it just tries to find a route. Thus, if a packet has not turned up at the destination, it means that it probably got dropped in the MAC layer. However, Delivery Ratio is an important metric often used for the routing process as well and it can be further used in Fault Tolerance scenarios to reveal the packet loss from the time a nodes fails to the time the network reconverges.

56 44 Chapter 5. Testing 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 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) Power consumption Since wireless sensors are power constrained as they run on batteries, the power consumption is one of the most important concerns. The power consumption is primary related to the radio transceiver (especially when it is used to transmit packets, not so much when it just receives) and then to the CPU when it is used intensively. Thus, the power consumption is significantly dependent on the routing protocol: 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 Fault tolerance (Recovery time) In the case when there are at least two paths towards a destination, a routing protocol chooses the best one with respect to the metrics that it uses. But, if a node on the chosen path fails, the failure needs to be detected and propagated throughout the network. This will lead to choosing an alternative path towards that destination if one exists. A suggestive example is presented in Figure 5.6. In Phase 1, node 1 can reach node 4 through both node 2 and 3, but the best path is chosen through 2. In Phase 2 node 2 becomes inactive (fails), so node 1 needs to detect this. Phase 3 reveals that node 1 terminated the link to node 2 (it changes from green to blue), and established a route towards node 4 through node 3.

57 5.3. Metrics 45 Figure 5.6: Fault Toleration Example A system is fault tolerant if it continues to operate properly in the event of failure of some of its components. Thus, in terms of computer/sensor networks, it is useful to know the number of packets that are lost due to the occurrence of a device failure before the network reconverges (detects the failure, propagates the information through the network and tries to find other routes between the nodes that were initially linked by the failed device). Faults occur frequently in WSNs, and for various real-life WSNs applications it is required an evaluation that reveals to what extent the deployed networks are fault tolerant. An example of such applications is presented in section Emergency management. For the purpose of simulating failure scenarios, the SpeckSim simulator allows the user to force a node (or an area consisting of several nodes) to fail. This is possible by accessing the following menus: Environments Failure o Cause ID failure o Cause area failure Route propagation time within the network The route propagation time is the time it takes for a change in the network topology to propagate so that each of the network s nodes will be informed about this change. An example that might be used for testing is introducing a new node in the network, and measuring the time that passes until all the

58 46 Chapter 5. Testing other nodes in the network learn about its presence. However, in RPL s case it is measured the time that passes until the information about the new node reaches the Root node. Unfortunately, there wasn t enough time allocated to the project to measure this metric, therefore the evaluation based on this metric is left for future work Implementation complexity It is useful to know the implementation complexity of a routing protocol if it is desired to run it on specific devices, thus requiring to port the protocol or to implement it from scratch on a different platform. This metric is measured in terms of lines of code and since the protocols are implemented in Java, it is also measured in terms of the number of classes used CPU load Since wireless sensors are constrained in both energy and processing power, it is useful to know how big is the burden that the routing protocol places on the sensors CPU. However, as in the case of the route propagation time metric, this metric has also been left for future work Types of Traffic There are three possible types of traffic: MP2P (MultiPoint-to-Point) P2MP (Point-to-MultiPoint) P2P (Point-to-Point / Peer-to-Peer) o The full test of Peer-to-Peer traffic pattern consists in any random node trying to send to every other node. The evaluation of the protocols focuses more on Peer-to-Peer traffic Statistics gathering process in SpeckSim In order to gather statistics in SpeckSim two classes are needed: a State class and Statistics class.

59 5.5. Statistics gathering process in SpeckSim 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; it s 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. The number of data packets sent by all nodes in the topology 2. The number of data packets received at their destinations 3. The delivery ratio 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. The average latency for a data packet transmission 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: Dataset search root: select the file <a_name> Active processes Add element: Statistics Run processes This will generate a.csv file containing the desired statistics. 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

60 48

61 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 Protocol Overhead The protocol overhead is measured in terms of the number of control packets exchanged by a network running the protocol for a period of time. The statistics regarding the overhead of the protocols were gathered from grid topologies of different sizes. The sizes of the topologies, measured in terms of the number of nodes, were 8, 27 and 64 nodes. Based on these statistics, graphs were constructed to reveal the flow of the network overhead over time and the size of the overhead for each of the protocols tested Control packet generation flow Protocol Overhead Flow The following graphs (Figures ) show how the overhead of the protocols over time scales with the size of the network. 49

62 No. of Control Packets No. of Control Packets No. of Control Packets No. of Control Packets No. of Control Packets No. of Control Packets 50 Chapter 6. Results and Critical Analysis RPL Overhead DSDV Overhead Time (s) Time (s) 64 nodes 27 nodes 8 nodes 64 nodes 27 nodes 8 nodes Figure 6.1: RPL Overhead Figure 6.2: DSDV Overhead SimplePv1 Overhead SimplePv2 Overhead Time (s) Time (s) 64 nodes 27 nodes 8 nodes 64 nodes 27 nodes 8 nodes Figure 6.3: SimplePv1 Overhead Figure 6.4: SimplePv2 Overhead SimplePv3 Overhead SimplePv4 Overhead Time (s) 64 nodes 27 nodes 8 nodes Figure 6.5: SimplePv3 Overhead Time (s) 64 nodes 27 nodes 8 nodes Figure 6.6: SimplePv4 Overhead

63 No. of Control Packets 6.1. Protocol Overhead 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. DSDV s 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 Flow Comparison The graph presented in Figure 6.7 exposes the overhead flow for all the six tested protocols. Based on this graph it is possible to observe how the behaviour of each protocol (in terms of the overhead flow) relates to the others. In order for this graph to be more comprehensive, a logarithmic scale was used for the No. of Control Packets axis. Overhead SimplePv1 DSDV SimplePv2 SimplePv4 SimplePv3 RPL Time (s) Figure 6.7: Overhead Flow

64 No. of Control Packets 52 Chapter 6. Results and Critical Analysis Overhead Size Overhead RPL DSDV SimplePv1 SimplePv2 SimplePv3 SimplePv4 8 nodes 27 nodes 64 nodes Figure 6.8: Overhead Size Based on the graph presented in Figure 6.8 it is possible to compare the size of the overhead for each of tested protocols. Based on these results, RPL s performance, in terms of the size of the generated overhead, is better than most of the other protocols. For a better exposure of the overhead sizes, this graph also uses a logarithmic scale for the No. of Control Packets axis Size of Table Number of Entries The number of entries in the routing table is important because when a node needs to forward a packet, it performs a sequential search over all the entries in its routing table until it finds the route for the desired destination. If the route is not found, the node either uses a default route if one is available, or discards the packet. In a very large network where the nodes have very large routing tables, when a node receives many packets that it needs to forward, it will have to perform the sequential search for every packet. This will create a delay in the forwarding process thus affecting the network s latency. Also, it will place a significant burden on the nodes CPU. The statistics presented in Figure 6.9 are gathered from all protocols tested on the 11-node Building (Informatics Forum) topology.

65 Table Size (Entries) Table Size (Entries) Average Table Size (Entries) 6.2. Size of Table 53 Table Size 15 RPL_Storing_F 10 RPL_Storing_D 5 RPL_NonStoring_F RPL_NonStoring_D 0 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 network s latency because all packets will have to be routed through the Root node. The following graphs (Figures ) 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. Table Size - Building Topologies Table Size - Grid Topologies G_8 nodes G_27 nodes B_11 nodes B_24 nodes G_64 nodes G_125 nodes Figure 6.10: Table Size Building Figure 6.11: Table Size Grid

66 Table Size (Entries) Table Size (Entries) 54 Chapter 6. Results and Critical Analysis Table Size - Random Topologies Table Size - Tree Topologies R_27 nodes R_64 nodes R_125 nodes T_21 nodes T_91 nodes Figure 6.12: Table Size Random Figure 6.13: Table Size Tree Results Analysis In all these cases, RPL using non-storing routing has an average table size of approximately one entry, because only the Root node stores entries to all other node in the network. The other nodes will just store the next hop (DODAG parent) and the path metrics values for each DODAG parent. Throughout all the Table Size graphs presented in this section, it can be observed that the size of the routing table for the DSDV protocol is slightly bigger than the table sizes in the case of the four versions of the SimpleP protocol. This is because every DSDV node stores an additional route compared to SimpleP nodes. This additional route is a route to itself with the metric zero. (It has as destination and next hop the current node and the metric (number of hops to the destination) zero.) Memory Usage The size of the table in bits of memory can be determined based on the number of entries in the table. The number of entries is linear with the size of the table, thus it is possible to relate the size of the table with the number of entries it has, only if the sizes of the entries are the same. Unfortunately, the protocols evaluated in this study have entries of different sizes (except the versions of SimpleP which have the same routing table entries). Thus for each entry, the size of each element it contains is estimated in order to calculate the full size of the entry. For the values assigned below, it is assumed that an integer value is stored in 32 bits.

67 6.2. Size of Table 55 SimplePv1-v4 routing table entry contains 3 elements: 1. Destination Address (IPv6) 128 bits 2. Next Hop Address (IPv6) 128 bits 3. Number of hops to the destination 32 bits SimplePv1-v4 routing table size = 288 bits DSDV forwarding table entry contains 5 elements: 1. Destination Address (IPv6) 128 bits 2. Next Hop Address (IPv6) 128 bits 3. Metric (= number of hops) 32 bits 4. Sequence Number a. Sequence Number 32 bits b. Creator of the sequence number 32 bits DSDV forwarding table size = 320 bits Each RPL node stores the following information: 1. Next Hop (DODAG parent; IPv6 Address) 128 bits 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) Size of the information stored by all nodes = 160 bits And RPL storing nodes store a DAO routing table entry that contains the following elements: 1. IPv6 Address 128 bits 2. Retry Counter 32 bits 3. Logical equivalent of DAO Content: 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. DAO Lifetime -32 bits d. DAO Path Control 32 bits 4. Destination Prefix (or Address or Multicast Group IPv6 Address) 128 bits DAO routing table entry size = 488 bits Figure 6.14 presents the memory usage by taking into account the size of the routing tables for each of the tested protocols, calculated based on the number of entries and the values calculated previously.

68 Average Coverage (%) Memory (bits) 56 Chapter 6. Results and Critical Analysis Memory Usage RPL_Storing_F RPL_Storing_D RPL_NonStoring_F RPL_NonStoring_D DSDV SimplePv1 SimplePv2 SimplePv3 Figure 6.14: Memory Usage 11-node Building Topology (Informatics Forum) According to the results displayed in Figure 6.14, even though RPL nodes store fewer entries in their routing tables compared to the other protocols, the difference in memory usage is not that significant because RPL stores more information for each entry. However, with an increase in the number of nodes, the other protocols will have a significant increase of entries in their tables compared to RPL. Thus, the difference between RPL s memory usage and that of the other protocols will become more evident Coverage A node s 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 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)

69 Coverage (%) Coverage (%) Coverage (%) Coverage (%) 6.3. Coverage 57 The graphs presented in Figures reveal how the average coverage of each protocol varies for different types and sizes of topologies. Coverage - Building Topologies Coverage - Grid Topologies G_8 nodes G_27 nodes B_11 nodes B_24 nodes G_64 nodes G_125 nodes Figure 6.16: Coverage Building Figure 6.17: Coverage Grid Coverage - Random Topologies Coverage - Tree Topologies R_27 nodes R_64 nodes R_125 nodes T_21 nodes T_91 nodes Figure 6.18: Coverage Random Figure 6.19: Coverage Tree The results suggest that a better coverage is obtained for networks with a larger number of nodes. RPL s average coverage in non-storing mode is given by the following formula: RPL_coverage = 1 Topology_Size(Number_Of_Nodes) This means that RPL s 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.

70 Delivery Ratio (%) Delivery Ratio(%) Delivery Ratio (%) Delivery Ratio (%) 58 Chapter 6. Results and Critical Analysis 6.4. Delivery Ratio In order to test the delivery ratio of the protocols, the test code generates a stream of data packets. Thus, after the network converged, each node in the topology was configured to send one data packet to every other node in the topology. The graphs in Figures presenting the delivery ratio reveal that the delivery ratio is unrelated to the routing protocol and strongly related to the MAC protocol. For each of the protocols, all graphs show a decrease in the delivery ratio with an increase of the number of nodes in the network, even though the average network coverage percentage is high (above 80%). This is due to MAC issues that lead to a high rate of collisions at the MAC Layer. However, the drop in the delivery ratio is not completely related to the MAC layer. It is also related to the interference caused by the large number of packet transmissions from different sources. Delivery Ratio - Building Top. Delivery Ratio - Grid Top G_8 nodes G_27 nodes B_11 nodes B_24 nodes G_64 nodes G_125 nodes Figure 6.20: Delivery Ratio Building Figure 6.21: Delivery Ratio Grid Delivery Ratio - RandomTop. Delivery Ratio - Tree Top R_27 nodes R_64 nodes R_125 nodes T_21 nodes T_91 nodes Figure 6.22: Delivery Ratio Random Figure 6.23: Delivery Ratio Tree

71 Average Latency (s) 6.5. Latency 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 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) Power Consumption The simulation scenario for evaluating the power consumption consisted of using the same type of specks, each with the same type of battery, and measuring the average time it takes for the specks to run out of power while running, in turns, each of the routing protocols. The scenario consisted of a 64- node grid topology, with the specks equipped with batteries of capacity 1mAh and a voltage of 3V.

72 Power Consumption (mw) 60 Chapter 6. Results and Critical Analysis The power consumption was calculated from the current consumption and the voltage drawn by the node. The current consumption was determined from the battery s capacity and the lifetime of the battery. PowerConsumption RPL DSDV SimplePv1 SimplePv2 SimplePv3 SimplePv4 Figure 6.25: Power Consumption 6.7. Fault Tolerance Scenario The fault tolerance scenario used for the evaluation of the protocols is the one presented in Chapter 5, section Fault tolerance (Recovery time). The topology used for this scenario is very small and simple, and can be seen in Figure Figure 6.26: Fault Tolerance Topology (SpeckSim) Both node 1 and 2 are in range with node 3 and 4, but they are not in range with each other. Thus, when the simulation starts, node 1 establishes a route to node 2 through node 3. Then, node 1 starts generating traffic towards node 2. It sends one packet per second. While node 1 is constantly sending

73 No. of Packets Lost 6.7. Fault Tolerance 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 3 s 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 Results The results for the fault toleration scenario are presented in Figure Fault Tolerance DSDV SimplePv4 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

74 Number of Classes 62 Chapter 6. Results and Critical Analysis 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. SimplePv4 exchanges two ACK messages before establishing a neighbour relationship between two nodes. Thus, it takes longer for SimplePv4 to form an adjacency between two nodes than for DSDV. 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 SimplePv Implementation Complexity The implementation complexity was measured based on the number of lines of code of the source files and the number of classes used. In order to measure the number of lines of code, I have made a Linux script that for a list of input files counts the number of lines of code, ignoring the java comments and empty lines. The script can be found in section B. NoComments Script of the Appendix. Implementation Complexity Lines of Code 1500 Implementation Complexity RPL DSDV SimplePv1 SimplePv2 SimplePv3 SimplePv4 Figure 6.28: Complexity (Lines of Code) RPL DSDV SimplePv1 SimplePv2 SimplePv3 SimplePv4 Figure 6.29: Complexity (Number of Classes) 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.