Implementation and Testing of Loadng: a Routing Protocol for WSN

Bachelor of Science Thesis Telecommunication Engineering

Implementation and Testing of LOADng: a Routing Protocol for WSN

Alberto Camacho Martínez

Directed by: Thomas H. Clausen

Paris, 2012

To my family

Abstract

The Wireless Sensor Networks is an emerging technology with strong potential in a wide range of fields. Data acquisition, connectivity, and monitoring are real demand services in constant growth in which sensor networks can take an important role. Routing protocols for wireless sensor networks must be developed to satisfy the needs of the applications and to adapt to the limited sensor nodes resources. The current standardized routing protocol for Wireless Sensor Networks, RPL, has been proved to be inefficient in some scenarios and for certain traffic patterns. There is a need to develop routing protocols adapted to the traffic patterns in which RPL is not optimized. The work collected in this manuscript contributes in the developing process of a routing protocol for wireless sensor networks, LOADng [32], which was submitted as an IETF internet-draft during the elaboration of this thesis. The description of LOADng draft is presented in chapter 3. A LOADng implementation has been written and integrated into Contiki OS, an operating system for sensor nodes and other embedded systems. This implementation is documented in chapter 5. During the development of this work, some interoperability tests were made in cooperation with HIPERCOM, Hitachi YRL, and EDF. The results were satisfactory and are published in [10]. The results of the simulations testing LOADng implementation – and performance – for Contiki OS are presented in chapter 6 of this manuscript. This manuscript concludes stating that LOADng is able to discover routes in mesh networks, and is able to find optimal paths towards the destination when using the hop-counting metrics.

Resumen

Las Redes de Sensores (Wireless Sensor Networks, WSN) es una tecnología emergente con un gran potencial de uso en distintas aplicaciones. La adquisi- ción de datos, conectividad y monotorización son servicios cada vez más necesarios y demandados, en los que las redes de sensores pueden tomar un papel importante. Los protocolos de enrutamiento para redes de sensores deben ser diseñadas para satisfacer los requerimentos de las aplicaciones y adaptarse a los recursos limitados de los nodos sensores. Se ha probado que el protocolo estándar de enrutamiento en WSN, RPL, es ineficiente en cierto tipo de escenarios y cierto tipo de tráfico de datos. Es necesario por tanto diseñar nuevos protocolos de enrutamiento que se adapten a los patrones de tráfico en que RPL no es eficiente. El trabajo contenido en este manuscrito contribuye en el proceso de desarrollo de un protocolo de enrutamiento para redes de sensores, LOADng [11], que fue presentado como internet-draft en el IETF durante la elaboracion de esta tesis. El capítulo 3 contiene la descripción de LOADng. LOADng se ha implementado e integrado en Contiki OS, un sistema opera- tivo para nodos sensores y otros sistemas embebidos. Dicha implementación está documentada en el capítulo 5. Durante el desarrollo de esta tesis se realizaron unos tests de interoperabilidad para LOADng en cooperación con HIPERCOM, Hitachi YRL y EDF. Los resultados fueron satisfactorios y están publicados en [10]. En el capítulo 6 se presenta los resultados de las simulaciones realizadas para testear la implementación – y eficiencia – de LOADng para Contiki OS. Este manuscrito concluye afirmando que LOADng es capaz de descubrir rutas multisalto en redes mesh, y usando la métrica del número de saltos es capaz de obtener rutas óptimas.

Resum

Les Xarxes de Sensors (Wireless Sensor Networks, WSN) es una tecnologia emergent amb un gran potencial d’ús en diverses aplicacions. L’adquisició de dades, connectivitat, i monotorització són serveis cada cop més necesaris i demandats en què les xarxes de sensors poden jugar un paper important. Els protocols d’enrutament per xarxes de sensors deuen ser dissenyats per satisfer els requeriments d les aplicacions i adaptar-se als recursos limitats dels nodes sensors. S’ha provat que el protocol estàndard d’enrutament en WSN, RPL, és ineficient en cert tipus d’escenaris i cert tipus de tràfic de dades. És necessari, per tant, dissenyar nous protocols d’enrutament que s’adaptin als patons de àfic en que RPL no és eficient. El treball contingut en aquest manuscrit contribueix en el procès de desen- volumapent d’un protocol d’enrutament per a xarxes de sensors, LOADng [11], que va ser presentat com internet-draft al IETF durant l’elaboració d’aquesta tesi. El capítol 3 conté una descripció de LOADng. LOADng s’ha implementat i integrat en Contiki OS, un sistema operatiu per a nodes sensors i altres sistemes embeguts. Aquesta implementació esta documentada al capítol 5. Durant el desenvolupament d’aquesta tesi es van realitzar uns tests d’interoperabilitat per a LOADng en cooperació amb HIPERCOM, Hitachi YRL, i EDF. Els resultats van ser satisfactoris i estàn publicats a [10]. El capítol 6 presenta els resultats de les simulacions realitzades per testejar la implementació – i aficiència – de LOADng per a Contiki OS. Aquest manuscrit conclou afirmant que LOADng és capaç de descobrir rutes multisalt en xarxes mesh i, emprant la mètrica del número de salts és capaç d’obtindre rutes òptimes.

Acknowledgements

This work was realized during an internship at the Hipercom research group, at the Laboratoire d’Informatique (LIX) of the Ecole Polytechnique. This means this work would not have been possible without the opportunity that Prof. Dr. Thomas Clausen gave to me to join his group. Special thanks to my colleagues. Listed alphabetically: Thomas Clausen, Juan Antonio Cordero, Ulrich Herberg, Matthias Philipp, Axel C. de Verdière, Georg Wittenburg, and Jiazi Yi. It was a privilege working with such a high level team. They gave me the opportunity to discuss ideas, contribute to the development of a protocol and, deﬁnitely, made me feel part of a research team. Last, but not the least, I would also thank the research group at Hitachi YRL: Yuichi Igarashi, Yoko Morii, and Hiroki Satoh for his kindness and courtesy during the development of the interoperability tests at Tokyo, Japan.

Contents

Contentsi

1 Wireless Sensor Networks1 1.1 Description and Characteristics...... 1 1.1.1 Elements of a WSN ...... 1 1.1.2 Characteristics of WSN ...... 2 1.1.3 Design Factors ...... 5 1.2 Nodes in a WSN ...... 6 1.2.1 Hardware...... 6 1.2.2 Platform comparison...... 7 1.3 Applications of WSN...... 10 1.3.1 Medicine ...... 10 1.3.2 Military...... 11 1.3.3 Road Traﬃc...... 12 1.3.4 Environment ...... 13 1.3.5 Home ...... 14 1.4 Standardization...... 14 1.4.1 IETF Working Groups...... 15 1.4.2 IEEE 802.15.4 ...... 17 1.5 Motivation ...... 18 1.5.1 WSN evolution...... 19 1.5.2 Future Internet Networks ...... 20 1.6 Conclusion ...... 21

2 Routing protocols in WSN 23 2.1 Protocol Stack ...... 23 2.1.1 The Physical Layer...... 24 2.1.2 The Data Link Layer...... 24 2.1.3 Network Layer ...... 25 2.1.4 Transport Layer ...... 25 ii CONTENTS

2.1.5 Application Layer ...... 25 2.2 Routing in WSN ...... 25 2.2.1 Route selection criteria...... 26 2.2.2 Route managing ...... 26 2.2.3 Packet routing ...... 27 2.3 Mesh-under vs. Route-over Routing ...... 28 2.3.1 Analysis...... 29 2.3.2 Beneﬁts of each scheme ...... 29 2.4 Routing protocols...... 30 2.4.1 RPL protocol...... 30 2.4.2 AODV...... 36 2.4.3 OLSR...... 37 2.4.4 ZRP...... 38 2.5 Conclusion ...... 40

3 LOADng Draft 41 3.1 Process Overview...... 41 3.2 Deﬁnitions...... 42 3.2.1 Terminology...... 42 3.2.2 Parameters ...... 43 3.3 Structures...... 44 3.3.1 LOADng Packets...... 44 3.3.2 Information Base...... 47 3.4 Algorithm...... 49 3.4.1 Common rules for RREQ and RREP messages ...... 49 3.4.2 LOADng Packet Processing...... 52 3.4.3 LOADng Packet Forwarding...... 54 3.5 Route Maintenance...... 56 3.6 Conclusion ...... 56

4 Working Tools 59 4.1 Contiki OS ...... 59 4.1.1 Rime Stack...... 60 4.2 Cooja Simulator ...... 62 4.2.1 Graphical User Interface...... 63 4.2.2 Wireless Channel Model...... 64 4.2.3 Debbugging in Cooja...... 65 4.3 Tools...... 66 4.4 Conclusion ...... 67

5 LOADng Implementation 69 5.1 Implementation overview...... 69 CONTENTS iii

5.2 Routing in Contiki OS...... 70 5.3 Modules...... 71 5.3.1 route-discovery module...... 71 5.3.2 route module...... 74 5.4 Functions ...... 76 5.5 Conclusion ...... 85

6 LOADng performance on WSN 87 6.1 Description of the simulations...... 87 6.1.1 Scenarios ...... 88 6.1.2 Platforms...... 90 6.1.3 Sensor nodes ...... 90 6.1.4 LOADng Configuration ...... 91 6.1.5 Nomenclature and features ...... 92 6.2 Medium Access...... 93 6.2.1 Backoff time influence...... 93 6.2.2 Backoff time comparative ...... 94 6.2.3 Implementation...... 95 6.3 Network Diameter Influence...... 96 6.3.1 7-hop radius Scenario ...... 96 6.3.2 3-hop radius Scenario ...... 109 6.3.3 Discussion...... 116 6.4 Platform Influence ...... 118 6.4.1 Tmote Sky ...... 119 6.4.2 MicaZ...... 126 6.4.3 Discussion...... 132 6.5 Tests in random network...... 135 6.5.1 Analysis of the route discovery process ...... 135 6.5.2 Discussion...... 136 6.6 Conclusion ...... 139

7 Conclusion 141

Bibliography 143

A WSN Platforms and applications 151 A.1 Areas of application ...... 151 A.2 WSN Platforms...... 153

B Routing 155 B.1 Counting to inﬁnity problem ...... 155 B.1.1 Count to inﬁnity and AODV ...... 156 B.2 Multipoint Relaying ...... 156 iv CONTENTS

C The Contiki Environment 159 C.1 Operating Systems Summary ...... 159 C.2 Contiki OS ...... 159 C.2.1 Introduction ...... 159 C.2.2 Architecture...... 161 C.2.3 Processes ...... 163 C.2.4 Layer Structure in Contiki...... 164 C.2.5 Software Development for Contiki ...... 167 C.2.6 Routing in Contiki OS...... 167

D Simulations documentation 169 D.1 Sensor nodes code ...... 169 D.1.1 Root Node Type...... 169 D.1.2 Leaf Node Type ...... 171 D.2 LOADng parameters...... 172 D.2.1 route module parameters...... 172 D.2.2 route-discovery module parameters ...... 173

E Reference Manual 175 E.1 Instant Contiki installation ...... 175 E.2 Contiki OS ﬁlesystem ...... 176 E.2.1 LOADng module installation ...... 176 E.2.2 Working directory ...... 179 E.3 Contiki OS Compilation...... 179 E.3.1 Makeﬁle...... 179 E.3.2 Compilation...... 181 E.4 Cooja Simulations ...... 181 E.4.1 Massive simulations ...... 181 E.5 Simulations Data Analysis...... 182 E.5.1 From string messages to numeric tables ...... 182 E.5.2 From numeric tables to octave plots ...... 182

List of algorithms 183

List of Figures 184

List of Tables 188 Chapter 1

Wireless Sensor Networks

Wireless Sensor Networks were considered to be the next revolutionary technology by the MIT Journal [1] in 2003 and, in fact, the number of potential applications for these kind of networks support this statement. This chapter is an introduction to the wireless sensor networks. It gives an overview of the WSN characteristics, some of its applications, the standardization – at the moment this manuscript was written –, and gives a motivation to think about the future impact of WSN.

1.1 Description and Characteristics

Wireless Sensor Network characteristics are diﬀerent in each individual scenario but, in general terms, a WSN consists of several sensor nodes distributed around, or very close to, a phenomenon to monitor environmental data. The information acquired by the nodes is sent in a multi-hop fashion to a base station, which sometimes acts as a gateway to other external networks. In some situations the nodes process the information, and can act on its environment † ( e.g. sending a signal to activate air conditioner when monitoring temperature). Some of the WSN applications are presented in section 1.3.

1.1.1 Elements of a WSN

Figure 1.1 illustrates the elements of a standard WSN: the sensor nodes, the base station, and the gateway.

†When some nodes in a WSN have capabilities to act on the environment, this networks are also called Wireless Sensor and Actuator Networks (WSAN). 2 ELEMENTOS DE LA ARQUITECTURACHAPTER 1. WSN WIRELESS SENSOR NETWORKS

Figure 1.1: Sensor Nodes (sensor + mote) forming a WSN.19 source: [18]

• The sensor nodes are electronic autonomous devices with capabilities of sensing, computing, storage and wireless communication. A sensor node is divided in two main parts: the sensor board and the mote. The sensor board contains the sensors to acquire environmental information (light, temperature, chemical levels, . . . ). The mote integrates the microcontroller and the radio transceiver.

• The base station is the concentrator of the data sent by the sensor nodes, and can also be another sensor node of the network. In some cases, the base station can setup and reconﬁgure the sensor motes remotely.

• The gateway, if needed, connects the WSN with other external networks.

The detection of environmental information and its corresponding transmission is a task done in conjunction by all the nodes: data messages are sent hop by hop from the source to its destination, reducing the transmission power needed by the source node to transmit such packet directly to the destination. In case some data analysis is required, the source and intermediate nodes can be designed to process such data in order to alleviate the base station from doing it. The computational cost and requirements of the single nodes are lower than those needed by a unique node executing the same task. In addition, data pre-analysis in the source nodes can result in sending only relevant information, and thus, saving energy in data transmission.

1.1.2 Characteristics of WSN Wireless Sensor Networks have speciﬁc features in terms of network topology, data messages size, data traﬃc, and resources.

Network Topology The network topology change and maintenance can be divided into the pre- deployment and deployment phase, the post-deployment phase, and the redeployment phase, explained below. 1.1. DESCRIPTION AND CHARACTERISTICS 3

1. Pre-deployment and deployment phase: The optimal nodes placement has a strong dependance (among other factors) with the particular application, the expected traffic patterns, and the field characteristics. These factors can result in distributing the sensor nodes at random – e.g., when dropped from a plane to provide connectivity in disaster areas– , or distributing the sensor nodes in accurately predefined places – e.g., when placed in an engine to monitor its temperature.

2. Post-deployment phase: The WSNs topology is dynamic over time, and is aﬀected by changes in sensor nodes position, in their available energy, malfunctioning, reachability problems due to obstacles, noise, etc.

3. Redeployment of additional nodes phase: New nodes are added or subtracted from the network due to changes in task dynamics, to replace other sensor nodes or because of other issues.

The WSNs topology is dynamic over time due to changes in link quality and node state, but also due to mobility of the nodes. In general, the WSN nodes distribute forming a mesh network with high probability of failure in communications. For that reason, the nodes in a WSN must possess auto-conﬁguration capabilities to adapt to network changes.

Data Trafﬁc

In WSNs doesn’t use to exist a direct link between every two nodes, and the communication between two nodes is done in a multi-hop fashion. This is due to the limited nodes antenna transmission range. In addition, the routing path connecting two single nodes in the network can change over time because of changes in the network topology or for some other reasons. For example, the link connecting two nodes can suffer from noise, shadowing, or other issues making this link useless for communication. The nodes in a WSN can play different roles according to the traffic flow: they can be the source of data, a sink or an intermediate node. The role of a node is not fixed nor unique, so nodes can change its role over time, or even play different roles at the same time.

Source nodes The source nodes are the nodes originating data packets.

Sink nodes The sinks of data are the destination nodes of the data packets sent by the source nodes. A sink node can either be part of the WSN, or be the base station, or even be an external entity. 4 CHAPTER 1. WIRELESS SENSOR NETWORKS

Intermediate nodes The intermediate nodes are the nodes through which the data is sent from the source to the sink in a multi hop sense.

In some WSN applications (see section 1.3), the data traffic is directed towards a special node – either a data collector node, or a node acting as a gateway, or a node taking part in routing data packets, or any other situation. In case of centralized traffic, is important to avoid bottle necks, or to provide a mechanism to control traffic. Some protocols have been developed to optimize routing process towards a specific sink node. It is the case of RPL (see section 2.4.1), published as RFC [58]. Not all WSN applications perform centralized data traffic. In that scenarios, RPL may not perform well, as the analysis published in [14, 13] demonstrate. For that reason, other WSN routing protocols (for instance, LOADng [11, 12]) are being developed to adapt to other topologies and traffic patterns .

Type of service

Sensor node platforms possess limited energy and process resources (see section 1.2.2). Energy-efficient operations should be considered for communication, computation, and sensing. The traditional quality of service (QoS) metrics do not apply in WSNs. WSNs quality of service must be good in some sense: right answers at the right time. Nodes in the network use to collaborate towards a joint goal. Pre-processing data in each single node – instead of centralizing all processing tasks– can greatly improve the global efficiency. Nodes can transmit data (e.g., those obtained from their environment) following different patterns:

Event reporting A node, on its own initiative, and after a certain event (e.g., after an environmental event) sends traﬃc destined for some other node, possibly a base station.

Periodic reporting A node, on pre-determined schedule, sends acquired data destined for some other node, possibly a base station.

Request-reply A node, upon being requested to do so by another node – probably a base station – generates traﬃc (e.g. environmental data) destined for some other node, possibly a base station.

Event-driven data reporting can contribute to save energy and reduce network traﬃc in front of using periodic reporting. For example, rather than providing 1.1. DESCRIPTION AND CHARACTERISTICS 5 real-time temperature, the sensor nodes should only alert when the temperature overpass certain threshold.

1.1.3 Design Factors

The design of a sensor network is inﬂuenced by many factors, including: programmability, maintainability, resources, fault tolerance, and scalability.

Programmability In some situations might be necessary to reprogram the nodes (e.g., when adding a new environmental feature to monitor). When the WSN nodes are located in unaccessible places, this task must be done remotely.

Maintainability WSNs must be able to adapt to topology changes, e.g., the addition of new nodes, or general changes in the network topology.

Resources Optimizing energy consumption is an important issue when energy resources are limited – e.g., is diﬃcult or not possible to replace batteries –, in order to increase the lifetime of nodes. Wireless transmissions are the main source of energy wasting, so the number of transmissions should be reduced as possible by way of: – reducing the number of hops of the routes, and – avoiding packet retransmissions. Figure 1.2 shows the three node states: sleep; wakeup, the transition to the active state; and the active state. To further increase power saving, the CPU may be able to switch into a standby sleep mode periodically, or when there is no task to execute.

Figure 1.2: Nodes increase power saving by switching into an standby mode periodically

Fault Tolerance Fault Tolerance is the ability to sustain sensor network func- tionalities without any interruption due to sensor node failures. The relia-

bility Rk(t) is the probability of not having a failure within the time interval 6 CHAPTER 1. WIRELESS SENSOR NETWORKS

(0, t) and its probability distribution is modeled with a Poisson with param-

eter λk, the failure rate of the node k. In a WSN the nodes can run out of energy, be damaged by external factors, be aﬀected from interferences, etc. In a reliable and robust WSN design, the failure of sensor nodes should not aﬀect the overall task of the sensor network, which should adapt to these network changes.

Scalability: A WSN design adapted to scalability must support the addition of new nodes in the network.

The limitations in the WSN design make challenges in the design of wireless networks and diﬀerentiate them from the classic wireless networks. It is true that, in certain scenarios some of the listed limitations can not apply, or even new ones could appear.

1.2 Nodes in a WSN

This section presents the WSN nodes hardware main elements, and analyzes some of the WSN node platforms.

1.2.1 Hardware A sensor node is made up of four basic components: a sensing unit, a processing unit, a transceiver unit, and a power unit (ﬁgure 1.3).

Figure 1.3: Basic components of a sensor node.

Sensing Unit A node can be equipped – or not – with one or more sensors to acquire environmental information. Depending on the platform, the sensing unit can be embedded in the mother board, or be connected to an external port.

Processing Unit The tendency over time has been increasing the CPU performance. At the time this manuscript is written, many WSN nodes processing unit is a CPU running at 8MHz (see table A.1). 1.2. NODES IN A WSN 7

Transceiver Unit The tendency over time has been increasing the transmission rate. At the time this manuscript is written, many WSN nodes built the TR1000 chip (IEEE 802.15.4 compliant) and, more recently, the CC2420. The later one reaches up to 250Kbps transmission rates.

Power Unit The WSN nodes can be powered by batteries, solar cells, or some other method to provide energy to the nodes. Batteries can limit nodes lifetime if they are limited and non replaceable. WSN nodes should be energy-eﬃcient in order to maximize lifetime. A comparative analysis exposed in [44] states that, supporting mesh networking with a pair of AA batteries reporting data once every 3 minutes using synchronization (<1% duty cycle), Mica2 platform lasted 453 days; MicaZ platform lasted 328 days; and Telos platform lasted 945 days.

Apart from that, other components can be added, such as a location ﬁnding system. A more detailed analysis and comparison of hardware performance between diﬀerent sensor node platforms is presented in section 1.2.2.

1.2.2 Platform comparison

The WSN requirements and constraints, some of them presented in sections 1.1 and 1.1.2, do affect in the WSN nodes platform design. Despite all the sensor nodes use to have similar components, each individual platform – Mica mote, Tmote, Imote, etc. – manifest different behavior because they have different hardware and design. The variety of WSN platforms make possible to choose the one that best fits for every singular WSN application requirements. Sensor nodes generally consist of some sensors which provide environmental data to a microcontroller. The mote also has some memory and a radio transceiver to provide connectivity. Figure 1.3 is a basic schema of the main components of a sensor node, which can be distinguished in figure 1.4 for the Tmote Sky and Telos platforms. An analysis extracted from [6] compares both system core and radio properties of some of the most popular WSN node platforms – the BTnode rev3, Mica2, Mica2Dot, Tmote Sky, and Imote. Figure 1.5 shows overall platform evaluation, in which the arrows give an idea of the behavior tendency of each mote. A table detailing different sensor node platforms specifications can be found in section A.2. Each platform has its own advantages and inconveniences. For example: Mica2Dot is tinier than the other platforms, but lacks in terms of memory. As a conclusion, it is not correct to state that there are better platforms than anothers. Instead, 8 CHAPTER 1. WIRELESS SENSOR NETWORKS

(a) Detail of Tmote Sky platform. (b) Detail of Telos platform, from [24] Berkeley Figure 1.4: Schema of a sensor node there are platforms that match better than anothers the concrete application requirements.

6. REFERENCES [1] D. Estrin, R. Govindan, J. Heidemann, and S. Kumar, “Next century challenges: Scalable coordination in BTnode rev3 Mica2 Mica2Dot Tmote Sky Imote sensor networks,” in Proc. 5th ACM/IEEE Ann. Int’l System Core Conf. Mobile Computing and Networking (MobiCom ’99). ACM Press, New York, Aug. 1999, pp. 263–270. [2] J. Kahn, R. Katz, and K. Pister, “Next century challenges: Mobile networking for smart dust,” in Proc. 5th ACM/IEEE Ann. Int’l Conf. Mobile

Radio Systems Computing and Networking (MobiCom ’99).ACM Press, New York, Aug. 1999, pp. 271–278. [3] K. Römerand F. Mattern, “The design space of wireless sensor networks,” IEEE Wireless Communications, vol. 11, no. 6, pp. 54–61, Dec. 2004. Figure 1.5: System Core and Radio comparison of different sensor node [4] S. Künzli, L. Thiele, and E. Zitzler, “A modular platforms. source: [6] design space exploration framework for embedded Figure 3: Overall platform evaluation. systems,” IEE Proc. Computers & Digital Techniques, vol. 152, no. 2, pp. 183–192, Mar. 2005. A separate analysis of the system core and radio system for the different platforms[5] G. Simon, G. Balogh, G. Pap, M. Maróti,B. Kusy, is presentedinto below. account Figure perfect 1.6 contains conditions, the same e.g. information asymptotically as figure large 1.5, using J. Sallai, A.´ Lédeczi, A. Nádas,and K. Frampton, a differentad presentation hoc networks, that perfect makes easier scheduling to compare (no collisions), properties between perfect different “Sensor network-based countersniper system,” in platforms.knowledge of conditions and neighbor states, etc. Depend- Proc. 2nd ACM Conf. Embedded Networked Sensor ing on the application characteristics, it is not sufficient to Systems (SenSys 2004). ACM Press, New York, Nov. just relate to the theoretical capacity, but metrics must be System core comparison 2004, pp. 1–12. combined with application duty-cycle, traffic patterns, the [6] T. Liu, C. Sadler, P. Zhang, and M. Martonosi, Figure 1.6anumber is a comparative of nodes and of the the different region sensor covered node by architectures, their transmis- taking into “Energy-efficient surveillance system using wireless accountsions, – among MAC other and variables link-layer – CPU properties. architecture, speed, memory, external IO sensor networks,” in Proc. 2nd ACM/USENIX Conf. and on-board5. CONCLUSION sensors. Mobile Systems, Applications, and Services (MobiSys 2004). ACM Press, New York, June 2004, pp. In this paper we have demonstrated that it is difficult to 256–269. compare different sensor network platforms due to the broad [7] J. Hill, M. Horton, R. Kling, and L. Krishnamurthy, range of applications, each with their distinct characteris- “Wireless sensor networks: The platforms enabling tics. We have motivated a set of general platform metrics wireless sensor networks,” Communications of the and developed a methodology using multidimensional star ACM, vol. 47, no. 6, pp. 41–46, June 2004. plots for an easy to use and intuitive visual comparison that can be applied early on in the design phase. This has been [8] J. Polastre, R. Szewczyk, and D. Culler, “Telos: demonstrated in a case study comparing some state of the Enabling ultra-low power wireless research,” in Proc. art sensor network platforms. The focus of this case study 4th Int’l Conf. Information Processing in Sensor here was not on the numbers presented in the tables, al- Networks (IPSN ’05). IEEE, Piscataway, NJ, Apr. though we have taken care to be as precise as possible and 2005, pp. 364–369. tried to use measured values as much as possible. The dis- [9] J. Beutel, M. Dyer, M. Hinz, L. Meier, and cussion of the different cases and their implication clearly M. Ringwald, “Next-generation prototyping of sensor demonstrate the overall complexity of seemingly simple sys- networks,” in Proc. 2nd ACM Conf. Embedded tem architectures. Moreover, we have elaborated on a se- Networked Sensor Systems (SenSys 2004).ACM lect example how to analyze and interpret the functional Press, New York, Nov. 2004, pp. 291–292. resources and criteria of typical sensor network platforms. [10] L. Nachman, R. Kling, R. Adler, J. Huang, and We believe that it is not beneficial to try to derive single V. Hummel, “The Intel mote platform: A merits of value for each platform from the metrics discussed Bluetooth-based sensor network for industrial due to the complexity of the context and the implications monitoring,” in Proc. 4th Int’l Conf. Information different criteria have on each other. For example, minimiz- Processing in Sensor Networks (IPSN ’05). IEEE, ing size ultimately means to limit the scale and amount of Piscataway, NJ, Apr. 2005, pp. 437–442. I/Os. A platform based on a system-on-chip is thus inher- [11] V. Shnayder, M. Hempstead, B. Chen, ently more complex to couple to different sensors than say a G. Werner-Allen, and M. Welsh, “Simulating the Mica2 with generic connector interfaces. The optimum here power consumption of large-scale sensor network still depends on the goals of the individual application and applications,” in Proc. 2nd ACM Conf. Embedded preference of the individual system designer. Networked Sensor Systems (SenSys 2004).ACM Press, New York, Nov. 2004, pp. 188–200. Acknowledgments [12] L. Negri, J. Beutel, and M. Dyer, “The power The work presented in this paper was partially supported consumption of Bluetooth scatternets,” in Proc. IEEE by the National Competence Center in Research on Mobile Consumer Communications and Networking Information and Communication Systems (NCCR-MICS), a Conference (CCNC 2006). IEEE, Piscataway, NJ, center supported by the Swiss National Science Foundation Jan. 2006, pp. 519–523. under grant number 5005-67322. 1.2. NODES IN A WSN 9

The Mica2 and Mica2Dot differ only in respect to size, CPU, and external IO. Both of them have less memory and processing capabilities than the other platforms, and their sensing and storage capability is just average. ode rev3 which is a dual radio platform resembling a twin modulation, transmit power and sensitivity are more of in- odeThebetween rev3 Tmote which the Imote is a Sky dual and radiois the the Mica2. platform platform It resembling runs a cooperative with a twin moremodulation,terest sensors to the transmitand radio designer, storage power and the sensitivitycapabilities.data rate, radio are more range On of (cell in- betweenthemultithreaded other the Imote hand, operating and the it system Mica2.lacks targeted It in runs terms at a embedded cooperative of size net- andterestsize), especially to amount the radio of distinct designer, memory channels the data capabilities. and rate, setup radio time range are Its (cell very multithreadedworking platforms. operating For system the comparison targeted at ofembedded radio features net- size),relevant amount to application of distinct performance. channels and Furthermore setup time the are inter- very a distinction has been made between the low-power radio face modalities under which a radio is connected to a host working platforms. For the comparison of radio features relevant to application performance. Furthermore the inter- characteristics(LPR) and the Bluetooth make radio it (BT)most on suitable the BTnode. for lightweightCPU and the applications services offered by with the radio long are inactive of concern. a distinction has been made between the low-power radio face modalities under which a radio is connected to a host Of the seven properties depicted in Figure 2, all but the (LPR)3.1 and System the Bluetooth Core radio (BT) on the BTnode. CPU and the services offered by the radio are of concern. periods and bursty processing demands. setup-time, which is to be minimized are to be maximized Of the seven properties depicted in Figure 2, all but the 3.1In System a concrete Core comparison, the system core is evaluated so for best performance. Although the Mica2, Mica2Dot and that CPU architecture, speed, memory sizes, external IO setup-time, which is to be minimized are to be maximized TheIn a concrete Imote comparison, stands out the system by its core considerable is evaluated so processingBTnode3 LPR power are using and the same program radio they memory are typically and on-board sensors are all to be maximized, whereas the for best performance. Although the Mica2, Mica2Dot and that CPU architecture, speed, memory sizes, external IO specified for different protocol variants resulting in differ- system size is to be minimized to derive an optimal architec- BTnode3 LPR are using the same radio they are typically andon on-board a small sensors device, are all to but be maximized, lacks in whereas terms the of integratedent data rates and sensors, radio ranges. storage Clearly and situated data at one ture (see Figure 1). The Mica2 and Mica2Dot show conser- specified for different protocol variants resulting in differ- system size is to be minimized to derive an optimal architec- extreme of the design space when compared to the link- memory.vative memory and processing capabilities combined with a entoriented data rates 802.15.4 and and radio Bluetooth ranges. radios Clearly used situated in the at Tmote one turedefault (see Figure sensing 1). and The storage Mica2 capability. and Mica2Dot They show differ conser- only in extreme of the design space when compared to the link- vative memory and processing capabilities combined with a Sky, Imote and BTnode3 BT, the broadcast-oriented CC1000 respect to size, CPU speed and external IO. The Tmote Sky orientedISM radio 802.15.4 supports and only Bluetooth few distinct radios channels used in resulting the Tmote in a defaultThesupportsBTnode3 sensing increased and storage processinghas capability. much capabilities, more They many di dataffer onlyon-board memory in Sky, than Imote and the BTnode3 rest BT,of platforms,the broadcast-oriented but CC1000 it is respect to size, CPU speed and external IO. The Tmote Sky low capacity. When operated at high transmit power levels sensors combined with ample storage capabilities but lacks ISMthe radio radio supports ranges achieved only few are distinct also high, channels further resulting limiting in the a supportsjustclearly average increased in terms of processingin size all and the especially capabilities, other memory many aspects capabilities. on-board and lackslow capacity. in terms When operated of program at high transmit memory power and levels sensors combined with ample storage capabilities but lacks capacity of a network. The Tmote Sky shows a different It is thus most suitable for lightweight applications with theapproach radio ranges with lower achieved transmit are also power, high, higher further sensitivity limiting theand clearlynumber in terms of of integrated size and especially sensors. memory capabilities. long inactive periods and bursty processing demands. The capacitybandwidth, of a a network. number of The dedicated Tmote channels Sky shows and a extremely different It is thus most suitable for lightweight applications with Imote is harnessing considerable processing power and pro- approachlow setup-time. with lower The transmit Bluetooth power, radios higher on sensitivity the Imote and and long inactive periods and bursty processing demands. The Imotegram memory platform on a small stands form factor out but in it termslacks in terms of speedbandwidth,BTnode3 and BT a program number are situated of dedicated memory, at the channels other the end and of Tmote extremelythe design Imote is harnessing considerable processing power and pro- of integrated sensors, storage and data memory. All four lowspace setup-time. supporting The a very Bluetooth high data radios rate, theon the highest Imote amount and gram memory on a small form factor but it lacks in terms standsTinyOS out platforms in storage suffer from and very scarce number data memory of on-board re- BTnode3of sensors, channels BT and are the so situated resulting BTnode3 at in the considerably other is the end higher platform of the capacity. design of integrated sensors, storage and data memory. All four sources requiring extreme care during the design and metic- spaceIt must supporting be noted a very however, high thatdata therate, setup-times the highest displayed amount TinyOS platforms suffer from very scarce data memory re- havingulous effort larger in developing data applications memory, that etc. fit into There such lim- isof nohere channels platform are for and the so hardware resulting better resource in than considerably alone the and higher others do not capacity. encom- in sourcesited memory requiring footprints extreme care of a during few kilobytes the design only. and This metic- limits Itpass must the be time noted necessary however, to set that up the a communication setup-times displayed link and ulousallthe analyzed e applicabilityffort in developing andvariables. flexibility applications of the that Mica fit family into such consider- lim- heresuccessfully are for the transmit hardware data. resource alone and do not encom- itedably memory when footprintsput into context of a few with kilobytes the rather only. high This computing limits pass the time necessary to set up a communication link and thepower applicability of at least and the flexibility Tmote and of the Imote Mica platforms. family consider- successfully transmit data. ably when put into context with the rather high computing power of at least the Tmote and Imote platforms.

Figure 2: Platform comparison – radio properties.

Figure 1: Platform(a) System comparison core – system core. Figure3.3 Bringing 2: Platform(b) Platform Radio comparison properties Metrics – radio into properties. Context Figure 1.6: System Core and Radio comparisonWhen viewed of side different by side in an sensor overall comparison node (see 3.2Figure Radio 1: Platform Systems comparison – Physical – Properties system core. 3.3Figure Bringing 3) further Platform details apart Metrics from the into lack Context of flexibil- Withplatforms. the system core source: features given [6] as objective facts, the ity/memoryWhen viewed and side the by diff sideerent in strategies an overall employed comparison in the (see ra- 3.2radio Radio features Systems already pose – Physical considerable Properties problems and room Figuredios are 3) evident. further details The system apart core from features the lack as ofwell flexibil- as the Withfor interpretation. the system core The features cause given for this as objective is mainly facts, the broad the ity/memoryradio systems and all the are diff stronglyerent strategies biased employedfor a specific in the set ra- of radiorange features of options already and pose configurations considerable possible problems on most and of room these diosfeatures are evident. and thus The specific system niche core applications features as on well theas Mica2, the forradio interpretation. devices. Although The cause designed for this for is standardized mainly the interop- broad radioMica2Dot, systems Tmote all are Sky strongly and Imote. biased The for BTnode a specific system set core of erability, a multitude of protocols and operating schemes resources seem to be more balanced here. It’s two radios range of options and configurations possible on most of these features and thus specific niche applications on the Mica2, are available and the performance of a single solutions is so combined span a more balanced polygon than the other four radioRadio devices. properties Although designed comparison for standardized interop- Mica2Dot, Tmote Sky and Imote. The BTnode system core highly dependent on the requirements of the underlying ap- platforms when viewed in a combined plot the the LPR and erability, a multitude of protocols and operating schemes resources seem to be more balanced here. It’s two radios plication. While the physical parameters such as frequency, BT radios as seen here. The BTnode is thus more versatile areFigure available 1.6b and thecompares performance platform of a single solutions radio is properties so combined in span different a more balanced platforms, polygon than taking the other into four highly dependent on the requirements of the underlying ap- platforms when viewed in a combined plot the the LPR and plication.account While the the transmission physical parameters range, such as frequency, the numberBT of radios channels as seen here. in The transmission, BTnode is thus more the versatile sensitivity, transmission power, setup time, data rate, and frequency band. The BTnode3 stands out in terms of number of channels and data rate, but lacks in terms of range and setup time. It transmits at high frequencies with low 10 CHAPTER 1. WIRELESS SENSOR NETWORKS transmission power. The Mica2 and Mica2Dot platforms offer high transmission power reaching high outdoor ranges, at the same time they need a small setup time. On the other hand, its number of channels is very reduced and the data rate is low. The Tmote Sky mote needs very short setup time – almost negligible compared to the setup time of other platforms, which is between 0.05 and 0.5 seconds –, and reaches high outdoor range with low transmission power. However, it doesn’t reach a high data rate and it doesn’t have many channels. The Imote offers a good data rate with a lot of channels and not much transmitting power. It lacks in terms of outdoor range, sensitivity and setup time. Again, there is no platform better than the others in all analyzed variables. In summary, different platforms have different properties. Each different WSN scenario and application has a concrete node platform which adapt the best to its requirements.

1.3 Applications of WSN

The applications of Wireless Sensor Networks cover different areas. Each particular application involves specific requirements and environmental variables, such as interferences. Even in hostile or hard to access placements, the deployment of a WSN must assure the correct transmission. For that reason, a special con- sideration must be taken to adapt the WSN design – protocols, node platforms, topology, etc. – to the concrete media and application. WSNs are already used in industrial and civilian application areas, such as industrial process monitoring and control, machine health monitoring, environment and habitat monitoring, healthcare applications, home automation, traffic control, monitoring product quality, monitoring disaster areas, managing inventory, etc. [30, 50, 26]. However, some standardization is still required in many of the WSN applications. A non-exhaustive analysis of WSN applications is presented in this section, and a more extensive list is presented in appendixA.

1.3.1 Medicine The advances in wireless sensor networking have open new opportunities in healthcare systems [48]. Big amounts of data can be collected and mined automatically [31], reducing the cost and inconvenience of getting it and increasing the surveillance of the patient. Some of the WSN applications in the medicine ﬁeld are: 1.3. APPLICATIONS OF WSN 11

Real-Time Monitoring The vital signs of the patient are monitored in real time by unobtrusive and wearable bio-sensors deployed in the patients body (see ﬁgure 1.7a). Bio-sensors designed to have large lifetime can be used in implants.

Alarm Activation A set of alarms can be deployed around home using a WSN. This devices could be simple alarm buttons or incorporate special capabilities to detect an alarm situation, e.g., for people who need special care.

The collected data, can be sent to the hospital or another processing center by connecting the WSN with external networks (ﬁgure 1.7b), specially if an alarm situation occurs.

!"#$%"&'$()*+(,"*-./"#* 0"&",()*12",2$"3

!320/%=2&)+% <-#'+5-+%2/$%/#0+)% /012'(,%&'()"*%+',-"*.

!"#$ #%&' !"#$ #%&'

!"#$ 4)+*0325#/% ,'+-")%.)/+0#/% #%&' !3)2.60/7%32.)% !"#$ #%&'

!"#()*+ !"##$% 1)23.%32.)% &#"'()%*'"+)% ,-&&.'/01' !"#$%&'()"*)%+',-"*. 2'3%4'$5040$ 6%..'74%1 9:0/%-#/$'-5&0.;% 8)(*)32.'3)% !"#$%&'(

/334256,2"( 7"*,

8"*.94"-

9*>?% :'52)2"(%,6.2(;%3*"5')) <6(#42(;%"9%646*0) @";-)(02% <")32,64%8"*.94"-%2(,';*6,2"( A'"+)%B2&)%C)"#-0.;%

<3.)30#+-")3#+0+% !)'(&*+,$)-'&"- !"#$%&'()*(+",+%&(*--.(/ 0(1234526(517( ?@A(BCC#"<$9"&%8("%(D:$#9E(2%F"G&%H:%9 )> 5%89"9,9:(;&#"9:<%"<&(="(!"#$%&(*--. (a) Distribution and applications of a (b) Domestic WSN sending health WSN on a human body. source: [31] data to a specialized health operator. source: [20] Figure 1.7: Health and medicine applications

1.3.2 Military

Wireless Sensor Networks have potential military applications [2]. The design of a self-organized WSN, with rapid deployment and fault tolerance properties matches the possible requirements of a network to be used in in command, control, communications, computing, intelligence, surveillance, reconnaissance, and targeting systems. By sending environmental information, a WSN can help improving the eﬃciency of combat operations. In addition, WSNs can prevent people from doing some tasks, and reduce then the personal risks. For example, a WSN deployment can be used to detect, deactivate or activate mines, detection of enemy units, sensing intruders on bases, or chemical/biological threats[16]. 12 CHAPTER 1. WIRELESS SENSOR NETWORKS

Figure 1.8: Military sensor deployments

1.3.3 Road Traffic Wireless Sensor Networks can be used to provide road traffic state information. The knowledge of this information can be used to alleviate road traffic congestion and avoid accidents. Research on this topic is done by the Intelligent Transport System (ITS) research community [8]. Some of the WSN applications in road traffic are:

Traffic Monitoring A tracking application can locate a specific vehicle and monitor its movement. For example, traffic radars detecting infractions can send data trough a distributed WSN.

Automated Traffic The knowledge of the traffic state allow a more automatic and optimal way of driving. For example, the knowledge of the state of traffic lights and traffic density affect in the optimal speed of a vehicle approaching to a semaphore.

Figure 1.9: A WSN can track and alert from the state of traﬃc.

Vehicle Monitoring: A set of sensors installed in strategic parts of a vehicle – in the wiper, lights, seats, etc. – can report to the driver important information about the environment, such as the weather, pavement information, tires pressure, or information about the driver vital signs. The data collected by 1.3. APPLICATIONS OF WSN 13

the sensors can be used either to make changes manually or automatically [49]. For example, some of those actions can be to activate the brakes, the airbag (automatically), or to adjust the tire pressure (manually).

1.3.4 Environment

Sensor nodes can be used to monitor the environment. The device’s communication have been proved to work in real environments in ranges up to 300 to 500 meters. The design of sensor nodes with high battery lifetime makes WSN suitable for use in hard-to-access placements – where battery replacement can be diﬃcult or not possible. WSNs can be used in applications of tracking, monitoring, and in particular, in risk prevention.

Tracking and Monitoring Nodes equipped with sensors can monitor the hu- midity, temperature, light, etc. This data can be sent, for example, to meteorological stations. An analysis of particular requirements of environmental monitoring is presented in [4]. WSN can also be used to control the position of mobile objects, when a sensor node is placed on it. An example of this type of application is the ZebraNet project [28], from Princeton University. The goals of that project where both to explore wireless protocols, and to perform nobel studies of animal migrationsAPLICACIONES and inter-species interactions. PARA WSN To control (III) zebra’s move- ments, a sensor node was installed in a collar in the zebra’s neck (see ﬁgure 1.10). 3) TRACKING

•Aplicación para controlar objetos que están etiquetados con nodos sensores en una región determinada. •A diferencia del resto , la topología de la red es muy dinámica, debido al continuo movimiento de los nodos sensores: Figure 1.10: Detail of sensor nodes installed in a zebra’s neck,•La for WSN debe ser capaz de Foto: Proyecto ZebraNet the ZebraNet project descubrir nuevos nodos y formar nuevas topologías. Risk Prevention4) AREDES WSN HÍBRIDAS can be used to prevent risks by monitoring the environment (for example, by monitoring the water level of rivers to prevent from ﬂooding).•En Some general, examples los escenarios are given de below. aplicación contienen aspectos de las tres categorías anteriores.

10 14 CHAPTER 1. WIRELESS SENSOR NETWORKS

The Faculty of Information Technology in King Mongkut’s University of Technology North Bangkok has done some research in WSNs for weather and disaster alarm systems [61]. The University of California, Berkeley, carried the FireBug project [7, 15] to detect fires prematurely: a deployment of sensor nodes capture temperature and barometric pressure to detect fire in its proximities, as reflected in figure 1.11a. The University of Harvard, the University New Hampshire, and the Uni- versity of North Carolina have done research in using WSN deployment in a volcano surroundings to monitor its state [37, 54]. When an earthquake or eruption occurs, nodes detect the seismic event and the base station is alerted (figure 1.11b) Intel and BP used a WSN to support preventive maintenance on board of an oil tanker in the North Sea. This project was recognized by InfoWorld as one of the top 100 IT projects in 2004.

(a) Barometric pressure and tem- (b) WSN to detect and alert from seismic perature change as ﬁre front events around a volcano. source: [62] moves past a mote of the Fire- Bug project [15] Figure 1.11: WSN applications in risk prevention

1.3.5 Home A domestic WSN can connect all the electronic home apparels to make possible communication between all them [60, 53]. Figure 1.12 shows a domestic WSN where diﬀerent devices are connected in one or several WSN.

1.4 Standardization

The standardization of the protocols and technologies for wireless sensor networks is conducted by the Institute of Electrical and Electronics Engineers (IEEE) and 1.4. STANDARDIZATION 15

source:J. Stankovic Figure 1.12: Domestic WSN envolving diﬀerent applications and devices. source: Wireless Sensor Networks, Jack Stankovic, University of Virginia. the Internet Engineering Task Force (IETF).

1.4.1 IETF Working Groups

The IETF Working Groups are the primary mechanism for the development of IETF specifications, standards, and guidelines. The Working Groups are typically created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.). Upon completion of its goals and achievement of its objectives, the Working Group is terminated. There are some IETF working groups of particular interest to WSN: the ROLL group, the 6LoWPAN group, and the CoRE group.

ROLL Working Group

The Routing Over Low-power and Lossy networks (ROLL) Group gives detailed analysis of the routing requirements focussing on several applications – Home automation (RFC 5826), Commercial building automation (RFC 5867), Industrial automation (RFC 5673), Urban environments (RFC 5548). Its work addresses the special requirements of Low power and Lossy Networks (LLNs) such as WSN. Among the routing protocols for WSN, the IPv6 Routing Protocol for LLNs (RPL) (section 2.4.1) has been published as RFC [58]. RPL is an energy-efficient protocol for multipoint-to-point traffic communications, and is the case of many WSN applications, in which nodes report measurements to a base station. However, this is not the case of all WSN applications. Unfortunately, RPL performance has proven to be extremely inefficient in point-to-multipoint and point-to-point communications [13, 14]. The article referenced in [12] introduces a critical comparison between RPL and LOADng evidences that the last protocol is, in general situations, more efficient than RPL is, at the same time it consumes less memory resources. 16 CHAPTER 1. WIRELESS SENSOR NETWORKS

6LoWPAN Working Group The objectives of IPv6 over Low power WPAN (6LoWPAN) working group are to ensure interoperability, security, and management of 6LoWPAN networks. This group work closely with the ROLL working group, which is developing IPv6 routing solutions for low power and lossy networks (LLNs). The 6LoWPAN working Group has completed two RFCs: – RFC4919 [33], that documents and discusses the problem space of 6LoWPANs, and – RFC4944 [39], which deﬁnes the format for the adaptation between IPv6 and 802.15.4. Some special considerations for routing over 6LoWPANs are:

• Most LLN must be optimized for energy consumption

• LLN have a very limited memory and should work on low power. So in some situation is better to choose a single interface routing and a ﬂat topology.

• Traffic data flows might be considered in the selection of the routing protocol. Note that RPL is optimized for multipoint-to-point flows, works pretty well for point-to-multipoint and gives basic support for peer-to-peer traffic.

• LLNs have low data rates, so LLN protocols must give support and be optimized for low data rates. It is recommended to under-react, as the conditions leading to loops could be transient. Also, over-reacting to such conditions in LLNs could lead to further routing oscillations and energy consumption in nodes to process the control packets.

CoRE Working Group The Constrained RESTful Environments (CoRE) working group will deﬁne a framework for applications which deal with the manipulation of simple resources on constrained networks. A constrained IP network has limited packet sizes, may exhibit a high degree of packet loss, and may have a substantial number of devices that may be powered oﬀ at any point in time but periodically “wake up” for brief periods of time. This includes applications to monitor simple sensors (e.g. temperature sensors, light switches, and power meters), to control actuators (e.g. light switches, heating controllers, and door locks), and to manage devices. CoRE working group has done the major standardization work for CoAP protocol [46, 57]; Constrained Application Protocol (CoAP) is an Application layer protocol that is intended for use in resource-constrained internet devices, such as WSN nodes. The CoRE group has proposed the following features for CoAP: 1.4. STANDARDIZATION 17

• RESTful protocol design minimizing the complexity of mapping with HTTP.

• Low header overhead and parsing complexity.

• URI and content-type support.

• Support for the discovery of resources provided by known CoAP services.

• Simple subscription for a resource, and resulting push notiﬁcations.

• Simple caching based on max-age

1.4.2 IEEE 802.15.4 A WSN protocol should satisfy all the requirements and objectives for which it ! = !" (*.*!/%(011 ! (*.* + ! (*.* #$#$ )*+,-( × !! %&'("" !$2"!.'4! 9<):46! %1! 568)8.8&47! *9(! '%7.! /%9.6%--46! 89.461*/4! $UW;"! has! been!"#$%&&%'( developed, )*+( ,-.!$$( /0&%&1&"2(while being 1&*2#3$( as "$22( simple /&4$0(4&49.7! )2( as 1%6!3$1')*-23;( possible. G-<4.%%.'F! *$%4&0C( *9(! .'4! 2-=$;( 9<):467! )*+( 2$1#0-%>( %1! ^HW#,U`! )0$( )"2&( /0$"-3-*)0>( 3'4!5*6*)4.467!-87.4(!89!3*:-4!;;!*64!*-7%!<74(!1%6!.'4!/%(89=!1&3/)0$+( 4-%'( 56!( )*+( 6-78-9( !)2$+( &*( %'$( :-%(568)8.8&47! 0)%$;( )( 1&3/)0$+9(G'-2(/)/$0(-2(*&%(%&(+0)4()*>(1&*1"#2-&*(0$.)0+-*.( 1%6! LMGF! I8=G44F! *9(! M8N@8! 56%.%/%-7?! ;9! .'4! 4118/849/>!/%)5*687%9?!@8=?!A!7'%B7!.'4!(*.*!/%(89=!4118/849/>!1&3/)0-2&*( &<(*&03)"-=$+( $*$0.>( 1&*2#3/%-&*( -2( /0&?-+$+(^HW#,U`! -*( 4'-1'(&*$(-2(2#/$0-&0(2-*1$(%'$(2#-%):-"-%>(&<(*$%4&0C(/0&%&1&"2( -*>467F! .'4! G-<4.%%.'! 568)8.8&47! 89/-<(4! /-849.! In%1! .'4! some 1%<6!8-.9(@9(80&3(%'$( B864-477! WSN 94.B%6C7! applications!"#$% &467<7!(#*-%(/&-*%(&<(?-$4;(%'$(56!()*+(6-7 .'4! (*.*! 78D4?!nodes @%6! 7)*--! battery746&8/4! and *//477!-2(.0$)%">(-*<"#$*1$+(:>(/0)1%-1)"()//"-1)%-&*2;(&<( lifetime 5%89.! $cH,"F! play UW;! an cH,F! important 7>9/'6%9%<7! role4'-1'(3)*>( – e.g.(*.*! 78D47! in8-(')?$(:$%%$0($<<-1-$*1>(-*($*$0.>(1&*2#3/%-&*9( $*6%<9(! the ZebraNet7)*--46! .'*9! AAE! project :>.47"F! G-<4.%%.'! [28] 87! the .'4! /%994/.8%9N%6849.4(! nodes&%'$0(<)1%&02(2#1'()2(%'$(*$%4&0C(0$"-):-"-%>;(0&)3-*.(1)/):-"-%>;( lifetime $cW\"! determine cH,F! *9(! -%=8/*-! the -89C! /%9.6%-! time *9(! during :47.!7%-<.8%9?!H-7%F!I8=G44!'*&4!*!=%%(!4118/849/>!1%6!(*.*!78D4!A*(2#33)0>;(!"#$%&&%'()*+(,-.!$$()0$(2#-%):"$(<&0("&4(+)%)(*(*5.*.8%9!56%.%/%-!0$1&?$0>(3$1')*-23;( $]2WH,"! 568)8.8&47?! 1'-/2$%( H7! /0-1$;( 7'%B9! )*+(-*2%)"")%-&*( 89! @8=?! OF! 1&2%(*$$+( a7)*--46!.'*9!JK2!:>.47?!@%6!-*6=4!(*.*!78D47F!G-<4.%%.'F!LMGF! sensor0)%$( )//"-1)%-&*2( node will 4-%'( "-3-%$+( track :)%%$0>( the /&4$0( zebra’s B2#1'( )2( position..'4! 3&:-"$( G-<4.%%.'!%&(:$(1&*2-+$0$+(-*(%'$(<#%#0$9( 87! In .'4! such )%7.! /%)5-8/*.4(! applications, 56%.%/%-! B8.'! the JXX! use of *9(! M8N@8!+$?-1$2()*+(:)%%$0>7&/$0)%$+(2$*2&0(*$%4&0C2D;(+#$(%&(%'$-0("&4( '*&4! )! %1! %&46! EOPF! *7! 568)8.8&47!*9(!4&49.7!89!.%.*-?!\9!.'4!%.'46!'*9(F!I8=G44!87!.'4!( simple/%)5*64(!/&4$0( .%! protocols, .'4! 1&*2#3/%-&*( QR?S2P! %1!standards "$)+-*.(I8=G44! $B'464! %&( )( "&*.( .'4! and "-<$%-3$9( (*.*! operatives 87! JKT! E*( %'$(78)5-47.!%94!B8.'!%9->!OX!568)8.8&47!(41894(!89!XK2?JS?O?!3'87! &%'$0( may contribute to power-saving while HLVNE6IJWXPJNG( :>.47!*7!-87.4(!89!3*:-4!;;"?!3'4!(87/%9.89<8.847!89!@8=?!2!*9(!A!')*+;(<&0('-.'(+)%)(0)%$(-3/"$3$*%)%-&*2(B2#1'()2()#+-&F?-+$&(.%.*-!9<):46!%1!568)8.8&47!87!%9->!*:%<.!%94!1%<6.'!.'4!9<):46! *64! /*<74(! :>! (*.*! 16*=)49.*.8%9F! 8?4?! .'4! )*+8)<)! (*.*! %1! 568)8.8&47! *9(! 4&49.7! (41894(! 89! G-<4.%%.'?! H7! /%)5*64(! maintaining2#0?$-"")*1$( desired 2>2%$32D;( 56!( functioning )*+( 6-78-( 4&#"+( of the :$( :$%%$0( network.G'-2( 4&0C( For 4)2( example, 2#//&0%$+( :>( using %'$( P-*-2%0>( Bluetooth &<( J1&*&3-1( 5*>-%*(F! B'8/'! 87! AAEF! 2KOOF! JK2F! *9(! 2AJ2! :>.47! 1%6! B8.'! .'4! G-<4.%%.'F! LMGF! *9(! M8N@8F! .'4! 78)5-8/8.>! )*C47! 2&"#%-&*2(:$1)#2$(&<(%'$-0("&4(*&03)"-=$+($*$0.>(1&*2#3/%-&*9( H<<)-02( &<( G)-4)*;( MEL;( #*+$0( %'$( J3:$++$+( O>2%$3( insteadG-<4.%%.'F!LMGF!I8=G44F!*9(!M8N@8F!64754/.8&4->?!;9!*!M8N@8! of UWB when possible may contributeI8=G44!&46>!7<8.*:-4!1%6!7497%6!94.B%6C89=!*55-8/*.8%97!(<4!.%! to power-saving as presented in ( O&<%4)0$( I):&0)%&0>( -*( W&3$2%-1( L&33#*-1)%-&*( )*+( 8916*7.6!*9(!/%)5<.*.8%9*-!/*5*/8.>?! GH!IJ(AK( E/%&$"$1%0&*-12(A*<0)2%0#1%#0$(L&*2%0#1%-&*(Q0&Y$1%9( ﬁgure94.B%6C7!B8.'!0.'4694.F!*9(!.'4641%64!-8)8.!.'4!5*>-%*(!78D4!.%! 1.13aL5MMJNG(LENO5PQGAEN(E8(LRAQOJGO(8EM(JHLR(QMEGELEI. ( ! .'4! )*+8)<)!0.'4694.! 5*>-%*(! 78D4!*7! JSKK! :>.47?! U%B4&46F! (( 3HG]0!;;;! ( !"#$%#&% !"#$%&&%' ()! *+,!$$ )+-.+ aL^G0[!\@!,[;^;3;Z0c!Hab!0Z0a3c!@\[!0HWU!,[\3\W\]! 1%6!*!=4946*-!/%)5*687%9F!*9!*(N'%/!)%(4!87!*77<)4(!*9(!.'4!'()*+," -./,'0&,1 2!334 ''1564 '276333 MJ8JMJNLJO( Figure 1.13, extracted from [34], is the result"#$%&$'& of$&'%())(* a comparative .+$ !"#$%% +",-" test"#$%&$'& of diﬀerent 2AJ2!:>.47!87!*(%5.4(!89!.'87!5*546?!899:;<0."= 3>? 6>6 6>4 !6>6 ()))!"*+,-Z[\: M9(/0123423 ,#0)42C-;( /0123425 ]X#$2%( /0123426 $+-%&0-)"( /012337898# &<( 2/$1-)"(()))!"*+,- 2$1%-&*( &*( <)1%&0>( wireless@%6!*!B864-477!7497%6!94.B%6C!89!1*/.%6>!*<.%)*.8%9!7>7.4)7F!@2:;AB= standards7C for useD11C>6 in WSN: 15>C Bluetooth,13E .'/0/#/1+2 UWB,1&33#*-1)%-&*( 343 556 ZigBee, 2>2%$32;^( 74!"""#$%&'()#!'*)#"+,-.%/') and 78 Wi-Fi. 9:;!*'/0/#/1+2;(?&"9(_`;(*&9(@;(//9( 789/4! )%7.! (*.*!F2:;AB= 78D4! %1! 89(<7.68*-!5C )%98.%689=!D11C>6 *9(! /%9.6%-! 1C *64! 137 <;(!+1+%#2[[a@7[[aa;(W$19(bccb9( 75 8= 37 >7 .!7)*--F!$4?=?!.'4!.4)546*.<64!(*.*!89!*9!49&86%9)49.*-!-)":&#",:;GHI+= 4>C1 335 4>17 75 ( Zb\: 89(I9(I-)*;(d(9M9(P&>*$;()*+(W9(P9(G-":#0>;(]Q$0<&03)*1$($?)"#)%-&*(&<(6!:**'@1+&!AB8-34-7C- ! )%98.%689=!)*>!64V<864(!-477!.'*9!O!:>.47!%9->"F!G-<4.%%.'!*9(!( ! 1&*%0&"( *$%4&0C2e( J%'$0*$%;( L&*%0&"N$%;( )*+( W$?-1$N$%;^( !"""# 0/'.%)# ?44 8BB 12(.)#3&4)(?&"9(bb;(*&9([;(//9(@@7af;(8$:9(bcc[9( I8=G44!56%.%/%-7!)*>!:4!*!=%%(!74-4/.8%9!$16%)!*!(*.*!/%(89=! Zf\: H9(6-""-.;(]H*()01'-%$1%#0$(<&0(4-0$"$22($U%$*2-&*(&<(Q0&<-:#2;^(-*( 5%/-)# 4118/849/>!5%89.!%1!&84B"!89!758.4!%1!.'486!7-%B!(*.*!6*.4?!@2 !"""# !'.)# 0/'6)# !'*)# "+,-.%/')#DQ!+1+%#2BAJLENgcfD;( M&)*&C$;( KH;( N&?9( bccf;( //9(bf@`7bfhS9( J44 F2 34B DQ!*'/0- 100 Z_\: J9( 8$00&( )*+( 89( Q&%&0%-;( ]!"#$%&&%'( )*+( 6-78-( 4-0$"$22( /0&%&1&"2e( H( .()*+()(1&3/)0-2&*;^( !"""# 78%,+,((#0/99:');( ?&"9([b;( *&9([;(//9( 9:;!*'/0- 80 544 3BB [b7[@;(8$:9(bccS9( $&'%())(* ZS\: i9(6)*.;(j9(M$*;(d9(,')&;(,9(X#&;()*+(M9(j)&;(]L&3/)0-2&*(&<(AJJJ( acb9[[$()*+(AJJJ(acb9[S9f(PHL;^(-*(5%/-)#!"""#0;1#129<)#"9,%48'4# 60 144 4B $,-='/+/48,(>#3/?8+,#@#78%,+,((#0/99:';(O')*.')-;(L'-*);(P)>;(bcc_;(

HF0-!@I!.'/0/#/1+2!J!)1+%#2 //9(@hS7@ac9( Q0R,&:'0$+/A*")0$:;AL= 40 .+$ Z@\: !)C$0;( N9( ],-.!$$( )*+( !"#$%&&%'e( O%0$*.%'2( )*+( 4$)C*$22$2( <&0( !"#$%% 4 B -*+#2%0-)"()//"-1)%-&*2;^(!""#0/9<:.8'4#@#0/'.%/+#"'48',,%8'4;(?&"9([@;( -./,"00"( KL- M)N-,, L)OP) DEF+#@@#G KLD M/ND++ L/OP/ 20 ( *&9(b;(//(bc7bS;(H/0-"FP)>(bccS9( ! Data Coding Efficiency( (%) +",-" ! Zh\: W9(Q&01-*&()*+(69(R-0%;(]5"%0)74-+$:)*+(0)+-&(%$1'*&"&.>e(Q&%$*%-)"()*+( 8-.9(S9((L&3/)0-2&*(&<(%'$(/&4$0(1&*2#3/%-&*(<&0($)1'(/0&%&1&"9( @8=?!O?!!W%)5*687%9!%1!.'4!/%)5-4+8.>!1%6!4*/'!56%.%/%-?!1')""$*.$2()'$)+;^(!"""#0/99:')#3&4);(?&"9(_[;(*&9(h;(//9(@@7h_;(d#">( 0 (a) Protocols consumption (b) Protocols complexity ( 0 1 2 3 4 ! bccf9( ( 10 10 10 10 10 Za\: d9( O9( I$$;( ]Q$0<&03)*1$( $?)"#)%-&*( &<( AJJJ( acb9[S9_( <&0( "&470)%$( FigureData Payload 1.13: Size (bytes) Comparative of Wireless Standards. source: [34] 674 ! 2$! *"&3.%*+&456,-'0&4*4-0$"$22( /$02&*)"()0$)(*$%4&0C2;^(!"""#$%&'()#0/'(:9,%#"+,-.%/');(?&"9( ! G-<4.%%.'! *9(!Sb;(*&9(f;(//9(h_b7h_`;(H#.9(bcc@9( I8=G44! *64! 89.49(4(! 1%6! 5%6.*:-4! 56%(!&467<7!.'4!(*.*!78D4?!644 7'%6.!6*9=47F!*9(!-8)8.4(!:*..46>!5%B46?!W%974V<49.->F!8.!%11467!Z`\: d9( O9( I$$( )*+( j9( L9( R#)*.;( ]AGMA( ,!*&+$e( H( ,-.!$$FAJJJ( acb9[S9_( ! @2 /")%<&03(<&0(4-0$"$22(2$*2&0(*$%4&0C2;^(-*(5%/-)#!"""#!'.)#0/'6)#12(.,9(A# 174 &46>! -%B! 5%B46! /%97<)5.8%9! *9(F! 89! 7%)4! /*747F! B8--! 9%.! ;9!.'87!74/.8%9F!*9!4&*-<*.8%9!%1!.'4!G-<4.%%.'F!LMGF!I8=G44F!F2 3&'#@#02?,%',.8-(;(G)-/$-;(G)-4)*;(E1%9(bcc@;(//9([_@b7[_@h9( Bluetooth and ZigBee are suitable for)4*7<6*:->! lowZ[c\ data *114/.!: H9( O-C&0)( :*..46>! rate )*+( -814?! K9( applications 89( LMG! X0&=);( 87! ]L&$U-2%$*1$( 56%5%74(! with &<(1%6! AJJJacb9[S9_( 7'%6.N limited 4-%'( &%'$0( *9(! M8N@8! %9! (8114649.!144 *754/.7! 87! 56%&8(4(?! ;.! 87! 8)5%6.*9.! .%! 6*9=4!*9(!'8='!(*.*!6*.4!*55-8/*.8%97?!\9!.'4!%.'46!'*9(F!M8N@8!2>2%$32( -*( %'$( b9_( XR=7AOP7!)*+;^( -*( 5%/-)# !"""# !'(.%:9,'.&.8/'# @# 9%.8/4! .'*.! 74&46*-! 7-8='.! (8114649/47! 4+87.! 89! .'4! *&*8-*:-4! 3,&(:%,9,'.#$,-='/+/42#0/'6,%,'-,;(E%%)4);(P)>(bccS;(//9[ha@7[h`[9( battery power,374 as ﬁgure 1.13a illustrates,87!(478=94(!1%6!*!-%9=46!/%994/.8%9!*9(!7<55%6.7!(4&8/47!B8.'!*! due to their lower power consumption Z[[\: V9( O'#)-:;( P9( !&#"3)"<;( 89( O)""):-;( )*+( H9( I)C)2;( ]L&7$U-2%$*1$( &<( 7%<6/47?! @%6! 4+*)5-4F! 89! .'4! ;000! XK2?JS?O! 7.*9(*6(F! .'4! 7<:7.*9.8*-! 5%B46! 7<55->?! ;9! %6(46! .%! 56*/.8/*-->! /%)5*64! .'4! */.8%9!6*9=4!87!*:%<.!JK)F!B'8-4!8.!87!QKNAKK)!89!.'4!64-4*74(!344 ,-.:$$()*+(6IHNe(H(/$0<&03)*1$(2%#+>;^(-*(5%/-)#!"""B!C!5#!'.)#0/'6)# – up to 4 times lower – compared to5%B46!/%97<)5.8%9F!1%<6!B864-477!56%(!*&*8-*:-4!*64!:6841->!564749.4(!*7!*9!bcc@9( rate56%&8(4!891%6)*.8%9!%9->F!789/4!%.'46!1*/.%67F!7( low 4-0$"$22(

S0&A>:T$,&NU:'0$+A/*")0$ ;AVIGH= 4+*)5-4F! 89/-<(89=! G-<4W%642! dJAe! 16%)! W*):68(=4! c8-8/%9! 4 1&33#*-1)%-&*2e( H( /$0<&03)*1$( )//0)-2)"( &<( %'$( !"#$%&&%'( )*+( %'$( 74978.8&8.>! *9(!89.4614649/4F! 5-*>! *!)*Y%6!6%-4!89! *114/.89=! .'4! [*(8%!$Wc["F!_cJJK!dJOe!16%)!@6447/*-4F!!WW2OAK!dJSe!16%)! normalized5461%6)*9/4!89!64*-87.8/!8)5-4)49.*.8%97?! power-./,"00"( consumption. KL- M)N-,, L)OP) ( ,-.!$$( 1&""&1)%$+( &*()*(-*+#2%0-)"( <"&&0;^(-*( 5%/-)#!"""#!'.)#0/'6)#!'*)# ( W'85/%9! %1! 34+*7!"+,-.%/') ;97.6<)49.7!(BAJLENgcfD;(M&)*&C$;(KH;(N&?9(bccf;(//9(bfa[7bfa@9( $3;"F! *9(! W_SAJJJ! dJRe! 16%)! ! 8-.9(@9((L&3/)0-2&*(&<(%'$(*&03)"-=$+($*$0.>(1&*2#3/%-&*(<&0($)1'(/0&%&1&"9(W%94+*9.!Z[f\ $564&8%<7!: L)3:0-+.$( ;9.4678-f7! O-"-1&*( M)+-&;( ,687)"?!H+:,0/%,IJ"K.,%'&+# 3'4! /<6649.! 5%/*:-.# L&.&# 1=,,.9( L)3:0-+.$;(5V;(H#.9(bcc@9( Figure;Z?! (,[\3\W\]! 1.13bW\^,]0_;3`!Hab! is a comparative,\M0[!W\acL^,3;\a of! protocol/%97<)5.8%97!%1!.'4!.6*97)8.!$3_"!*9(!64/48&4!$[_"!/%9(8.8%97! complexityZ[_\: 80$$21)"$;( M1NNO# based P7H# 1/+:.8/'# on 6/%# 3,*8&JQ8-=# the number 78%,+,((# ;<<+8-&.8/'( of 9( 1%6!4*/'!56%.%/%-!*64!7'%B9!89!3*:-4!;Z?!3'4!(*.*!7'%B9!*64! K9: LENLI5OAENO( O)*(W-$.&;(LH;(W$19(bcc_9( primitives#$! "%&'&(&)*+&,-)./0'1* and events. Bluetooth is the1%6!5*6.8/<-*6!56%(!64564749.*.8&4!1%6! mostZ[S\: L'-/1&*;( complex00IRSO# 5%,+898'&%2#protocol, L&.&# 1=,,.# and T%,U)# has N)OSV9( E2"&;( three N&04)>;( ;9!.'87! 5*546F!.'4!G'-2(/)/$0(')2(/0$2$*%$+()(:0&)+(&?$0?-$4(&<(%'$(<�(3&2%( /%)5-4+8.>! %1! 4*/'! 56%.%/%-! 87! /%)5*64(! 4+*)5-47! %1! .'4!bcc@9( 7*)4! .>54?! @8=?! S! 89(8/*.47! .'4! 5%B46! times more primitives than ZigBee, which isZ[@\ the: L&*$U)*%;( simplest18'4+,J0=8<# protocol. 7W;E# Q&*8/# 0MXSNNN9( N$4/&0%( !$)1';( LH;( :*74(!%9!.'4!9<):467!%1!568)8.8&47!*9(!4&49.7?!3*:-4!;;;!7'%B7!/&/#")0(4-0$"$22(2%)*+)0+2;(!"#$%&&%';(56!;(,-.!$$;()*+(6-7/%97<)5.8%9! 89!bcc@9(!"! <98.! 1%6! 4*/'! 56%.%/%-?! \:&8%<7->F! .'4! 8-( 4-%'( )( T#)*%-%)%-?$( $?)"#)%-&*( -*( %$032( &<( %'$( %0)*23-22-&*( ( %-3$;( +)%)( 1&+-*.( $<<-1-$*1>;( /0&%&1&"( 1&3/"$U-%>;( )*+( /&4$0( 1&*2#3/%-&*9( 8#0%'$03&0$;( %'$( 0)+-&( 1')**$"2;( 1&$U-2%$*1$( 50

51 18 CHAPTER 1. WIRELESS SENSOR NETWORKS

Due to the limited memory and computational capacity of sensor nodes, and low communication data rates, ZigBee is very suitable for sensor networking applications. IEEE 802.15.4 is the globally accepted wireless standard for WSN. It is the basis of ZigBee, an alliance of 25 enterprises (some of them being semiconductor manufacturers) with the aim to develop a low price wireless technology with low energy consumptions. IEEE 802.15.4 devices communicate on frequency bands at 868 MHz, 915 MHz, and 2.4 GHz. Depending on the frequency band, they achieve data rates between 20 kbps and 250 kbps. They employ a DSSS modulation scheme and use CSMA/CA for channel access. In communication, ZigBee nodes may form multi-hop networks and play diﬀerent roles: end devices (clients), routers, or gateways. Table 1.1 compares several wireless technology standards. ZigBee provides communication to much more nodes in a single network than the other technologies, with the beneﬁt of requiring less memory, power and resources. On the other hand, its bit rate (bandwidth) and coverage is more limited.

Standard Wi-Fi Wi-Fi Bluetooth ZigBee 802.11g 802.11b 802.15.1 802.15.4 Main Application WLAN WLAN WPAN Control & Monitoring Required Memory 1MB+ 1MB+ 250KB+ 4 − 32 KB Battery Life (days) 0.5 − 5 0.5 − 5 1 − 7 100−1000+ Network size (nodes) 32 32 7 255 − 65000 Bit rate 54Mbps 11Mbps 720Kbps 20 − 250 Kbps Coverage (meters) 100 100 10 (v1.1) 1 − 100 Important parameters Bitrate; Bitrate; Cost; Reliability; Flexibility Flexibility Application Low power proﬁles consumption; Low price

Table 1.1: Comparative between wireless technology standards.

1.5 Motivation

WSN is a new emerging technology said to be one of the technologies that will change the world in the near future. This section presents WSN evolution and introduces its importance in future networks. 1.5. MOTIVATION 19

1.5.1 WSN evolution

One of the first predecessors of modern sensor networks is the Sound Surveillance System (SOSUS) sensor network. Its development started in 1949 to research antisubmarine warfare during the Cold War and was used until 1990s. Several institutions took part in SOSUS development, such as MIT, Bell Labs and Columbia University. The SOSUS components are now used for scientific projects such as tracking the vocalizations of whales and other ocean mammals. In the 80 decade, the Defense Advanced Research Projects Agency (DARPA) of the USA promoted a Distributed Sensor Network (DSN). In 1998, Dr. Kristofer Pister from Berkeley University, started the Smart Dust Project: how to embed an autonomous sensor in an 1mm3 device. One year later, in 1999, the first mote was built (the mote René). In 2002 TinyOS appeared as the first operative system for sensor nodes. The development of energy-efficient microprocessors has increased during the first decade of 21st century. Due to the amount of electronic systems installed all over the World (for industry, domestic use, etc.), a big amount of energy can be saved if power efficiency of these systems is improved. Instead, by consuming less power, electronic devices can increase their autonomy, or become portable – in case they weren’t because of their power consumption – with use of batteries. Since the first sensor node appeared, sensor nodes have experienced a considerable evolution. Table 1.2 presents the characteristics of a selection of different sensor nodes in order of appearance. While maintaining its size and power consumption, they have increased its processing power, memory, and radio capabilities.

Platform René Mica2/Mica2Dot Telos Tmote Sky Imote2 (1999) (2002) (2004) (2005) (2007) CPU ATMEL8535 ATmega128L TI MSP430 TI MSP430 IntelPXA271 8 bit 8 bit 16 bit 32 bit 32 bit 4 MHz 8 MHz 8 MHz 8 Mhz 13–416 MHz Memory 512 B RAM 4KB RAM 2 KB RAM 10 KB RAM 32 MB RAM 8 KB Flash 128 KB 60 KB Flash 48 KB Flash 32 MB Flash L1: PhysicalL1:L1: Physical PhysicalFlash Radio TR1000 CC1000 CC2420 CC2420 CC2420 10 Kbps 38.4 Kbps 250 Kbps 250 Kbps 250 Kbps

Table 1.2: Evolution of sensor node platforms. 20 CHAPTER 1. WIRELESS SENSOR NETWORKS

1.5.2 Future Internet Networks In February 2003, the MIT listed the 10 emerging technologies that will change the world [1] (ﬁgure 1.14), inIntroduction: which the Wireless 2003 Sensor Networks appeared on the top of the list.

Figure 1.14: Front page of the MIT journal.

From the 1960s, people-per-computer rate have increased many orders of!"#$%&'(!)' mag- )%*+,%-.%/' nitude, while the physical size of computers has been reduced (ﬁgure 1.16b). Nowadays, many people own a smartphone (1.15a), which in fact is nothing but a tiny computer with autonomy, mobility, and communication capabilities. People interaction with sensor nodes will be common in the near future. Acting as a sensor node, people can interact with the environment, and environment can impact on people. Smartphones can be used to monitor and track data. For example, the climatological information can be used to track and predict much more accurately the weather forecast in populated cities (ﬁgure 1.15b), providing meteorological information with high accuracy. Future: mobiles as sensors?

(a) Global smartphone users (b) Weather forecast with the forecast. aid of WSN. source [62]

Figure 1.15: People impact on WSN.Introduction to Wireless Sensor Networks - March 2010

In that new emerging scenario, the existing technologies have been adapted to satisfy the communication requests. However, new proper communication protocols should be developed. Naming, addressing and optimal routing are important issues to solve in WSN, specially thinking about integration into the Future Inter- 1.6. CONCLUSION 21 net. The connectivity of this devices needs to consider both existing and future technologies for connecting to the global infrastructure. This means that scalability, interoperability and reliability are important factors in the WSN technology development. A Brief History

1$ !"#$%&'"&!'$&'($)"*&+,'(-$

./01$ ./21$ ./31$ .//1$ 4111$ 41.1$

(a) Future mobile and ﬁxed internet (b) People per computer evolution. !"#$%&'()**%+&,--.' networks. source: [44] Figure 1.16: People-per-computer evolution and future networks.

1.6 Conclusion

Wireless Sensor Networks were recognized – in the year 2003 – by the MIT Jour- nal as one of the emerging technologies that will change the world. The current applications of WSN cover a wide range of fields such as health, traffic monitoring, domotics, or military applications. In the near future, people will take the role of sensor nodes, contributing to interact with the environment in smart city scenarios. In this context, new standards for WSN must appear to adapt to different needs, applications, and requirements. WSN development is a must in a technological world where communication and data traffic is increasing exponentially. At the time this manuscript is written, there are few stablished standards in WSN. This leads to problems of interoperability and integration between components. There is not a clear predominant hardware platform for sensor nodes, nor a clear tendency about which platform to use in each application. IETF’s working groups are doing an important task in standardization. However, the RPL routing protocol proposed as RFC doesn’t seem to adapt well in all kind of scenarios, so better (or alternative) protocols should be developed.

Chapter 2

Routing protocols in WSN

Wireless Sensor Networks are used in many fields, covering from health to military applications. As long as different applications present different traffic patterns, a routing protocol that performs well in an specific scenario, also uses to lack in scenarios with different characteristics. This chapter presents the protocol stack in WSNs, and introduces a selection of different routing techniques and protocols.

2.1 Protocol Stack

The protocol stack consists of the physical layer, the data link layer, the network layer, the transport layer, and the application layer (ﬁgure 2.1). TaskPlane Management Mobility Management Plane MobilityManagement PowerPlane Management

Application Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Figure 2.1: Protocol stack for wireless sensor networks.

In addition to the protocol stack, three abstract planes can be considered, which 24 CHAPTER 2. ROUTING PROTOCOLS IN WSN act across all the levels of the protocol stack: the power management plane, the mobility management plane, and the task management plane.

• The power management plane manages how a sensor uses its power.

• The mobility management plane detects and registers the movement of sensor nodes. By knowing who the neighbor sensor nodes are, the sensor nodes can balance their power and task usage.

• The task management plane balances and schedules the sensing tasks given to a speciﬁc region.

These management planes are needed so that sensor nodes can work together in a power-eﬃcient way, route data in mobile sensor networks, and share resources between sensor nodes.

2.1.1 The Physical Layer

The Physical Layer is responsible for the definition of transmission medium and modulation scheme. Nodes are linked in a wireless medium, using radio, infrared or optical media technology. Both infrared and optical transmissions require line of sight, whereas radio technology doesn’t. Infrared is license-free, robust to interference from electrical devices, cheap and easy to build, but its range is reduced compared to radio technology. The transmission media in a WSN is chosen depending on application, interoperability needs, and other factors. Wireless communications can employ, among others, – see section 1.4 – Ultra WideBand (UWB) or Impulse Radio (IR). UWB employs baseband transmission so no radio carrier is needed. Generally, Pulse Position Modulation (PPM) is used. Multi hop communication can overcome shadowing – caused by obstacles in communication link, such as vehicles, buildings, trees, etc. – and be affected by path loss – i.e., the radio signal attenuation as it propagates through the air. The choice of a good modulation scheme is critical. For example, an M-ary scheme can reduce the transmitted bits, but it results in more complex circuitry and increased radio power consumption. Generally, in WSN communication the binary modulation scheme is more energy-efficient and preferably over an M-ary schem.

2.1.2 The Data Link Layer

The Data Link Layer is responsible for multiplexing of data streams, data frame detection, medium access and error control. 2.2. ROUTING IN WSN 25

Medium Access Control

The Medium Access Control is a sublayer of the Data Link Layer. It must ensure mutual exclusion over the communications channel – which is usually a shared medium –, so as to avoid packet collisions, interferences, and cross-talk.

Error Control

Two important modes of error control are Forward Error Correction (FEC) and Automatic Repeat Request (ARQ). FEC uses additional overhead in messages, and error correction requires decoding complexity. On the other hand, ARQ requires additional energy in retransmissions. The use of FEC or ARQ depends on several aspects: when requiring low-complexity encoding and decoding (for instance, in a WSN with processing and energy limitations in its nodes), a simple error control code as ARQ may be desired over FEC. When the probability of errors in transmission is considerable (for instance, in a wireless shared channel with noise and interferences), using FEC may be desired over ARQ retransmissions.

2.1.3 Network Layer

The Network Layer provides multi-hop connectivity in the network, and ensures reliable point-to-point (P2P) and point-to-multipoint (P2M) connections. The network layer is also responsible to provide connection with external networks.

2.1.4 Transport Layer

The Transport Layer is responsible for maintaining the ﬂow of data if the application requires it.

2.1.5 Application Layer

Despite wireless sensor networks can be applied in many areas, application layer protocols are open research and remain unexplored at the time this manuscript has been written.

2.2 Routing in WSN

This section presents the route selection criteria for selecting the best routes, and the route managing in WSN node routers. 26 CHAPTER 2. ROUTING PROTOCOLS IN WSN

2.2.1 Route selection criteria Among all the possible routes towards a destination, choosing the preferred route depends on many aspects. Depending on the application (see sections 1.3 ), the characteristics of the WSN (see 1.1.2), etc. diﬀerent factors may be taken into account when choosing a preferred route. Some examples of diﬀerent criteria to choose the preferred route are listed below.

Number of hops A route is preferred among other if its path has a lower number of hops.

Time A ﬁrst route is preferred among a second if the time – usually, the expected time, or average time – a packet spends to reach the destination towards the ﬁrst route is lower than the spent by choosing the second route.

Power-efficiency A route is preferred among other if it is more power-efficient. A power-efficiency criteria can be defined taking into account the available power (PA) of the nodes in several different ways (the list is not exhaustive):

Maximum PA route The route that has maximum total PA is preferred. Maximum Energy route The route that consumes minimum energy to transmit the data packets between the sink and the sensor node is preferred. Maximum minimum PA node route The route along which the minimum PA is larger than the minimum PAs of the other routes is preferred.

2.2.2 Route managing Depending on how the routes are stablished and maintained, routing protocols – not only speciﬁc in WSN, but in general – can be reactive, proactive or hybrid.

Reactive protocols The protocols that only seek up routes on-demand are called reactive protocols. That is, a node will only try to establish a route when it wants to communicate with another node to which has no route. Some typical reactive protocols are DSR (Dynamic Source Routing), and AODV, Ad-Hoc On-Demand Distance Vector (RFC3561) described in section 2.4.2.

Proactive protocols The proactive routing protocols seek to maintain a constantly updated network topology by ﬂooding topology link-state information. This action results in a 2.2. ROUTING IN WSN 27 constant overhead of routing traﬃc information, but has the advantage that, in theory, the entire network topology is known to all nodes. In contrast with reactive protocols, there is no initial delay in communication. Some typical proactive protocols are OLSR, Optimized Link State Routing (RFC3626) described in section 2.4.3, and TBRF.

Hybrid deployments

Hybrid protocols combine the characteristics of reactive and proactive protocols. An example is the Zone Routing Protocol (ZRP) [25], described in section 2.4.4.

2.2.3 Packet routing Depending on the nodes which establish the route of a packet, routing – not only speciﬁc in WSN, but in general – can be classiﬁed in:

Source Routing When sending a packet, the source node decides the entire route path towards destination – including all the intermediate nodes. The intermediate nodes just forward the packet to the next hop according to the pre-stablished route indicated in the packet header.

Destination routing Also known as “hop-by-hop” routing. It occurs when the source node only sets the destination in the message header. The intermediate (and source) nodes send the packet to the appropriate next hop towards destination according to their respective routing tables.

There exist many ways and algorithms of routing packets, although most of them are not suitable for WSN. For example, IP algorithms can be divided into:

Link State Routing It is the case of the wired internet routing or OSPF. In link state routing, each node gathers information about link state of other nodes and ﬁnd the preferred route according to a ﬁxed criteria (e.g., using the Dijkstra algorithm to build routes). Each node maintains a view of the network topology with a cost of each link. To maintain the cost information updated, each node periodically broadcasts the link costs via its outgoing links. In wireless networks, and specially in WSN, this procedure causes an extra use of bandwidth and an extra waste of energy power.

Distance-Vector Routing These routing protocols are used in multi-hop packet radio networks. Every node maintains a routing table for all available des- tinations, containing a vector with the next hop and the cost (according 28 CHAPTER 2. ROUTING PROTOCOLS IN WSN

to a metric) to reach such destination. To maintain topology, nodes router periodically informs its neighbors of topology changes. Distance-vector routing protocols use the Bellman-Ford algorithm, Ford- Fulkerson algorithm, or DUAL FSM (in the case of Cisco Systems’s protocols) to calculate paths. An example of distance-vector routing protocol is LOADng, whose draft is described in section3 and further performance simulations are analyzed in chapter6. Some Distance-Vector protocols do not prevent routing loops from happen- ing and suﬀer from the count-to-inﬁnity problem (see appendix B.1). To avoid this problems, a sequence number can be associated – e.g. in AODV, described in section 2.4.2 – to each destination route and advertisement.

2.3 Mesh-under vs. Route-over Routing

The routing scheme in WSNs can be divided into two categories: the mesh-under and the route-over (see ﬁgure 2.2).

Layer2 forwarding (aka Mesh-Under) In the mesh-under scheme, routing and forwarding are performed at the link layer, using Layer 2 addresses. Packet fragmentation and assembly is done only in the origin and destination nodes, respectively.

TheMesh packet Under fragments vs. Route Over are delivered to the next hop by mesh routing and eventuallyTwo important reach architectural their destination. issues for IPv6 If over some LoWPAN of these are how fragments link-level factors are lost, a se- inform routing and at what layer datagram forwarding occurs within the LoWPAN. lectiveTraditionally, fragment IP retransmissionrouting occurs at the can network be layer preformed in a manner to largely retransmit independent only the lost packetsfrom –the forunderlying example, links that lost implement packets the individual can be hops. identiﬁed 6LoWPAN,by in its receiving role as an negative adaptation between the link (layer two) and the network (layer three), can support routing acknowledgmentat either layer. Figure packets 10 show (NACK). the difference in packet-processing between the two approaches.

FigureFigure 2.2: 10. Mesh-Under Mesh-Under (Layer vs.-Two) Route-Over vs. Route-Over routing. (Layer-Three) source: Forwarding. [27]

In a mesh under organization, the network stack performs no IP routing within the LoWPAN; instead, the adaptation layer seeks to mask the lack of a full broadcast at the physical level by transparently routing and forwarding packets within the LoWPAN. By emulating a full broadcast link, it potentially provides compatibility with IPv6 protocols that expect such communication behavior. The challenge is that logical link emulation is significantly more complex in LoWPANs than in traditional infrastructure-based 802.11 topologies. Mesh topologies require forwarding over multiple radio hops, and link-local multicast must deliver packets to all nodes in the entire LoWPAN. Many mechanisms that exist to form, maintain, and diagnose IP routing must also be recreated at the link layer for meshing to operate reliably.

Alternatively, route over performs routing at the IP layer, with each node serving as an IP router. We can view it as a collection of over-lapping link-local scopes, with each link- local domain defined by the inherent radio connectivity. Unlike mesh under, route over supports layer three forwarding mechanisms within the LoWPAN that can utilize network-layer capabilities defined by IP, such as IPv6 routing and ICMPv6 for configuration and management. Route over also lets IP routing protocols span different link technologies, enabling better integration into more capable networks. It also lets IP- based protocols constrain IP communication to local radio coverage, rather than an entire LoWPAN. Issues of link- versus network-layer routing aren’t unique to 6LoWPAN — they arise in Frame Relay, Asynchronous Transfer Mode (ATM), switched Ethernet, and

13 2.3. MESH-UNDER VS. ROUTE-OVER ROUTING 29

Layer3 routing (aka Route-Over) Route-Over routing is the typical way of IP routing, performing Layer 3 addresses. In route-over scheme all routing decisions are taken in the network layer. Fragmentation and reassembly of data packets occurs in every node. If one or more fragments are lost in a single hop transmission, a selective NACK can be performed for selective retransmission, but generally all fragments are retransmitted when using a route-over scheme.

2.3.1 Analysis This section analyzes the impact of diﬀerent variables – packet size, number of hops, and probability to loose packets – in each of the schemes. A deeper analytical comparison between the mesh-under and route-over schemes can be found in [9].

Packet size In route-over, packet fragments – even from different transmissions – are buffered in every node, and there is possibility of buffer overflow. In mesh-under scheme there is no possibility of buffer overflow at intermediate nodes since the packet fragments are not buffered.

Number of hops The probability of packet loss during transmission increases with the number of hops of the route. The retransmission scheme election – a selective retransmission versus the retransmission of all packets – aﬀects to the total delay on transmission. When using a route-over scheme, the packet reassembly performed in each intermediate node increases the delay in front of using a mesh-under scheme.

Packet loose probability Network environment noise, interferences, or the number of hops of the route, are some of the variables that increase the packet loose probability in transmission. Packet retransmissions using a route-over scheme (in which generally all packets are retransmitted) can increase the delay in front of using a mesh-under scheme (in which a selective retransmission is performed).

2.3.2 Benefits of each scheme The route-over and mesh-under schemes performance is different, and the benefit of using one or other scheme depends on the characteristics of the concrete network scenario. 30 CHAPTER 2. ROUTING PROTOCOLS IN WSN

An analysis performed in [9] concludes that, when using selective retransmission, using a route-over scheme results in a more reliable fragments transmission from the source to the destination – because of the hop-by-hop recovery –, and requires a lower number of transmissions. However, the mesh-under scheme performs better in terms of total delay. In mesh-under scheme, packet fragmentation and assembly is done only in the origin and destination nodes, while in route-over scheme this situation occurs in every node. For that reason, in WSN scenarios where processing capabilities and memory are limited, the mesh-under scheme may be considered a good option for use. The mesh-under scheme is not a good choice for use in noisy environments, in which noise increases the packet loss probability. Instead, the route-over scheme is good for environments with high packet loss probability across the route path, because of the hop-by-hop recovery mechanism. The hop-by-hop recovery mechanism of the route-over scheme can beneﬁt some applications requiring reliable transmissions. On the other hand, in transmissions where the packet size is small or the number of hops is low, the use of a mesh- under scheme may perform better than the route-over scheme. In applications where loosing some packets is allowed, the use of a mesh-under scheme should perform better than the route-over scheme.

2.4 Routing protocols

Some adapted versions of Cellular systems, bluetooth and MANET have been proposed for use in WSN [47], but they are unsuitable for sensor networks due to its large messaging overhead and link setup delay. This section describes a selection of routing protocols valid for use in WSN. All of them are well-recognized standards for mesh networks. This selection contains RPL, the WSN routing protocol published as RFC; AODV, a reactive distance- vector routing protocol; OLSR, an adhoc wireless mesh routing protocol; and ZRP, the ﬁrst hybrid routing protocol.

2.4.1 RPL protocol

RPL (Routing Protocol for Low Power and Lossy Networks) is intended to be the IPv6 routing protocol for LLN and sensor networks. One of the unoﬃcial goals of the ROLL Working Group is to prevent fragmentation in the sensor networking market by providing an IP-based routing standard, and solicit industrial support behind that standard. At the time this manuscript is written, RPL has been published as RFC by the ROLL Working Group of the IETF. 2.4. ROUTING PROTOCOLS 31

The objective of RPL is to target networks which comprise up to thousands of nodes having very constrained resources and where the network is managed by a (single or few) central supernodes. Handling mobility is not an explicit design criteria. RPL does distinguish between three type of traffic: multipoint-to-point (M2P), point-to-multipoint (P2M) and point-to-point (P2P). RPL works with all three type of traffic. It is well optimized for M2P, gives reasonably support for P2M but, besides, it provides only basic features for P2P. RPL aims to be a flexible protocol, able to provide a standard of of few base mechanisms where different WSN applications can agree. Various RPL extensions are provided to fit some of the specific application requirements.

RPL description RPL is a distance-vector routing protocol entirely deﬁned for IPv6-based WSNs. RPL is a proactive routing protocol, i.e., it construct its routes in periodic intervals. It is possible to run several RPL Instances in one physical network, so the network nodes are allowed to be part of more than one RPL Instance. Starting from one or more root nodes, each Instance builds up a tree-like routing structure in the network, resulting in a Destination-Oriented Directed Acyclic Graph (DODAG). As multiple RPL Instances may coexist, multiple DODAG may coexist in the same network. However, a node can not join more than one DODAG within one Instance.

Topology Formation RPL topology construction begins by designating a special node to be the root node for one Instance. The conﬁguration parameters of the network are packed into a DODAG Information Object (DIO), which is then used to disseminate the information in the network. Many options are available to conﬁgure a DIO to match the application’s requirements. However, the compulsory information contained in a DIO includes:

• the RPL Instance ID for which the DIO is sent: It is a unique identiﬁer of an RPL Instance in a network.

• the DODAG ID of the RPL Instance of which the sending node is part: It serves to uniquely identify a DODAG in an RPL Instance.

• the current DODAG version number: A unique identiﬁer of the DODAG.

• the node’s rank within the DODAG: It describes the node’s logical distance from the root node within the DODAG. 32 CHAPTER 2. ROUTING PROTOCOLS IN WSN

This rank number increases from root node to the successive parents and leaf nodes within the formed network tree.

When forming the DODAG, each node is required to select parent nodes from its neighbors, under the restriction that the node’s calculated rank must be larger than the rank of all its parents. By this procedure, the formation of loops is prevented. The node’s rank is calculated based on the Objective Function (OF) and using its related metric, which is speciﬁed according to the DODAG’s application requeriments. Note that the Objective function may vary in each network, and it could use (not necessairly) the metrics given by the distance of hops or the physical distance. The Objective function can also take into account the desirability of a one speciﬁc neighboring node to be chosen as a parent.

RPL route discovery example

The following example illustrates a typical route discovery process. The ﬁgure 2.3 shows a simple network structure, where the circles represent nodes and the discontinued lines represent the possible links between nodes. In this example, the metrics used and desired to minimize is the number of hops.

Figure 2.3: A example of wireless sensor network.

The RPL protocol starts when the root node (node 0 in figure 2.4) triggers the DODAG formation by broadcasting a DIO message to its neighbors. The diffusion of DIOs, by construction of the protocol, can only be initiated by the root node of the DODAG. As seen in figure 2.4, the DIO messages traverse the network while the rank field is updated in each hop. The root node’s rank is 0, since it has distance 0 to itself, and the rank of its immediate neighbors is 1 according to the OF. 2.4. ROUTING PROTOCOLS 33

Figure 2.4: DIO message broadcast by the root node.

After calculating their rank, each node updates the DIO and broadcasts it to its neighbors as shown in ﬁgure 2.5. Each node retains a candidate neighbor set, with all the neighbors with equal or lower rank than the rank it has ﬁrst received in a DIO message. From this set, the node chooses the called preferred parent, which will serve as the node’s next hop towards the root when routing a data packet. This choice is determined by the OF.

Figure 2.5: DIO message broadcast by the inmediate root node neighbors.

The preferred parents (for nodes with rank 1) are chosen to minimize the number of hops. This relationship is represented by the bold plain arrows in ﬁgure 2.5. In the next step of the RPL topology construction, the nodes with calculated rank 2 have chosen their preferred parent and broadcasted their DIO messages. The leaves of the network tree have then received these DIO messages and joined the DODAG by calculating their rank. As it happens in the example, sometimes there are parents that satisfy the same conditions imposed by the OF to be elected as the preferred parent. In this case, 34 CHAPTER 2. ROUTING PROTOCOLS IN WSN

Figure 2.6: DIO message broadcast by the inmediate root node neighbors.

the node is free to choose any of the suitable parent nodes as a preferred parent. After the leave nodes of the network tree choose a preferred parent, the ﬁnal topology structure may look like in ﬁgure 2.7.

Figure 2.7: Final topology structure with selected parents for root node 0

Therefore, although nodes have chosen a preferred parent node, they still keep track of all their parent nodes, to which it can resort as next hops in case its preferred parent becomes unreachable. The DODAG structure including both parent and preferred parent connections is shown in ﬁgure 2.8

Route maintenance

Node failures, changes in node location or other general network changes may require to rebuild the routing topology. To help nodes to keep track of which DODAG iteration they are in, and to determine whether it is the newest one, 2.4. ROUTING PROTOCOLS 35

Figure 2.8: DODAG structure with parents and preferred parents the DIO message contains a version number field. Only the root is allowed to increment the version number in order to trigger a new rebuild of the DODAG. When a node receives a DIO message containing a newer version than the one recorded, it realizes that there are changes in the network. The node can add the sender of this DIO to its candidate parent set, but a node can only become part of the new DODAG iteration once a specified percentage of its parents are part of this DODAG interaction as well. That percentage is indicated in the OF specifications. When changes occur in the network and a new DODAG must be stablished, all the nodes must update to the current DODAG. This implies a problem of data dissemination with maximum reliability and maximum power efficiency. To reach this requirements, RPL employs the Trickle algorithm to notify changes in the network.

Traffic Patterns RPL distinguishes three type of data traffic, depending on the source and destination of the data traffic : multipoint-to-point, point-to-multipoint and point-to- point. RPL provides an optimized mechanism for multipoint-to-point (M2P) data traffic, i.e., traffic from nodes within the network to the root node. This type of traffic is called “upward” traffic. Additionally, RPL also provides a mechanism to support point-to-multipoint (P2M) data traffic, i.e., traffic from the root to the rest of the network nodes. This type of traffic is called “downward” traffic. However, RPL provides a very basic mechanism for point-to-point (P2P) data traffic, i.e., traffic where both the source and destination nodes are other than the 36 CHAPTER 2. ROUTING PROTOCOLS IN WSN root. Downward routes are established using Destination Advertisement Object (DAO) messages. P2P traffic is routed in two steps; all data are directed from the source to the root node, and then it is directed to the destination. Despite the P2P routes are suboptimal, routing traffic in that way may lead to big problems of bottle necks in the root node and its direct neighbors. The RPL specification distinguishes between two modes of traffic routing; storing and non-storing mode. In the storing mode, the RPL Instance keeps state of the route to all the other nodes. In this traffic mode, if a P2P connection is sending a packet upwards and an intermediate node knows a route downwards to the destination of the packet the packet is routed downwards immediately. In the non-storing traffic mode, intermediate nodes do not know any downward route, so in a P2P connection the packet must be routed through the root node.

2.4.2 AODV Ad-Hoc On-Demand Distance Vector (RFC3561) Routing is a routing protocol for mobile ad hoc networks (MANETs) and other wireless ad-hoc networks [43]. It is jointly developed in Nokia Research Center, University of California, Santa Barbara and University of Cincinnati by C. Perkins, E. Belding-Royer and S. Das. AODV is a reactive routing protocol. AODV works as follows:

• When a node wants to communicate with a host to which has no route, it will generate a route request (RREQ) message, which will be ﬂooded in the network.

• A route is considered found when the RREQ message reaches either the destination itself, or an intermediate node with a valid route entry for the destination.

While a route is active, AODV remains passive. When the route becomes invalid or lost, AODV will again issue a request. AODV avoids the “counting to inﬁnity” problem from the classical vector algorithm by using sequence numbers for every particular route (see section B.1). AODV deﬁnes three types of control messages for route maintenance:

RREQ When a node requires a route to another node, it sends a route request message that is ﬂooded in the network. When ﬂooding these messages, AODV uses an expanding ring technique. Every RREQ carries a time to 2.4. ROUTING PROTOCOLS 37

live (TTL) ﬁeld that states for how many hops this message should be forwarded. Retransmissions of RREQ occur if no replies are received.

RREP When a node receives a RREQ, a route reply message is generated if the receiver is either the node using the requested address, or it has a valid route to the requested address. During the RREQ ﬂooding procedure every node caches a route back to the originator, so the RREP is unicasted back to the originator.

RERR Each node keeps a precursor list, containing the IP address for each of its neighbors that are likely to use it as a next hop towards each destination. Nodes monitor the link status of next hops in active routes. When a node detects a link breakage in an active route, this situation is notiﬁed to other nodes by a route error message.

Figure 2.9 represents an AODV route lookup session. In this situation, node A wants to send data traﬃc to node J for wich it has no route. Node A sends a RREQ wich is ﬂooded in the network. When J receives this RREQ from H, it generates a RREP. Then, this RREP is unicasted back to A using the catched entries in nodes H, G, and G.

RREQ H E RREQ B RREQ RREQ RREQ RREQ RREQ RREP RREP J RREQ D G RREP A RREP RREQ RREQ I RREQ F C RREQ RREQ Figure 2.9: AODV route lookup session. source: [51] Figure 2.3: A possible path for a route reply if A wishes to ﬁnda route to J.

2.4.3forwarded OLSRto J from H, J generates a RREP. This RREP is then unicasted back to A using the cached entries in nodes H, G and D. In a proactive protocol, link-state information is periodically flooded troghout the network.2.2.2 Pr OLSRoactiv optimizese protocols the- OLSR flooding mechanism to preserve network capacity, byA wayproacti ofv thee approachMultiPointto MANET Relayingrouting seekstechniqueto maintain (seea constantly sectionupdated B.2topology). understanding. The whole network should, in theory, be known to all nodes. This results in a constant overhead of routing OLSRtraffic, isbut ano table-driveninitial delay in communication. protocol; its operation consists of updating and main- tainingThe Optimized informationLink State inrouting a variety(OLSR) ofis tables.described in TheRFC3626[23 data in]. theseIt is a table-dri tablesven ispro-acti basedve on protocol. As the name suggests, it uses the link-state scheme in an optimized manner to diffuse topology receivedinformation. controlIn a classic traffic,link-state and controlalgorithm, trafficlink-state isinformation generatedis flo according o d e d throughout to thethe netw informa-ork. tionOLSR retrieveduses this fromapproach theseas well, tables.but since Fromthe protocol theseruns tablesin wireless dependsmulti-hop thescenarios route calculation.the message flo o d i n g in OLSR is optimized to preserve bandwidth. The optimization is based on a technique called MultiPoint Relaying. The MPR technique is studied further in chapter 3. Being a table-driven protocol, OLSR operation mainly consists of updating and maintaining information in a variety of tables. The data in these tables is based on received control traffic, and control traffic is generated based on information retrieved from these tables. The route calculation itself is also driven by the tables. OLSR defines three basic types of control messages all of which will be studied in detail in chapter 3:

HELLO - HELLO messages are transmitted to all neighbors. These messages are used for neighbor sensing and MPR calculation. TC - Topology Control messages are the link state signaling done by OLSR. This messaging is optimized in several ways using MPRs. MID - Multiple Interface Declaration messages are transmitted by nodes running OLSR on more than one interface. These messages lists all IP addresses used by a node.

OLSR is further studied in chapters 3 and 4.

8 38 CHAPTER 2. ROUTING PROTOCOLS IN WSN

OLSR deﬁnes three basic types of control messages:

HELLO HELLO messages are trasmitted to all neighbors, and used for neighbor sensing and MPR calculation.

TC Topology Control messages, optimized using MPRs, are the link state signaling.

MID Multiple Interface Declaration messages list all IP addresses used by a node, and are transmitted by nodes running OLSR on more than one interface.

Route calculation in OLSR is a relatively trivial shortest-path algorithm, which can be listed as:

1. Add all the one-hop neighbors resgistered as symmetric to the routing table, with a hop-count of 1.

2. For each symmetric one-hop neighbor, add their respective symmetric neighbors such that have not already been added to the routing table. These entries will have hop-count of 2 and next-hop the current one-hop neighbor.

3. For every added node N in the routing table with hop-count n = 2, add all entries from the TC set where: The originator in the TC entry is N The destination has not already been added to the routing table. New entries will be added with a hop-count of n + 1 and the next hop as the next-hop registered on N’s routing entry.

4. Increase n by ine and return to step 3 until there are no entries in the routing table with hop-count n + 1.

5. For all entries E in the routing table the MID set is queried for address aliases. If such aliases exist an entry is added to the routing table with hop-count set to E’s hop-count, and next-hop set to Es next-hop for every alias address.

Note that only symmetric routes are considered.

2.4.4 ZRP Taking profit of the different characteristics of the network in different zones, what ZRP does it to divide the network into zones. Any different routing protocol can be used within and between zones, making ZRP totally modular. The assignation of zones is based on the weaknesses and strengths of the protocols used. The size of the assigned zones is parametrized by its radius in hops, r. Figure 2.10 shows a scenario with r = 1. 2.4. ROUTING PROTOCOLS 39

Intra-zone routing is solved by a proactive protocol, because these protocols keep an up to date view of the zone topology, which results in no initial delay when communicating between diﬀerent zones. Mereover, inter-zone routing is done by a reactive protocol, eliminating the need for the nodes to keep a proactive fresh state of the entire network.

B E H

D G J AB E I H K F C D G J A Figure 2.10: ZRP scenario with zones of node A and J with radius r = 1. Figure 2.4: A ZRP scenario showing the zones of node A and node J using a r value ofI 2. Within the zones a pro-activeK routingsource:protocol [51is]used while a re-active protocol is Fused between zones. C Locally proactive Globally reactive Intrazone Routing Protocol Interzone Routing Protocol Figure 2.11 show the different(IARP) components of the ZRP.(IERP) To control traffic between zones, ZRP defines(any a proacitve technique protocol) called Bordercast(any reactive Resolution protocol) Protocol. BRP is

used to spread the reactive route request inroute the request inter-zone routing if a node has Figure 2.4: A ZRP scenario showing the zones of node A and node J using a r value of 2. Within the zones a pro-active no route to a destination provided by the intra-zone proactive routing protocol. routing protocol is used while a re-active protocol is used betweenBordercastzones. route reply, Resolution route error, Protocol(BRP) etc. Locally proactive Globally reactive IP Intrazone Routing Protocol Interzone Routing Protocol (IARP)Figure 2.5: The different components of the Zone Routing(IERP)Protocol. (any proacitve protocol) (any reactive protocol)

2.2.3 Hybrids - ZRP route request Hybrid protocols seek to combine the proactive and reactive approaches. An example of such a protocol is the Zone Routing Protocol(ZRP)[39]. ZRP divides the topologyBordercastinto zones and seekrouteto utilize reply,different routing protocols within and between the zones based on the weaknessesResolutionand strengthsrouteof these error,protocols. ZRP is totally modular, meaning that any routing protocol canProtocol(BRP)be used within and betweenetc. zones. The size of the zones is defined by a parameter r describing the radius in hops. Figure 2.4 illustrates a ZRP scenario with r set to 1. Intra-zone routing is done by a proactive protocol since these protocols keep an up to date view of the zone topology, which results in no initial delay when communicating with nodes within the zone. Inter-zone routing is done by a reactivIPe protocol. This eliminates the need for nodes to keep a proactive fresh state of the entire network. Figure 2.11: ZRP components. source: [51] ZRP defines aFiguretechnique2.5:calledThethedifBorferentdercastcomponentsResolution Profotocolthe Zone(BRP)Routingto controlProtocol.traffic between zones. If a node has no route to a destination provided by the proactive inter-zone routing, BRP is used to spread the reactive route request. Figure 2.5 illustrates the different components of ZRP.

2.2.3 Hybrids - ZRP 9 Hybrid protocols seek to combine the proactive and reactive approaches. An example of such a protocol is the Zone Routing Protocol(ZRP)[39]. ZRP divides the topology into zones and seek to utilize different routing protocols within and between the zones based on the weaknesses and strengths of these protocols. ZRP is totally modular, meaning that any routing protocol can be used within and between zones. The size of the zones is defined by a parameter r describing the radius in hops. Figure 2.4 illustrates a ZRP scenario with r set to 1. Intra-zone routing is done by a proactive protocol since these protocols keep an up to date view of the zone topology, which results in no initial delay when communicating with nodes within the zone. Inter-zone routing is done by a reactive protocol. This eliminates the need for nodes to keep a proactive fresh state of the entire network. ZRP defines a technique called the Bordercast Resolution Protocol (BRP) to control traffic between zones. If a node has no route to a destination provided by the proactive inter-zone routing, BRP is used to spread the reactive route request. Figure 2.5 illustrates the different components of ZRP.

9 40 CHAPTER 2. ROUTING PROTOCOLS IN WSN

2.5 Conclusion

WSN protocol stack differs from other type of networks. Current protocols for other type of networks may not be adapted to WSN because they fail in important aspects or constraints. Specific protocols must be designed for sensor networks. RPL routing protocol has been published as an RFC, and it is believed by several institutions that this protocol is excessively complex and doesn’t work well in terms of optimization, traffic and energy consumption for many applications and in several scenarios, specially such requiring point-to-point and point-to- multipoint traffic. Development of alternative routing protocols to RPL, specially if they are efficient in scenarios where RPL don’t perform as well as required, is a necessity for many WSN applications. Chapter 3

LOADng Draft

6LoWPAN Ad Hoc On-Demand Distance Vector Routing – Next Generation (LOADng) is a routing protocol for WSN developed in collaboration by HIPER- COM. ∗, EDF, ERDF, Hitachi, and Fujitsu. It is a simpliﬁed on-demand reactive routing protocol derived from AODV, and intended for use in IEEE 802.15.4 devices in a 6LoWPAN (low power personal area networks) and LLN. Its behavior is based on using multi-hop routing between devices to establish and maintain on-demand routes in 6LoWPan. LOADng has its origins in LOAD protocol [32]. LOAD algorithm is characterized by its simplicity and low memory storage requirements, making it is suitable for WSN. Nevertheless, this routing protocol algorithm is known to have several bugs and incompleteness. This chapter introduces LOADng draft, which can be found in reference [11].

3.1 Process Overview

LOADng is a routing protocol for sensor networks whose objectives are to discover bi-directional paths. Each LOADng Router generates and processes RREQ, RREP, RREP–ACK and RERR messages. As a reactive protocol, routes are stablished only when there is data to be sent and there is any path towards destination. Routes are maintained for as long as there is traﬃc using this path. When a LOADng router seeks to send a data packet to a LOADng router for which it has no matching entry in its Routing Set, it begins the LOADng route discovery

∗HIPERCOM (HIgh PERformance COMmunications) is a team inside the Informatics Lab- oratory (LIX) of École Polytechnique, Paris. 42 CHAPTER 3. LOADNG DRAFT procedure. A RREQ packet is then generated and flooded in the network. During this process, nodes router receiving such RREQ install or update their route towards RREQ originator if corresponds. When the destination receives the RREQ, it generates a RREP packet which is unicast hop-by-hop towards RREQ originator along the reverse route. If the RREP–ACK flag is set, nodes receiving the RREP will unicast a proper RREP–ACK to the neighbor from which received the RREP, with the purpose to notify the neighbor sending the RREP that their link is bidirectional. When the originator of the RREQ receives the correspondent RREP, the route is installed in the Routing Set. In the route discovery procedure, only the destination is permitted to respond to a RREQ. This eliminates the need for Destination Sequence Numbers – which is an artifact used in AODV –, so the message size can be reduced compared to other protocols. In this way, no gratuitous RREP are not sent whilst loop freedom is retained. When a route towards destination is formed, a LOADng router does not maintain a precursor list – as AODV does –, and it only takes care of the next hop to forward the packet towards the final destination. If when forwarding a data packet to the next hop towards destination fails, a route error (RERR) packet is sent only to the originator of that data packet. Different address lengths are supported, including those of IPv6. The only con- straint is that in a given network each device has a unique address, and that all addresses of the network are of the same length. Each LOADng router must have at least one interface, each of them configured with one or more network addresses. This protocol is layer-agnostic. It means it may be used at layer 3 as a route over protocol or at layer 2 as a mesh under routing protocol. LOADng supports per-path maintenance: path maintenance (route discovery and route recalculation, if necessary) do not need global topology recalculation, unlike other routing protocols such as RPL. Control messages can include a set of TLV (Type-Length-Value) elements, permitting flexible protocol extensions to be developed,and making possible to adapt the protocol to specific application needs.

3.2 Deﬁnitions

LOADng draft uses the following terminology and parameters.

3.2.1 Terminology

LOADng protocol uses the following terminology: 3.2. DEFINITIONS 43

LOADng Router A router implementing the LOADng routing protocol.

Destination The address of a router or host, to which a route is sought discovered and maintained.

Originator The address of a router, wich seeks to discover and maintain a route to a Destination.

Forward Route A stablished route to send data packets from the Originator to the Destination. The Forward Route is set up when a LOADng Router forwards Route Reply messages

Reverse Route A route from the Destination to the Originator set up when a LOADng Router forwards Route Request (RREQ) messages. It is used to send and forward RREP messages, as well data packets.

Link Cost The cost between a pair of LOADng Routers, determined by a LOADng Router upon receipt of a packet. The cost type must be speciﬁed.

Route Cost The sum of the Link Cost of the links crossed by a RREQ from Originator to the node computing the Route Cost.

Weak Link A link which is marginally usable, i.e., that may be used if no other routes without weak links are available, but should be avoided at all possible. An example to deﬁne a weak link is a link with a signiﬁcant loss-rate.

3.2.2 Parameters

LOADng protocol uses the following parameters and constants:

NET_TRAVERSAL_TIME Is the maximum time a packet needs to traverse the entire network, the worst-case time a packet takes to go from one node to another, i.e., to pass through network diameter hops. After originating a RREQ, a LOADng router waits for a corresponding RREP. If no such RREP is received within 2∗ NET_TRAVERSAL_TIME, the LOADng router may reattempt a new RREQ up to a maximum of RREQ_RETRIES times.

RREQ_RATELIMIT A LOADng router should not originate more than RREQ_RATELIMIT RREQ’s per second.

RREQ_RETRIES Is the maximum number of times a particular router can attempt to discover a route to a speciﬁc destination before declaring it unsuccessful. 44 CHAPTER 3. LOADNG DRAFT

RREQ ID Each RREQ includes a Route Request ID unique for each RREQ generated by a router. These RREQID’s for a LOADng router must be generated so as to be monotonically increasing. This unsigned integer ﬁeld, specifying a sequence number, uniquely identiﬁes the particular RREQ/R- REP when taken in conjuction with the originator of the RREQ or RREP.

R_TIME Is the minimum time a route should be kept active after being created or refreshed.

RREP_ACK_TIMEOUT Is the minimum time a LOADng router should wait for a RREP_ACK (after forwarding a RREP to its neighbor) before considering the link to this neighbor to be unidirectional.

BLACKLIST_TIME Is the time during a LOADng router’s neighbor should be kept in the blacklist after being added.

3.3 Structures

LOADng routing protocol uses the packets and tables described in the following subsections.

3.3.1 LOADng Packets

Packet format for all LOADng packets follows the same structure, consisting of the type ﬁeld, the tlv block, and the message corresponding to the packet type (table 3.1).

Field Size/bits Description 4 Encodes the type of message in the ﬁeld. variable Contains the required TLVs. variable Contains the RREQ, RREP, RERR, or RREP– ACK message according to the ﬁeld.

Table 3.1: LOADng packet format

LOADng bases the route discovery process mainly in two type of messages: Route Requests (RREQs) and Route Replies (RREPs).

Type ﬁeld

This ﬁeld encodes the type of message included in the LOADng packet. Table 3.2 shows the encoding for each possible LOADng message. 3.3. STRUCTURES 45

LOADng message RREQ 0 RREP 1 RERR 2 RREP–ACK 3

Table 3.2: Encoding for the ﬁeld.

TLV block

The TLV block contains zero or more Type-Length-Value elements (TLVs). A TLV allows the association of an arbitrary attribute with a packet. The attribute (value) is made up from an integer number of consecutive octets. Different attributes have different types; attributes which are unknown when parsing can be skipped, as specified by flags associated with a given TLV. The format of the TLV block is specified in table 3.3.

Field Size/bits Description 4 Specifies the number of TLVs included, each one containing the following fields. 4 Specifies the type of the TLV. 4 Specifies processing and forwarding rules related to the TLV processing. bit 0-3 (RESERVED): should be set to zero on transmission and should be ignored upon receipt. 8 Specifies the length of the following field, in octets. tlv–length Field of length tlv–length, in octets.

Table 3.3: TLV block

RREQ messages

RREQ packets (table 3.4) are generated by a LOADng router, when it has data packets to deliver to a destination for which it has no matching entry in the Routing Set. The RREQ is transmitted to all directly reachable neighbor LOADng routers, which retransmit such packet by simply broadcast or other ﬂooding techniques. 46 CHAPTER 3. LOADNG DRAFT

RREP messages

Route Reply (RREP) packets are generated by the destination node of a RREQ packet in response to such RREQ. RREPs are sent, hop by hop, in unicast towards the originator of the corresponding RREQ along the Reverse Route installed by that RREQ.

Field Size/bits RREQ/RREP initial value 4 bit 0 is the ACK-REQUIRED ﬂag, set to 1 if RREP–ACK message is required. bits 1 to 3 are RESERVED. 4 length of the address −1, in octets 4 LOADng router metrics 4 0 16 next LOADng router unused RREQ_ID 8 cost associated with the interface over which the RREQ is transmitted, in correspondence to the ﬁeld. addr–length +1 LOADng router address, destination of the RREQ addr–length +1 LOADng router address, generating the RREQ.

Table 3.4: RREQ/RREP ﬁelds and initial values

RERR messages

A Route Error (RERR) packet is generated by a LOADng router when, after having detected a route error, the route repair mechanism is not successful or not attempted. A route error occurs when a link has broken and it is unable to forward a data packet towards its destination, possibly after Route Repair procedure. A RERR packet is then unicast to the source of the undelivered data packet. The format of a RERR message is speciﬁed in table 3.5:

RREP–ACK messages

Route Reply Acknowledgements (RREP–ACKs) packets are used to monitor bidirectionality of links with neighbor routers. The format of a RREP–ACK message is as follows in table 3.6 3.3. STRUCTURES 47

Field Size/bits Description 4 Encodes and speciﬁes the error type. 4 length of the address −1, in octets. addr-length + 1 LOADng router address, specifying the source address of the data packet, for which delivery to address failed. addr-length + 1 LOADng router address, specifying the address of the destination, which has become unreachable and for which an error is reported.

Table 3.5: RERR message format.

Field Size/bits Description 4 length of the address −1, in octets 16 value of the ﬁeld of the RREP originating the RREP–ACK addr–length +1 LOADng router address, corresponding to the ﬁeld of the received RREP

Table 3.6: RREP–ACK message format

3.3.2 Information Base

Each LOADng router maintains necessary protocol state by way of several information base sets: the Routing Set, the Blacklisted Neighbor Set, the Destination Address Set, and the Pending Acknowledgement Set. Each LOADng implementation may chose any representation or structure for when maintaining this information.

Routing Set

Routing Set stores the routing information for all reachable nodes. The Routing set have, for each entry, the following information:

R_dest_addr The address of the destination.

R_next_addr The address of the next hop on the selected route towards destination. 48 CHAPTER 3. LOADNG DRAFT

R_dist The distance of the selected route to destination, according to a selected metric in ﬁeld. It is a tuple containing route_cost, weak_links, and optional ﬁelds.

R_metric Specifies how R_dist is defined and calculated, as well as defines a comparison operator to determine which of two routes has lower cost in terms of R_dist.

R_seq_num Corresponds to the ﬁeld of the RREQ or RREP which installed or last updated this tuple. For the routing tuples installed by previous hop information of RREQ or RREP, must be set to −1.

R_valid_time Speciﬁes the time until the information contained in that tuple is considered to be valid.

Blacklisted Neighbor Set The Blacklisted Neighbor Set records the neighbors to which connectivity has been detected to be unidirectional; it is possible to receive data from them, but it is not possible to communicate. An unidirectional link can be detected when an expected RREP–ACK is not received. Blacklist tuples consist of:

B_neighbor_address The address of the blacklisted neighbor.

B_valid_time Speciﬁes the time until the information contained in that tuple is considered to be valid.

Destination Address Set The Destination Address Set records addresses, for which a LOADng router will generate RREPs in response to received RREQs. The Destination Address Set may be provisioned by external protocols. Updates on it could be due to changes of the environment (new connected or disconnected hosts), but its signaling is not speciﬁed in LOADng draft.

Pending Acknowledgement Set The Pending Acknowledgement Set contains information of the RREPs transmitted with the ACK–REQUIRED ﬂag set, and for which a RREP–ACK has not yet been received. Pending Acknowledgement tuples consists of:

P_next_hop The address of the neighbor to which the RREP was sent.

P_originator The address of the originator of the RREP. 3.4. ALGORITHM 49

P_ack_timeout Speciﬁes the time until the link to the correspondent neighbor is not considered to be bidirectional. During this time, this neighbor should be added to the blacklist. After this time, the tuple should be discarded.

3.4 Algorithm

A LOADng router obtain routes by sending RREQ packets. The routing table can be also modified when receiving LOADng packets. LOADng packet receiving, processing and forwarding for different types of message is described in sections 3.4.1, 3.4.2, and 3.4.3, respectively. Figure 3.1 shows a flowchart of the LOADng algorithm, in which the different phases — packet receiving, processing, and forwarding — are identified.

Figure 3.1: LOADng algorithm ﬂowchart.

3.4.1 Common rules for RREQ and RREP messages RREQ and RREP messages are identical in structure and have similar processing steps. This section describes the common procedures for this type of messages. By sharing some part of the processing algorithms, LOADng code can be considerably simpliﬁed. In fact, the bast majority of LOADng algorithm is occupied 50 CHAPTER 3. LOADNG DRAFT by algorithm 3.2, which is common in RREQ and RREP packet processing. This ﬁts with the restricted requirements of sensor nodes in terms of memory and processing.

Identifying valid RREQ and RREP Messages

On receiving a RREQ or RREP message, a LOADng router must ﬁrst check if the message is invalid for processing. A received RREQ is invalid for processing, and must be discarded under some conditions given in algorithm 3.1. A LOADng router may recognize additional reasons to identify that a RREQ is invalid for processing.

Algorithm 3.1 Identifying valid RREQ and RREP Messages

1: procedure isValidMessage(loadng_packet) 2: if contains an address of this router then 3: return false 4: end if 5: repeat . for each Routing Tuple 6: Read Routing Tuple in the Routing Set 7: until R_dest_addr = and R_seq_num > 8: if matching Routing Tuple found then 9: return false 10: end if 11: if 6= interface metrics then 12: return false 13: end if 14: if some TLVs required by the metric are absent then 15: return false 16: end if 17: if = RREQ_TYPE and previous-hop is blacklisted then 18: return false 19: end if . additional reasons for identifying invalid packet can be added 20: return true 21: end procedure

RREQ and RREP Message Processing

RREQ and RREP message processing, which is described in detail in section 3.4.2, share some part of their algorithm. Common processing algorithm for RREQ and RREP packets valid for processing is shown in algorithm 3.2: 3.4. ALGORITHM 51

Algorithm 3.2 RREQ and RREP Common Processing algorithm Require: isValidMessage(loadng_packet)= true 1: procedure CommonProcess_RREQ_or_RREP(loadng_packet) 2: Process_TLV() . add/remove/update TLV ﬁelds 3: if packet received over weak link then 4: ← + 1 5: end if 6: repeat . for each Routing Tuple 7: Read Routing Tuple in the Routing Set 8: until R_dest_addr = 9: if no matching Routing Tuple found then . create matching Routing Tuple . create reverse route or forward route 10: R_dest_addr ← 11: R_next_addr ← previous-hop 12: R_dist ← MAX_DIST 13: R_seq_num ← −1 14: R_valid_time ← current time + R_HOLD_TIME 15: end if . Compare matching Routing Tuple with the received message 16: if { (, , ()*) < R_dist and R_seq_num = } or R_seq_num > then . Update the Routing Set . used TLVs deﬁned by included in the message 17: R_next_addr ← previous-hop 18: R_dist ← (, , ()*) 19: R_seq_num ← 20: R_valid_time ← current time + R_HOLD_TIME 21: repeat . for each Routing Tuple 22: Read Routing Tuple in the Routing Set 23: until R_dest_addr = previous-hop 24: if no matching Routing Tuple found then 25: . create matching Routing Tuple 26: R_dest_addr ← previous-hop 27: R_next_addr ← previous-hop 28: R_dist ← MAX_DIST 29: R_seq_num ← −1 30: R_valid_time ← current time + R_HOLD_TIME 31: end if 32: . Consider the RREQ or RREP for forwarding 33: return true 34: else . message not processed further, and not considered for forwarding 35: return false 36: end if 37: end procedure 52 CHAPTER 3. LOADNG DRAFT

3.4.2 LOADng Packet Processing

When receiving a LOADng packet, it is processed as described in this section, and according to the packet type.

RREQ Message processing

On receiving a RREQ message, a LOADng router must process the message according to algorithm 3.3.

Algorithm 3.3 RREQ Processing algorithm

1: procedure Process_RREQ(loadng_packet) 2: if isValidMessage(loadng_packet)= false then 3: return false . message discarded without further processing . message not considered for forwarding 4: else if CommonProcess_RREQ_or_RREP(loadng_packet)= false then 5: return false 6: end if 7: if 6= an address of this router then 8: return true . message considered for forwarding 9: else 10: Generate_RREP(loadng_packet) 11: return false 12: end if 13: end procedure

When the RREQ reaches its destination, a RREP is generated. This is contem- plated by the function Generate_RREP: a RREP is generated in response to the LOADng packet according to table 3.4 and then unicast to the next hop towards the originator of the RREQ along the reverse route.

RREP Message Processing

On receiving a RREP message, a LOADng router must process the message according to algorithm 3.4 3.4. ALGORITHM 53

Algorithm 3.4 RREP Processing algorithm

1: procedure Process_RREP(loadng_packet) 2: if isValidMessage(RREP)= false then 3: return false . message discarded without further processing . message not considered for forwarding 4: else if CommonProcess_RREQ_or_RREP(loadng_packet)= false then 5: return false 6: end if 7: if ACK-REQUIRED flag = 1 then 8: Send_RREP_ACK(loadng_packet) . send RREP_ACK to the previous-hop 9: end if 10: if 6= an address of this router then 11: return true . message considered for forwarding 12: end if 13: end procedure

The function Send_RREP_ACK sends by unicast a RREP_ACK to the previous- hop neighbor from which received the RREP. Table 3.6 describes the RREP_ACK message format.

RERR Message processing

Upon receiving an RERR, a LOADng router must update its Routing Set as in algorithm 3.5.

RREP–ACK Message processing

On receiving a RREP–ACK from a LOADng neighbor router, a LOADng router should run the algorithm 3.6, in which it updates its routing set if necessary. The function CheckPending checks whether a corresponding RREP is pending, i.e. if the Pending Acknowledgment Set contains a tuple (P_next_hop, P_originator, P_seq_num, P_ack_timeout) such as:

• P_next_hop is the address of the LOADng neighbor router from which the RREP–ACK was received;

• P_originator corresponds to the ﬁeld of the RREP–ACK;

• P_seq_num corresponds to the ﬁeld of the RREP–ACK. 54 CHAPTER 3. LOADNG DRAFT

Algorithm 3.5 RERR Processing algorithm

1: procedure Process_RERR(loadng_packet) 2: Process_TLV(loadng_packet) . add/remove/update TLV ﬁelds 3: repeat . for each Routing Tuple 4: Read Routing Tuple in the Routing Set 5: until 6: R_dest_addr = and R_next_addr = previous-hop 7: if no matching Routing Tuple found then 8: . RERR not processed further, and not considered for forwarding 9: return false 10: else if matching Routing Tuple found then 11: . update this matching Routing Tuple 12: R_valid_time ← expired 13: return true . Consider the RERR for forwarding 14: end if 15: end procedure

Algorithm 3.6 RREP–ACK Processing algorithm

1: procedure Process_RREP–ACK(loadng_packet) 2: Process_TLV(loadng_packet) . add/remove/update TLV ﬁelds 3: CheckPending(neighbor,originator,seq-num) 4: if matching Tuple is found then . the RREP has been correctly acknowledged 5: discard the tuple 6: end if 7: end procedure

3.4.3 LOADng Packet Forwarding

After message processing, and if it still continues being processed (i.e., if the correspondent processing function returns true value), the message is considered to be forwarded.

RREQ Forwarding

A Route Request (RREQ), considered for forwarding, must be updated as follows in algorithm 3.7, prior to it being transmitted. The function UpdateRouteCost updates field according to the cost associated with the interface over which the RREQ is transmitted, and according to the specification of the included in the RREQ The function Forward_RREQ forwards the RREQ message. RREQ forwarding may be undertaken using classic flooding, may employ a reduced relay set 3.4. ALGORITHM 55

Algorithm 3.7 RREQ Forwarding algorithm Require: Process RREQ(loadng_packet)= true 1: procedure Consider_Forwarding_RREQ(loadng_packet) 2: . update 3: UpdateRouteCost(interface, ) 4: Forward_RREQ(loadng_packet) 5: end procedure mechanism such as Simpliﬁed Multicast Forwarding [38], or any other information diﬀusion mechanism such as the Trickle Algorithm [35].

RREP Forwarding

A Route Reply (RREP) message, considered for forwarding, must be updated as follows, prior to it being transmitted:

Algorithm 3.8 RREP Forwarding algorithm Require: Process_RREP(loadng_packet)= true 1: procedure Consider_Forwarding_RREP(loadng_packet) 2: . update 3: Update_RouteCost(interface, metrics) 4: if interface uses RREP–ACKs then 5: ACK_REQUIRED flag ← 1 6: end if 7: Forward_RREP(loadng_packet) 8: end procedure

Note that if this interface of the LOADng router uses RREP–ACKs to check the bidirectionality of the links, the ACK_REQUIRED ﬂag must be set to 1. The function UpdateRouteCost is the same as in algorithm 3.7. The function Forward_RREP unicasts the RREP message to the next hop towards the indicated in the RREP.

RERR Forwarding

A RERR is, ultimately, destined for the LOADng router which has the address from the ﬁeld, in its Destination Address Set. A RERR, considered for forwarding is therefore processed as follows in algorithm 3.9. The function Forward_RERR unicasts the RERR message to the next hop towards the indicated in the RERR. 56 CHAPTER 3. LOADNG DRAFT

Algorithm 3.9 RERR Forwarding algorithm Require: Process_RERR(loadng_packet)= true 1: procedure Consider_Forwarding_RERR(loadng_packet) 2: repeat . for each Routing Tuple 3: Read Routing Tuple in the Routing Set 4: until D_address = 5: if no matching Routing Tuple found then 6: discard the RERR . and not retransmit 7: else 8: Forward_RERR(loadng_packet) 9: end if 10: end procedure

RREP–ACK Forwarding A RREP–ACK is intended only for a speciﬁc direct neighbor, and must not be forwarded.

3.5 Route Maintenance

Entries in the Routing Set are maintained by way of four diﬀerent mechanisms:

1. RREQ/RREP exchange, as described in section 3.4.2.

2. Data traﬃc delivery success.

3. Data traﬃc delivery failure.

4. External signals indicating that an entry in the Routing Set necessitates updating.

5. Information expiration.

Routing Tuples in the Routing Set contain a validity time in ﬁeld, which is refreshed in successful RREQ/RREP/data exchange. Data traﬃc failure, external signals or other sources indicating the failure of a link can initiate the route repair procedure (consisting of initiating common route discovery procedure), or sending a RERR message. After this time, the information in such tuples is to be considered as invalid.

3.6 Conclusion

LOADng is a routing protocol for sensor networks whose objectives is to discover bi-directional paths. As a reactive protocol, routes are stablished and maintained 3.6. CONCLUSION 57 only when there is data to be sent. This protocol does not require periodic signaling since control traffic is based on network events. In such way, network flooding and traffic is reduced, and power energy is saved. As an update of LOAD protocol, LOADng uses the same basis:

• Is a reactive routing protocol for LLNs.

• Supports the use of optimized ﬂooding for REQs.

• Enables to discover bi-directional paths.

• Supports addresses of any length.

• Is layer-agnostic, i.e., may be used at layer 3 as a “route over” routing protocol, or at layer 2 as a “mesh under” routing protocol.

• Supports per-path maintenance without need for global recalculation.

Compared to AODV (RFC3561), LOADng is simpliﬁed as follows:

• only the destination is permitted to respond to a RREQ. This eliminates the need for Destination Sequence Numbers, eliminates gratuitous RREPs and retains loop freedom. At the end, simpliﬁes protocol operation and reduces messages size.

• A LOADng router does not maintain a precursor list.

• Optimized ﬂooding is supported

• Diﬀerent address lengths are supported as long as in a given LLN each device has a unique address, and that all addresses within a LLN are of the same address length.

• Control messages can include a set of TLV elements, permitting ﬂexible protocol extensions to be developed.

LOADng offers several advantages over RPL. In contrast to RPL, LOADng adapts quite well in point-to-point, point-to-multipoint, and multipoint-to-point scenarios. A great improvement in terms of energy efficiency is done by supporting per-path maintenance; a single required route can be obtained without having to construct a whole network routing tree. In conclusion, LOADng is a routing protocol suitable for sensor networks, as long as it is adapted to processing capabilities and memory limitations of sensor nodes. By the use of TLV’s, LOADng is open to future enhancements and can adapt to concrete application requirements. Its simplicity and versatility can make it 58 CHAPTER 3. LOADNG DRAFT a protocol to be considered for future WSN applications. However, LOADng performance must be tested to detect, analyze and correct possible undesired effects. Chapter 4

Working Tools

This chapter describes the working tools used to develop LOADng protocol in sensor networks, as well as to debug it, simulate it and to obtain simulated performance results. LOADng has been implemented for Contiki operating system [41]. The subse- quent simulations have been run with Cooja simulator [42] — a java simulator developed for Contiki OS—, and the results have been analyzed with Octave [40]– a high-level interpreted language, primarily intended for numerical computation. The following sections introduce Contiki OS and Cooja, and describe the main tools used during development of the work contained in this manuscript.

4.1 Contiki OS

Contiki OS is an operating system intended for use in sensor motes and tiny devices, developed by SICS. SICS provides Instant Contiki: a virtual machine image with a complete development environment for Contiki OS. Instant Contiki is an Ubuntu Linux installation containing the MSP430 gcc compiler toolset, the Cooja network simulator, the Netsim network simulator, and tools for uploading a compiled Contiki system to connected sensor boards like the Tmote Sky. Further information about Contiki OS can be found in appendixC. Instant Contiki image has been run in the VMWare Player (v.3.1.3) for MacOS (v.10.6.8). The LOADng code was initiallys implemented for Contiki OS version 2.4. Contiki OS version 2.5 was released on September 2011, so the existing code was ported to this new version. 60 CHAPTER 4. WORKING TOOLS

Choosing Contiki as the WSN OS

Table 4.1, taken from [17], is a comparative between the main OS used for general WSN tiny networked devices. Contiki OS has been chosen for implementing LOADng as a routing protocol. The reason is that Contiki runs over many WSN platforms, including the most popular sensor nodes, but also can run natively in linux systems. Contiki provides support for simulations and its programming language is C, which is simple, easy and familiar. Despite that MANTIS OS provides better support to use custom routing protocols, the modular architecture of Contiki also makes possible to replace and/or modify the correspondent modules to implement LOADng.

OS/Feature Communication File System Simulation Programming Shell Security Support Support Languaje TinyOS TinySec Single level file TOSSIM NesC Not available system Contiki ContikiSec Coffee file sys- Cooja C Unix-like shell tem runs on sensor mote MANTIS Not available Not available Through C Unix-like shell AVRORA runs on sensor mote Nano-R K Not available Not available Not available C Not available LiteOS Not available LiteFS Through LiteC++ Shell that runs AVRORA on base station

Table 4.1: Operating Systems comparative.

4.1.1 Rime Stack

The application layer uses the tools of a router to send messages. Depending on the conﬁguration, the router can use the rime stack, or the IP stack (either with IPv4 or IPv6 addresses for 6LoWPAN), as described in table 4.2. Both IPv4 and rime use the same modules for the routing table and route discovery process in mesh networks, meanwhile for IPv6 Contiki uses another methods.

Stack Contiki module Rime mesh IPv4 uip-over-mesh IPv6 sicslowpan

Table 4.2: Contiki modules for diﬀerent protocol stacks. 4.1. CONTIKI OS 61

Modules Hierarchy The Rime Stack is a set of hierarchical modules providing a set of wireless network protocols (see ﬁgure 4.1). More complex modules make use of the simpler ones. In conjunction, the Rime Stack implements from a simple broadcaster to a multihop mesh network routing. For example, when the rime router wants to send a packet in a multihop routing, the mesh module calls the multihop module, which calculates the node to whom forward the packet, and sends it via the unicast module, which encapsulates such packet and sends it to lower-layer modules.

Figure 4.1: Rime Stack.

Figure 4.1 shows an schema of the Rime stack and the main functions provided by each of its modules. The main modules involved in the routing procedure are route, route-discovery, mesh, and multihop. route module This module is the core of the router. By calling other libraries, it manages the routing table and maintains, updates, removes and adds routes. It provides procedures to get, lookup and refresh routes. route-discovery module This module works in addition to route module and provides tools to discover new routes and maintain the routing table updated. It also have capabilities to report error messages when a link is detected to be broken and manages the local repair procedure. The route-discovery module can work together with the rime module – i.e., using rime addresses – as well as with the uip-over-mesh module – i.e., using IP addresses. This is possible because of the modular hierarchy of rime. This is the module being replaced by the LOADng routing protocol module. mesh and uip-over-mesh modules These libraries make use of both of the above libraries. They work in an upper layer, and provide to the router functions to send messages and assure transport-layer security (i.e., trying local repair 62 CHAPTER 4. WORKING TOOLS

or send an error message when a link is broken). The mesh module sends packets using multi-hop routing to a speciﬁed receiver somewhere in the network. The uip-over-mesh module makes use of IP addresses and stack. multihop module This module, when working with the mesh module, allows the router to use multi-hop routing.

Limits of rime

Buffer management is one of the limits of the current rime stack implementation; it only provides support to store and manage one packet in the buffer. In case of low traffic, a one-packet-sized buffer can be enough – although it can overflow in peaks of data traffic, for example. Sensor networks don’t expect to have a great amount of route-discovery traffic. Further, LOADng – as an AODV simplified protocol – avoids the use of hello messages, and one of its characteristics is to keep the network save of control traffic and save energy. A WSN using – properly – LOADng routing protocol is expected to not have many topology changes (otherwise a protocol implementing hello messages would be more effective). Under this premises, the network is expected to not have many route-discovery procedures due to topology changes. Therefore, working with a one-packet buffer can be considered in a WSN using LOADng routing protocol, despite buffer management should be revised in future Contiki updates. .

4.2 Cooja Simulator

Cooja is the Contiki OS simulator developed for simulations of sensor nodes running Contiki OS. Contiki can be built for several platforms (such as Tmote Sky, TelosB, native,. . . ), and one of the advantages of Cooja is to simulate behavior of a sensor node not only in terms of its operating system but also for the specific hardware of the platform over Contiki runs. In addition, when simulating a WSN, Cooja is able to simulate each node independently, so in each node either the (simulated) hardware or software may vary. Cooja is a cross-level simulator, meaning that it can simulate different abstraction levels of a system – i.e., network level, the operating system level, and the machine code instruction set level. In Cooja each node can be simulated at only one of these levels, but in one simulation nodes can cooperate from all levels – i.e., an emulated node can send a radio packet to a Java based node. Cooja is aimed to be a flexible simulator, by allowing some extensions. A description of the different levels of simulation is presented below. 4.2. COOJA SIMULATOR 63

Networking level Simulations can adopt diﬀerent radio propagation models. For the nodes, Cooja can distinguish several radio devices hardware. In addition, some nodes can be replaced by abstract Java implementations. This level is useful when developing a routing protocol, where the nodes hardware is not such an important issue. operating System level Each individual node is simulated so it can run speciﬁc Contiki operating system code. This can be specially useful to allow testing and evaluation of changes in Contiki libraries.

Machine Code Instruction Set level Nodes having diﬀerent underlying structure may be simulated using Java-based microcontroller emulator instead of a compiled Contiki system.

4.2.1 Graphical User Interface Cooja is the Contiki OS simulator written in Java. It can run in command line interface, but it also provides a graphical simulation interface (see ﬁgure 4.2).

Figure 4.2: Cooja graphical user interface and main plugins.

The GUI is divided into three main parts: the log listener it shows debugging messages and other printf calls. Debug- ging messages are called in source files, and are simple macros which can be enabled or disabled independently in each source file they are used. Cooja also provides the functionality to disable (not to show) all debug messages in the log file, and keeping the rest of text messages. the simulation visualizer Cooja shows a symbolic physical field where the sensor nodes are deployed. The coordinates of sensor nodes can be set manually 64 CHAPTER 4. WORKING TOOLS

or at random, either in 2D or 3D ﬁeld. Several features can be shown and adjusted in this window, such as the transmission range of each node, the enabled or disabled nodes, or the network traﬃc. the control panel it contains the controls to start and pause the simulation.

Cooja offers the possibility to place WSN nodes in the field, each one with its correspondent Contiki-code, and simulate the complete network system. The log file will report the activity in the network, as long as the debugging messages are enabled in its proper source file.

4.2.2 Wireless Channel Model

Different channel modes can be adopted in Cooja, which are explained below. Customized channels can be added (or extend other ones) via pluggins. This makes possible to simulate specific channel models, and obtaining results closer to the real WSN application performance than when using Cooja predefined models.

No Radio Traﬃc This model doesn’t allow radio communications. It is used to complement other radio model implementations –e.g., when simulating shadowing or radio channel interferences.

Unit Disk Graph Medium (UDGM) - Constant Loss This model is a version of UDGM implementation, where the transmission range is an ideal disk; all nodes inside that disk do not receive packets, while the nodes inside the disk region receive all the packets. The transmission range is proportional to the transmitting power.

Unit Disk Graph Medium (UDGM) - Distance Loss This model is an improvement of the UDGM-Constant Loss model, in which interferences and success ratio are considered. The interference range is deﬁned, and usually set to the double of the transmission range. The model assumes a pessimistic situation where all interferences lead to lose packets (while in reality, a communication can still be possible). In addition, the success ratio of the transmission and reception can be deﬁned.

Directed Graph Radio Medium (DGRM) This model defines a transmission range, where success ratio and delays can be defined. The success ratio can be specified in an asymmetric per-link manner. This model is used as a stand-alone radio model or as a basis for other models. 4.2. COOJA SIMULATOR 65

Multi-path Ray-tracer Medium (MRM) This radio model is not based on empirical measurements but on analytical approach, and takes into account takes into account obstacles as attenuators, refractions, reﬂections and diﬀractions to simulate the radio channel, as well as the transmitted power, antenna gains, packet lengths and SNR threshold. For example, it calculates the node’s received power using the Friis formula, and also uses ray tracing technique.

4.2.3 Debbugging in Cooja

Cooja allows the most common instructions to debug code, such as: observing the value of the variables and/or editing it, advancing step-by-step through the machine code instructions, etc. In Cooja is not common to debug code by looking the value of the variables, or by advancing code instructions step-by-step until finding the bug. Instead, it is more straightforward to print and read debug messages. Debug messages are simple PRINTF macros in Contiki source files, which can be individually enabled or disabled for each source file: when DEBUG variable is set in the source file, the instruction PRINTF is treated as a common printf. Otherwise, it is ignored. Messages are output in the Log Listener, if the Cooja GUI is used, or into an output text file if the simulation is run over the command line. Cooja’s log listener can filter output messages. Thus, it is a good practice to write a prefix in each debug message in correspondence with the module or process it belongs to. By doing this, debugging messages – and, in general, information messages – can be filtered in Cooja’s log listener and log file. For example, in the simulation of figure 4.2, a filter route_discovery can be applied for filtering route discovery process information messages; or a filter LOADNG can be applied to follow LOADng packet traffic across the network.

LOADng debug messages

During simulations, LOADng debug messages are activated to provide route discovery process information. The debug messages follow the pattern time:id:message, where time indicates the runtime when the debug message takes place, id indicates the node id of the node producing the debug message, and message is the debug message. LOADng debug messages are presented in table 4.3. In addition, some debug messages related to transmission of the data packet at application level have been activated. These messages are described in table 4.4 66 CHAPTER 4. WORKING TOOLS

Field Description LOADNG RREQ Indicates the node sends a RREQ packet destined to LOADNG RREP Indicates the node sends a RREP packet destined to LOADNG RREP_ACK Indicates the node sends a RREP_ACK packet destined to LOADNG RREP_ACK_RECV Indicates the node receives a RREP_ACK packet from

Table 4.3: LOADng debug messages

Description DATA TOSEND Indicates the node wants to send a data packet to DATA RECEIVE Indicates the node receives a data packet destined to DATA ACK Indicates the node receives a data acknowledge packet from

Table 4.4: Application level debug messages.

4.3 Tools

The following tools have been used during the development of this thesis.

Instant Contiki An Ubuntu image with preinstalled tools to develop a Contiki system [41].

VMware Instant Contiki image has been mounted in VMWare Player (v.3.1.3) [21].

Octave Used to ﬁlter logﬁle data from simulations [40].

Gnuplot Used to generate plots and statistical graphics [22].

Several scripts have been written to create Cooja simulation files, for each different scenario, and with different seeds to add randomness in simulations. Logfiles have been preprocessed with another script, which transform the logfile information strings into a table of simulation statistics able to be processed by the octave program. 4.4. CONCLUSION 67

4.4 Conclusion

LOADng implementation for Contiki requires to install an entire development work suite. To setup all required tools is a tedious work, sometimes followed by errors and incompatibilities on installing packets. Fortunately, SICS provides Instant Contiki, an Ubuntu Linux image with all required tools to develop for Contiki. However, working with a virtual machine carries out several disadvan- tages. The main disadvantage is the system performance, which is considerably low since it emulates an Ubuntu system with only 512 MB RAM. This low performance is patent in Cooja simulations, which could be run more quickly in a native operating system. Simulations data process and analysis has been done across some scripts written for this purposes. They are most likely not optimally written, but this is not an important issue as is to obtain correct statistics. In summary, LOADng implementation and tests have been successfully obtained with the cited tools, despite the use of Instant Contiki virtual machine image have carried out some delays during simulations.

Chapter 5

LOADng Implementation

“Knowing is not enough, we must apply; willing is not enough, we must do.” — Bruce Lee

Simulations of WSN protocols contribute to the design and testing of a protocol. Nevertheless, important simpliﬁcations and assumptions are implicit in simulations, and sometimes they are not valid in a real-world scenario. For that reason, despite simulations can give a general overview of the protocol, it is important to test it in diﬀerent real-world scenarios. One of the main purposes of the work of this manusctipt was to implement a LOADng routing protocol for sensor networks running Contiki OS.

5.1 Implementation overview

The LOADng routing protocol has been implemented to run as a routing protocol in Contiki OS. Contiki OS is an operating system designed for use in sensor nodes and tiny devices. It is designed to be extensible, and is still being developed and reﬁned. In this way, LOADng implementation has been developed taking into account the need of modifying the code in the future, both for updates or to add new features. With this aim, these points have been followed:

Modularity The LOADng code is part of the entire Contiki OS operating system, which is divided into diﬀerent modules. LOADng implementation covers the routing protocol module, and can easily replace the routing protocol 70 CHAPTER 5. LOADNG IMPLEMENTATION

implemented for Contiki OS by default. The LOADng implementation has been developed to be as modular as possible. All the functions called upon receiving or sending a packet, or the management of LOADng tables are independent and transparent from each other, so further modiﬁcations can be done in an easy and straightforward way without aﬀecting the rest of the code.

Consistent data-structures All the data-structures related to tables have the same structure, so the implementation is consistent.

Stack transparency LOADng protocol is layer-agnostic. Given the modularity of Contiki OS, the provided routing protocol is able to work under IP layer as layer-2 protocol or over IP. Nevertheless, LOADng completely integrates in the Contiki Rime stack as its routing protocol.

Readable code The code have been documented properly. Doxygen software [52] has been used for that purpose.

Platform independent code Contiki OS provides support for diﬀerent platforms, including Sky motes compilation or even compilation for running code in native mode, i.e, in machines running Linux. LOADng has been proved to run in several of this platforms, obtaining success in all the tests.

5.2 Routing in Contiki OS

Contiki OS uses AODV routing protocol by default, which is implemented across the libraries of the router and the route discovery procedure. The module for route discovery in Contiki OS is called route-discovery, and provides tools for route discovery and management at the core of the router, in the route module. In an upper layer, we can find the transport layer. For example, mesh.h or uip-over-mesh.h. The first one works with Rime, while the second one uses IPv4 connections in upper layers. Since Contiki OS architecture is modular and the route-discovery module independent to procedures to send packets and the rest of the router, it is possible to integrate LOADng in Contiki OS without affecting the rest of the operating system. In order to integrate LOADng as default Contiki OS routing protocol, two libraries must be replaced:

• route-discovery.h

• route.h

The functions provided by each of the libraries are shown in table 5.1. 5.3. MODULES 71

route.h route-discovery.h route_init route_discovery_open route_add route_discovery_discover route_lookup route_discovery_close route_refresh route_decay route_remove route_flush_all route_set_lifetime route_num route_get

Table 5.1: route.h and route-discovery.h functions.

Two of these functions are void of content and are only maintained for compatibility: route_decay and route_flush_all. The name of the functions is self-explanatory, but a brief description of each one can be found in sections 5.3.2 and D.2.

5.3 Modules

LOADng implementation modiﬁes two modules of Contiki: the route module, and the route-discovery module. Next subsections document the functions and variables of each module.

5.3.1 route-discovery module The route discovery module does route discovery for LOADng router.

Data Structures

• struct tlv This structure stores a TLV vector of the TLV block.

• struct rerr_message This structure stores the ﬁeld of a RERR packet.

• struct rrep_ack_message This structure stores the ﬁeld of a RREP-ACK packet.

• struct route_message This structure stores the ﬁeld of a RREQ or RREP packet. 72 CHAPTER 5. LOADNG IMPLEMENTATION

• struct route_discovery_packet This structure points to the information of a RREQ or RREP packet.

• struct rrep_ack_packet This structure points to the information of a RREQ-ACK packet.

• struct rerr_packet This structure points to the information of a RERR packet.

• struct request_tuple A tuple in the Request List.

• struct route_discovery_callbacks route discovery callbacks structure

• struct route_discovery_conn route discovery connection structure

Routing Set Stores the Request Tuples responsible to resend RREQ packets in case of not receiving a RREP.

• LIST (request_set)

• MEMB (request_mem, struct request_tuple, NUM_REQ_ENTRIES)

Files

• ﬁle route-discovery.c LOADng route discovery protocol header.

• ﬁle route-discovery.h LOADng route discovery protocol header.

Parameters and constants

• #define ROUTE_TIMEOUT 5 ∗ CLOCK_SECOND

• #define RREP_ACK_TIMEOUT 0.1 ∗ CLOCK_SECOND

• #define ROUTE_DISCOVERY_ENTRIES 8

• #define MAX_RETRIES 3 5.3. MODULES 73

• #define MAX_REPAIR_RETRIES max_retries

• #define NUM_REQ_ENTRIES 8

• #define MEAN_BACKOFF 50

• #define UNIFORM 1

• #define EXPONENTIAL 1-uniform

• #define ACK_REQUIRED 1

• #define METRICS 0

Deﬁnes

• #define RREQ_TYPE 0x0

• #define RREP_TYPE 0x1

• #define RERR_TYPE 0x2

• #define RREP_ACK_TYPE 0x3

• #define MAXVALUE 255

• #define VERBOSE 1

• #define BACKOFF 1

• #define DEBUG 0

• #define PRINTF(...)

Functions

• void route_discovery_open (struct route_discovery_conn ∗c, clock_time_t time, uint16_t channels, const struct route_discovery_callbacks ∗callbacks) Opens a route discovery connection.

• void route_discovery_close (struct route_discovery_conn ∗c) Closes a route discovery connection.

• int route_discovery_discover(struct route_discovery_conn ∗c,const rimeaddr_t addr, clock_time_t timeout) Starts a LOADng route discovery protocol. 74 CHAPTER 5. LOADNG IMPLEMENTATION

• int route_discovery_repair(struct route_discovery_conn ∗c,const rimeaddr_t ∗addr, clock_time_t timeout) Opens a route discovery repair procedure.

• int route_discovery_rerr (struct route_discovery_conn ∗c, uint8_t Er- ror_Code, const rimeaddr_t ∗broken_source_addr, const rimeaddr_t ∗broken_dest_addr) Initiates the route error communication procedure.

5.3.2 route module

The route module handles the LOADng route table with Rime support.

Data Structures

• struct dist_tuple The distance structure consists of a tuple (route_cost, weak_links), and works together with its correspondent metrics.

• struct routing_tuple Routing tuple entry structure for the LOADng routing table.

• struct route_entry This structure redeﬁnes the routing tuple with another name. Just deﬁned to maintain compatibility with mesh.c , uip-over-mesh.h and other libraries that call for routes.

• struct pending_entry Pending entry tuple structure for the Pending Acknowledgement Set.

• struct blacklist_tuple Blacklist tuple entry structure for the Blacklisted Neighbor Set.

Files

• ﬁle route.c LOADng router header.

• ﬁle route.h LOADng router header. 5.3. MODULES 75

Parameters and constants

• #define NUM_RS_ENTRIES 8

• #define NUM_BLACKLIST_ENTRIES 2 ∗ NUM_RS_ENTRIES

• #define NUM_pending_ENTRIES NUM_RS_ENTRIES

• #define ROUTE_TIMEOUT 5 ∗ CLOCK_SECOND

• #define NET_TRAVERSAL_TIME 2 ∗ CLOCK_SECOND

• #define BLACKLIST_TIME 10 ∗ CLOCK_SECOND

• #define METRICS 0

Deﬁnes

• #define DEBUG 0

• #define PRINTF(...)

Functions • void route_init (void) Allocates and initializes route tables.

• struct routing tuple ∗route_add ( const rimeaddr t ∗dest, const rimeaddr t ∗nexthop, struct dist tuple ∗dist, unsigned long int seq_num) Adds a route entry to the Routing Table.

• struct pending_entry ∗route_pending_list_lookup (const uip_ipaddr_t ∗from, const uip_ipaddr_t ∗orig, uint8_t seq_num) Looks for an entry in the Pending List.

• struct pending_entry ∗route_pending_add(const uip_ipaddr_t ∗nexthop, const uip_ipaddr_t ∗dest, uint8_t RREQ_ID, clock_time_t timeout) Adds a pending entry to the Pending List.

• struct route_entry ∗route_lookup ( const rimeaddr_t ∗dest ) Looks for a Routing Tuple in the Routing Set.

• struct blacklist_tuple ∗route_blacklist_lookup ( const uip_ipaddr_t ∗addr ) Searches a blacklist tuple in the Blacklist Table. 76 CHAPTER 5. LOADNG IMPLEMENTATION

• struct blacklist_tuple ∗route_blacklist_add ( const uip_ipaddr_t∗neighbor, clock_time_t timeout ) Adds a blacklist entry to the Blacklist.

• void route_refresh (struct route_entry ∗e) Refreshes a route entry in the Routing Set.

• void route_remove (struct routing_tuple ∗e) Removes a route entry in the Routing Set.

• void route_decay (struct route_entry ∗e) Not implemented and only maintained for compatibility.

• void route_set_lifetime (int seconds) Not implemented and only maintained for compatibility.

• int route_num (void) Not implemented and only maintained for compatibility.

• struct route_entry ∗route_get (int num) Not implemented and only maintained for compatibility.

5.4 Functions

This section contains detailed documentation of the functions mentioned in the previuous sections. void route_discovery_close ( struct route_discovery_conn ∗c ) Closes a route discovery connection.

Parameters

Parameter Description c A pointer to a struct route_discovery_conn

Description This function closes the route discovery connection that was previously opened with the route_discovery_open() 5.4 procedure. Deﬁnition at line 1508 of ﬁle route-discovery.c. 5.4. FUNCTIONS 77

int route_discovery_discover ( struct route_discovery_conn ∗c, const_rimeaddr_t ∗addr, clock_time_t timeout ) Starts a LOADng route discovery protocol.

Parameters

Parameter Description c A pointer to a struct route_discovery_conn addr A pointer to a struct rimeaddr timeout The timeout to discover a new route

Returns

0 If the route is not discovered. 1 If the route discovery is initialized.

Description This function initiates the LOADng route discovery protocol to discover a path towards the destination address addr. Deﬁnition at line 1535 of ﬁle route-discovery.c. void route_discovery_open ( struct route_discovery_conn ∗c, clock_time_t time, u16 t channels, const struct_route_discovery_callbacks ∗callbacks ) Opens a route discovery connection.

Parameters

Parameter Description c A pointer to a struct route_discovery_conn time The timeout to discover a working route, in clock ticks channels The number of channels already used callbacks A pointer to a struct route_discovery_callbacks 78 CHAPTER 5. LOADNG IMPLEMENTATION

Description

This function must be called before the use of any other function in this library. This function creates a new route discovery architecture. The pointers to the created structures are stored in the structure route_discovery_conn given as a parameter. The time parameter ﬁxes the maximum predeﬁned time to discover a new route. The broadcast and unicast channels are assigned consecutively from the channels parameter. The struct callbacks pointer must point to a structure containing a pointer to a route_discovery_callbacks. This contains the callback pointers to the functions called upon receive and send the route discovery messages. int route_discovery_repair ( struct route_discovery_conn ∗c, const rimeaddr_t ∗addr, clock_time_t timeout )

Opens a route discovery repair procedure.

Parameters

Parameter Description c A pointer to a struct route_discovery_conn addr A pointer to a struct rimeadd_t timeout The timeout to repair the broken route

Returns

0 If an error occurs. 1 If the route repair procedure is initiated.

Description

This function tries to repair a broken route towards destination addr within a time timeout. Deﬁnition at line 1622 of ﬁle route-discovery.c. 5.4. FUNCTIONS 79 int route_discovery_rerr ( struct route_discovery_conn ∗c, uint8_t Error_Code, const rimeaddr_t ∗broken_source_addr, const rimeaddr_t ∗broken_dest_addr )

Initiates the route error communication procedure.

Parameters

Parameter Description c A pointer to a struct route_discovery_conn Error_Code The error code. broken_source_addr A pointer to a struct rimeaddr. broken _dest_addr A pointer to a struct rimeaddr.

Description

This function can be called when a route discovery error occur. This function creates and initiates a new route error procedure. The pointers to the connection structures are stored in the structure route_discovery_conn given as a parameter. The Error_Code parameter identiﬁes the error in route discovery and is transmitted from node to node in the proper route error packet. The broken_source_addr struct points a rimeaddr struct containing the address of the corresponding route discovery source in the route discovery procedure, destination of the RERR packets. The broken_dest_addr struct points a rimeaddr struct containing the address of the destination of the packet originating the route error. struct routing_tuple ∗route add ( const rimeaddr_t ∗dest, const rimeaddr_t ∗nexthop, struct dist_tuple ∗dist, unsigned long int seq_num )

Adds a route entry to the Routing Table. 80 CHAPTER 5. LOADNG IMPLEMENTATION

Parameter Description nexthop A pointer to a struct uip_ipaddr. dest A pointer to a struct uip_ipaddr. seq_num An integer containing the LOADng packet sequence number .

Parameters

Returns

The pointer to the routing_tuple struct containing the routing tuple demanded by the received parameters. If the pending_entry could not be created, the function returns a NULL pointer.

Description

This function adds a route entry tuple to the Routing Table. The caller must have initiated route structures. The uip_ipaddr struct pointer dest must point to a structure containing a pointer to the next hop rime address of the destination of the new route. The uip_ipaddr struct pointer nexthop must point to a structure containing a pointer to the rime address of the next hop towards destination. Deﬁnition at line 287 of ﬁle route.c. struct blacklist_tuple ∗route_blacklist_add ( const uip_ipaddr_t ∗neighbor, clock_time_t timeout )

Adds a blacklist entry to the Blacklist.

Parameters

Parameter Description neighbor A pointer to a struct uip_ipaddr. timeout The timeout for a neighbor to be blacklisted, in clock ticks. 5.4. FUNCTIONS 81

Returns

The pointer to the blacklist_tuple struct containing the blacklisted neighbor. If the blacklist_entry can not be created, the function returns a NULL pointer.

Description

This function blacklists a neighbor for at least timeout clock ticks. When the timer expires, the blacklist entry is removed. The caller must have initiated route structures. The uip_ipaddr struct pointer must point to a structure containing a pointer to a rime address of the neighbor wanted to blacklist. Deﬁnition at line 148 of ﬁle route.c. struct blacklist_tuple ∗route_blacklist_lookup ( const uip_ipaddr_t ∗addr )

Search a blacklist tuple in the Blacklist Table.

Parameters

Parameter Description addr The address searched in the Blacklist Table

Returns

The pointer to the blacklist_entry struct corresponding to the addr parameter received. If the RREQ_entry is not found, the function returns a NULL pointer.

Description

The caller must have initiated route structures. Deﬁnition at line 327 of ﬁle route.c. void route_init ( void )

Allocate and initialize route tables. 82 CHAPTER 5. LOADNG IMPLEMENTATION

Description

This function must be called before all the others. Deﬁnition at line 222 of ﬁle route.c. struct route_entry ∗route_lookup ( const rimeaddr_t ∗dest )

Looks for a Routing Tuple in the Routing Set.

Parameters

Parameter Description dest A pointer to a struct uip_ipaddr.

Returns

The pointer to the route_entry struct containing the Routing Tuple entry corresponding with a route with destination the received parameter dest. If the entry is not found, the function returns a NULL pointer.

Description

The caller must have initiated route structures. The struct uip_ipaddr pointer dest points to a structure containing a pointer to the rime address of the destination of the route searched. Deﬁnition at line 347 of ﬁle route.c. struct pending_entry ∗route_pending_add ( const uip_ipaddr_t ∗nexthop, const uip_ipaddr_t ∗dest, uint8_t RREQ_ID, clock_time_t timeout )

Adds a pending entry to the Pending List.

Parameters

Returns

The pointer to the pending_entry struct containing the pending tuple corresponding with the received parameters. If the entry could not be created, the function returns a NULL pointer. 5.4. FUNCTIONS 83

Parameter Description nexthop A pointer to a struct uip_ipaddr. dest A pointer to a struct uip_ipaddr. RREQ_ID The RREQ_ID corresponding to the route request. timeout The timeout for a route pending to be waiting acknowledge, in clock ticks.

Description This function adds a pending entry tuple to the Pending List. If the LOADng router doesn’t receive a route reply ack within timeout clock ticks, the dest address is blacklisted. The caller must have initiated route structures. The struct uip_ipaddr pointer nexthop must point to a structure containing a pointer to the next hop rime address where the route reply is forwarded. The struct uip_ipaddr pointer dest must point to a structure containing a pointer to the rime address of the route reply originator. Deﬁnition at line 257 of ﬁle route.c. struct pending_entry ∗route_pending_list_lookup ( const uip_ipaddr_t ∗from, const uip_ipaddr_t ∗orig, uint8_t seq_num ) Looks for an entry in the Pending List.

Parameters

Parameter Description from A pointer to a struct uip_ipaddr. orig A pointer to a struct uip_ipaddr. seq_num An integer containing a sequence number.

Returns

The pointer to the pending_entry struct containing the Pending List tuple entry corresponding with a route with the received parameters. If the route_entry is 84 CHAPTER 5. LOADNG IMPLEMENTATION not found, the function returns a NULL pointer.

Description The caller must have initiated route structures. Deﬁnition at line 207 of ﬁle route.c. void route_refresh ( struct_route_entry ∗e ) Refreshes a route entry in the Routing Set.

Parameters

Parameter Description e A pointer to a struct route_entry.

Description This function refreshes the expiration timer of the route entry given as a parameter. Deﬁnition at line 375 of ﬁle route.c. void route_remove ( struct routing_tuple ∗e ) Removes a route entry in the Routing Set.

Parameters

Parameter Description e A pointer to a struct route_entry.

Description This function removes the route entry pointed by its given parameter. Deﬁnition at line 392 of ﬁle route.c. void route_remove pending_entry ( void ∗n ) Removes an entry in the Pending List. 5.5. CONCLUSION 85

Parameters

Parameter Description n A pointer to a struct route_entry.

Description This function removes the route entry pointed by its given parameter. Deﬁnition at line 194 of ﬁle route.c.

5.5 Conclusion

LOADng has been successfully implemented for Contiki OS. This implementation replaces default AODV routing protocol, and thanks to Contiki modularity is completely integrated with the whole system. Is important to use light protocols in sensor nodes, due to its limited memory and process capabilities. LOADng implementation is written in about 2.500 lines of code, which is much lighter than the current implementations of other routing protocols, such as RPL. This gives an idea of how complex the protocol is, and thus, how expensive is in therms of process and memory usage.

Chapter 6

LOADng performance on WSN

6.1 Description of the simulations

To test general behavior of LOADng as Contiki routing protocol for WSN, several simulations have been run with Cooja simulator. These simulations test point-to- point communications in a WSN. In these simulations, a set of nodes are deployed in a ﬂat ﬁeld, and one special node (called root node) tries to send a data packet sequentially to all the other nodes (called leaf nodes). The root node waits an interlude time between each attempt to send a data packet. This interlude time is set longer enough to:

1. ensure there are not packets – either data packets or LOADng packets – from previous processes propagating in the network. The reason is to avoid collisions which can lead to not discovering optimal routes.

2. ensure expiration of all existent routes in each node’s routing table. The reason is to initiate all route discovery processes in the same initial conditions.

The previous requirements are reached by setting an interlude time longer than the network convergence time (for item 1), and by setting an interlude time larger than the convergence time plus the route expiration time (for item 2). The procedure of sending a data packet is as follows: When the root node proceeds to send a new data packet, the LOADng route discovery procedure is called to obtain the sought route. After receiving a data packet, each leaf node sends an acknowledge data packet back to the root node. During the LOADng route discovery procedure, the reverse route is installed so the destination leaf node has no need to discover a new path towards the root node. 88 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Figure 6.1: Detail of Cooja simulation environment and node distribution.

6.1.1 Scenarios

Sensor nodes are deployed in a flat field, and positioned uniformly, as shown in figure 6.3. In the simulation design, some constraints are desired in nodes communication:

Transmitting Range A transmitting node can only reach its nearest neighbors (in ﬁgure 6.3, its four nearest neighbors).

Interference Range Interferences might affect, at most, to the two-hop away neighbors (in figure 6.3, the eight nearest neighbors) of a transmitting node, and should not affect to further nodes.

To satisfy this requirements, simulations are conﬁgured with the parameters shown in table 6.1.

Parameter Value Simulator Cooja Radio medium UDGM Grid size variable Density of nodes constant 4 nodes/(100m)2 Number of nodes 25, 113 Node separation 50m Transmitting range 55m Interference range 85m Success ratio tx / rx 1.0 / 1.0

Table 6.1: Cooja simulation parameters 6.1. DESCRIPTION OF THE SIMULATIONS 89

Simulation scenarios consist of a set of nodes uniformly distributed in a flat grid field, with a density of 4 nodes per (100m)2. The minimum distance between nodes is set to 50 meters, while transmitting range is 55 meters. The selected radio medium is UDGM, with an ideal success ratio on transmission and reception. When interferences occur, the UDGM model always implies failure on reception. This is a conservative model, because in practice not all interferences imply reception failure. This effect can be balanced by choosing smaller interference ranges. Typically, interference range is assumed to be two times the transmitting range. However, in these simulations this range is set to 1.7 times the transmitting range (i.e., 85 meters). By doing this, the model turns out to be more realistic; the adopted interference range covers 4 nodes instead of the 8 nodes that would be affected by choosing the greater interference range.

(a) Ideal range (b) Realistic range Figure 6.2: Node transmitting range

3-hop radius scenario

The smallest scenario used in simulations is a 3-hop radius network. In this scenario, 24 leaf nodes are uniformly distributed around a source node, as in ﬁgure 6.3a. Minimum distance between nodes is 50 meters. This scenario is a subset of the nodes of the 7-hop radius scenario presented in ﬁgure 6.3b. Simulations show that net traversal time in this network is lower than 2 seconds.

7-hop radius scenario

The largest scenario used in simulations is a 7-hop radius network. In this scenario, 112 leaf nodes are uniformly distributed around a source node, as in ﬁgure 6.3b. Minimum distance between nodes is 50 meters. Simulations show that net traversal time in this network is lower than 4 seconds. 90 CHAPTER 6. LOADNG PERFORMANCE ON WSN

(a) 3-hop radius (b) 7-hop radius scenario. scenario. Figure 6.3: Nodes distribution in simulated scenarios. Root node (green), leaf nodes (yellow), node transmitting range (green) and interference range (grey).

6.1.2 Platforms

Simulations have been run using several sensor node platforms: the Tmote Sky, and MicaZ.

Tmote Sky

Tmote Sky is a mote platform equipped with a great number of sensors. It builds the Texas Instruments TI MSP430 F1611 microcontroller, with a 16-bit RISC processor. It uses a USB controller to communicate with the cost computer and features the Chipcon CC2420 radio, which is IEEE 802.15.4 compliant. The internal Inverted-F microstrip antenna is a pseudo omni directional antenna reaching up to 50-meter range indoors and up to 125-meter range outdoors.

MicaZ

MicaZ platform builds a processor board MPR2400 based on the Atmel AT- mega128L. The 51-pin expansion connector supports Analog Inputs, Digital I/O, I2C, SPI and UART interfaces, and can be equipped with several sensors. It uses a serial/USB interface for both programming and data communications. Its RF transceiver is IEEE 802.15.4 compliant; a dipole antenna reaches up to 30-meter range indoors, and up to 100-meter range outdoors.

6.1.3 Sensor nodes

Sensor nodes run a modiﬁed Contiki operating system, where the routing protocol has been replaced by LOADng. A sample of the Contiki source code used in sensor nodes (at application level) is presented in appendix D.1. 6.1. DESCRIPTION OF THE SIMULATIONS 91

The Rime stack has been used for communication between nodes. Concretely, the simulated nodes send packets with the mesh module, which makes use of the multi-hop communication across the multihop module. The data packet sent by the root node contains a payload of 100 octets. The data acknowledge payload has 11 octets. A summary of the Contiki conﬁguration is shown in table 6.2.

Parameter Value Platform Tmote Sky, MicaZ Contiki version 2.5 Transport protocol Rime mesh Data packet 100 bytes Data ACK packet 11 bytes

Table 6.2: Contiki parameters in simulated sensor nodes

The main sensor node platform used for simulations is the Tmote Sky. The reason is that the Tmote Sky nodes are deeply introduced in common WSN. It is an extended platform with good capabilities, memory storage, and power eﬃciency. It is interesting to prove LOADng performance in such popular platform.

6.1.4 LOADng Conﬁguration

LOADng parameters have been setup according to table 6.3. In these simulations, net traversal time has been detected to be lower than 2 seconds. To avoid loops in RREQ ﬂooding, Route lifetime has been set greater than two times the net traversal time. Direct link communication time has detected to be less than 50 ms, so RREP-ACK timeout has been set to 100ms. Best routes are chosen according to an hop-count metric. For each desired route, route discovery process is tried once. The reason is that probability of success (and other statistics) remains constant in each attempt, so the probability of success (and other statistics) with more than one attempt can be obtained from the results of these tests. Hop-count metrics are used in all simulations. This, despite it is not the most common applicable metrics for real applications, is a good metric for use in simulations to test optimality of the discovered routes. The success of LOADng to discover the best routes relays on avoiding collisions in RREQ broadcast propagation. For that reason, a uniformly distributed jitter time have been set before RREQ broadcast transmissions. Some tests have revealed that in this kind of topology a jitter time between 0 and 200 ms increases the 92 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Parameter Value Number of retries 1 attempt Metrics 0 (hop-count) Route lifetime 5 seconds Net traversal time 2 seconds Blacklist time 10 seconds Backoﬀ 0–200 ms (uniform) ACK-REQUIRED Yes RREP-ACK timeout 100 ms

Table 6.3: LOADng parameters in simulated sensor nodes success rate and the optimality of the routes found, meanwhile the number of reattempts to discover a route decreases.

6.1.5 Nomenclature and features

The features observed in simulations are presented below. Some of them are presented in form of normalized histograms, which approximates the probability distribution function.

Success Rate The percentage of successfully discovered routes. It is represented in a pie chart, and distinguish between optimal routes, suboptimal routes and routes failed to be discovered.

Number of hops The number of hops of the discovered route. It is presented in form of a normalized histogram.

RREQ Traﬃc The number of RREQ packets sent to the network during a successful route discovery process. It is presented in form of a normalized histogram.

RREP/RREP-ACK Traﬃc The number of RREP packets, and RREP-ACK packets sent to the network during a successful route discovery process. It is presented in form of a normalized histogram.

Route Discovery Time The time from the route discovery process init until a the originator receives the (ﬁrst) RREP. It is presented in form of a normalized histogram.

Convergence Time The time from the route discovery process init until the last packet is sent to the network. It is presented in form of a normalized histogram. 6.2. MEDIUM ACCESS 93

Upload Time The time from the route discovery process init until the destination receives the (ﬁrst) RREQ. It is presented in form of a normalized histogram.

Download Time The time from the destination receives the (ﬁst) RREQ until the originator receives the (ﬁrst) RREP.

A detailed analysis of LOADng performance is done for each simulated scenario. Route discovery statistics are divided and treated separately depending on the number of hops of an optimal sought route.

6.2 Medium Access

Selecting an efficient medium access technique is crucial in LOADng performance. LOADng specification recommends using some backoff time prior RREQ transmission, and the LOADng tested implementation supports the use of backoff times prior to RREQ transmission, being possible to configure its mean and distribution: uniform or exponential. Contiki supports MAC protocols. Depending on the node platform memory, using a medium access protocol such as CSMA is possible. Tmote Sky has enough recourses to support CSMA, which improves significantly RREQ propagation in front off using a NULLMAC medium access in hostile scenarios. Some simulations have been done to test LOADng perfomance using different uniform backoff times. Section 6.2.1 shows the influence of using – or not – a backoff time in packet’s transmission. Section 6.2.2 presents a comparative of using different backoff times and medium access control techniques. Finally, the election used in implementation according to the simulation results is presented in section 6.2.3. The purpose of this manuscript is to test LOADng performance to discover new routes, and not to develop nor study medium access protocols. In real applications, a proper backoff time should be setup according to the network and traffic patterns. In this thesis, LOADng performance tests are configured with a simply uniform backoff time, long enough to ensure certain level of success on RREQ transmission.

6.2.1 Backoff time influence Figure 6.4 presents the results of the simulations using a uniform-distributed backoff between 0 and 100 ms – an intentionally low backoff time has been chosen, see further conclusions in this section –, and CSMA/CA medium access technique. In the simulated process, LOADng route discovery try to discover optimal 2-hop 94 CHAPTER 6. LOADNG PERFORMANCE ON WSN and 3-hop routes in the 3-hop radius scenario described in section 6.1.1, and using Tmote Sky nodes.

(a) Route-discovery (b) Number of hops (c) Success rate time distribution expectance Figure 6.4: Route discovery performance for 2-hop routes with bad back- oﬀ time.

Figure 6.4a shows a normalized histogram of the route discovery time. The routes not discovered in a first attempt are attempted to be discovered in a second attempt after certain timeout (4 seconds). If a route is not obtained, a third attempt is tried. In each new attempt, the route discovery time distribution follows similar patterns, as well as the percentage of routes successfully discovered. This leads to think that the probability to discover a route in each attempt remains constant and, in general, the statistics during route discovery process are independent in each attempt. Figure 6.4b shows the distribution of the number of hops of the routes discovered. More than 95% of the routes discovered are optimal. Nevertheless, only 40% of the routes are discovered in the first attempt, and almost 20% are not discovered after three attempts, as shown in figure 6.4c. The percentage of discovered routes decreases to 20% when discovering routes for 3-hop away nodes. Route discovery processes fails because of interferences. This can be fixed by improving medium access techniques. As the purpose of this thesis is not to develop complex algorithms nor focus in medium access, the adopted solution is to increase the backoff time (see section 6.2.2).

6.2.2 Backoff time comparative

Figure 6.5 shows the success rate of route discovery processes for different backoff times – the figure indicates the mean of the backoff time, of uniform distribution –, using CSMA or NULLMAC as medium access technique. In the simulated process, LOADng route discovery try to discover optimal 2-hop routes in the 3-hop radius scenario described in section 6.1.1 and using Tmote Sky nodes. The success rate, in this case, estimates the probability to discover a valid route, 6.2. MEDIUM ACCESS 95

route discovery success rate 1 NULLMAC, NULLRDC CSMA/CA, CONTIKIMAC 0.8

0.6

0.4 probability

0.2

0 0 50 100 150 200 250 300 350 400 mean backoff (ms) Figure 6.5: Backoﬀ time eﬀect in route discovery success rate.

not necessarily to be optimal. When using null medium access protocol (nullmac) and a mean backoff time of 50 ms, 50% success rate is reached. With CSMA/CA, around 150 ms of backoff time is needed to reach the same rate. In both cases, an 80% success rate is achieved with 300 ms backoff time. The success rate using CSMA/CA is lower success than those obtained using nullmac. This is due to centralized network topology of the tests, and LOADng radial expansion of LOADng messages, which make nullmac still suitable for RREQ propagation. In general, real network topologies are not as regular as in those tests, and bottle necks exist. In addition, other data packets can traverse the network during a LOADng route discovery process. For that reasons, a medium access technique such as CSMA/CA or other is highly recommendable.

6.2.3 Implementation

The purpose of this manuscript is not to study nor develop medium access techniques. In general, backoff times should be chosen according to the network topology and its data traffic (estimated) patterns, and in general should implement more specific distributions than the uniform distribution tested before. In order to study LOADng performance, a backoff time has been selected for simulations long enough to assure certain success rate in RREQ propagation, and thus, in LOADng route discovery processes. Results shown in section 6.2.2 reveal that, when discovering 3-hop routes, a backoff time uniformly distributed between 0 and 780 ms. ensure correct RREQ propagation to reach 90% of success rate on discovering those routes. Then, for the simulations presented in the next sections, a backoff time uniformly distributted between 0 and 780 ms is selected. An uniform distributed backoff time is implemented with the function: 96 CHAPTER 6. LOADNG PERFORMANCE ON WSN

clock_wait(random_rand() % (2*MEAN_BACKOF))

That is, the node waits a random time uniformly distributed between 0 and 2*MEAN_BACKOFF milliseconds. The simulations described in next sections have been run with MEAN_BACKOFF = 390 ms.

6.3 Network Diameter Inﬂuence

The following tests evaluate the inﬂuence of the network size in LOADng performance. The selected scenarios are the 3-hop radius network and the 7-hop radius network. The parameters adopted in these simulations for the diﬀerent simulated scenarios are listed in table 6.4.

Network radius 7-hop 3-hop Platform Tmote Sky Tmote Sky Route lifetime (seconds) 8 5 Net traversal time (seconds) 5 2 Routing Set (entries) 8 8 Pending List (entries) 8 8 Blacklist (entries) 16 16 Data packet (bytes) 100 100 Data ack (bytes) 11 11 MAC CSMA/CA CSMA/CA RDC ContikiMAC ContikiMAC

Table 6.4: Network Radius inﬂuence. Simulation parameters.

In each scenario, a separate analysis of the parameters listed in section ... is done depending on the number of hops of the optimal route sought to be discovered.

6.3.1 7-hop radius Scenario In this simulation, a set of 113 nodes are deployed in a grid ﬁeld as in ﬁgure 6.3b. The central node is the source node, and all the other nodes are leaf nodes.

Analysis of the optimal 1-hop routes

A total of 22 route discovery processes to discover 1-hop optimal routes have been simulated. All route discovery processes have successfully discovered 1-hop optimal routes. In 85% of the cases RREQ ﬂooding propagates to 100 or more nodes. All RREP and RREP–ACK packets have been successfully transmitted. 6.3. NETWORK DIAMETER INFLUENCE 97

Route discovery time has a peak in 0.6 seconds, which corresponds in average to 0.4 seconds of upload time and 0.2 seconds of download time. Maximum route discovery time is lower than 2 seconds in all simulated processes. The expected convergence time is around 6 seconds, having its maximum cote in 7.5 seconds.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes 0%failed to discover 0.8

0.6

0.4 Probability

0.2

0 100% 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.6: 7-hop radius scenario, 1-hop routes: Success rate and number of hops

Probability distribution of route discovery time Convergence time probability distribution 0.7 0.25

0.6 0.2 0.5

0.4 0.15

0.3 0.1 Probability Probability 0.2 0.05 0.1

0 0 0 0.5 1 1.5 2 4.5 5 5.5 6 6.5 7 7.5 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.7: 7-hop radius scenario, 1-hop routes: Route discovery and convergence time 98 CHAPTER 6. LOADNG PERFORMANCE ON WSN

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.7 1 RREP packets RREP-ACK packets 0.6 0.8 0.5

0.4 0.6

0.3 0.4 Probability Probability 0.2 0.2 0.1

0 0 40 50 60 70 80 90 100 110 120 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.8: 7-hop radius scenario, 1-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.35 0.5

0.3 0.4 0.25

0.2 0.3

0.15 0.2 Probability Probability 0.1 0.1 0.05

0 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0 0.2 0.4 0.6 0.8 1 1.2 1.4 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.9: 7-hop radius scenario, 1-hop routes: Upload and download time 6.3. NETWORK DIAMETER INFLUENCE 99

Analysis of the optimal 2-hop routes A total of 54 route discovery processes to discover 2-hop optimal routes have been simulated. Up to 80% of the routes are optimal, near 19% of the routes are suboptimal, and 2% of the routes are not discovered. Route discovery time distribution (figure 6.11a) has a cumulative point around 2 seconds, corresponding to the peak of the optimal routes in figure 6.10b, and representing 80% of the discovered routes. Upload and download distribution time don’t show a peak. Both are distributed around 1 second; upload time moves from 0.5 to 2.2 seconds, and download time moves from 0.4 to 1.6 seconds. Figure 6.12a shows the effect of the RREQ flooding in the entire network: in high percentage of the discovered routes (up to 70%), the RREQ is flooded to more than 100 nodes. This RREQ retransmissions imply an unnecessary energy- wasting of the nodes not belonging to the chosen optimal (or suboptimal) route. Convergence time expectance is around 6 seconds, having a maximum cote of 10 seconds.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed 2%to discover 19% 0.8

0.6

0.4 Probability

0.2 80% 0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.10: 7-hop radius scenario, 2-hop routes: Success rate and number of hops 100 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Probability distribution of route discovery time Convergence time probability distribution 0.2 0.4

0.35

0.15 0.3

0.25

0.1 0.2

Probability Probability 0.15

0.05 0.1

0.05

0 0 0.5 1 1.5 2 2.5 3 3.5 4 2 4 6 8 10 12 14 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.11: 7-hop radius scenario, 2-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.8 1 RREP packets 0.7 RREP-ACK packets 0.8 0.6

0.5 0.6 0.4 0.4 Probability 0.3 Probability

0.2 0.2 0.1

0 0 40 60 80 100 120 140 160 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.12: 7-hop radius scenario, 2-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.2 0.2

0.15 0.15

0.1 0.1 Probability Probability

0.05 0.05

0 0 0 0.5 1 1.5 2 2.5 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.13: 7-hop radius scenario, 2-hop routes: Upload and download time 6.3. NETWORK DIAMETER INFLUENCE 101

Analysis of the optimal 3-hop routes A total of 44 3-hop processes to discover 3-hop optimal routes have been simulated. More than 64% of the routes have been optimally discovered, 14% of them are suboptimal, and 23% of them failed to be discovered. Route discovery time graphic (figure 6.39a) shows two cumulative points around 2.5 and 4 seconds, corresponding to the two cumulative points for the number of hops in figure 6.38b. That is, the 80% of the discovered routes are optimal. Upload time is distributed around two cumulative points, around 1.5 and 3 seconds, corresponding again to the number of hops of the discovered route. Down- load time is more uniformly distributed between 0.6 and 1.6 seconds. Convergence time of the network shows no significative differences respect to the other routes.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed to discover 23% 0.8

0.6

0.4 14% Probability 64% 0.2

0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.14: 7-hop radius scenario, 3-hop routes: Success rate and number of hops 102 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Probability distribution of route discovery time Convergence time probability distribution 0.35 0.35

0.3 0.3

0.25 0.25

0.2 0.2

0.15 0.15 Probability Probability 0.1 0.1

0.05 0.05

0 0 1 1.5 2 2.5 3 3.5 4 4.5 5 4 5 6 7 8 9 10 11 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.15: 7-hop radius scenario, 3-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.7 1 RREP packets RREP-ACK packets 0.6 0.8 0.5

0.4 0.6

0.3 0.4 Probability Probability 0.2 0.2 0.1

0 0 60 70 80 90 100 110 120 130 140 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.16: 7-hop radius scenario, 3-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.35 0.25

0.3 0.2 0.25

0.2 0.15

0.15 0.1 Probability Probability 0.1 0.05 0.05

0 0 0.5 1 1.5 2 2.5 3 3.5 0.5 1 1.5 2 2.5 3 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.17: 7-hop radius scenario, 3-hop routes: Upload and download time 6.3. NETWORK DIAMETER INFLUENCE 103

Analysis of the optimal 4-hop routes A total of 39 route discovery processes to discover 4-hop optimal routes have been simulated. A total of 69% of these routes are optimal, 13% are suboptimal, and 18% are not discovered. Route discovery time between 2.5 and 4.5 seconds is more uniformly distributed than in shorter routes. Effects of backoff time and other random delays across the hops of the route mask the peaks of the number of hops of the route. The RREQ packets are flooded to the majority of nodes. Upload time is distributed around two cumulative points, in 1.5 seconds, and in 2.25 seconds, corresponding to the number of hops of the discovered route. Download time distribution does not manifest this peaks so clearly. Convergence time in the network maintains between 4.5 and 7 seconds, but is more uniformly distributed than is when discovering shorter paths.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed to discover 18% 0.8

0.6 13% 0.4 Probability

69% 0.2

0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.18: 7-hop radius scenario, 4-hop routes: Success rate and number of hops 104 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Probability distribution of route discovery time Convergence time probability distribution 0.2 0.2

0.15 0.15

0.1 0.1 Probability Probability

0.05 0.05

0 0 2 2.5 3 3.5 4 4.5 4.5 5 5.5 6 6.5 7 7.5 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.19: 7-hop radius scenario, 4-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.35 1 RREP packets RREP-ACK packets 0.3 0.8 0.25

0.2 0.6

0.15 0.4 Probability Probability 0.1 0.2 0.05

0 0 70 80 90 100 110 120 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.20: 7-hop radius scenario, 4-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.2 0.2

0.15 0.15

0.1 0.1 Probability Probability

0.05 0.05

0 0 0.5 1 1.5 2 2.5 3 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.21: 7-hop radius scenario, 4-hop routes: Upload and download time 6.3. NETWORK DIAMETER INFLUENCE 105

Analysis of the optimal 5-hop routes A total of 62 route discovery processes to discover 5-hop optimal routes have been simulated. Up to 76% of them have been optimally discovered, an the 24% of the rest have failed. There has’t been discovered any suboptimal route, perhaps due to the topology of the network. Route discovery time graphic (figure 6.23a) shows that the most of the routes are discovered between 3.5 and 4 seconds. This time, there is no different peaks in this distribution due to different number of hops, because all discovered routes are optimal. Upload time is distributed around one peak at 2 seconds, and download time is around 1.5 seconds. Convergence time of the network maintains between 4 and 7 seconds, and has a peak around 5 seconds.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed to discover 24% 0.8

0.6 0% 0.4 Probability

0.2 76% 0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.22: 7-hop radius scenario, 5-hop routes: Success rate and number of hops 106 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Probability distribution of route discovery time Convergence time probability distribution 0.25 0.35

0.3 0.2 0.25

0.15 0.2

0.1 0.15 Probability Probability 0.1 0.05 0.05

0 0 3 3.5 4 4.5 5 3 4 5 6 7 8 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.23: 7-hop radius scenario, 5-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.35 1 RREP packets RREP-ACK packets 0.3 0.8 0.25

0.2 0.6

0.15 0.4 Probability Probability 0.1 0.2 0.05

0 0 60 70 80 90 100 110 120 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.24: 7-hop radius scenario, 5-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.35 0.25

0.3 0.2 0.25

0.2 0.15

0.15 0.1 Probability Probability 0.1 0.05 0.05

0 0 1 1.5 2 2.5 3 3.5 0.8 1 1.2 1.4 1.6 1.8 2 2.2 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.25: 7-hop radius scenario, 5-hop routes: Upload and download time 6.3. NETWORK DIAMETER INFLUENCE 107

Analysis of the optimal 6-hop routes A total of 18 route discovery processes to discover 6-hop optimal routes have been simulated. In this case, the success rate considerably decreases. Only 39% of the routes are discovered (in this case, optimally discovered), while 61% of the routes failed to be discovered. The percentage of nodes not being ﬂooded with RREQ packets are those nodes more hops away from the source node. This explains the low success rate on 6-hops-away nodes. High success rates could be achieved with better medium access techniques, helping to avoid collisions of RREQ packets.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed to discover 0.8

39% 0.6

0.4 Probability 61% 0.2 0% 0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.26: 7-hop radius scenario, 6-hop routes: Success rate and number of hops

Probability distribution of route discovery time Convergence time probability distribution 0.35 0.35

0.3 0.3

0.25 0.25

0.2 0.2

0.15 0.15 Probability Probability 0.1 0.1

0.05 0.05

0 0 3 3.5 4 4.5 5 4 4.5 5 5.5 6 6.5 7 7.5 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.27: 7-hop radius scenario, 6-hop routes: Route discovery and convergence time 108 CHAPTER 6. LOADNG PERFORMANCE ON WSN

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.5 1 RREP packets RREP-ACK packets 0.4 0.8

0.3 0.6

0.2 0.4 Probability Probability

0.1 0.2

0 0 98 100 102 104 106 108 110 112 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.28: 7-hop radius scenario, 6-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.7 0.35

0.6 0.3

0.5 0.25

0.4 0.2

0.3 0.15 Probability Probability 0.2 0.1

0.1 0.05

0 0 1.6 1.8 2 2.2 2.4 2.6 2.8 3 1.5 1.6 1.7 1.8 1.9 2 2.1 2.2 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.29: 7-hop radius scenario, 6-hop routes: Upload and download time 6.3. NETWORK DIAMETER INFLUENCE 109

6.3.2 3-hop radius Scenario The simulated network is a subset of the network scenario used in previous simulations. Specifically, it consists of a 25-node distribution, as shown in figure 6.3a. In the simulations, routes are being discovered as in simulation of section 6.3.1, with the difference of the number of nodes in the network. So, route discovery process in simulations of 3-hop radius network acts as in simulations of 7-hop radius network (section 6.3.1), with the particularity that some of the nodes do not take part in the process (i.e., do not receive nor send LOADng packets to the network). The purpose of the following simulations is to test the influence of the network size in the route-discovery process. 110 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Analysis of the optimal 1-hop routes A total of 30 route discovery processes to discover 1-hop optimal routes have been simulated. The following figures show the result of the simulations. All routes in these case are optimal. The RREQ is not flooded to the entire network; in 40% of the tests, the RREQ reaches less than 20 nodes, and in up to 90% of the cases, the RREQ arrives to less than 22 over the total 25 nodes of the network. This is because the destination node does not forward the RREQ packet. Consequently, there is a branch of the network graph not receiving such RREQ directly from the destination node, but across another node which provides longer routes (thus, with higher probability of failure in propagation). Nevertheless, this non-flooding high expectance for 1-hop routes contributes to save energy in the network while maintaining optimality of the routes. Route discovery time for 1-hop routes is distributed around 0.6 seconds, and lower than 1.3 seconds in all the cases. Route discovery time is divided into upload time, which is the time spent for the RREQ packets to reach destination, and the download time, which is the time spent for the RREP packets to reach the source node. Upload time is around 0.4 seconds, and download time is around 0.2 seconds.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes 0%0% failed to discover 0.8

0.6

0.4 Probability

0.2

0 100% 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.30: 3-hop radius scenario, 1-hop routes: Success rate and number of hops 6.3. NETWORK DIAMETER INFLUENCE 111

Probability distribution of route discovery time Convergence time probability distribution 0.5 0.35

0.3 0.4 0.25

0.3 0.2

0.2 0.15 Probability Probability 0.1 0.1 0.05

0 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1 2 3 4 5 6 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.31: 3-hop radius scenario, 1-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.35 1 RREP packets RREP-ACK packets 0.3 0.8 0.25

0.2 0.6

0.15 0.4 Probability Probability 0.1 0.2 0.05

0 0 10 12 14 16 18 20 22 24 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.32: 3-hop radius scenario, 1-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.2 0.35

0.3 0.15 0.25

0.2 0.1 0.15 Probability Probability 0.1 0.05 0.05

0 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0 0.2 0.4 0.6 0.8 1 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.33: 3-hop radius scenario, 1-hop routes: Upload and download time 112 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Analysis of the optimal 2-hop routes A total of 203 route discovery processes have been simulated. The following figures show the result of the simulations. Up to 80% of the discovered routes are optimal, while the 20% of the rest are 4- hop suboptimal routes. The sub-optimality of the found routes is due to collisions in RREQ propagation, and can be reduced by improving medium access control techniques, or adding more jitter to RREQ transmissions – further studies shall be done to study this behaviour. In this case, the RREQ flooding arrives to more nodes of the network, and in the half of the cases the RREQ is transmitted over 20 nodes out of 25, i.e., 5 of those nodes save the energy of transmitting such RREQ. Under another point of view, in the half of the cases the RREQ is flooded to between 19 and 25 nodes. The expected route discovery time is around 2 seconds, with a peak of almost 25% routes discovered in nearly 1.6 seconds. Both upload and download time are around 1 second. The convergence time expectance for the 2-hop optimal routes is around 1.5 seconds, and lower than 6 seconds in all the cases. Note that the expected convergence time is lower than it is for the 1-hop optimal routes, and it is because flooding is more difficult for 1-hop routes, as long as the destination node does not propagate the RREQ, which reaches some nodes across longer routes increasing the convergence time.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed to4% discover 0.8 19% 0.6

0.4 Probability

0.2 77% 0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.34: 3-hop radius scenario, 2-hop routes: Success rate and number of hops 6.3. NETWORK DIAMETER INFLUENCE 113

Probability distribution of route discovery time Convergence time probability distribution 0.2 0.35

0.3 0.15 0.25

0.2 0.1 0.15 Probability Probability 0.1 0.05 0.05

0 0 0.5 1 1.5 2 2.5 3 3.5 1 2 3 4 5 6 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.35: 3-hop radius scenario, 2-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.35 1 RREP packets RREP-ACK packets 0.3 0.8 0.25

0.2 0.6

0.15 0.4 Probability Probability 0.1 0.2 0.05

0 0 10 12 14 16 18 20 22 24 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.36: 3-hop radius scenario, 2-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.2 0.25

0.2 0.15

0.15 0.1 0.1 Probability Probability

0.05 0.05

0 0 0 0.5 1 1.5 2 2.5 0 0.5 1 1.5 2 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.37: 3-hop radius scenario, 2-hop routes: Upload and download time 114 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Analysis of the optimal 3-hop routes A total of 108 route discovery processes have been simulated. The following figures show the result of the simulations. Up to 74% of the routes discovered are optimal, whereas the suboptimal routes, which are the 8%, have been discovered in 5 hops. The 18% of the rest of the routes failed to be discovered. The 3-hop away nodes are in the peripheral of the network graph. A first approach leads to think that, in order to discover a route to one of those nodes, the RREQ should flood all the entire network. Figure 6.40a reveals that in most of the cases, the RREQ doesn’t arrive to the totality of the nodes. This is because of collisions but, besides that, the optimal route can still be discovered because of the redundancy of optimal paths towards destination node. The convergence time expectance keeps between 2 and 4 seconds, having its peak around 2.5 seconds. The route discovery time is around 2.5 seconds; the upload time is around 1.4 seconds, and the download time is around 1.1 seconds.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed to discover 18% 0.8

0.6 8% 0.4 Probability

0.2 74% 0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.38: 3-hop radius scenario, 3-hop routes: Success rate and number of hops 6.3. NETWORK DIAMETER INFLUENCE 115

Probability distribution of route discovery time Convergence time probability distribution 0.25 0.35

0.3 0.2 0.25

0.15 0.2

0.1 0.15 Probability Probability 0.1 0.05 0.05

0 0 1 1.5 2 2.5 3 3.5 4 4.5 1 2 3 4 5 6 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.39: 3-hop radius scenario, 3-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.25 1 RREP packets RREP-ACK packets 0.2 0.8

0.15 0.6

0.1 0.4 Probability Probability

0.05 0.2

0 0 12 14 16 18 20 22 24 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.40: 3-hop radius scenario, 3-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.25 0.35

0.3 0.2 0.25

0.15 0.2

0.1 0.15 Probability Probability 0.1 0.05 0.05

0 0 0.5 1 1.5 2 2.5 3 0.6 0.8 1 1.2 1.4 1.6 1.8 2 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.41: 3-hop radius scenario, 3-hop routes: Upload and download time 116 CHAPTER 6. LOADNG PERFORMANCE ON WSN

6.3.3 Discussion

An LOADng performance comparison analysis is done for the 25-nodes and 113- nodes scenario used for simulations. Results reveal some patterns in LOADng behavior.

Success Rate Figure 6.42a presents LOADng success rate on discovering optimal routes in each simulated scenario. Results show that, both in 25-nodes and 113-nodes scenario, LOADng reaches the same success rate on discovering optimal paths. The network extension – in terms of space, and maintaining the number of nodes density – doesn’t affect to the success rate on discovering optimal routes. As expected, LOADng is 100% effective when seeking 1-hop optimal routes. For 2-hop optimal routes, LOADng successfully discover optimal paths in nearly 80% of the cases. The statistics show that success rate decreases to nearly 70% when discovering 3-hop optimal routes. Routes not being discovered in an optimal way can still be discovered via a suboptimal path. For 2-hop optimal routes, both in 25-nodes and 113- nodes scenario, LOADng discovers suboptimal paths in the same proportion. However, results reveal that the 113-nodes scenario provides better robustness discovering alternative suboptimal routes for those nodes being 3-hops away from the source. The reason is that the path of those suboptimal routes make profit of external nodes appearing in the 113-nodes scenario and not appearing in the 25-nodes scenario. In other words, these suboptimal paths go out of the 25-nodes scenario. Success rate on discovering 4-hop optimal routes (only for the 113-nodes scenario) decreases until 60%. A higher percentage of the discovered routes become suboptimal, which increases from 20% to 26%. This variation is not enough significative to state that optimality of the routes decreases, but this seems to be the tendency.

Number of hops Figure 6.42b shows the number of hops of the discovered route depending on the number of hops of the optimal route. The points in the graph indicate the second quartile of the data (Q2), and its boxes indicates Q1 and Q3 extremes. Discovered routes are optimal in both scenarios, as shown in ﬁgure 6.42a. For 1-hop to 3-hop, routes are optimally discovered at least from from Q1 to Q3. However, 4-hop optimal routes are not optimally discovered in the same proportion; the third quartile for 4-hop optimal routes in 113-nodes scenario increases up to 5 hops. 6.3. NETWORK DIAMETER INFLUENCE 117

Route discovery success rate Route Discovery Number of hops 1 7 optimal 25-nodes scenario suboptimal 113-nodes scenario failed 6 0.8 5 0.6 4 rate 0.4 3

0.2 2

Number of hops the discovered route 1 0 0 1 2 3 4 5 6 7 1 hop 2 hops 3 hops 4 hops 5 hops 6 hops Number of hops of the optimal route 25 nodes113 nodes 25 nodes113 nodes 25 nodes113 nodes 113 nodes 113 nodes 113 nodes (a) Success rate (b) Number of hops Figure 6.42: Network Radius Inﬂuence: Success rate and number of hops

Route discovery time Figure 6.43b presents the route discovery time of discovered routes respect to the number of hops of the optimal route to be discovered. The points indicate the mean of the data, and the boxes indicate conﬁdence interval, i.e., the extreme of the quartiles Q1 and Q3. As expected, route discovery time increases linearly with the number of hops of the route (which is optimal in the majority of the cases). The curve for the 113-nodes scenario is slightly above the curve for the 25-nodes scenario. However, conﬁdence and variance intervals suggest that there is no evidence to state that the route discovery time is higher in the 113-nodes scenario. In conclusion, the route discovery time follows the same patterns both in the 25-nodes and 113-nodes scenario.

Route Discovery Time Route Discovery process Convergence Time 5 7 25-nodes scenario 25-nodes scenario 113-nodes scenario 113-nodes scenario 4 6

3 5

2 4 time (seconds) time (seconds)

1 3

0 2 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 Number of hops of the optimal route Number of hops of the optimal route (a) Route discovery time (b) Convergence time Figure 6.43: Network Radius Inﬂuence: Route discovery and convergence time

Convergence time Convergence time remains constant with the path length in 118 CHAPTER 6. LOADNG PERFORMANCE ON WSN

each scenario. As expected, the convergence time increases with greater number of nodes. Ideally, the convergence time would increase with the network radius, but because of collisions longer routes appear, so the relationship becomes more complex. The 25-nodes scenario has radius 3, and in 113-nodes scenario has radius 6. The rate between the convergence time and the network radium is, respectively, 0.9 and 0.75.

Packet traffic In the 25-nodes scenario, RREQ flooding covers from 70% to 80% of the nodes. In contrast, in the 113-nodes scenario, RREQ packets are flooded to 90% of the network. This is due to the higher redundancy of paths to reach nodes in larger networks. Although the destination node does not propagate the RREQ, the other nodes do contribute to flood such RREQ. The effect is that the RREQ is better flooded in larger networks.

Route Discovery process Packet Traffic in 25-node scenario Route Discovery process Packet Traffic in 113-node scenario 25 120 RREQ packets RREQ packets RREP packets RREP packets 100 20

80 15 60 10 40 Number of packets Number of packets 5 20

0 0 0.5 1 1.5 2 2.5 3 3.5 0 1 2 3 4 5 6 7 Number of hops of the optimal route Number of hops of the optimal route (a) Packet traffic in 25-node scenario (b) Packet traffic in 113-node scenario Figure 6.44: Network Radius Influence: LOADng packet traffic

The RREP and RREP-ACK packets are equal to the number of hops of the discovered route, which is optimal in most of the cases. There is almost 100% success on transmitting RREP and RREP-ACK.

6.4 Platform Inﬂuence

This section introduces a comparison of LOADng performance between different platforms. The chosen scenario is the 3-hop radius network, consisting of 25 sensor nodes. The following tests evaluate the influence of the node platform into the LOADng performance. The adopted parameters for the different simulated platforms are listed in table 6.5. Due to storage limitations in MicaZ mote, a nullmac is selected as medium access technique. 6.4. PLATFORM INFLUENCE 119

Net traversalRoute time Lifetime (seconds)Routing (seconds) SetPending (entries) ListBlacklist (entries) (entries)Data PacketData (bytes) Ack (bytes) MAC Layer LOADng Data Set Application Physical Layer Layer Tmote Sky 2 5 8 8 16 100 10 NullRDC NullMAC MicaZ 2 5 8 8 16 10 11 NullRDC NullMAC

Table 6.5: LOADng conﬁguration for each platform.

The purpose of this simulations is to test LOADng performance in more than one platform, and observe diﬀerent patterns in LOADng performance.

6.4.1 Tmote Sky For the following simulations, the Tmote Sky is used and conﬁgured according to table 6.5.

Analysis of the optimal 1-hop routes A total of 20 route discovery processes have been simulated. The following figures show the result of the simulations. All routes have been successfully and optimally discovered. Route discovery time is delimited within 0.26 and 0.36 seconds. As no backoff time is used in RREP transmission, download time is really low compared to upload time. Network convergence time when discovering 1-hop routes is between 2 and 3 seconds, with a peak in 2.6 seconds. RREQs propagate to the entire network: only in 10% of the tests the RREQ propagated to 24 nodes (that is, there were 23 of those transmissions as the destination node does not forward such RREQ), and in 90% of the tests the RREQ was flooded to the entire network. 120 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes 0%failed to discover 0.8

0.6

0.4 Probability

0.2

0 100% 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.45: Tmote Sky platform, 1-hop routes: Success rate and number of hops

Probability distribution of route discovery time Convergence time probability distribution 0.5 0.5

0.4 0.4

0.3 0.3

0.2 0.2 Probability Probability

0.1 0.1

0 0 0.26 0.27 0.28 0.29 0.3 0.31 0.32 0.33 0.34 0.35 0.36 2 2.2 2.4 2.6 2.8 3 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.46: Tmote Sky platform, 1-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 1 1 RREP packets RREP-ACK packets 0.8 0.8

0.6 0.6

0.4 0.4 Probability Probability

0.2 0.2

0 0 23 23.2 23.4 23.6 23.8 24 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.47: Tmote Sky platform, 1-hop routes: LOADng packet traffic 6.4. PLATFORM INFLUENCE 121

Upload time probability distribution Download time probability distribution 0.5 0.5

0.4 0.4

0.3 0.3

0.2 0.2 Probability Probability

0.1 0.1

0 0 0.24 0.26 0.28 0.3 0.32 0.34 0.36 0.0063 0.0064 0.0065 0.0066 0.0067 0.0068 0.0069 0.007 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.48: Tmote Sky platform, 1-hop routes: Upload and download time 122 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Analysis of the optimal 2-hop routes A total of 69 route discovery processes have been simulated. The following ﬁgures show the result of the simulations. More than 95% routes have been successfully and optimally discovered. Route discovery time is delimited within 0.1 and 1.3 seconds, which is in great part the upload time. Network convergence time when discovering 2-hop routes is between 1.5 and 2.7 seconds, with a peak in 1.6, 2, and 2.2 seconds. The number of RREQ packets sent to the network goes from 22 to 26. In 20% of the cases, the number of transmitted RREQ is greater than the number of nodes in the network. This is because some nodes receive RREQ packets across diﬀerent paths, and if they can forward more than one RREQ packet (each time a better route is provided).

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed to4% discover0% 0.8

0.6

0.4 Probability

0.2

96% 0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.49: Tmote Sky platform, 2-hop routes: Success rate and number of hops 6.4. PLATFORM INFLUENCE 123

Probability distribution of route discovery time Convergence time probability distribution 0.2 0.35

0.3 0.15 0.25

0.2 0.1 0.15 Probability Probability 0.1 0.05 0.05

0 0 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.50: Tmote Sky platform, 2-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.5 1 RREP packets RREP-ACK packets 0.4 0.8

0.3 0.6

0.2 0.4 Probability Probability

0.1 0.2

0 0 22 22.5 23 23.5 24 24.5 25 25.5 26 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.51: Tmote Sky platform, 2-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.2 0.2

0.15 0.15

0.1 0.1 Probability Probability

0.05 0.05

0 0 0 0.2 0.4 0.6 0.8 1 1.2 1.4 0.015 0.02 0.025 0.03 0.035 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.52: Tmote Sky platform, 2-hop routes: Upload and download time 124 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Analysis of the optimal 3-hop routes A total of 90 route discovery processes have been simulated. The following figures show the result of the simulations. Almost 99% routes have been successfully and optimally discovered. Route discovery time is delimited within 0.6 and 1.7 seconds, which is in great part the upload time. Network convergence time when discovering 3-hop routes is between 1 and 2.4 seconds, with a peak in 1.5, 1.8, and 2.3 seconds. RREQs propagate to the entire network: only in 15% of the tests the RREQ propagated to 24 nodes (that is, there were 23 of those transmissions as the destination node does not forward such RREQ), and in 85% of the tests the RREQ was flooded to the entire network. In that case, nodes use to receive their best route with the first RREQ. This is due to the radial network topology and because the destination node (the only one stopping RREQ radial flooding) is in the frontier of the network.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed 1%to0% discover 0.8

0.6

0.4 Probability

0.2

0 99% 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.53: Tmote Sky platform, 3-hop routes: Success rate and number of hops 6.4. PLATFORM INFLUENCE 125

Probability distribution of route discovery time Convergence time probability distribution 0.25 0.25

0.2 0.2

0.15 0.15

0.1 0.1 Probability Probability

0.05 0.05

0 0 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 1 1.2 1.4 1.6 1.8 2 2.2 2.4 2.6 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.54: Tmote Sky platform, 3-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 1 1 RREP packets RREP-ACK packets 0.8 0.8

0.6 0.6

0.4 0.4 Probability Probability

0.2 0.2

0 0 22 22.5 23 23.5 24 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.55: Tmote Sky platform, 3-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.25 0.25

0.2 0.2

0.15 0.15

0.1 0.1 Probability Probability

0.05 0.05

0 0 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 0.02 0.03 0.04 0.05 0.06 0.07 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.56: Tmote Sky platform, 3-hop routes: Upload and download time 126 CHAPTER 6. LOADNG PERFORMANCE ON WSN

6.4.2 MicaZ Analysis of the optimal 1-hop routes A total of 10 route discovery processes have been simulated. The following ﬁg- ures show the result of the simulations. All discovered routes are discovered and optimal. Route discovery time is delimited within 0.75 and 0.83 seconds, which is in great part due the upload time. Network convergence time when discovering 1-hop routes is around 2.1 seconds. The number of transmitted packets is 24, which indicates that most probably the RREQ packet is ﬂooded to the entire network. RREQ does not propagate to the entire network: in 0 of the tests, there are 23 RREQ transmissions, which translates in there is (at least) one node not receiving such RREQ. Probably, this node is the node behind the destination node, which does not receive the RREQ from the destination node but neither from other nodes because of collisions.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes 0%failed to discover 0.8

0.6

0.4 Probability

0.2

0 100% 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.57: MicaZ platform, 1-hop routes: Success rate and number of hops 6.4. PLATFORM INFLUENCE 127

Probability distribution of route discovery time Convergence time probability distribution 1 0.35

0.3 0.8 0.25

0.6 0.2

0.4 0.15 Probability Probability 0.1 0.2 0.05

0 0 0.0860.088 0.09 0.0920.0940.0960.098 0.1 0.1020.104 2.184 2.186 2.188 2.19 2.192 2.194 2.196 2.198 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.58: MicaZ platform, 1-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 1 1 RREP packets RREP-ACK packets 0.8 0.8

0.6 0.6

0.4 0.4 Probability Probability

0.2 0.2

0 0 21 22 23 24 25 26 27 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.59: MicaZ platform, 1-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.5 0.5

0.4 0.4

0.3 0.3

0.2 0.2 Probability Probability

0.1 0.1

0 0 0.09020.09030.09040.09050.09060.09070.09080.0909 0.091 0.004 0.00410.00420.00430.00440.00450.00460.00470.0048 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.60: MicaZ platform, 1-hop routes: Upload and download time 128 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Analysis of the optimal 2-hop routes Almost 99% routes have been successfully and optimally discovered. Route discovery time is delimited within 0.6 and 1.7 seconds, which is in great part the upload time. Network convergence time when discovering 3-hop routes is between 1 and 2.4 seconds, with a peak in 1.5, 1.8, and 2.3 seconds. RREQs propagate to the entire network: only in 15% of the tests the RREQ propagated to 24 nodes (that is, there were 23 of those transmissions as the destination node does not forward such RREQ), and in 85% of the tests the RREQ was flooded to the entire network. In that case, nodes use to receive their best route with the first RREQ. This is due to the radial network topology and because the destination node (the only one stopping RREQ radial flooding) is in the frontier of the network.

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes 0%failed to discover 0.8

0.6

0.4 Probability

0.2

0 100% 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.61: MicaZ platform, 2-hop routes: Success rate and number of hops 6.4. PLATFORM INFLUENCE 129

Probability distribution of route discovery time Convergence time probability distribution 0.8 0.8

0.7 0.7

0.6 0.6

0.5 0.5

0.4 0.4

Probability 0.3 Probability 0.3

0.2 0.2

0.1 0.1

0 0 0.76 0.77 0.78 0.79 0.8 0.81 0.82 0.83 1.4 1.6 1.8 2 2.2 2.4 2.6 2.8 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.62: MicaZ platform, 2-hop routes: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.8 1 RREP packets 0.7 RREP-ACK packets 0.8 0.6

0.5 0.6 0.4 0.4 Probability 0.3 Probability

0.2 0.2 0.1

0 0 22 22.2 22.4 22.6 22.8 23 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.63: MicaZ platform, 2-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.8 0.25

0.7 0.2 0.6

0.5 0.15 0.4 0.1 Probability 0.3 Probability

0.2 0.05 0.1

0 0 0.75 0.76 0.77 0.78 0.79 0.8 0.81 0.82 0.012 0.0122 0.0124 0.0126 0.0128 0.013 0.0132 0.0134 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.64: MicaZ platform, 2-hop routes: Upload and download time 130 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Analysis of the optimal 3-hop routes

Route discovery success Probability distribution of number of hops 1 optimal routes suboptimal routes failed to5% discover0% 0.8

0.6

0.4 Probability

0.2

95% 0 0 2 4 6 8 10 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.65: MicaZ platform, 3-hop routes: Success rate and number of hops

Probability distribution of route discovery time Convergence time probability distribution 0.7 0.7

0.6 0.6

0.5 0.5

0.4 0.4

0.3 0.3 Probability Probability 0.2 0.2

0.1 0.1

0 0 1.2 1.4 1.6 1.8 2 2.2 1.4 1.6 1.8 2 2.2 2.4 2.6 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.66: MicaZ platform, 3-hop routes: Route discovery and convergence time 6.4. PLATFORM INFLUENCE 131

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 0.7 1 RREP packets RREP-ACK packets 0.6 0.8 0.5

0.4 0.6

0.3 0.4 Probability Probability 0.2 0.2 0.1

0 0 21 21.5 22 22.5 23 23.5 24 0 2 4 6 8 10 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.67: MicaZ platform, 3-hop routes: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.7 0.35

0.6 0.3

0.5 0.25

0.4 0.2

0.3 0.15 Probability Probability 0.2 0.1

0.1 0.05

0 0 1.2 1.4 1.6 1.8 2 2.2 0.020.02020.02040.02060.02080.0210.02120.02140.02160.02180.022 Time Time (seconds) (a) Upload traﬃc distribution (b) Download traﬃc distribution Figure 6.68: MicaZ platform, 3-hop routes: Upload and download time 132 CHAPTER 6. LOADNG PERFORMANCE ON WSN

6.4.3 Discussion

A LOADng performance comparison analysis is done between the 25-nodes and 113-nodes scenario used for simulations. Results reveal some patterns in LOADng behavior.

Success Rate Almost all routes are discovered due to radial network topology and radial RREQ ﬂooding expansion. Nodes can receive RREQ packets across many paths in case of failure in one RREQ transmission. This is not the case all real networks, where success rates could decrease.

Route discovery success rate Route Discovery Number of hops 1 3 optimal Tmote Sky suboptimal MicaZ failed 0.8 2.5

0.6 2 rate 0.4

1.5 0.2

0 Number of hops the discovered route 1 1 hopMicaZ 2 hopMicaZ 3 hopMicaZ 0.5 1 1.5 2 2.5 3 3.5 Tmote Sky Tmote Sky Tmote Sky Number of hops of the optimal route (a) Success rate (b) Number of hops Figure 6.69: Platform Inﬂuence: Success rate and number of hops

Number of hops Another time, due to network radial topology and RREQ ﬂooding, discovered routes are optimal. In addition, nodes use to receive the ﬁrst RREQ across the optimal path.

Route discovery time Route discovery time, at ﬁrst approach, depends linearly on the number of hops of the discovered route. We can express route discovery time as:

RDT = PT0 + NH(TT + BT + PT ) + NH(TT + PT ) =

= PT0 + NH(2(TT + PT ) + BT )

where PT0 is the process time spent by the source node, to initialize LOADng route discovery process; NH is the number of hops of the discovered route, most likely the optimal number of hops; TT is the transmission time of the LOADng packets; BT is the backoﬀ time; and PT is the process time of a RREQ or RREP packet. 6.4. PLATFORM INFLUENCE 133

Route discovery time curve of Tmote Sky has more pendent than the one of MicaZ. This could be due to differences in process time and transmission time of the packets. If significant differences in transmission or process time exist, they will manifest in differences in route discovery time. In a network with more than one type of platform, discovered routes will tend to select the type of nodes with lower transmission and process time. Differences between nodes can be balanced by selecting different apropiate backoff times in each type of platform. The objective is to balance the sum (2(TT + PT ) + BT ).

Route Discovery Time Route Discovery process Convergence Time 2 2.8 Tmote Sky Tmote Sky MicaZ MicaZ 2.6 1.5 2.4

2.2 1 2

time (seconds) time (seconds) 1.8 0.5 1.6

0 1.4 0.5 1 1.5 2 2.5 3 3.5 0.5 1 1.5 2 2.5 3 3.5 Number of hops of the optimal route Number of hops of the optimal route (a) Route discovery time (b) Convergence time Figure 6.70: Platform Inﬂuence: Route discovery and convergence time

Convergence time Convergence time is similar in each type of platform. In MicaZ motes, convergence time remains more constant with the number of hops of the optimal route than in Tmote Sky platform. When discovering a route, the destination node does not propagate the RREQ. Some nodes must receive such packet across longer routes than receiving it from the destination node. This eﬀect is more patent in 1 and 2-hop optimal routes.

Packet traffic RREQ packets are transmitted to almost the entire network. Backoff time before sending RREQ packets is sufficient to ensure RREQ flooding in the tested network. However, in another network topologies, specially with bottle necks, collisions can appear and will occur in some branches of the networks not receiving such packets. RREP and RREP-ACK packets are correctly transmitted across the reverse route with any errors. 134 CHAPTER 6. LOADNG PERFORMANCE ON WSN

Route Discovery process RREQ Packet Traffic Route Discovery process RREP/RREP-ACK Packet Traffic 25 3 Tmote Sky Tmote Sky MicaZ MicaZ 24 2.5

23 2 22

Number of packets Number of packets 1.5 21

20 1 0.5 1 1.5 2 2.5 3 3.5 0.5 1 1.5 2 2.5 3 3.5 Number of hops of the optimal route Number of hops of the optimal route (a) Packet traffic in 25-node scenario (b) Packet traffic in 113-node scenario Figure 6.71: Platform Influence: LOADng packet traffic 6.5. TESTS IN RANDOM NETWORK 135

6.5 Tests in random network

LOADng performance has been tested in a the scenario with the properties described in 6.3.2, with the particularity that the nodes – a total of 25 nodes – have been randomly positioned. One of these nodes takes the role of root node, and tries to send packets to all the other nodes sequentially. The platform chosen for this test is the Tmote Sky, with the common transmitting and interference ranges, and with CSMA/CA MAC protocol. Simulation scenario can be shown in ﬁgure 6.72, which gives an idea of the nodes deployment.

Figure 6.72: Random network deployment scenario. Source node (in blue), leaf nodes (yellow), transmitting range (green), and interferences range (grey).

6.5.1 Analysis of the route discovery process A total of 113 route discovery processes have been simulated for the 25-node network of figure 6.72. This results are compared to previous simulations of a 25-nodes regular scenario of section 6.3.2, and summarized in section 6.3.3. LOADng obtained 86% success on discovering routes. 40% of those routes are 1-hop routes; 34% of those routes are 2-hop routes; and 12% of those routes are 3-hop routes. Figure 6.73b shows the distribution of the number of hops of the discovered routes. In the regular network scenario, 1-hop, 2-hop, and 3-hop routes needed a route discovery time of, respectively, 1 second, 2 seconds, and 2.5 seconds. These are represented in figure 6.43a. In the random network scenario, route discovery time goes from 0.5 to 2.5 seconds, which adjust with the route discovery time obtained in previous simulations. Convergence time follows a gaussian distribution between 1 and 2.5 seconds. This is lower than the convergence time of the 3-hop radius scenario of previous sim- 136 CHAPTER 6. LOADNG PERFORMANCE ON WSN ulations (which is around 3 seconds), and is due to network topology. Generally speaking, collisions can cut the RREQ flooding in one branch of the network, which ends up in lower convergence time. RREQ packets, generally, successfully flooded to the entire network. In the bast majority of the cases, the nodes do receive the first RREQ packet across the optimal route. Only in some rare cases (really being outlayers), nodes receive RREQ packets containing a better route than the one previously installed. RREP and RREP-ACK packets can be successfully transmitted, as show figure 6.75b in correspondence with the number of hops distribution of figure 6.73b. Upload and download time are distributed between 0.1 and 1.5 seconds, which correspond to the margins of 1,2, or 3-hop routes previously analized in the 3-hop radius regular scenario.

Route discovery success Probability distribution of number of hops 0.5 1-hop routes 2-hop routes 3-hop routes14% longer routes 0.4 failed to discover 0% 40% 12% 0.3

0.2 Probability

0.1

34% 0 0 0.5 1 1.5 2 2.5 3 3.5 4 Number of hops (a) Success rate (b) Number of hops expectance Figure 6.73: Random Network Deployment: Success rate and number of hops

6.5.2 Discussion

LOADng performance in a random node deployment generally corresponds to previously behavior seen in regular scenarios introduced in section 6.1.1. Route discovery success rates reach ranges greater than 80%. Taking into account that better backoff times can be configured according to network topology and data traffic, this is a good success percentage. Previous results lead to think that great percentage of the discovered routes are optimal. Another time, the election of proper backoff times and medium access techniques can increase the probability of obtaining optimal routes. In summary, LOADng can successfully discover routes in all the analyzed scenarios, not only with uniformly distributed nodes but also in an scenario with 6.5. TESTS IN RANDOM NETWORK 137

Probability distribution of route discovery time Convergence time probability distribution 0.2 0.25

0.2 0.15

0.15 0.1 0.1 Probability Probability

0.05 0.05

0 0 0 0.5 1 1.5 2 2.5 3 0.5 1 1.5 2 2.5 3 Route discovery time (seconds) Time (a) Route-discovery time distribution (b) Convergence time distribution Figure 6.74: Random Network Deployment: Route discovery and convergence time

LOADng RREQ packet traffic per route LOADng RREP/RREP-ACK packet traffic per route 1 0.5 RREP packets RREP-ACK packets 0.8 0.4

0.6 0.3

0.4 0.2 Probability Probability

0.2 0.1

0 0 5 10 15 20 25 30 35 0.5 1 1.5 2 2.5 3 3.5 4 Packets sent to the network Packets sent to the network (a) RREQ traffic distribution (b) RREP/RREP–ACK traffic distribution Figure 6.75: Random Network Deployment: LOADng packet traffic

Upload time probability distribution Download time probability distribution 0.2 0.2

0.15 0.15

0.1 0.1 Probability Probability

0.05 0.05

0 0 0 0.5 1 1.5 2 0 0.5 1 1.5 2 Time Time (a) Upload traffic distribution (b) Download traffic distribution Figure 6.76: Random Network Deployment: Upload and download time 138 CHAPTER 6. LOADNG PERFORMANCE ON WSN randomly-positioned nodes. LOADng should preserve its effectiveness in similar scenarios, i.e., scenarios with similar – or keeping the same proportion between them – number of nodes, node density, and transmission range. 6.6. CONCLUSION 139

6.6 Conclusion

Simulations show LOADng performance for discovering routes. In the tested network topologies, and using some specific configuration, LOADng is able discover a path to the sought destination in 90% of the attempts. Within the discovered routes, up to 90% are optimal. These statistics are obtained in concrete scenarios with specific network topology. Results on other topologies may vary. The collision of RREQ packets is main problem that leads to route discovery processes failure. This problem can be partially solved by studying the network topology, adapting flooding techniques, and using adapted medium access techniques. Despite that it does not reach the entire network in all the cases, LOADng flooding is effective. Better RREQ packet flooding could be obtained by using medium access techniques adapted to the particular network, but the empirical results show that with the medium access technique used in tests, the optimal route is usually discovered. In addition, the sub-flooding of the RREQ packets benefit on energy saving. Results of the tests reveal that LOADng can reach 80% success rates on discovering optimal routes. In situations where optimality of routes is primordial and worths some extra energy-wasting and delay, a second route discovery process can be tried. By doing this, the probability of obtaining an optimal route considerably increases, while the energy spent to discover such route multiplies by two.

P (optimal route | 2 processes) = 1 − P (not optimal route | 2 processes) = 1 − (P (not optimal route | 1 process))2 = 1 − (1 − P (optimal route | 1 process))2

Assuming P (optimal route | 1 process)) = 0.8, we obtain:

P (optimal route | 2 processes) = 0.96 . The optimality of discovered routes leads to state that network nodes usually receive RREQ packets across an optimal path, and thus the convergence time is proportional to the network diameter (or radium). During simulations any loop has been detected. This is due to LOADng construction and the fact that every LOADng router keeps information of the best path over the RREQ has been received during, at least, the convergence time of the network.

Chapter 7

Conclusion

Wireless sensor networks are an emerging technology expected to take an important role in the future networks. Although sensor networks first appeared in the 1960s for pioneer military applications, WSN din’t start having the addient technology until the beginnings of the 21st century. Since the first wireless sensor mote appeared in 1999, a lot of platforms have been developed. Each time better devices are built, with better processing and memory capabilities while maintaining high connectivity and low power consumption. Industry is interested in this new technology. Future networks, smart grid and smart cities will base its communication skills in WSN. As an emerging technology, specific protocols must be created to satisfy the specific needs and requirements of the applications and the hardware. In addition, some of this protocols must be adopted as standard to ensure correct functioning, performance and interoperability between devices. In this context,the IETF ROLL Working Group has proposed RPL routing protocol as RFC. There is still no global acceptation about the standardization of this protocol, and some analysis have demonstrated that RPL does not perform well in point-to-point and multipoint-to-point communications. For that reasons, another WSN routing protocol, LOADng, has been developed. At the time this manuscript is written, LOADng has been published as an internet-draft. The purpose of the work contained in this manuscript is to contribute in the development of LOADng routing protocol. The contributions have been: contribute in the elaboration of the LOADng draft; contribution in the LOADng interoperability tests; implementation of LOADng routing protocol for use in Contiki OS; and simulate LOADng route-discovery processes to evaluate its performance. LOADng internet-draft was first published in April 2012, in colaboration with LIX 142 CHAPTER 7. CONCLUSION

(École Polytechnique), EDF, ERDF, Maxim Integrated Products, and Hitachi YRL. This internet-draft is intended to become a standards track. LOADng has been developed intended to be a lightweight routing protocol able to discover bidirectional routes. Its algorithm contemplates multipoint-to-point, point-to- point, and point-to-multipoint traffic. The interoperability tests for different LOADng implementations were carried out at Hitachi YRL facilities in Yokohama, Japan, from october 17th to october 19th 2011. The work done during the tests permitted to adjust some LOADng requirements and the interoperability performance was satisfactory. LOADng has been successfully implemented for use in Contiki OS. The memory consumption and process requirements of this LOADng implementation are compatible with the Tmote Sky and MicaZ platforms, using a routing table with capaticy storage for – at least – 8 entries. LOADng has been proved to work in scenarios of up to 7-hop radius networks. The results in simulations reveal that LOADng protocol is able to reach route- discovery success rates of around 90% of the routes, from which 90% result to be optimal (using the hop-count metrics). The bidirectionality of the discovered routes have been proved to work in the simulations. A high success rate relies on low number of retransmissions both in route discovery and data routing. Some improvements can be done in the election of the jitter and the medium access technique – depending on network topology and expected traffic –, which may affect in LOADng performance. As a conclusion of this work, LOADng is a reactive protocol for WSN able to discover routes with high and success rate on discovering optimal paths. In terms of memory and process consumption, LOADng implementation has proved to satisfy with the common WSN node capabilities.

Prospective and Future work Some tests in real testbed are necessary to verify LOADng performance, as well as to run LOADng in a real application during a considerable period of time to evaluate results. In the actuality there are several institutions contributing with LOADng development, and some others have demonstrated interest in LOADng as a routing protocol for WSN. Hitachi is developing some applications where LOADng is sup- posed to take part. French energy company EDF is also interested in LOADng for the future smart grids. In order to have LOADng publish as a RFC, a lot of work must be done creating and keeping contact with enterprises and industry in the IETF and other congresses. Bibliography

[1] 10 emerging technologies that will change the world. MIT’s Technology Review, February 2003.

[2] I.F. Akyildiz, Weilian Su, Y. Sankarasubramaniam, and E. Cayirci. A survey on sensor networks. Communications Magazine, IEEE, 40(8):102 – 114, aug 2002.

[3] Muneeb Ali. A Brief History of Sensor Networks. Princeton University, 2008.

[4] Guillermo Barrenetxea, Fran˜coisIngelrest, Gunnar Schaefer, and Martin Vetterli. Wireless Sensor Networks for Environmental Monitoring: The SensorScope Experi- ence. 20th IEEE International Zurich Seminar on Communications, March 2008.

[5] Veronica M. Bauer. Routing in Wireless Sensor Networks: An experimental Evalu- ation of RPL. Master’s thesis, École Polytechnique, France, December 2010.

[6] Jan Beutel. Metrics for Sensor Network Platforms. 2005.

[7] M. M. Chen, C. Majidi, D. M. Doolin, Glaser S., and N. Sitare. Design and construction of a wildﬁre instrumentation system using networked sensors. Network Embedded Systems Technology (NEST) Retreat, June 2003.

[8] Jatuporn Chinrungrueng, Udomporn Sununtachaikul, and Satien Triamlumlerd. A vehicular monitoring system with power-eﬃcient wireless sensor networks. In ITS Telecommunications Proceedings, 2006 6th International Conference, pages 951 – 954, june 2006.

[9] Aminul Haque Chowdhury, Muhammad Ikram, Hyon-Soo Cha, Hassen Redwan, S. M. Saif Shams, Ki-Hyung Kim, and Seung-Wha Yoo. Route-over vs mesh-under routing in 6lowpan. In Proceedings of the 2009 International Conference on Wireless Communications and Mobile Computing: Connecting the World Wirelessly, IWCMC ’09, pages 1208–1212, New York, NY, USA, 2009. ACM.

[10] T Clausen, A. Camacho, J. Yi, A. Colin de Verdiere, Y. Igarashi, H. Satoh, and Y. Morii. Experience with the LOADng routing protocol for LLNs. Internet-Draft draft-lavenu-lln-loadng-interoperability-report, Internet Engineering Task Force, April 2012. Informational. 144 BIBLIOGRAPHY

[11] T. Clausen, A Colin, J Yi, A. Niktash, Y Igarashi, H Satoh, and U Herberg. The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng), January 2012. INTERNET-DRAFT draft-clausen-lln-loadng-01.

[12] T. Clausen and Ulrich Herberg. A Comparative Performance Study of the Rout- ing Protocols LOAD and RPL with Bi-Directional Traﬃc in Low-power and Lossy Networks (LLN). INRIA, June 2011.

[13] T. Clausen and Ulrich Herberg. Study of Multipoint-to-Point and Broadcast Traﬃc Performance in RPL. INRIA, April 2011.

[14] T. Clausen, Ulrich Herberg, and Matthias Philipp. A Critical Evaluation of the ”IPv6 Routing Protocol for Low Power and Lossy Networks" (RPL). INRIA, May 2011.

[15] Firebug. Design and Construction of a Wildﬁre Instrumentation System Using Net- worked Sensors. http://firebug.sourceforge.net/, 2003. [Online; accessed 8- Jul-2012].

[16] S.S. Doumit and D.P. Agrawal. Self-organizing and energy-eﬃcient network of sensors. In MILCOM 2002. Proceedings, volume 2, pages 1245 – 1250 vol.2, oct. 2002.

[17] A. K. Dwivedi, M. K. Tiwari, and O. P. Vyas. Operating Systems for Tiny Networked Sensors:A Survey. International Journal of Recent Trends in Engineering, 1(2), May 2009.

[18] Soledad Escolar Diaz. Wireless sensor networks. ARCOS, March 2011.

[19] M. O. Farooq and T. Kunz. Operating Systems for Wireless Sensor Networks: A Survey. IEEE Personal Communications, May 2011.

[20] Enrico Frumento. WSN Applications in Health Environment. Workshop on Wireless Sensor Networks and their applications for SMEs, 2009.

[21] VMWare Fusion. version 3.1.3 for MacOS. http://www.vmware.com/, 2011. [On- line; accessed 23-June-2012].

[22] gnuplot. version 3.4. http://www.gnuplot.info/, 2010. [Online; accessed 23-June- 2012].

[23] Joaquín González Guerrero. Survey of Hardware Platforms and Localization Appli- cations for Wireless Sensor Networks. Institute of Computer Science, Freie Univer- sität Berlin, 2006.

[24] Weijun Guo. Performance analysis of ip over ieee 802.15.4 radio using 6lowpan, November 2008.

[25] Zygmunt J. Haas, Marc R. Peralman, and Prince Samar. The Zone Routing Protocol (ZRP) for Ad Hoc Networks. Internet-Draft, July 2002.

[26] S. Hadim and N. Mohamed. Middleware: middleware challenges and approaches for wireless sensor networks. Distributed Systems Online, IEEE, 7(3):11, 2006. BIBLIOGRAPHY 145

[27] Jonathan Hui, David Culler, and Samita Chakrabarti. 6lowpan: Incorporating ieee 802.15.4 into the ip architecture. Internet Protocol for Smart Objects (IPSO) Alliance, January 2009.

[28] Philo Juang, Hidekazu Oki, Yong Wang, Margaret Martonosi, Li Shiuan Peh, and Daniel Rubenstein. Energy-eﬃcient computing for wildlife tracking: design tradeoﬀs and early experiences with zebranet. In Proceedings of the 10th international conference on Architectural support for programming languages and operating systems, ASPLOS-X, pages 96–107, New York, NY, USA, 2002. ACM.

[29] Vivek Katiyar, Narottam Chand, and Naveen Chauhan. Recent advances and future trends in Wireless Sensor Networks. International Journal Of Applied Engineering Research, Dindigul, 1(3), 2010.

[30] R. Kay and F. Mattern. The Design Space of Wireless Sensor Networks. IEEE Wireless Communications, 11(6):54–61, 2004.

[31] Jonghwa Kim. Emotion recognition from physiological measurement (biosignal). Workshop Santorini, Humaine WP4/SG3, 2004.

[32] K. Kim, S. Daniel Park, G. Montenegro, S. Yoo, and N Kushalnagar. 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD). Internet-Draft draft-daniel- 6lowpan-load-adhoc-routing-03, Internet Engineering Task Force.

[33] N. Kushalnagar, G. Montenegro, and C. Schumacher. IPv6 over Low-Power Wire- less Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem State- ment, and Goals. RFC 4919 (Informational), August 2007.

[34] Jin-Shyan Lee, Yu-Wei Su, and Chung-Chou Shen. A comparative study of wireless protocols: Bluetooth, uwb, zigbee, and wi-ﬁ. Information Communications Research Labs Industrial Technology Research Institute (ITRI), November 2007.

[35] P. Levis, T. Clausen, J. Hui, O. Gnawali, and J. Ko. The Trickle Algorithm. RFC 6206 (Proposed Standard), March 2011.

[36] Y.S. Lohith. 6LoWPAN: Wireless “Internet Of Things”, November 2010.

[37] Konrad Lorincz, Matt Welsh, Omar Marcillo, Jeﬀ Johnson, Mario Ruiz, and Jonathan Lees. Deploying a wireless sensor network on an active volcano. In IEEE Internet Computing, pages 18–25, 2006.

[38] J. Macker. Simpliﬁed Multicast Forwarding, July 2011. draft-ietf-manet-smf-12 (work in progress).

[39] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler. Transmission of IPv6 Packets over IEEE 802.15.4 Networks. RFC 4944 (Proposed Standard), September 2007. Updated by RFC 6282.

[40] GNU Octave. version 3.4.0 for MacOS. http://www.gnu.org/software/octave/, 2011. [Online; accessed 21-June-2012].

[41] Contiki OS. version 2.5. http://www.contiki-os.org/, 2012. [Online; accessed 21-June-2012]. 146 BIBLIOGRAPHY

[42] F. Osterlind. Cross-Level Sensor Network Simulation with COOJA. 31st IEEE Conference on Local Computer Networks, November 2006.

[43] C. Perkins, E. Belding-Royer, and S. Das. Ad hoc On-Demand Distance Vector (AODV) Routing. RFC 3561 (Experimental), July 2003.

[44] Joseph Polastre, Robert Szewczyk, Cory Sharp, and David Culler. The Mote Revo- lution: Low Power Wireless Sensor Network Devices. Proceedings of Hot Chips 16: A Symposium on High Performance Chips, August 2004.

[45] Senslab. http://www.senslab.info/?p=383, 2012. [Online; accessed 28-June- 2012].

[46] Z Shelby, Sensinode, K. Hartke, Bormann C., Universitaet Bremen TZI, Frank B., and SkyFoundry. Constrained Application Protocol (CoAP). Internet-Draft, June 2012.

[47] K. Sohrabi, J. Gao, V. Ailawadhi, and Pottie G.J. Protocols for self-organization of a wireless sensor network. IEEE Personal Communications, October 2000.

[48] J. A. Stankovic. Wireless Sensor Networks for In-Home Healthcare: Potential and Challenges. HCMDSS, 2005.

[49] Jorge Tavares. Application of Wireless Sensor Networks to Automobiles. Measure- ment Science Review, 8, Section 3.

[50] A. Tiwari, P. Ballal, and F.L. Lewis. Energy-eﬃcient wireless sensor network design and implementation for condition-based maintenance. ACM Transactions on Sensor Networks (TOSN), 3(1):17, 2007.

[51] Andreas Tønnesen. Implementing and extending the Optimized Link State Routing Protocol. Master’s thesis, UniK University Graduate Center University of Oslo, August 2004.

[52] Dimitri van Heesch. User Manual for Doxygen 1.7.6.1, May 2011.

[53] Michal Varchola and Miloš Drutarovský. Zigbee based home automation wireless sensor network.

[54] Matt Welsh. Monitoring Volcanic Eruptions with a Wireless Sensor Network. Har- vard University, 2006.

[55] Geoﬀrey Werner-Allen, Konrad Lorincz, Matt Welsh, Omar Marcillo, Jeﬀ Johnson, Mario Ruiz, and Jonathan Lees. Deploying a Wireless Sensor Network on an Active Volcano. IEEE Internet Computing, March-April 2006.

[56] Contiki Wiki. https://www.sics.se/contiki/wiki/index.php/Main_Page, 2012. [Online; accessed 28-June-2012].

[57] Wikipedia. Constrained application protocol — wikipedia, the free encyclopedia. http://en.wikipedia.org/w/index.php?title=Constrained_Application_ Protocol&oldid=494922944, 2012. [Online; accessed 17-June-2012]. BIBLIOGRAPHY 147

[58] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, and R. Alexander. RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks. RFC 6550 (Proposed Standard), March 2012.

[59] Georg Wittenburg. A Rule-Based Middleware Architecture for Wireless Sensor Net- works. Master’s thesis, Freie Universität, Barlin, November 2005.

[60] Li Yang, Maorong Ji, Zhenru Gao, Weiping Zhang, and Tao Guo. Design of home automation system based on zigbee wireless sensor network. International Confer- ence on Information Science and Engineering.

[61] Cholatip Yawut and Sathapath Kilaso. A Wireless Sensor Network for Weather and Disaster Alarm Systems. International Conference on Information and Electronics Engineering, 2011.

[62] Marco Zennaro. WSN Applications WSN 2.0. Workshop on Applications of Wireless Sensor Networks for Environmental Monitoring in Developing Countries, February 2011.

Appendices

Appendix A

WSN Platforms and applications

A.1 Areas of application

Some of the recent advances and future trends of WSN, taken from [29], are shown below.

Smart Home / Smart Oﬃce Provides custom behavior.

Military Military situation awareness (Shen, 2001), Battleﬁeld surveillance, Sens- ing intruders, detection of enemy units (Doumit and Agrawal, 2002).

Industrial Commercial Monitoring and control of industrial equipment. Man- ufacturing monitoring.

Traﬃc Management Monitoring Traﬃc congestion control (Chinrungrueng, 2006).

Structural Healthcare condition based maintenance (Tiwari, 2004), concrete and composite materials (Arms, 2001).

Topology and coverage control prolong lifetime, reducing radio interference, increasing the eﬃciency, graph models of topology control (Jardosh and Ranjan, 2008).

Quality of Service provision Tradeoﬀ between reliablity and energy consumption, delay energy consumption and delay (Abidin, 2009).

Mobility management NEMO (Devarapalli, 2005), MANEMO (Wakikawa, 2007).

Security and privacy concern Security in wired and wireless networking, databases and data mining (Li and Das, 2009). 152 APPENDIX A. WSN PLATFORMS AND APPLICATIONS

Biomedical / Medical CodeBlue (Lorincz et al., 2004), ALARMNET (Wood et al., 2006), AMON (Anliker et al., 2004), GlucoWatch G2 (Dario et al., 2004).

Cognitive sensing Bioinspired sensing (Dario, 2004), Swarm intelligence, Quo- rum sensing.

Spectrum management Multiple frequencies for parallel communication, Self- Adaptive Spectrum Management (Zhou, 2009). item[Underwater acoustic sensor systems] Oceanographic data collection, pollution monitoring, disaster prevention, assisted navigation, tactical surveillance (Akyildiz, 2005).

Coordination in heterogeneous networks Connecting the WSN with heterogeneous network, Gateway based interconnection and overlay based interconnection (Liutkevicius, 2010).

Sensing based cyberphysical systems Collision avoidance, robotic surgery and nanolevel manufacturing, search and rescue operation, air traﬃc control, healthcare monitoring.

Time-critical applications Real time applications like ﬁre monitoring (Zeng, 2010), border surveillance (Doumit, 2002), medical care, and highway traﬃc coordination(Chinrungrueng, 2006).

Experimental systems and new applications WSNs for Oil & Gas, Mon- itoring Wildlife Passages (Sanchez, 2010),Fire Hazard Monitoring (Zeng, 2010), NEURON, Wireless Multimedia Sensor Networks (Alaei, 2010).

New models and architectures EAWNA (Liu, 2010), Cubic and CrossLayer (CCL) (Lin, 2007), WASP) (Lukkien, 2008). A.2. WSN PLATFORMS 153

A.2 WSN Platforms

Several sensor node platforms have been developed since 1999, when the ﬁrst sensor node tiny devices appeared.

(a) WeC (b) René/René 2 (c) Dot

(d) Mica/Mica2 (e) Mica2Dot (f) Telos Imote2 HIGH-PERFORMANCE WIRELESS SENSOR NETWORK NODE

• Marvell PXA271 XScale® Processor at 13 – 416MHz

• Marvell Wireless MMX DSP Coprocessor

• 256kB SRAM, 32MB FLASH, 32MB SDRAM

• Integrated 802.15.4 Radio (g) TmoteImote2 Sky (h) Imote2 (i) Scatterweb • Integrated 2.4GHz Antenna, Optional External SMA Connector The Imote2 is an advanced wireless sensor The processor also supports numerous timers node platform. It is built around the as well as a real time clock. The PXA271 • Multi-color Status Indicator LED low-power PXA271 XScale CPU and also includes a wireless MMX coprocessor to integrates an 802.15.4 compliant radio. The accelerate multimedia operations. It adds • USB Client With On-board mini-B design is modular and stackable with interface 30 new media processor (DSP) instructions, Connector and Host Adapters connectors for expansion boards on both the support for alignment and video operations and compatibility with Intel MMX and SSE • Rich Set of Standard I/O: 3xUART, top and bottom sides. The top connectors integer instructions. For more information 2xSPI, I2C, SDIO, GPIOs provide a standard set of I/O signals for basic expansion boards. The bottom connectors on the PXA271, please refer to the Marvell • Application Specific I/O: I2S, AC97, provide additional high-speed interfaces datasheet. Camera Chip Interface, JTAG for application specific I/O. A battery board supplying system power can be connected to Radio & Antenna • Compact Size: either side. The Imote2 uses the CC2420 IEEE 802.15.4 36mm x 48mm x 9mm radio transceiver from Texas Instruments. The Processor CC2420 supports a 250kb/s data rate with Applications The Imote2 contains the Marvell PXA271 16 channels in the 2.4GHz band. CPU. This processor can operate in a low The Imote2 platform integrates a 2.4GHz • Digital Image Processing voltage (0.85V), low frequency (13MHz) surface mount antenna which provides a mode, hence enabling very low power (j) XBee • Condition Based Maintenance nominal range of about 30 meters. For operation. The frequency can be scaled from Figure A.1:longer range WSN a SMA connector Platforms can be • Industrial Monitoring and Analysis 13MHz to 416MHz with Dynamic Voltage soldered directly to the board to connect to Scaling. The processor has a number of • Seismic and Vibration Monitoring an external antenna. different low power modes such as sleep and deep sleep. The PXA271 is a multi- Power Supply chip module that includes three chips in a Block Diagram The Imote2 can be powered by various Antenna single package, the CPU with 256kB SRAM, GPIOs means: 802.15.4 32MB radio FLASH 2x SPI 32MB SDRAM and 32MB of FLASH memory. SMA 3x UART Primary Battery: This is typically I2C It integrates many I/O options making it I/O SDIO extremely flexible in supporting different accomplished by attaching a Crossbow XScale 32MB USB host Imote2 Battery Board to either the basic CPU core SDRAM USB client sensors, A/Ds, radios, etc. These I/O features AC’97 include I2C, 2 Synchronous Serial Ports (SPI) or advanced connectors. 256kB SRAM Camera I2S one of which is dedicated to the radio, 3 high XScale DSP Power speed UARTs, GPIOs, SDIO, USB client and Mgt. RTC host, AC97 and I2S audio codec interfaces, a JTAG Supply Battery Changer fast infrared port, PWM, a Camera Interface and a high speed bus (Mobile Scaleable Link).

Document Part Number: 6020-0117-03 Rev A

Phone: 408.965.3300 Fax: 408.324.4840 E-mail: [email protected] Web: www.xbow.com 154 APPENDIX A. WSN PLATFORMS AND APPLICATIONS kbaud Table A.1: WSN Platforms chip bus freq RAM ﬂash chip rate Year CPU Memory Radio Platform WeCRenéRené 2Dot 1999Mica 1999 2000Mica2DotMica 2 2002 2000 AT90LS8535Telos 2001 ATMEL8535Tmote 8 Sky bit ATmega163 2002BTnode 8 bit 2005 4 MHzMicaZ 16 2004 ATmega128L bit ATmega163 4 MHz ATmega128TIP — 8 700CM — bit 16DwaRF-168 bit — 8 ATmega128L bit 8 512 — — —XYZ MHz B TI MSP430 8 512 TI bit 8Imote2 B MSP430 MHz 32ScatterWeb 8 bit MHz 1 ATmega1281 16 KB 4KB — bit 8 8 — MHz KB TI 2007 8 MSP430 8 bit MHz 4KB 8 MPR2400CA ATmega168 1 KB KB 4KB 8 8 16 bit MHz bit 16 bit 16 10 KB 128 KB — KB TR1000 — — 2KB Intel TI PXA271 MSP430 128 ARM7TDMI TR1000 KB 16 KB 32 64 bit KB 128 16 KB bit 32 CC1000 TR1000 48 13–416 bit KB MHz — 10 Kbps 8 TR1000 60 32 MHz KB MB 10 10 TR1000 KB 512 16 Kbps KB KB CC1000 128 KB 38.4 CC2420 10 Kbps Kbps 2 32 CC2420 KB 40 MB 128 Kbps 48 KB ZV4002 KB 16 10 512 KB Kbps KB 38.4 Kbps 250 Kbps CC2420 MPR2400CA 250 60 CYWUSB6935 Kbps KB CC2420 256 723.2 KB Kbps > 250 62.5 kbps kbps 250 CC1020 Kbps CC2420 250 kbps 19.2/38.2 250 kbps Appendix B

Routing

B.1 Counting to inﬁnity problem

The counting to inﬁnity problem occurs when the state of nodes in the network force to update the state of each other in a loop. A classical example of this situation is showed in the ﬁgure B.1

Figure B.1: Exaple of counting to inﬁnity scenario

In this scenario, nodes A, B, C, and D make a network. The arrows represent bidirectional links between the nodes. In particular, the link between the nodes C and D is broken, and the node A is not updated on the fact that its route to D via C is broken. Node A has a registered route to D with cost of 2 hops. Node C has registered that the link to D is broken. Node B is updated on the link breakage between C and D, so it will calculate the shortest path to D via A using a metric of 3 hops. Node C registers that B can reach D in 3 hops and updates its metric to 4 hops. Node A registers an update in hop-count for its route to D via C, so it updates its metric to 5 hops. Nodes continue to increment their metric in a loop. 156 APPENDIX B. ROUTING

B.1.1 Count to infinity and AODV AODV avoids the “counting to infinity” problem from the classical vector algorithm by using sequence numbers for every particular route. By using these sequence numbers node B notifies that A’s route to D is old, so node B will discard the route and C will be the node with the molst recent routing information by which B will update its routing table.

B.2 Multipoint Relaying

Flooding is a mechanism to disseminate messages throughout all the network. In its simplest form, all nodes retransmits received packets but it is not the most appropiate technique in most of the cases. To avoid loops, a sequence number is usually carried in such packets. If a node receives a packet with a sequence number lower or equal than the most updated and retransmitted packet from the sender, the packet is not retransmitted. On wired networks other optimizations are usually added such as no retransmission on the interface on which a packet arrived. On a wireless multi-hop network however, it is essential that nodes retransmits packets on the same interface that it arrived. This again causes every re-transmitter to actually receive a duplicate packet from every symmetric neighbor that re-transmits the packet. Figure B.2 shows a flooding scenario in a wireless network. As said before, every transmission leafs to a reception of the same packet. In that case, the flooding technique is a simple broadcast retransmission of the packets received. If n is the number of nodes, the number of retransmissions in the whole network is n − 1. Of course, many nodes receive the packet from different nodes, so this flooding technique can be optimized.

Figure B.2: Flooding a packet without optimization

In that way, MultiPoint Relaying reduces the number of retransmissions. Given the network topology, only a few subset of nodes are chosen to retransmit the B.2. MULTIPOINT RELAYING 157 packets so every node in the network receives a copy of the packet in an efficient way (that could mean optimizing costs). Figure B.3 shows an optimized flooding scenario where the MPR technique has been applied. The center node starts transmitting a packet to the network. Only black nodes retransmit the packet by flooding, meanwhile the other nodes only receive it. All the nodes have a neighbor which retransmit the packet.

Figure B.3: Flooding a packet using MPR

By using MPR optimization, the number of retransmissions sent to the network can decrease drastically. For example, in the previous example, the number of retransmissions of the packet decreased from 24 to only 4. This implies fewer collissions and fewer monopolization of the medium, which can lead to higher success rates of the transmission of the packet. A part from that, by needing less retransmissions implies an important and important energy saving in the nodes.

Appendix C

The Contiki Environment

C.1 Operating Systems Summary

Several functional operating systems for sensor nodes exist. Tables C.1 and 4.1, taken from [17], compare ﬁve of the most extended OS for tiny networked devices. Beyond the analyzed OS, few of them provide support for real-time application, perhaps due to strong constraints of power and performance in these kinds of devices. The earlier WSN operative systems emphasized on using an event driven programming paradigm. However, more contemporary OSs do support the threading based programming model, and perhaps the reason is because de- velopers are more familiar with threading based programming paradigm rather than the event-driven model.

C.2 Contiki OS

C.2.1 Introduction

Contiki is a lightweight open source operative system written in C for WSN sensor networks and networked embedded systems. Contiki is primarily designed for networking applications, but can be used for any other application using only its event driven kernel. Contiki provide standard OS features like threads, timers, random number generator, clock, a file system and a command line shell. It includes an IPv4 stack (the original uIP stack), TCP and UDP support, as well as the Rime radio communication stack. Its latest version support IPv6 stack. Contiki is designed for microcontrollers with small amounts of memory. A typical Contiki configuration consumes 2 kilobytes of RAM and 40 kilobytes of ROM. 160 APPENDIX C. THE CONTIKI ENVIRONMENT SupportReal-time for Applications No No To sometent at ex- process scheduling level (Implementatio n ofscheduling priority within different processes types) Yes No Resource Shar- ing and Completion Events cess Through Semaphores. Serializedcess ac- mutexes through semaphores. and Provideimplementation of an Priority Ceil- ing Algorithm forinversion. priority Throughchronization syn- primitives Communication Protocolport Sup- Active Message Virtualization uIP and Rime Serialized Ac- At Kernel Level COMMNetworking layer. Layeruser isApplication at is level. freecustom to routing protocols. use Socketabstraction for networking like File based communication agementProtection and Management withprotection memory Dynamic mem- oryment and manage- link- ing. No process addressprotection. space Dynamic mem- oryment supported manage- butdiscouraged, useno is protection. memory Static Memory Management and No memory protection Dynamic mem- oryment manage- provides and memory it protection to processes. Scheduling MemoryFIFO Man- Static Memory Events are fired as theyInterrupts occur. execute w.r.t.ority pri- classes and fur- therin priorities each priority class. tonic andharmonized rate scheduling Priority based RoundScheduling Robin Table C.1: Operating Systems Summary. model Driven, support for TOS threads has been added and events Events OS/ Feature Architecture Programming TinyOS Monolithic Primarily event Contiki Modular Protothreads MANTIS Layered Threads Five priority Nano–R K Monolithic Threads Rate Mono- LiteOS Modular Threads and C.2. CONTIKI OS 161

A full Contiki installation includes features like: multitasking kernel, preemptive multithreading, protothreads, TCP/IP networking, IPv6, a Graphical User Inter- face, a web browser, a personal web server, a simple telnet client, a screensaver, and virtual network computing. A typical device running Contiki OS is provided with a wireless low-power communications device such as an IEEE 802.15.4 CC2420 chip, a set of sensors, and a battery. Some typical microcontrollers suitable for using Contiki are MSP430, AVR Atmega, or ARM Cortex M3.

C.2.2 Architecture

Contiki consists of several independent modules such as an event-driven thread- like multitasking environment with the protothread library, the uIP TCP/IP (v4 and v6) stack, the wireless sensor network set of protocols: the Rime stack. The Contiki OS follows the modular architecture. At the kernel level it follows the event driven model, but it provides optional threading facilities to individual processes. The Contiki kernel comprises of a lightweight event scheduler that dispatches events to running processes. Process execution is triggered by events dispatched by the kernel to the processes or by a polling mechanism. The polling mechanism is used to avoid race conditions. Any scheduled event will run to completion, however, event handlers can use internal mechanisms for preemption. Two kinds of events EW supported by Contiki OS: asynchronous events and synchronous events. The diﬀerence between the two is that synchronous events are dispatched immediately to the target process that causes it to be scheduled. On the other hand asynchronous events are more like deferred procedure calls that are en-queued and dispatched later to the target process. The polling mechanism used in Contiki can be seen as high-priority events that are scheduled in between each asynchronous event. When a poll is scheduled, all processes that implement a poll handler are called in order of their priority. All OS facilities e.g., senor data handling, communication, and device drivers are provided in the form of services. Each service has its interface and implementation. Applications using a particular service need to know the service interface. An application is not concerned about the implementation of a service. Figure 3 shows the block diagram of the Contiki OS architecture, as given in [19].

Events

The Contiki kernel is event-driven: events are posted to processes, and processes execute them until they block waiting for another event. A entire application (kernel + libraries + user code) may contain several processes that will execute concurrently for some time, then wait for events to happen (a process is said to INFORMATION PAPER International Journal of Recent Trends in Engineering, Vol. 1, No. 2, May 2009

x TinyOS uses multi-hop routing instead of point-to-point connections to save transmission power. Route x TinyOS has a Single Stack: TinyOS uses a simple discovery is done by 2-hop broadcast and topology queue with length 7 and a two level scheduling. discovery is based on shortest path from each node to Therefore, all I/O operations that last longer than a few the base station. hundred microseconds are asynchronous and have a x The paradigm for network transmissions in TinyOS is callback. A TinyOS component can post a task, which active messaging. Messages contain a handler address the OS will schedule to run later. and on arrival this handler is called. x To support larger computations, TinyOS provides tasks, which are similar to a Deferred Procedure Call and x 3.1.2 TinyOS Architecture interrupt handler bottom halves.

Main Latest version of TinyOS has numerous improvements such (includes Scheduler) as: Safe TinyOS, a compile-time option that lets us incorporate run-time memory safety checks into oour Application (User Components) application, TOSThreads, a threading library that runs on top of a standard TinyOS core etc. Active Message Actuating Sensing 3.2 Contiki Communication

Contiki is a memory-efficient open source operating system Sensor Node(Mote) for networked embedded devices. Contiki provide standard Hardware OS features like threads, timers, random number generator, Fig. 1: Simplified TinyOS Architecture clock, a file system and a command line shell. It includes an x Component Based Architecture: enables rapid IPv4 stack (the original uIP stack), TCP and UDP support, innovation and implementation while minimizing code as well as the Rime radio communication stack. It’s latest size as required by the severe memory constraints version support IPv6 stack. inherent in sensor networks. x Small footprint: fits in 178 Bytes of memory. 3.2.1 Contiki Features x Event based instead of threaded architecture. x Event-driven Kernel: reduce the size of the system.

APPLICATION x Preemptive multi-threading support: an application library that runs on top of the event-driven kernel is

start stop fired optionally linked with applications that explicitly require a multithreaded model of computation. 162 APPENDIX C. THE CONTIKI ENVIRONMENT TIMER x Simulator: COOJA start and stop are commands. x Written in ‘C’ Language. fired is a event invoked by Timer. The interface specifies: Timer must implement start 3.2.2 Contiki Architecture and stop, Application must implement fired.

o Propagates events in time it takes to copy 1.25 Contiki Operating Node Management Bytes. System o Switches context in the time to copy 6 Bytes of Memory. x Radio and Clock have interrupts. x Non-blocking/Non-preemptive Scheduling: Tasks will not preempts other tasks and run in FIFO order but only interrupts and associated events can preempt tasks. To Application-1 Application-2 Application-N avoid blocking scenarios, events and commands are Sensor Data Manager Code Updater Sensor Configurator Network Configurator expected to do only state transmissions and leave complex computations to tasks that can be preempted if Contiki Core necessary. This simple concurrency model is typically uIP Loader ProtoThreads sufficient for I/O centric applications, but its difficulty with CPU-heavy applications has led to several

proposals for incorporating threads into the OS. Driver

Non-Preemptive Task Scheduler in TinyOS Radio CPU Sensors Oscillator Others High Priority tasks Low High are enqueued, but Priority Priority miss their deadlines Hardware

be blocked). When an event happens, the kernel execute the process passing it information about the event. Events can be classiﬁed in three kinds, indicated in table C.2.

Event Type Description Example of use timer events A process will block until a periodic actions, or for net- timer expires (generates an working protocols e.g. in- event) and then continue its volving synchronization execution external events A process will wait periph- a push-button, a radio chip or eral devices connected to the a shock detector accelerome- microcontroller to generate ter events when triggering inter- ruptions internal events a process address events to interprocess communication any other process, or itself as informing a process that data is ready for computation

Table C.2: Type of events and examples of use.

The kernel supports two kinds of events: asynchronous and synchronous. Syn- chronous events are dispatched immediately to the target process that causes it to be scheduled. On the other hand asynchronous events are more like deferred procedure calls that are en-queued and dispatched later to the target process. Events have the following information: C.2. CONTIKI OS 163

process the process(es) addressed by the event.

event type the type of event. The user can deﬁne some event types for the processes to diﬀerentiate them, such as one when a packet is received, one when a packet is sent;

data additionally, some data may be provided along with the event for the process.

C.2.3 Processes Processes are the task-equivalent of Contiki. A process will contain most likely an inﬁnite loop and some blocking macro calls. Each process when executed will run until it blocks for an event. Listing C.1 shows a simple Contiki process code example.

Listing C.1: Example Process Code

1 /* The PROCESS() statement defines the process’ name.*/ 2 PROCESS(my_example_process,"My example process"); 3 /* The AUTOSTART_PROCESS() statement selects what process(es) 4 to start when the module is loaded.*/ 5 AUTOSTART_PROCESSES(&my_example_process); 6 /* The PROCESS_THREAD() contains the code of the process.*/ 7 PROCESS_THREAD(my_example_process,ev,data) 8 { 9 /* Do not put code before the PROCESS_BEGIN() statement- 10 such code is executed every time the process is invoked. */ 11 PROCESS_BEGIN(); 12 /* Initialize stuff here.*/ 13 while(1) 14 { 15 PROCESS_WAIT_EVENT(); 16 /* Do the rest of the stuff here.*/ 17 } 18 19 /* The PROCESS_END() statement must come at the end of the 20 PROCESS_THREAD().*/ 21 PROCESS_END(); 22 }

This code is a template to start coding a process. Its basic components are:

• The PROCESS() statement deﬁnes a process name and a string to associate to it (for example, in debugging messages). 164 APPENDIX C. THE CONTIKI ENVIRONMENT

• The AUTOSTART_PROCESS() statement selects what process(es) to start when the module is loaded.

• The PROCESS_THREAD() contains the code of the process

• A process must be described between the macros PROCESS_BEGIN() and PROCESS_END(). • Most commonly, a process waits for events to happen. One way to implement this it by calling the macro PROCESS_WAIT_EVENT()

Contiki processes carry some limitations when programming. Local variables are not preserved. Thus, the local variables value are not guaranteed to hold the same value after some jumps (caused to function calls, events, macros, etc.). A good way to solve that is to use static variables. Protothreads use local continuations to ﬁnd their state back after returning, which is done using a switch statement. Thus, using switch statements inside a process function can cause to mix up with another switch statements. A good way to solve that is not to use switch statements.

C.2.4 Layer Structure in Contiki Contiki gives support for using IP Layer (and IP addresses) or, instead of it, using the rime library. The rime library brings support for optimised communication specially in sensor networks. For example, has specific procedures for broadcasting, flooding, unicasting messages as well as comunicating in a mesh network via multihop. uIP TCP/IP stack Contiki contains a lightweight TCP/IP stack called uIP. It is very optimized, only the required features are implemented. For instance there is a single buffer for the whole stack, used for received packets as well as for those to send. uIP stack implements RFC-compilant IPv4, IPv6m, with TCP and UDP support for IPv4 and IPv6).

Application API Contiki supports two ways to program an application on top of the uIP stack: raw API The uIP raw API is desirable when implementing one simple application, but more complex to program when a more rich application is desired. protosocket API The protosocket library makes use of the protothread library for having a more ﬂexible way to program TCI/IP applications. C.2. CONTIKI OS 165

Lower Layers

Having a functional TCP/IP stack and some applications running on top of it is good,but not enough. The uIP stack requires a lower layer (according to the OSI model) in order to communicate with peers. WeâĂŹll distinguish two diﬀerent types of peers: nodes communication between nodes is achieved with a wireless link. The uIP stack needs to be able to send and receive packets. Depending on the uIP version, Contiki follows diﬀerent directions.

• When it comes to IPv6, Contiki chose to follow a route-over conﬁgu- ration. Therefore, uIPv6 uses a simple MAC layer called sicslowmac. Besides header compression provided by the 6loWPAN module, it just forwards the packet to/from the radio. • However, for IPv4, Contiki chose a mesh-under conﬁguration. This is done with the Rime communication stack. Rime provide mesh routing and route discovery, therefore uIP uses it to forward packets on the network. From the IP point of view, all the nodes of the sensor network form a local subnetwork, even though multiple radio hops may be required.

Gateways to reach a network entity outside the wireless sensor network, a gateway is required to make the link between the wireless sensor network and another network. It will be a PC in most experiments, although it could be many embedded system. The conection between a PC and a mote is a serial link. IP packets are sent between the two using SLIP, which stands for Serial Line IP. Depending on the uIP stack version, the functionality is not the same:

• With uIPv6, a node will be loaded with a very simple program that forwards every packet from the radio to the serial link an vive versa. The PC does all the work. • With uIPv6 it works diﬀerently. The node connected to the PC will act as a gateway, with all the IP stack in it.

Rime stack

The Rime stack provides a solution to communicate between nodes in a simpliﬁed and eﬀective lightweight sense. It supports routing and multihop communication in mesh networks. Its libraries are modular, and more complex modules make use of the simpler ones. Instead, the Rime stack contemplates MAC and Transport OSI layers. 166 APPENDIX C. THE CONTIKI ENVIRONMENT

Figure C.2: Rime hierarchy and organization

Figure C.2 shows the overall organization of the Rime protocols. A brief description of the main modules of Rime is given below. abc the anonymous broadcast. When called by an upper layer, it just sends a packet via the radio driver. When receiving a packet, it just passes them to the upper layer (usually the broadcast block). broadcast the identiﬁed broadcast. When called, it adds the sender address to the outgoing packet and passes it to the abc module. It also receives packets from the abc block. unicast This module adds a destination address to the packets, and passes it to the broadcast block. On the receive side, if the packet’s destination address doesn’t match the node’s address, the packet is discarded. stunicast the stubborn unicast. When asked to send a packet to a node, it sends it repeatedly until asked to stop. This module is used by the runicast one. runicast the reliable unicast. It sends a packet using the stunicast module waiting for an acknowledgement packet. After receiving, it stops the continuous transmission of the packet. polite and ipolite these two modules are almost identical. When a packet has to be sent in a given time frame, the module waits for half of the time, C.2. CONTIKI OS 167

checking if it has received the same packet it’s about to send. If it has, the packet is not sent, otherwise it sends the packet. This is useful for ﬂooding techniques to avoid unnecessary retransmissions. mutihop this module requires a route table function. When about to send a packet it asks the route table for the next hop and sends the packet to it using unicast. On the receive side, if the node is the destination then the packet is passed to the upper layer, otherwise it asks again the route table for the next hop and relays the packet to it.

MAC layer The uIPv6 stack uses a very simple MAC layer called “sicslowmac", and there is no real option here. However, the uIPv4 stack uses Rime as its immediately lower layer, which in turn uses a selectable MAC layer. There are a few MAC layers implemented in Contiki:

• the nullmac protocol, as its name may say does nothing but forwarding packets from the upper layer to the radio driver, and vice versa.

• the xmac protocol, which is a preamble sampling protocol, where nodes listen on the radio channel for a small amount of time, periodically.

• the lpp protocol, which is a probing protocol, where the nodes periodically send a small message saying they’re listening, they listen for a short time afterward and go back to sleep.

C.2.5 Software Development for Contiki Contiki programs are written in the C programming language. It consists of an event-driven kernel, on top of which application programs can be dynamically loaded and unloaded at run time. To ease software development and debugging, Contiki provides three simulation environments: the MSPsim emulator, the Cooja cross-layer network simulator, and the netsim process-level simulator. The development process for software for Contiki typically goes through all three simulation stages before the software runs on the target hardware.

C.2.6 Routing in Contiki OS Contiki uses AODV as default routing protocol in the Rime stack. Recent versions of Contiki provides support for RPL in 6LoWPAN.

Appendix D

Simulations documentation

D.1 Sensor nodes code

Sensor nodes used in simulations are loaded with Contiki operating system. This version of Contiki is modiﬁed to use LOADng as its routing protocol. There are two types of nodes, depending on their function at the application layer: the root node and the leaf node.

D.1.1 Root Node Type The root node is used in simulations to generate data packet traﬃc. It is usually placed in the center of the network, and it sends a data packet all the other nodes sequentially in intervals of 30 seconds. The code of root nodes, at application layer, is shown in listing D.1.

Listing D.1: Root Node Code for simulations

1 #include "contiki.h" 2 #include "net/rime.h" 3 #include "net/rime/mesh.h" 4 5 #define NUM_NODES_SIMULATION 113 6 static struct mesh_conn mesh; 7 /*------*/ 8 PROCESS(root_mesh_process, "Root mesh process"); 9 AUTOSTART_PROCESSES(&root_mesh_process); 10 /*------*/ 11 static void sent(struct mesh_conn *c) 12 {/*function called upon senda packet*/} 13 static void timedout(struct mesh_conn *c) 170 APPENDIX D. SIMULATIONS DOCUMENTATION

14 {/*function called when timedout to senda packet*/} 15 static void recv(struct mesh_conn *c, const rimeaddr_t *from, uint8_t hops) 16 {/*function called when receivinga data packet*/} 17 /*------*/ 18 const static struct mesh_callbacks callbacks = {recv, sent, timedout}; 19 /*------*/ 20 PROCESS_THREAD(root_mesh_process, ev, data) 21 { 22 static unsigned int i; 23 rimeaddr_t addr; 24 static struct etimer et; 25 static char payload[100] = "Payload message container"; 26 27 PROCESS_BEGIN(); 28 mesh_open(&mesh, 132, &callbacks); 29 30 /*set node addr to 1.0*/ 31 addr.u8[0] = 0x01; addr.u8[1] = 0; 32 rimeaddr_set_node_addr(&addr); 33 34 /*wait until all nodes are setup*/ 35 etimer_set(&et, CLOCK_SECOND * 15); 36 PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et) ); 37 i=2; 38 /*send data packets sequentially to all other nodes*/ 39 while(i<=NUM_NODES_SIMULATION){ 40 addr.u8[0] = i; 41 /* Trying go communicate to node#i*/ 42 packetbuf_copyfrom(payload , 100); 43 mesh_send(&mesh, &addr); 44 i++; 45 /*wait to receive data ACK and to delete all routes*/ 46 etimer_set(&et, CLOCK_SECOND * 30); 47 PROCESS_WAIT_EVENT_UNTIL(etimer_expired(&et) ); 48 } 49 PROCESS_END(); 50 } 51 /*------*/

Root nodes use the Contiki mesh stack, and sends a data packet to the destination in a multi-hop sense. The root node id is set to 1 (there is only one root node in each simulation), and the data packet size is set to 100 octets. Each time a data packet is wanted to be sent, the LOADng route-discovery procedure is initialized by a lower layer. D.1. SENSOR NODES CODE 171

D.1.2 Leaf Node Type

Leaf nodes are deployed in simulations to receive data packets from the root node. Upon receiving a data packet, they reply with a data acknowledgement. The code of leaf nodes, at application layer, is shown in listing D.2.

Listing D.2: Leaf Node Code for simulations

1 #include "contiki.h" 2 #include "net/rime.h" 3 #include "net/rime/mesh.h" 4 5 static struct mesh_conn mesh; 6 /*------*/ 7 PROCESS(son_mesh_process, "Leaf mesh process"); 8 AUTOSTART_PROCESSES(&leaf_mesh_process); 9 /*------*/ 10 static void sent(struct mesh_conn *c) 11 {/*function called upon senda packet*/} 12 static void timedout(struct mesh_conn *c) 13 {/*function called when timedout to senda packet*/} 14 static void recv(struct mesh_conn *c, const rimeaddr_t *from, uint8_t hops) 15 {/*function called when receivinga data packet*/ 16 char buf[11] = "Acknowledge"; 17 packetbuf_copyfrom(&buf, 11); 18 mesh_send(&mesh, from); 19 } 20 /*------*/ 21 const static struct mesh_callbacks callbacks = {recv, sent, timedout}; 22 /*------*/ 23 PROCESS_THREAD(leaf_mesh_process, ev, data) 24 { 25 PROCESS_EXITHANDLER(mesh_close(&mesh);) 26 PROCESS_BEGIN(); 27 /*Cooja automatically sets node addresses sequentially*/ 28 mesh_open(&mesh, 132, &callbacks); 29 while(1){ 30 PROCESS_WAIT_EVENT_UNTIL(ev == sensors_event); 31 } 32 PROCESS_END(); 33 } 34 /*------*/

Leaf nodes use the Contiki mesh stack. When receiving a data packet, a callback routine is called, which sends back a data acknowledgement of 11 octets. As 172 APPENDIX D. SIMULATIONS DOCUMENTATION the reverse route is installed during LOADng route discovery process, it is not necessary for the leaf node to discover the route towards the root node. The leaf nodes id are set automatically by Cooja simulator, starting by 2, so each node in the network has an unique identiﬁcation number.

D.2 LOADng parameters

LOADng can be adjusted with some parameters according to the characteristics of the network topology and usage. For the simulations of this thesis, LOADng has been set setup with the parameters shown in the following subsections.

D.2.1 route module parameters

LOADng route module manages three sets; the routing set, the blacklisted neighbor set, and the pending acknowledgement set. This module is set with the parameters shown in tables D.1.

Parameter Value NET_TRAVERSAL_TIME 2 seconds BLACKLIST_TIME 10 seconds METRICS 0 (hopcount) NUM_RS_ENTRIES 8 entries ROUTE_TIMEOUT 5 seconds

Table D.1: route module parameters

The Net Traversal Time is used by the route-discovery module to calculate the RTT of the network, and initiate a re-discover procedure or determine the failure of route-discovery procedure. The Blacklist Time determines the time a blacklisted neighbor maintain this state. The metrics type is set to 0, which corresponds to the hop-count metric. Despite it is not usually the best metric type, it is a good conﬁguration for simulations to test LOADng performance to discover optimal routes. The maximum number of routes stored in the LOADng router is determined by the Route_rs_entries parameter, which is set to 8 entries. Each route, when added or refreshed, is set with a lifetime of 5 seconds, given by the Route_timeout parameter. D.2. LOADNG PARAMETERS 173

D.2.2 route-discovery module parameters The route-discovery module is responsible to discover new routes. It is conﬁg- ured with the parameters shown in table D.2.

Parameter Value MAX_RETRIES 1 attempt METRICS 0 NUM_REQ_ENTRIES 8 MEAN_BACKOFF 100 milliseconds ROUTE_TIMEOUT 5 seconds RREP_ACK_TIMEOUT 0.1 seconds ROUTE_DISCOVERY_ENTRIES 8

Table D.2: route-discovery module parameters

The number of reattempts on discovering a route can be adjusted with the parameter Max_retries. For the simulation purposes there is no need to reattempt the route-discovery process, so this parameter is set to 1. In case that more than 1 attempt is configured, LOADng originator node must store some information of the RREQ packets originated. The maximum number of this entries is configured with the parameter Num_req_entries. If only one attempt is tried, this parameter don’t proceed. The Route_discovery_entries parameter indicates the number of entries the pending set must contain. The time waiting for a RREP–ACK packet is set with the RREP_ACK_timeout parameter, which is set to 0.1 seconds, long enough to receive such packet. RREQ packets are sent to the network with high probability of collision. For that reason, a backoff time when sending those packets is desirable. The backoff time in simulations is configured with the parameter Mean_Backoff, which indicates the mean of the backoff time for an uniform distribution.

Appendix E

Reference Manual

This chapter is a reference manual for all the work related to programming that have made possible the elaboration of this manuscript. This chapter covers the following points:

• Contiki OS development environment – i.e., Instant Contiki – installation.

• Contiki OS ﬁlesystem, and LOADng module installation.

• Contiki OS compilation.

• Cooja simulations.

• Simulations Data Analysis.

A detailed manual of using Contiki and Cooja simulator can be found in Contiki OS webpage [41] and its wiki [56].

E.1 Instant Contiki installation

Instant Contiki is an Ubuntu image with a set of preinstalled tools required for Contiki OS development. This tools include, e.g., the MSP430 complier toolset, the Cooja simulator, and the Contiki OS source ﬁles. Instant Contiki can be downloaded in Contiki web page [41], and can be loaded in a virtualization platform such as VMware [21]. 176 APPENDIX E. REFERENCE MANUAL

E.2 Contiki OS ﬁlesystem

Contiki OS has a wide documentation available on the web. This section focuses in the ﬁlesystem hierarchy of the rime stack.

Figure E.1: Contiki ﬁlesystem hierarchy.

Contiki OS filesystem is organized as follows in figure E.1. core The core/ folder contains the source files of the Contiki kernel. net The net/ folder contains source files related to network communication, such as the medium access techniques – in the mac/ folder —, the Rime stack – in the rime/ folder –, or the ContikiRPL implementation of RPL – in the rpl/ folder, added in version 2.5 of Contiki OS –. rime The rime/ folder contains the source files associated with the rime stack. For example, it contains the mesh.h library for the mesh module, the route.h library for the route module, and the route-discovery.h header for the route-discovery module (see figure 4.1).

E.2.1 LOADng module installation

In order to replace Contiki OS Rime routing protocol – which is AODV – by LOADng, the following ﬁles must be modiﬁed: E.2. CONTIKI OS FILESYSTEM 177

route.h & route.c It is the core of the router. The route module contains the routing table and maintains its routes.

route-discovery.h & route-discovery.c The route-discovery module is used by the router, and provides a mechanism to discover new routes. The source code of the route and route-discovery modules must be mod- iﬁed to replace AODV protocol by LOADng protocol.

mesh.c The mesh module is responsible of routing packets in a multihop manner, via the multihop module. The source code of the mesh module only needs a small modiﬁcation: LOADng does not specify refreshing routes upon forwarding packets (only upon receiving). Thus, a line of code in the packet forward function must be commented, as shown in line 26 of listing E.1.

Listing E.1: modiﬁcation of data_packet_forward function in mesh.c

1 /*function called when forwardinga data packet*/ 2 static rimeaddr_t * 3 data_packet_forward(struct multihop_conn *multihop, 4 const rimeaddr_t *originator, 5 const rimeaddr_t *dest, 6 const rimeaddr_t *prevhop, uint8_t hops) 7 { 8 struct route_entry *rt; 9 struct mesh_conn *c = (struct mesh_conn *) 10 ((char *)multihop - offsetof(struct mesh_conn, multihop)); 11 12 rt = route_lookup(dest); 13 if(rt == NULL) { 14 if(c->queued_data != NULL) { 15 queuebuf_free(c->queued_data); 16 } 17 18 PRINTF("data_packet_forward: queueing data, sending rreq\n"); 19 c->queued_data = queuebuf_new_from_packetbuf(); 20 rimeaddr_copy(&c->queued_data_dest, dest); 21 route_discovery_discover(&c->route_discovery_conn, dest, PACKET_TIMEOUT); 22 23 return NULL; 24 } else { 25 /*The following line is commented because LOADng does not specify refreshing routes upon forwarding(only upon receiving)*/ 26 // route_refresh(rt); 178 APPENDIX E. REFERENCE MANUAL

27 } 28 29 return &rt->nexthop; 30 }

uip-over-mesh.c The uip-over-mesh module uses the IP stack instead of the Rime stack. The source code of the uip-over-mesh module only needs three little appre- ciations. First, when receiving a data packet from a neigbour from which there is no route in the routing table, a route to this neighbor is added with NULL cost – instead of cost = 10 in the default Contiki code, and sequence number −1 . This can be seen in lines 6–12 of listing E.2. Sec- ond, a LOADNG_PORT must be defined – either in the source header of the route-discovery.h file, or in the project Makefile. And third, IP packets received from the LOADNG_PORT must be sent to the route-discovery module as shown in lines 16–23 of listing E.2.

Listing E.2: modiﬁcation of recv_data function in uip-over-mesh.c

1 static void 2 recv_data(struct unicast_conn *c, const rimeaddr_t *from) 3 { 4 5 ... 6 7 /*This conditional is added to listen for LOADng packets*/ 8 if( UIP_HTONS((((struct uip_udpip_hdr *)&uip_buf[UIP_LLH_LEN]))-> srcport) == LOADNG_PORT ){ 9 // if the socket is for LOADNG connection 10 PRINTF("uip-over-mesh: sending packet to route discovery\n"); 11 route_discovery_packet_received(); 12 return; 13 } 14 15 ... 16 17 e = route_lookup(&source); 18 if(e == NULL) { 19 /*The following line is commented and replaced.A new route is added with SEQ_NUM= -1, and route_cost= NULL*/ 20 // route_add(&source, from, 10, 0); 21 route_add(&source, from, NULL, -1); E.3. CONTIKI OS COMPILATION 179

22 } else { 23 route_refresh(e); 24 } 25 26 ... 27 28 }

E.2.2 Working directory

The Contiki OS source directory should not be modified – i.e., the files contained in the contiki/ directory should not be deleted nor modified. Instead, all the modifications of Contiki OS source files and/or new source files required for the project – e.g., application-level files – are placed in a single working directory and referenced in the Makefile.

Figure E.2: Working project directory.

Figure E.2 shows an example of a working directory, containing the files implementing LOADng – listed in section E.2.1 –, the application-level files of the root node and the leaf nodes (see section D.1), and the Makefile (see section E.3). An example of a working directory The working directory contains

E.3 Contiki OS Compilation

Contiki’s compilation process is simpliﬁed to the developer by using a Makeﬁle.

E.3.1 Makeﬁle

The Makefile is a file stored in the working directory which contains useful information for the compiler. Listing E.3 shows an example of Makefile for the project of figure E.1. Within the information a Makefile can contain, the following keywords are described: 180 APPENDIX E. REFERENCE MANUAL

CONTIKI Speciﬁes the Contiki source directory path.

CFLAGS Compiler ﬂags specifying, e.g.:

DWITH_UIP Specifies the use of the uIP stack when enabled – 1 –, or the Rime stack when disabled – 0 –. In case of using the uIP stack, the use of IPv4 or IPv6 is specified in the boolean variable UIP_CONF_IPV6. DPROJECT_CONF Specifies the project configuration source file, if exist.

CONTIKI_PROJECT Lists the project ﬁles to compile.

PROJECT_SOURCEFILES Ads the contiki source ﬁles of in the working directory, which will replace the default ones in the CONTIKI source path.

The global variables value defined in the Makefile overload any other possible existing value of them defined in the source files. This Makefile in fact compliments another Makefile – stored in the CONTIKI source directory by default – which is, in fact, the Makefile containing a set of instructions to compile the contiki source.

Listing E.3: Makeﬁle corresponding to the working directory of ﬁgure E.2

1 #contiki source directory path 2 CONTIKI=../contiki 3 4 #using Rime stack (not uIP) 5 CFLAGS += -DWITH_UIP=0 6 #UIP_CONF_IPV6=0 7 8 #extra project config can be defined in source files 9 #CFLAGS += -DPROJECT_CONF_H=1 10 #CFLAGS += -DPROJECT_CONF_H=\"project-conf.h\" 11 12 #project files to compile 13 CONTIKI_PROJECT = application-root_node application -leaf_node 14 15 #project source files replacing Contiki default source code 16 PROJECT_SOURCEFILES += route.c route-discovery.c mesh.c 17 18 19 all: $(CONTIKI_PROJECT) 20 21 22 include $(CONTIKI)/Makefile.include E.4. COOJA SIMULATIONS 181

E.3.2 Compilation Contiki can be compiled for several platforms. The concrete platform can be speciﬁed in a separate ﬁle by running the command:

> make TARGET=sky SAVETARGET which generate the ﬁle Makefile.target storing the target type of the platform to which compile – in the example, the Tmote Sky. The contiki code is then compiled by running the common make commands, e.g.:

> make all

Alternatively, the make command and the target can be speciﬁed in a single command by:

> make TARGET=sky all

E.4 Cooja Simulations

Cooja simulator is located in

/tools/cooja

Cooja GUI can be run executing the following command in the Cooja’s path:

> ant run

Cooja project ﬁles – describing a simulation – have the .csc extension. Simula- tions can be run in command line – i.e., without GUI and saving system resources.

E.4.1 Massive simulations

It is possible to order Cooja to simulate all the .csc ﬁles located in the following directory:

/tools/cooja/contiki_tests

The command to order the simulation of all .csc ﬁles is:

> bash RUN_ALL 182 APPENDIX E. REFERENCE MANUAL

All simulations run sequentially by lexicographic order, and an output ﬁle – .log ﬁle – is generated for each simulation, containing the output messages of such simulation.

E.5 Simulations Data Analysis

Simulations output ﬁles contain string messages generated by contiki code and still don’t have an adequate format to be easily processed by Octave or other analytics software.

E.5.1 From string messages to numeric tables An script has been programed for this purpose: verbose_counter.c. This script reads the string messages of the log ﬁles and outputs a log ﬁle containing a table with numerical results – e.g., the route discovery time, the number of RREQ’s sent, the data transmission success. etc. – for each route discovery process.

E.5.2 From numeric tables to octave plots Several octave functions have been written to process the numeric tables cited in section E.5.1. These functions process the data, make statistics and output the plots of the result. These functions have self-explicative name, as well as a short description, and are collected in a main octave ﬁle. List of Algorithms

3.1 Identifying valid RREQ and RREP Messages...... 50 3.2 RREQ and RREP Common Processing algorithm...... 51 3.3 RREQ Processing algorithm...... 52 3.4 RREP Processing algorithm...... 53 3.5 RERR Processing algorithm...... 54 3.6 RREP–ACK Processing algorithm...... 54 3.7 RREQ Forwarding algorithm...... 55 3.8 RREP Forwarding algorithm...... 55 3.9 RERR Forwarding algorithm...... 56 List of Figures

1.1 Sensor Nodes (sensor + mote) forming a WSN ...... 2 1.2 Nodes standby cycle...... 5 1.3 Basic components of a sensor node...... 6 1.4 Schema of a sensor node...... 8 1.5 Platforms comparison ...... 8 1.6 Platforms comparison ...... 9 1.7 Health and medicine applications...... 11 1.8 Military sensor deployments...... 12 1.9 A WSN can track and alert from the state of traﬃc...... 12 1.10 Detail of sensor nodes installed in a zebra’s neck, for the ZebraNet project...... 13 1.11 WSN applications in risk prevention ...... 14 1.12 Domestic WSN envolving diﬀerent applications and devices ...... 15 1.13 Comparative of Wireless Standards...... 17 1.14 Front page of the MIT journal...... 20 1.15 People impact on WSN...... 20 1.16 People-per-computer evolution and future networks...... 21

2.1 Protocol stack for wireless sensor networks...... 23 2.2 Mesh-Under vs. Route-Over routing ...... 28 2.3 A example of wireless sensor network...... 32 2.4 DIO message broadcast by the root node...... 33 2.5 DIO message broadcast by the inmediate root node neighbors. . . . . 33 2.6 DIO message broadcast by the inmediate root node neighbors. . . . . 34 2.7 Final topology structure with selected parents for root node 0 . . . . . 34 2.8 DODAG structure with parents and preferred parents ...... 35 2.9 AODV route lookup session...... 37 2.10 ZRP scenario...... 39 2.11 ZRP components...... 39 LIST OF FIGURES 185

3.1 LOADng algorithm ﬂowchart...... 49

4.1 Rime Stack...... 61 4.2 Cooja graphical user interface and main plugins...... 63

6.1 Detail of Cooja simulation environment and node distribution. . . . . 88 6.2 Node transmitting range...... 89 6.3 Nodes distribution in simulated scenarios...... 90 6.4 LOADng performance with bad medium access backoff...... 94 6.5 Backoff time effect in route discovery success rate...... 95 6.6 7-hop radius scenario, 1-hop routes: Success rate and number of hops . 97 6.7 7-hop radius scenario, 1-hop routes: Route discovery and convergence time...... 97 6.8 7-hop radius scenario, 1-hop routes: LOADng packet traffic ...... 98 6.9 7-hop radius scenario, 1-hop routes: Upload and download time . . . . 98 6.10 7-hop radius scenario, 2-hop routes: Success rate and number of hops . 99 6.11 7-hop radius scenario, 2-hop routes: Route discovery and convergence time...... 100 6.12 7-hop radius scenario, 2-hop routes: LOADng packet traffic ...... 100 6.13 7-hop radius scenario, 2-hop routes: Upload and download time . . . . 100 6.14 7-hop radius scenario, 3-hop routes: Success rate and number of hops . 101 6.15 7-hop radius scenario, 3-hop routes: Route discovery and convergence time...... 102 6.16 7-hop radius scenario, 3-hop routes: LOADng packet traffic ...... 102 6.17 7-hop radius scenario, 3-hop routes: Upload and download time . . . . 102 6.18 7-hop radius scenario, 4-hop routes: Success rate and number of hops . 103 6.19 7-hop radius scenario, 4-hop routes: Route discovery and convergence time...... 104 6.20 7-hop radius scenario, 4-hop routes: LOADng packet traffic ...... 104 6.21 7-hop radius scenario, 4-hop routes: Upload and download time . . . . 104 6.22 7-hop radius scenario, 5-hop routes: Success rate and number of hops . 105 6.23 7-hop radius scenario, 5-hop routes: Route discovery and convergence time...... 106 6.24 7-hop radius scenario, 5-hop routes: LOADng packet traffic ...... 106 6.25 7-hop radius scenario, 5-hop routes: Upload and download time . . . . 106 6.26 7-hop radius scenario, 6-hop routes: Success rate and number of hops . 107 6.27 7-hop radius scenario, 6-hop routes: Route discovery and convergence time...... 107 6.28 7-hop radius scenario, 6-hop routes: LOADng packet traffic ...... 108 6.29 7-hop radius scenario, 6-hop routes: Upload and download time . . . . 108 6.30 3-hop radius scenario, 1-hop routes: Success rate and number of hops . 110 186 LIST OF FIGURES

6.31 3-hop radius scenario, 1-hop routes: Route discovery and convergence time...... 111 6.32 3-hop radius scenario, 1-hop routes: LOADng packet traffic ...... 111 6.33 3-hop radius scenario, 1-hop routes: Upload and download time . . . . 111 6.34 3-hop radius scenario, 2-hop routes: Success rate and number of hops . 112 6.35 3-hop radius scenario, 2-hop routes: Route discovery and convergence time...... 113 6.36 3-hop radius scenario, 2-hop routes: LOADng packet traffic ...... 113 6.37 3-hop radius scenario, 2-hop routes: Upload and download time . . . . 113 6.38 3-hop radius scenario, 3-hop routes: Success rate and number of hops . 114 6.39 3-hop radius scenario, 3-hop routes: Route discovery and convergence time...... 115 6.40 3-hop radius scenario, 3-hop routes: LOADng packet traffic ...... 115 6.41 3-hop radius scenario, 3-hop routes: Upload and download time . . . . 115 6.42 Network Radius Influence: Success rate and number of hops ...... 117 6.43 Network Radius Influence: Route discovery and convergence time . . . 117 6.44 Network Radius Influence: LOADng packet traffic ...... 118 6.45 Tmote Sky platform, 1-hop routes: Success rate and number of hops . 120 6.46 Tmote Sky platform, 1-hop routes: Route discovery and convergence time...... 120 6.47 Tmote Sky platform, 1-hop routes: LOADng packet traffic ...... 120 6.48 Tmote Sky platform, 1-hop routes: Upload and download time . . . . 121 6.49 Tmote Sky platform, 2-hop routes: Success rate and number of hops . 122 6.50 Tmote Sky platform, 2-hop routes: Route discovery and convergence time...... 123 6.51 Tmote Sky platform, 2-hop routes: LOADng packet traffic ...... 123 6.52 Tmote Sky platform, 2-hop routes: Upload and download time . . . . 123 6.53 Tmote Sky platform, 3-hop routes: Success rate and number of hops . 124 6.54 Tmote Sky platform, 3-hop routes: Route discovery and convergence time...... 125 6.55 Tmote Sky platform, 3-hop routes: LOADng packet traffic ...... 125 6.56 Tmote Sky platform, 3-hop routes: Upload and download time . . . . 125 6.57 MicaZ platform, 1-hop routes: Success rate and number of hops . . . . 126 6.58 MicaZ platform, 1-hop routes: Route discovery and convergence time . 127 6.59 MicaZ platform, 1-hop routes: LOADng packet traffic ...... 127 6.60 MicaZ platform, 1-hop routes: Upload and download time ...... 127 6.61 MicaZ platform, 2-hop routes: Success rate and number of hops . . . . 128 6.62 MicaZ platform, 2-hop routes: Route discovery and convergence time . 129 6.63 MicaZ platform, 2-hop routes: LOADng packet traffic ...... 129 6.64 MicaZ platform, 2-hop routes: Upload and download time ...... 129 6.65 MicaZ platform, 3-hop routes: Success rate and number of hops . . . . 130 LIST OF FIGURES 187

6.66 MicaZ platform, 3-hop routes: Route discovery and convergence time . 130 6.67 MicaZ platform, 3-hop routes: LOADng packet traffic ...... 131 6.68 MicaZ platform, 3-hop routes: Upload and download time ...... 131 6.69 Platform Influence: Success rate and number of hops ...... 132 6.70 Platform Influence: Route discovery and convergence time ...... 133 6.71 Platform Influence: LOADng packet traffic ...... 134 6.72 Random network deployment scenario ...... 135 6.73 Random Network Deployment: Success rate and number of hops . . . 136 6.74 Random Network Deployment: Route discovery and convergence time 137 6.75 Random Network Deployment: LOADng packet traffic ...... 137 6.76 Random Network Deployment: Upload and download time ...... 137

A.1 WSN Platforms...... 153

B.1 Exaple of counting to inﬁnity scenario ...... 155 B.2 Flooding a packet without optimization ...... 156 B.3 Flooding a packet using MPR...... 157

C.1 Contiki simpliﬁed kernel architecture...... 162 C.2 Rime hierarchy and organization ...... 166

E.1 Contiki ﬁlesystem hierarchy...... 176 E.2 Working project directory...... 179 List of Tables

1.1 Comparative between wireless technology standards...... 18 1.2 Evolution of sensor node platforms...... 19

3.1 LOADng packet format ...... 44 3.2 Encoding for the ﬁeld...... 45 3.3 TLV block...... 45 3.4 RREQ/RREP ﬁelds and initial values ...... 46 3.5 RERR message format...... 47 3.6 RREP–ACK message format ...... 47

4.1 Operating Systems comparative...... 60 4.2 Contiki modules for diﬀerent protocol stacks...... 60 4.3 LOADng debug messages ...... 66 4.4 Application level debug messages...... 66

5.1 route.h and route-discovery.h functions...... 71

6.1 Cooja simulation parameters ...... 88 6.2 Contiki parameters in simulated sensor nodes...... 91 6.3 LOADng parameters in simulated sensor nodes...... 92 6.4 Network Radius inﬂuence. Simulation parameters...... 96 6.5 LOADng conﬁguration for each platform...... 119

A.1 WSN Platforms...... 154

C.1 Operating Systems Summary...... 160 C.2 Type of events and examples of use...... 162

D.1 route module parameters...... 172 D.2 route-discovery module parameters ...... 173