Design and Implementation of an IPv6 Architecture for Wireless Sensor Networks

Transcription

1 an IPv6 Architecture for Wireless Sensor Networks Alexandre Sadones Spring, 2011 Master of Science Thesis Stockholm, Sweden 2011 TRITA-ICT-EX-2011:78

2 Master Thesis Design and Implementation of an IPv6 Architecture for Wireless Sensor Networks Author: Alexandre Sadones Examiner: Markus Hidell Supervisor: Mario Lopez-Ramos April 9, 2011

3 1

4 Abstract The Diaforus project is a collaborative initiative aiming at building a framework for in-network reasoning in a Wireless Sensor Network. The focus of this thesis is located between the network layer and the application layer, articulated in two distincts parts. The first part aims at providing an API for communication to the embedded application, that must be as simple as possible. Hence, the application needs not to have any knowledge about the network s topology. Thus, an IPv6-based network layer has been developed on top of the Wavenis API provided by Coronis, using an adaptation layer, 6LoW- PAN, in order to adapt the IPv6 standard to the constraints inherent to the WSNs, in particular reducing the power consumption of the nodes by compressing the IP headers. Moreover, a routing protocol, RPL, has been implemented, that also takes into consideration the optimization aspects of the network. Finally, the second part focuses on the design of an interface for the management and the monitoring of parameters on the node from a standard network. It has been realized through a RESTful architecture, optimized for WSNs using a newly specified protocol, CoAP. The adaptation to the HTTP standard RESTful environments is achieved using a simple gateway. 2

5 Acknowledgements In the first place, I would like to thank my supervisor at Thales Communications France, M. Lopez-Ramos. He provided me with the guidelines I needed to become an active member of the Diaforus project. He gave me the opportunity to get involved not only by setting up the communication stack used in the project, but also by attending meetings with the members of the project, from Telecom Paristech, LABRI and Coronis. I would also like to thank these partners. It has always been interesting working in the team, and my internship would probably not have been as exciting as it was without our debating sessions. I learnt a lot from this collaboration. I thank Markus Hidell, my teacher at Kungliga Tekniska Högskolan, that accepted to be my examiner for this Master Thesis, and Jean-Marc Steyaert, my examiner at Ecole Polytechnique. And last but not least, I thank all the members of TAI. I really had a great time with you in the past 6 months. I will remember all the breakfasts we shared, the poker games we played, and the heated discussions we had almost every day about everything. 3

6 Contents 1 Introduction Presentation of the company Thales TAI Introduction to the Diaforus Project Scientific Goals Focus of This Report Operating System and Data-link Layer Protocol Excelyo modules and Wavenis protocol Operating System Architecture Protocols and Implementation of the Stack The 6LoWPAN Adaptation Layer Low-Power and Lossy Networks Why 6LoWPAN? Dispatch Byte Header Compression Fragmentation and Re-assembly Neighbor Discovery Implementation of the Communication Stack in Excelyo Nodes Application Task Stack Task Interfacing the Application and Stack tasks with UDP IPv6 Routing Protocol for LLNs, RPL RPL Topology RPL Mechanism Routing using ContikiRPL REST Architecture and Node Management Interface CoAP: Constrained Application Protocol Header Format Gateway CoAP gateway CoAP Subscription Protocol Node Management on top of CoAP Results and expected developments Simulation Results Results on the Excelyo Modules Characteristics of the Ref Design Excelyo SoC IPv6/6LoWPAN on chip RPL on chip RESTful services on chip using CoAP Summary Proposition of a New Architecture Points taken into account in the design Brief presentation

7 6 Conclusions 46 A Vocabulary 49 B XML Configuration File Specification 51 C XML Configuration File for RPL Testing 52 D Demonstration Board used for testing 54 E Network Layer - Activity Diagram 55 F CoAP tests 56 G CoAP simulation, AJAX Web Page 57 5

8 List of Figures 1 Excelyo SoC Wake-up preamble mechanism Inter-task communication using queues LoWPAN Dispatch Byte Stateless Header Compression Context-Based Header Compression Node Registration The Wavenis stack architecture UDP architecture Example of RPL Network Startup Stack implementation - distribution between application and stack task CoAP Header CoAP Header Option Interconnection of Internet and LLNs in a RESTful environment Observer-Subscriber mechanism in CoAP CoAP Server: Activity Diagram Simulator Architecture RPL Testing in the Simulation Environment Emission rate of RPL packets Creation of an interface under Unix environments Sequence Diagram of the CoAP Gateway Analysis of the needs for memory in the network layer Alternative network architecture Activity Diagram of the Network/Transport Layers Implementation CoAP GET request test List of Tables 1 Possible values for the 6LoWPAN Dispatch Byte Stateless vs Context-based Header Compression

9 1 Introduction 1.1 Presentation of the company Thales Thales Group is one of the world leaders for missioncritical information systems mainly in the aerospace and space, defense and security core businesses. Technologies with both commercial and military uses have come to play a pivotal role, both strategically and economically. The Thales Groups dual technology capability is one of its most significant competitive advantages in todays market for total security solutions. With a workforce of about 68,000 employees in over 50 countries, Thales realized a turnover of 12.7 G. Thales Communications France, where this thesis was written, is part of Thales Land & Joint Systems, although it is a legal company. Land & Joint Systems is the Thales Division that brings together Thales activities in information and communications systems, optronics systems, ground surveillance radars, ground robotics and armaments. The majority of these activities were previously part of the Communications and Optronics business groups. The creation of this Division, with a strong Franco-British base, provides Thales Land customers with clear access to reinforced prime contractorship capabilities. It also reinforces Thales position as a proven international prime contractor and as the leading European company for Joint Operations in the domain of C4ISR: ˆ Communication, navigation and identification ˆ Surveillance of the electromagnetic spectrum ˆ Electronic command and information systems ˆ Naval and terrestrial communication systems ˆ Military communication networks ˆ Satellite-based radio communication ˆ Radio surveillance systems Furthermore, Land & Joint Systems draws synergies and added-value from its expertise in communications and optronics equipment, offering its Land, Air and Naval customers the benefits of a comprehensive approach, which is key to the effective tri-service integration and allied interoperability required in the field. Thales Communication France s headquarters are located in Colombes (near Paris) and the three manufacturing plants are situated at Laval, Cholet and Brive. Thales Communications employs a total of 5,400 employees. Thales Communications France is a major player in the field of tactical, airborne and naval communications. 7

10 Its activities in the field of electronics also cover the Intelligence / Surveillance / Reconnaissance segment for Joint services. In 2009, its sales amounted to M. Thales Communications France is a major supplier of information and communications systems to the French Land Forces. In addition, 30 % of its sales are to customers outside France TAI Within Thales Communications France, the TAI laboratory, which stands for Technologies Avances pour l Information (Advanced Information Technologies), is responsible for the development and evaluation of new technologies for the sector of computer science and networking. To fulfill those objectives, the role of TAI is threefold. Firstly, it has to study and evaluate technologies that rise in academic and industrial contexts. Secondly, it plays an important role by acting as a privileged intermediary between the company and the exterior world in order to facilitate the sharing of knowledge in the field of advanced technologies. Thirdly, TAI should do the same work as an external expertise group by structured and precise research reports, sharing its knowledge in the different research domains in order to support the decision-makers. For these reasons, the TAI laboratory is involved in leading European IT research projects on the design and specification of systems as well as security and telecommunication architectures. Hence, the laboratory is in touch with universities and other research companies and research laboratories in order to share knowledge and results in innovative technologies. The topics of the projects are very often placed, evaluated and enhanced in the context of mobile network infrastructures. 1.2 Introduction to the Diaforus Project The Diaforus project (DIstributed Applications and Functions Over Redundant Unattended Sensors) aims at creating new exploitation opportunities for networks of unattended, affordable wireless sensors through a distributed middleware that allows a cross-layer optimization of the infrastructure and an overall optimization of energy usage allowing longer sensor autonomy. The target application, area security surveillance whether of critical industrial facilities, crowded events, or country borders presently relies on highprecision and costly sensors generally connected with high-bandwidth links, strongly fitted, and carefully calibrated. With the commercial availability of tiny, long-lived, and affordable wireless sensors, surveillance systems using numerous unattended wireless sensors are being deployed, for many purposes: pollution surveillance in Stockholm for instance (presented in [6]) However, exploitable solutions coupling sensors with different kind of transducers in an autonomous, efficient, and flexible way are yet to appear. Diaforus takes advantage of the modal and spatial redundancy in the sensor networks where sensing ranges overlap to achieve higher accuracy and better reliability while enhancing the energy efficiency through an orchestration of the detection functions, an 8

11 appropriate distribution of in-network computing thus minimizing the amount of data exchanged. To achieve this optimization, Diaforus creates a novel middleware providing the support for in-network reasoning, allowing the direct cooperation between neighbor sensors as requested by real-time surveillance applications (monitoring, identification, and tracking), with a special emphasis on security of operations and an easy-to-manage and flexible on-the-fly configuration capability to redistribute rules and roles Scientific Goals The ultimate objective of this project is to develop a framework for in-network reasoning and cooperation in heterogeneous wireless sensor networks, where nodes can autonomously interpret the context and meaning of sensor data to infer high-level phenomena through filtering, aggregation and correlation. It is meant to constitute a reusable software base at the sensor, gateway and application level for the development of sensing solutions where complex autonomous processing is required. In such a complex environment, flexibility and management capabilities are major objectives: the Diaforus framework will provide the tools for network supervision, live fine-tuning of sensors and gateways, on-the-fly reconfiguration of the network intelligence behavior and definition of cooperative tasks. The Diaforus middleware will provide mechanisms for injecting application knowledge into the infrastructure and the sensor network. Applicationawareness will significantly improve the resource and energy efficiency in nodes, for example by application-specific aggregation at intermediate levels. This application knowledge will be situated in the knowledge plane which will be distributed and hierarchical in order to satisfy application requirements and take into account network elements constraints. In terms of non-functional objectives, the framework will integrate low-level energy optimization functions to achieve energy-aware reasoning and cooperation. Security is very energy-consuming: first because it implies computationally expensive tasks, such as encryption or integrity and authentication checks, secondly because it may involve additional communications in order to establish a shared security context (some commonly used algorithms and key exchange protocols are presented in [17]). It is however an essential aspect, especially in surveillance scenarios. Diaforus has the ambitious objective of using the cooperative reasoning framework to dynamically adapt security mechanisms to threats in order to deliver a cost-effective security and trust solution Focus of This Report The area covered by the Diaforus project is wide, from the hardware design of the wireless sensors and gateways, to the application level. The report focuses on two distinct parts : it deals first with networking issues such as IPv6 and 9

12 routing between the nodes, then with the RESTful architecture built on top of CoAP. 10

13 Design and Implementation of Figure 1: Excelyo SoC 2 Operating System and Data-link Layer Protocol 2.1 Excelyo modules and Wavenis protocol The project is based on the chip proposed by one of the industrial partners in the Diaforus project, Coronis, member of the Elster group (the company and its products are presented in [1]). This chip is part of the several Wavenis-enabled platforms developed by Coronis. The Wavenis protocol is a data-link protocol, that targets industrial automation and telemetry applications in particular. It is supported by the Wavenis Open Standard Alliance1 [5]. Technically speaking, Wavenis has been designed to be ultra-low power and with long-range capabilities. In the context of the Diaforus project, this technology is particularly interesting since it provides longer lifetime to the deployed node, and can be used in wide areas (for border surveillance applications for instance). It is a proprietary protocol, hence one cannot have a look to the practical implementation provided by Coronis. However, some informations characterizing Wavenis are listed hereafter: Designed for worldwide deployment, operating in 3 possible frequency bands: 868 MHz for Europe, 915 MHz for Americas, 433 MHz for Asia. Low bandwidth: 48 kbps (min) < 19.2 kbps (typical) < 100 kbps (max), 150 bytes MTU. Reliable radio communications: Frequency-Hopping Spread Spectrum, reducing the impact of interferences, Forward Error Correction, adding redundancy in the communication, 1 Involving for instance Elster, Orange, Veolia or Cisco 11

14 Data interleaving, Data scrambling, Acknowledgments. ˆ Secure radio communications: Optional data encryption (3DES, AES-128, RSA...). ˆ 6 bytes data-link addresses: easy to plug on libraries originally designed for Ethernet. ˆ CSMA/CA or TDMA communication mode In order to save as much power as possible, Wavenis-enabled nodes do not listen to the radio channel continuously. They work in duty cycles, divided in two periods : a sleeping period, which normally represents the major part of the cycle, and a listening period. If a node wants to send a packet to its neighbor, it must first send a wake-up preamble, in order to inform the destination node that a packet will be sent soon. As it is not useful but power consuming to wake up all the nodes within range, the preamble includes the MAC address of the destination node, and only the destination will wake up when receiving this preamble. Figure 2: Wake-up preamble mechanism 2.2 Operating System Architecture The operating system running on the Excelyo modules developed by Coronis is FreeRTOS (for Free Real Time Operating System, [2]). It is a very generic operating system coded in C, that revolves around the idea of parallel tasks sharing CPU time using a system of task priorities. The version proposed for the module has 3 parallel tasks : the highest priority task is dedicated to network functionalities, the middle priority task is dedicated to the application, and finally, the lowest priority task is the idle task. The tasks communicate with each other using 2 queues of messages (figure 3). 12

15 Figure 3: Inter-task communication using queues This mechanism is used to build event-driven programs for both application and networking tasks. Every message on the queues is built using a swavenisbuffer structure, constituted as follows: 1 struct swavenisbuffer { 2 u i n t 8 t e v e n t t y p e ; 3 u i n t 1 6 t d a t a l e n ; 4 u i n t 8 t * data ; 5 } The treatment applied by a task on a message arrived on its queue is defined by the event type, and the parameters are the pointer to the data buffer and the length of this buffer. 13

16 3 Protocols and Implementation of the Stack The Swedish Institute of Computer Science (SICS, [3]) has been working on an operating system for small and constrained devices for a few years. This operating system, Contiki, includes a TCP/IP stack, µip, a very compact stack [4]. However, the basic implementation of µip is not necessarily meant to be used in wireless devices. This class of nodes has new constraints, related to power consumption, since emission and reception of packets become more costly in wireless environments. This is why it has been decided to include 6LoWPAN, defined in [18], in the stack. 3.1 The 6LoWPAN Adaptation Layer The world of wireless protocols includes a lot of different specifications. Wi- Fi or 3G protocols are probably the most famous and widely used in the area of embedded Internet technologies. However, they are not suitable for all the devices that are considered in the context of the Internet of Things, e.g. the Internet embedded on small and constrained devices. In particular, the so-called Low-Power and Lossy Networks, that are considered in the Diaforus project, present strong constraints for the protocols in use Low-Power and Lossy Networks The Low-Power and Lossy Networks (LLNs) consist of several connected wireless devices, with limited hardware capabilities. The low-power characteristic results from the need for long lifetime for devices powered using small batteries. The lossy characteristic results from the lower reliability of the wireless channels, compared to the wired links. The air as a communication medium is much more complicated to manage than a wired link, and the loss rate is high in a LLN, implying the need for retransmission. One other characteristic that can be responsible for packet loss in this context is the small memory capacity of the devices, which cannot buffer more than a few packets (in the case of the Diaforus project, there is room for only one single packet in memory, which means that the nodes drop all incoming packets while handling the buffered packet) Why 6LoWPAN? The Internet of Things idea is to attach small devices to the Internet cloud using standard protocols and design patterns. Thus, IP is to be used as a network layer protocol. In particular, IPv6 is best suited for this kind of applications, since it has a much wider range of addresses available 2. However, there is a duality between the use of IPv6 and the constraints of wireless sensors. First, IPv6 are rather wide, considering that sensors usually do not need to send a long payload. Indeed, transmission and reception of packets is the most power consuming operation for low-power wireless nodes, and having long headers represents a greater power consumption. Moreover, the minimal MTU of IPv6 is much bigger than the usual MTU of wireless protocols 2 IPv4 is still widely used all around the world, but needs the use of Network Address Translation to increase the amount of connected devices 14

17 (102 bytes for IEEE , 150 bytes for Wavenis for instance), with as a consquence a strong limitation on the path MTU: an optimized fragmentation mechanism is also important to be able to use IPv6 in the context of LLNs. Several benefits of using IPv6 as a network layer for Internet of Things applications are identified in [18]: ˆ The infrastructure for using IP is already widely deployed ˆ IP-based technologies already exist, are well-known, and proven to be working ˆ IP technologies are an open standard, with many open implementations available ˆ All the maintenance and monitoring tools already exist ˆ There is no need for complex translation gateways in order to connect a LoWPAN to the Internet cloud The following problems inherent to the usage of IPv6 in LLNs are solved by 6LoWPAN: ˆ Small MTU of Data-Link layer protocols (fragmentation features more straightforward than the one available using IPv6 header extensions) ˆ Wide 40-byte headers (using stateless or context-based header compression) ˆ Complex and power consuming Neighbor Discovery procedures 6LoWPAN is therefore a good tool to adapt IPv6 to the constraints of small wireless, battery-powered devices. This is why it is presented as an adaption layer, since it does not redefine a new protocol but optimizes an existing one taking into account power consumption, packet loss and memory constraints [18] Dispatch Byte 6LoWPAN packets all start with a dispatch byte [16] (as shown figure 4), used to apply the proper treatment on the incoming packet upon reception. The table of possible values is shown int table 1. The 2 Most Significant bits categorize the type of packet (Fragment, Compression...), the other bits give information about the parameters that must be used to treat the packet. Figure 4: 6LoWPAN Dispatch Byte 15

18 From To Allocation NALP - Not a LoWPAN frame Reserved for future use IPv6 packet (no 6LoWPAN-specific operation required) LOWPAN HC1 - compressed IPv6 (stateless) Reserved for future use LOWPAN BC0 - Broadcast Reserved for future use LOWPAN IPHC - compressed IPv6 (context-based) Additional Dispatch Byte follows MESH FRAG1 - First fragment of a packet Reserved for future use FRAGN - Fragment (not first) proposed for fragment recovery Reserved for future use Table 1: Possible values for the 6LoWPAN Dispatch Byte [19] Header Compression The 6LoWPAN specification includes 2 types of header compression: the stateless and the context-based schemes, which have both pros and cons. They are based on the same main ideas, e.g. elide any field from the IPv6 header that can be inferred from the lower level protocol headers, and optimize the usual addressing scheme. Stateless Header Compression The first header compression scheme to be introduced for use with 6LoWPAN was the stateless header compression, HC1/HC2. It was defined in [16]. The first part of stateless header compression is called HC1, and concerns the IPv6 header (figure 5). The included fields are : ˆ SAE/DAE 3 : This represents the way IPv6 source (resp. destination) address is handled for this packet, using the following codes : 0b00: prefix sent in-line, IID (Interface Identifier, often derived from the EUI-64 [14]) sent in-line, 0b01: prefix sent in-line, IID elided and derived from L2 address 0b10: prefix elided and assumed to be link-local (fe80::/64 [22]), IID sent in-line, 3 Source/Destination Address Encoding 16

19 Figure 5: Stateless Header Compression 0b11: prefix elided and assumed to be link-local, IID elided and derived from L2 address. ˆ C: if set to 1, the Traffic Class and Flow fields from the IPv6 header are elided and assumed to be zero. Otherwise, they are sent in-line, ˆ NH: some transport layer protocols are really common, which is used by 6LoWPAN to compress the Next Header field, 0b00: Next Header sent in-line 0b01: Next Header = 17 (UDP), 0b10: Next Header = 1 (ICMP), 0b11: Next Header = 6 (TCP). ˆ The last bit of the LOWPAN HC1 bit indicates the presence of HC2 compression, ˆ The IPv6 length field is always elided and inferred from the L2 header, ˆ The Hop Limit, on the contrary, is always sent in-line. To this HC1 specification is added a compression for UDP headers, named HC2. It adds the compression of the Source (S flag) and Destination (D flag) ports to 4 bits instead of 16 bits. If necessary, the L flag can be set to 1, indicating the the UDP length is sent in-line. Thus, stateless (HC1/HC2) compression may be used to avoid sending up to 41 bytes in the best case for a UDP packet, link-local with IID built from the L2 address. But it is not likely to be the case very often, and the average header length is generally located between 25 and 30 bytes, depending on the context in which 6LoWPAN is used. The main advantage of this compression scheme is that it does not rely on any context information that would need to be maintained within the network. Context-Based Header Compression Although the context-based header compression (LOWPAN IPHC specification is described in [13]) takes advantage of the same redundancies and addressing optimization than the stateless scheme, it adds context information that increases average efficiency of header 17

20 compression. The basic header when using LOWPAN IPHC is 13-bit long, 5 of them are located in the rightmost bits of the dispatch byte, which enables a better use of this first mandatory byte in comparison with HC1 (this is why the LOW- PAN IPHC is allocated to a range of dispatch bytes instead of one unique byte). The remaining 8 bits are included in the second byte, and the minimal header length is thus 2 bytes, reparted as represented figure 6. Figure 6: Context-Based Header Compression The fields included in this header are: ˆ TF: Traffic class and Flow label IPv6 fields are encoded in 3 different ways, depending on their value, or sent-inline if necessary, ˆ N: Next header compression flag, if set, LOWPAN NHC is used, otherwise, the next protocol s IANA code is sent in-line, ˆ HLM: hop limit, (0b00 = sent in-line, 0b01 = hop limit is 1, 0b10 = hop limit is 64, 0b11 = hop limit is 255 [13]) ˆ S/SAM and D/DAM: IPv6 address compression scheme (S for Source, D for Destination), ˆ M: if set, the destination address is a multicast address and consequently the multicast compression scheme is used. The SCI and DCI fields (Source and Destination Context Identifiers) are used whenever context information is needed to compress and uncompress the IPv6 addresses. It allows up to 16 different context for each address, that need to be shared by both end-points of the communication and all routers along the path between them. It is particularly useful when using a global prefix within the LoWPAN, that is to say most of the cases in most applications. Header compression for the transport layer protocols is also included in LOWPAN IPHC. It is called LOWPAN NHC (Next Header Compression). It is not yet defined for many protocols, but just for the most common ones. In particular, the UDP port compression is extended from HC1/HC2 and allows a more flexible compression (the source and destination ports can be encoded independently from each other to more possible values 4 ). 4 with stateless HC2, each port is encoded using 4 bits or sent in-line with 16 bits. 18

21 Stateless HC Context-based HC Pros - No need for synchronization - Lower average header length between nodes - Usable for globally routable packets - Relatively Simple Cons - Rarely Optimal - Higher need for memory - Need for synchronization (complexity) Table 2: Stateless vs Context-based Header Compression Stateless vs Context-based Header Compression The best-case header for compressed IPv6 datagrams is 3 bytes when using stateless header compression. That is 1 byte more than context-based header compression, which needs only 2 bytes. But the average length of the header with LOWPAN IPHC is much lower than with HC1, since context information allows global prefixes to be elided, which represents a gain of up to 15 bytes in comparison with HC1. On the other hand, stateless header compression is simpler to manage within a LoWPAN, since their is no need for context dissemination amongst the nodes. However, LOWPAN IPHC is becoming the standard for header compression, because of its increased efficiency [19]. A brief comparison of the two compression schemes can be observed in table Fragmentation and Re-assembly IPv6 designers have decided that all IPv6 enabled nodes must have a 1280 bytes minimal MTU. This size has been chosen to fit inside an Ethernet frame, on top of which IPv6 is typically used: the path MTU is then of 1500 bytes, which is enough for including a 128 byte payload, an IPv6 header and its extensions. Fragmentation might not be necessary then. But IEEE , the data-link layer protocol that 6LoWPAN was first designed for, has a MTU of 127 bytes, and there was therefore a vital need for fragmentation. Fragmentation is not natively included in IPv6. This disruption from the IPv4 specification was decided to reduce processing time in the routers. Instead of adapting the fragmentation to the next link s MTU, IPv6 routers send back an error ICMP message if the length exceeds the MTU of the next link. However, it is possible to add an extension header to the basic IPv6 header, in order to use fragmentation [8]. In that case, fragmentation is performed only by the source node, and re-assembly by the destination node. 6LoWPAN includes its own fragmentation mechanism, more suitable for constrained devices, using a shorter header (4 bytes instead of 8 bytes for the IPv6 fragmentation header). This mechanism has the following characteristics: ˆ Fragments identified by a specific dispatch byte (table 1), ˆ The size of the whole IPv6 packet is transmitted within every fragment, ˆ Each flow of fragment is identified by a four-tuple {src address, dst address, unique tag, datagram size}, ˆ No retransmission of a single fragment when packet loss occurs (all the fragments are retransmitted). 19

22 This mechanism is suitable when the nodes exchange quite small packets (e.g. when the amount of fragments necessary to send a fragmented IP packet is not too significant). Some discussions currently happen within the 6LoWPAN Work Group to include a simple fragment recovery protocol[12], because in some applications, bigger packets might be necessary (typically when upgrading a firmware) Neighbor Discovery The IPv6 protocol includes auto-configuration and neighbor discovery features: duplicate address discovery [22] for instance is a mechanism used to avoid address collisions, and the neighbor discovery protocol [20] is used to detect neighbors in the range of a node 5. An important part of those features, however, are not suitable for LLNs. Thus, the designers of 6LoWPAN have included some specific mechanisms. Duplicate Address Detection Usual Duplicate Address Detection (DAD) consists of sending a Neighbor Solicitation ICMP packet to the multicast solicitednode address, based on the last 6 bits of the IPv6 address that is to be checked for duplication and from the unspecified address [22]. Any node that would use the target address would receive the NS, and inform the sender back that the address is already in use. But in the case of LoWPANs, this protocol is replaced by an address registration protocol. In terms of architecture, the edge router of the LoWPAN, which does not have the same constraints as the nodes within the LoWPAN, keeps a white-board up to date, containing all the addresses currently used in the LoWPAN (figure 7). For that purpose, 6LoWPAN introduces 2 new ICMP messages, Node Registration and Node Confirmation [7]. Figure 7: Node Registration at the Edge Router 5 In the case of wireless networks, which is what 6LoWPAN is about. 20

23 The operations required by this optimization are : 1. The node sends a Node Registration message, that is relayed up to the edge router, 2. The edge router checks in the white-board if the target address is already used, sends back a Node Confirmation message 6, and updates its address white-board, 3. The node keeps its state up to date at the edge router in time, by repeating the operation on a regular basis. 3.2 Implementation of the Communication Stack in Excelyo Nodes As stated in the section 2.2, the operating system revolves around the repartition of CPU time between 2 tasks, one dedicated to the stack, with the highest priority, and one dedicated to the execution of the application. The work carried out consists of 2 major points : 1. Integration of the µip library in the stack task, on top of the Wavenis library provided by Coronis, 2. Design of a new event-driven API for networking with UDP in the application task Application Task Our first attempt to port µip to the FreeRTOS operating system provided by Coronis was located in the application task. The application task s original implementation handles a set of events, mostly generated from the stack task. These events are related to the data-link layer directly, e.g. to the Wavenis protocol in this project. The input function from µip was only called from the callback used by the application to process Wavenis incoming packets. This simple approach has the advantage of presenting a loose coupling between the network and transport layers implementation and the operating system implementation (even if Coronis changes the implementation of the stack task, the event-driven framework will not change). However, we observed that this implementation is not the most efficient way to proceed. First, network layer operations and application functionnalities are not dependent of each other, meaning that it is possible to hide the IPv6 and routing related operations from the application developer. Secondly, including these operations in the stack task implies that they will be handled with the highest priority. Thus, the global processing time for the packets that do not need to be transmitted to the application (ICMP, routing) is lower, which means that the µip buffer is freed faster. 6 The Node Confirmation is also used when the address is already used and that the registration is refused. 21

24 This led us to the decision of redefining the event-driven application framework, in order to build a UDP API on top of it, with the following event definitions: ˆ tick event The application task receives this event on regular basis. The tick being the time unit in FreeRTOS, it is sent periodically, every N ticks. This is where the application actually performs its work, that is implemented in a specific callback function. The frequency can be adjusted in order to lower power consumption. ˆ udp input This message is posted by the stack task to the application queue, signaling that a UDP message has been received, and is ready for handling by the application task. ˆ transmission complete This event happens when a message has been successfully sent. If it was broadcasted, it just means that it has been sent out. If it was unicast, it means it has been acknowledged at the Wavenis layer (data-link). ˆ no acknowledge This event means that the message was sent but never acknowledged Stack Task Since we took the decision of including the network layer implementation in the stack task, we had to modify the stack task implementation. Our main idea is to cross all the layers from the OSI model by applying short treatments at each level, and by firing an event to be handled in the stack task by the next layer (up for reception, down for emission). (a) Stack architecture without µip (b) Stack architecture with µip Figure 8: The Wavenis stack architecture The task itself was already implemented in binary for the Wavenis treatment, and the events where sent directly after the data-link layer to the application 22

25 task. The proposed architecture integrates the network and transport layers within the stack task, which offers more reactivity in the networking code execution. The figure illustrates the layered implementation of the stack task without µip (the original version, figure 8(a)) and with µip (figure 8(b)). The activity diagram of our network/transport layers implementation can also be found in tha appendix E. The network and transport layer events handled by the stack task are: ˆ ses event send frame request The application tasks wants to send a packet (transport layer). A UDP/ 6LoWPAN packet must be built from the data, then the compressed packet is sent to the MAC layer for emission. ˆ mac event send frame confirm The MAC layer confirms that the packet has been sent on the air, and the result of the operation is sent up to the network layer (no acknowledgment, no answer, transmission complete). ˆ ses event end cycle request The application task requests the end of the current session. ˆ mac event indication The MAC layer is passing a packet up to the network layer after it has been received. The packet is passed to the input function (6LoWPAN treatment, then IPv6 treatment), then passed to the application task (posted on the application s queue). ˆ mac rx enable confirm The MAC layer informs the network layer that it is ready to receive data again after sending a packet on the air Interfacing the Application and Stack tasks with UDP In a constrained environment, the widely used TCP protocol does not really fit, for several reasons. First, TCP end points must send quite a lot of packets, in order to keep the state of the communication up to date. This is not suitable in terms of power consumption. Secondly, the state of a connection has a footprint that must not be neglected when the available space in RAM is limited. UDP is therefore much more suitable in the context of highly constrained networks. The µip implementation of the TCP/IP stack only includes a limited support for UDP. In standard computer software, the socket API is usually used, but no such API is available on constrained nodes. Thus, a system of callback is proposed as an alternative solution for reception of UDP packets from the stack. The basic idea is that the transport layer, that is managed by the stack task, decides whether or not the packet belongs to an open port, and if so, transmits the packet to the application task, that is then responsible for calling the corresponding callback (figure 9). 23

26 Figure 9: UDP architecture API proposed for sending and receiving data on top of UDP ˆ Open a connection struct uip_udp_conn * udp_open( u16 lport, void(*callback)( u8 * data, int len, struct uip_udp_conn * conn)); A UDP link between 2 end nodes is defined by 4 parameters : a remote port, a remote network (here, IPv6) address, a local port and a local network address. In practice, the uip udp conn structure gathers a local port and a callback function that must be used upon reception of a UDP 24

27 packet belonging to this port. If lport is set to NULL, the program selects any available port. Parameters * u16 lport: the local port, or NULL if the port does not matter, * void(*callback)(u8 * data, int len, struct uip udp conn * conn): the callback for reception Returned value The value returned is the pointer to the structure stored by the network layer to represent the connection. ˆ Send a packet void udp_set_address( struct uip_udp_conn * conn, uip_ipaddr_t * addr ); Configure the remote IP address on the next destination host. Parameters: * struct uip udp conn * to: pointer to the UDP connection that must be used, * uip ipaddr t * addr: the remote IP address. void udp_set_rport( struct uip_udp_conn * conn, u16 rport ); Configure the remote port on the next destination host. Parameters: * struct uip udp conn * to: pointer to the UDP connection that must be used, * u16 port: the remote port. u8 udp_send( struct uip_udp_conn * to, u8 * data, u16 length); When called, this function posts a message to the stack queue, requesting the emission of the data passed as parameter on the specified UDP connection. 25

28 Parameters: * struct uip udp conn * to: pointer to the UDP connection that must be used. The remote port and IP address must have been configured first, * u8 * data: the UDP payload (excluding the UDP header), * u16 length: the length of the UDP payload. Returned value: The value returned is 1 if the operation was successful, 0 otherwise (it does not concerns the actual sending, just that the message was successfully passed to the stack task through the queue. ˆ Receive a packet void(*callback)(u8 * data, int len, struct uip_udp_conn * conn) The mechanism proposed in order to receive data on top of UDP is based on the registration of callbacks. The callback corresponding to a UDP connection is registered during the creation of the connection. Parameters * u8 * data: pointer to the first byte of the received payload (excluding the UDP header), * u16 len: the length of the UDP payload, * struct uip udp conn * conn: the connection that received the packet, in order to be able to differentiate the treatment of packets incoming on different ports. 3.3 IPv6 Routing Protocol for LLNs, RPL The Diaforus project aims at building large networks, which means that routing considerations are important for the project to work efficiently. Since nothing but small, autonomous, low-power devices can be deployed, both routers and their connected nodes are constrained. Thus, routers must embed an optimized routing protocol in order to cope with their own limitations. The Routing Over Low-power and Lossy networks working group from IETF (ROLL WG) is currently designing a new optimized routing protocol : the so-called IPv6 Routing Protocol for LLNs (RPL) [21] RPL Topology RPL is routing protocol designed for wireless networks working using IPv6. New challenges arise in wireless networks, because of the nature of the links: in wired networks, a link is usually not oriented. On the contrary, between two wireless interface, it can be oriented, if one of the node has a range lower than the other, and the distance between them is located between the two ranges. Thus, RPL first discovers the network topology, in order to build a Direction Oriented Directed Acyclic Graph (DODAG). Then, 4 different values are used to structure and maintain it [21]: 26

29 ˆ RPL Instance ID This value identifies a set of one or more DODAGs. It is possible to use several RPL Instance IDs within a single network, but in that case, all DODAGs in the same instance use the same objective function. ˆ DODAG ID Each DODAG within a RPL instance is identified by a DODAG ID. ˆ DODAG Version Number When a change happens in a DODAG s structure, the version number associated to it increases, which indicates to the network that the change occurred when it is disseminated, which triggers a global repair operation. ˆ Rank The rank is computed using the Objective Function (OF) of the RPL instance. It defines a hierarchy in the DODAG, since all nodes must have a strictly greater rank than any potential parent. RPL is designed to allow the use of several topologies in parallel, when multiple RPL instances are defined. This is a way to use different topologies for different purposes. For instance, one can define a first RPL instance whose OF uses the bandwidth metric, and a second one whose OF is related to packet loss rate. Thus, if a packet must be delivered very fast, a node would use the first instance, if the fact that it is not lost is more important, it would be routed using the second one. Finally, RPL topology offers a quite good robustness. First, the multiplicity of DODAGs within each instance can be used to avoid single points of failure, since it allows multiple edge routers. Moreover, each node within the network can handle multiple parents (a DAG is not necessarily a tree), which allows faster local repairs RPL Mechanism The RPL protocol is based on the use of a few new ICMPv6 messages, called RPL Control Messages, used to detect the neighboring routers and to advertise RPL information within the network. They use the ICMP message type 155 (to be confirmed by IANA [21]). The most important are: ˆ DODAG Information Solicitation (DIS): used to detect the neighboring routers. When joining the network, a node will broadcast this message to all routers in the area, and if any, they will send back a DIO, ˆ DODAG Information Object (DIO): used to advertise a DODAG and disseminate its information within the network, ˆ DODAG Advertisement Object (DAO): used to build downward routes. It is emitted in unicast to the first router a node takes as parent, and is then forwarded up to the DODAG root. 27

30 Upward routes An upward route is a route a packets follows towards the DODAG root. Building upward routes in RPL is quite straightforward: when a node wants to connect to a network, it requests the routers in its range to inform it of available DODAGs it can join, sending out a DIS. If any router is around, it sends back a DIO, with all necessary information (the 4 identifiers mentioned in 3.3.1). From the DIS it receives, the node computes its rank and chooses his preferred parent. Downward routes A downward route, on the contrary, is a route a packets follows from the DODAG root towards a node in the DODAG. When a node has received a DIO and accepts the router that issued it as a parent, it sends back a unicast DAO to its new parent. DAOs are then forwarded up to the root. RPL supports 2 different downward routing modes: storing and non-storing mode. In both cases, P2P packets have to go up towards the DODAG root using preferred parents at each hop. In non-storing mode, the packet will necessarily go through the root node, but in storing mode, it may start going down towards the final destination from the first common ancestor. Figure 10: Example of RPL Network Startup Maintaining the Topology In time, the topology can change. In order to keep the topology-related information up to date for all the nodes, RPL specifies 2 mechanisms. First, when a router detects a change (for instance, a router becomes unreachable), it will send out a DIO with an incremented DODAG 28

31 Figure 11: Stack implementation - distribution between application and stack task version number. If a router receives a DIO with a greater version number that the one it had in memory, it recomputes its rank, performs the appropriate operations on its table of parents, and sends out a new DIO with the new version number. This makes sure that the information is disseminated within the network, and is called a global repair. Secondly, all routers regularly emit a DIO, in order to inform their children that nothing has changed. This emission of DIO is triggered by the Trickle Algorithm [15], which aims at minimizing the rate of routing message emission when the topology is stabilizing. 3.4 Routing using ContikiRPL After porting µip to FreeRTOS, we decided to use RPL as a routing protocol. Since ContikiOS 2.4 included a basic implementation of RPL, ContikiRPL, it was natural to use this implementation, in order to avoid integration difficulties. However, ContikiRPL does not include all the possibilities offered by the ROLL WG in the specification of RPL. In particular, it works with only one RPL instance, which does not allow the superposition of different metrics in the network and the differentiation of the metric depending on the message s priority. The RPL code is inserted in the stack task, more precisely it is plugged into µip. The final implementation of the stack is presented figure 11. The work we performed here has been testing this implementation in several configurations, and evaluating its performance. The conclusions are presented in the Results section of this report. 29

32 4 REST Architecture and Node Management Interface The Diaforus project includes some on the fly node configuration requirements. The manageable parameters can be of various kinds. For instance, one could need to configure the parameters used for in-network reasoning applications. One could also need to change the communication parameters during runtime, for security reasons or to adapt to changes. We decided to use the REST standard as a support for a node management interface. 4.1 CoAP: Constrained Application Protocol RESTful web-services are widely used to publish a resource to a network, using the HTTP protocol. However, HTTP is an ASCII protocol, not optimized in terms of message length. Thus, it is not adapted for the publication of resources from nodes located in highly constrained networks such as LLNs. In this context, the Constrained Application Protocol, CoAP, is an attempt to palliate to the lack of optimized protocol that can be used to build RESTful architectures in these networks [10] Header Format Packet headers can usually be efficiently modified to shorten the average length of the packets. The first important point in CoAP is indeed its short header. It starts with 4 bytes that contain header information, organized following the schema presented figure 12. Figure 12: CoAP Header More options can be added after this header, depending on the operation performed, before adding payload if necessary. The 5 CoAP header fields are: ˆ V: the first 2 bits are set to the version in use (currently, the only possible value is 1) ˆ T: Transaction Type, defines the type of the first message of a transaction, that will determine the next messages to be sent. The 4 different types are: CONFIRMABLE: this type of message requests an acknowledgment, NON-CONFIRMABLE: this type of message does not request any acknowledgment, ACKNOWLEDGMENT, 30

33 RESET: if a received message does not correspond to any coherent context, the receiver must send a RESET message to the sender. ˆ OC: Option Count, the amount of options added to the standard CoAP header. ˆ Code: can take 2 kinds of values, Request Method code or Reply code. The possible values for the Request Methods: GET: 0x01 POST: 0x02 PUT: 0x03 DELETE: 0x04 Some common values for Reply code, and the associated traditional HTTP code: 164 (0xa4) 404 Not Found 80 (0x50) 200 OK 81 (0x51) 201 Created 124(0x7c) 304 Not Modified The options added after the header are coded starting with 4 bits, that determine the code of the option, then the option length, and finally the option s data. The option s code itself is not put in the 4 first bits. The value of this field is actually the difference between the currently processed option s code and the one of the previous option processed (option delta). Consequently, if there are more than one option included in the message, they must appear following a specific order. The way options are included in the CoAP header depends also on the length of the option, and is defined as presented in figure 13. Figure 13: CoAP Header Option Various options are available, and more are added regularly in the CoAP specification. They are close to the options available in HTTP. Some or the more common are: ˆ URI-Path, e.g. the string representation of the resource concerned by the request/response, ˆ Token, used for security uses, 31

34 ˆ Max-Age, for caching, ˆ Content-Type, in order to know how to handle the payload of the request/response, ˆ Subscription-Lifetime, used in the publisher-subscriber specification. Finally, a payload can be added in the requests and responses. PUT and POST requests can include payload in order to create or modify a resource on a server node, and responses from the server node include the state of the resource in the payload. No length field is included in the header, since this length can be inferred from the UDP length and the processing of the CoAP header Gateway CoAP gateway The fact CoAP designers sticked to the HTTP specification regarding the methods and the response codes used allows the interconnection of the standard Internet cloud and nodes publishing resources using CoAP from a LLNs using simple gateways. The general architecture of the system is shown figure 14. Figure 14: Interconnection of Internet and LLNs in a RESTful environment CoAP Subscription Protocol In some applications, the resource consumers need to be constantly up to date with the resource owner. The CoAP design includes support for the observersubscriber design pattern, so the information is pushed to all the resource consumers on the network when a change occurred in the resource s context. It is specified in [11]. If the operation is unicast (multicast is also a supported possibility, with some constraints), the publisher must implement a node list, that keeps track of the subscribers, using their network address, the associated UDP port, and a lifetime for the subscription. One node list is associated to one particular resource. The messages pushed to the subscribers can request an acknowledgment or not. This choice must be done depending on the application s needs: it is a 32

35 Figure 15: Observer-Subscriber mechanism in CoAP trade off between power consumption, since sending an acknowledgment costs energy to the subscriber, and the necessity for the system to make sure that the subscribers are up to date at any moment. 4.2 Node Management on top of CoAP Two types of management parameters have been distinguished: runtime parameters and startup parameters. The first ones are essential to be able to alter the behavior of the system once it has been deployed and started running. The second ones are necessary in order to keep track of changes in time, even after the nodes have been switched off. Thus, the management of the current and startup parameters on the chip is an important part of the project. It has been decided to expose the 2 following REST web services from the nodes : ˆ Current configuration, under the URI /run mgt, which represents a set of variables that can be changed on the fly when the system is running, ˆ Startup configuration, under the URI /start mgt, which represents a set of variables that are loaded when the power is switched on and the system boots. In order to avoid the usually long ACSII packets that are used in HTTP, the nodes have been designed as CoAP servers instead of HTTP servers. This server is initialized during the application task initialization, in particular by opening a UDP connection on the CoAP default port. The core function of the server is thus the callback associated to this connection, that is responsible 33

36 for parsing and handling CoAP requests on the server s UDP port (the activity diagram of the Application Task Loop is shown in figure 16, with CoAP server functionalities). Figure 16: CoAP Server: Activity Diagram These resources are actually an aggregation of several fields, corresponding to an ASCII key. The reason for proceeding this way is that we wanted to minimize the memory footprint in RAM: this aggregation allows transfering the memory needs from RAM to ROM (in the code). There are two kind of REST methods accepted on the management : the GET method to obtain the value associated to one or more keys, the PUT method to 34

37 change the value associated to one or more key 7. The payload of the requests must be formatted as following: ˆ For the GET method: No payload, if the request concerns all the values included under the name of the resource, key + 0x0, repeated for each key covered by the request, key is in ASCII characters. ˆ For the PUT method: key + 0x0 + n + 0x0 + value, repeated for each key covered by the request, key is in ASCII characters, n is the amount of bytes necessary for coding the value associated to the key, No payload, and then the PUT request is equivalent to a global GET request. 7 The policy to access and read or modify the management resources is out of scope of this report. 35

38 5 Results and expected developments 5.1 Simulation Results In the first step of the project, the target devices were not available, and a simulation environment has been developed in order to test the stack. It was not built from scratch, but based on a first, simplistic version used by one of the partners in the Diaforus project (Telecom ParisTech). Its architecture is based on a dispatcher in Python on the one hand, and a FreeRTOS-Wavenis simulator on the other hand. The code to be tested is included in the FreeRTOS-Wavenis simulator (figure 17). In order to simulate a real network, the dispatcher uses a XML configuration file to be able to decide whether a packet must be dispatched, and to which node it must be delivered (using a matrix containing booleans, representing the links between the nodes). This feature is important because it is the only way to test the Neighbor Discovery protocol implementation, as well as the RPL implementation. This file is also seeded to the FreeRTOS part of the simulator, so the simulated nodes can be configured dynamically. We defined a XML schema so the simulator can be reused easily in the future (appendix B). Communication Protocols The first tests where performed in order to confirm the successful integration of IPv6/6LoWPAN in the FreeRTOS operating system. Two tests were successfully operated: ˆ Auto-configuration and Neighbor discovery, Due to the fact that no gateway was implemented at first, Duplicate Address Detection was tested as in wired networks, not as specified in the 6LoWPAN specification, Neighbor discovery was tested sending a Neighbor Solicitation to a static address that is supposed to be in the neighborhood. The neighbor receives a Neighbor Solicitation with its solicited-node multicast address, and sends a Neighbor Advertisement including its link-layer address, Neighbor reachability has been successfully tested by simply killing the process of the destination node, and observing the reaction of the sender (it sends a few Neighbor Soliciation to the destination node in unicast). ˆ ICMPv6 and UDP communication, validating in particular the management of the new events posted to the stack and application queues. Ping between two nodes, Echo application on top of UDP. Routing protocol The routing protocol has been tested by defining a network using the XML configuration file (the file is joined in Appendix C). The simulated network was constituted of 11 nodes, configured with specific ranges that do not give more than one possible graph for RPL, using the Objective 36

39 Figure 17: Simulator Architecture Function 0 [23]. The characteristics of this network can be observed in figure 18(a). We also developed a simple GUI, that reads the configuration file and draws the different nodes in the network. Then, the messages that are dispatched by the network simulator are spied, and when a DAO is detected 8, a link between the source and destination of the packet is drawn. The resulting topology is shown figure 18(b) (page 38). The graphical interface can also detect the emission/forwarding of ICMPv6 packets (Echo Request and Echo Reply types), by enlightening in red the node that sends the packet. When a Ping has been performed from outside the simulator to the very bottom of the network, the enlightened nodes have shown that the forwarding functionalities were functioning properly. RPL has been designed using the Trickle algorithm in order to decrease the average number of packets needed to maintain a coherent network. An analysis on the packet emission rate within this same network has been realized. We obtained a result similar to [9] 9, and is presented figure 19. The time scale is not representative, because the simulation environment cannot be assimilated to the actual platform in terms of speed, but several facts can be observed : ˆ The rate is decreasing fast, ˆ Some peaks of emission can be observed, triggered by the expiration of the RPL timer at one of the nodes in the network. The peaks are more and more distant in time. 8 A DAO is always sent by a node to its direct ancestor, and thus reflects directly a route between these nodes. 9 They actually measured the power consumption of RPL, but since the transceiver is the most power-consuming component, we can assume that the correlation between power consumption and emission rate is close. 37

40 (a) Geographical Configuration (b) Resulting Topology Figure 18: RPL Testing in the Simulation Environment. This test of RPL in the simulation environment has thus been satisfying regarding several points : ˆ The routing/forwarding functionalities have been successfully integrated, 38

41 Figure 19: Emission rate of RPL packets (topology from figure 18(a)), #{packets emitted between t 5 and t+5} tx rate(t) = 10. ˆ The routing algorithm is working well, since all the nodes tend to get the smaller possible rank within the DODAG, ˆ The emission rate tends to be small, increasing the potential lifetime of the node s battery. Application Protocol, RESTful architecture The implementation of the CoAP-based web services started using the Contiki beta v2.5. However, this implementation of the CoAP protocol is not complete, and some work has been done to make it compliant with [11]. The first tests have been performed in CoAP-only context, simulating a client node, running FreeRTOS on top of the dispatcher, and a server node, publishing resources in the same context. The tests have been successful, including using the network topology shown figure 18(a) (multiple hops between client and server). Gateway The simulator has been then plugged to a tunnel IPv6 interface, created using the Python code presented figure 5.1. This interface is used to send packets from outside the LoWPAN to a node simulated inside the LoWPAN. The root of the RPL DODAG forwards the traffic to the simulator, that forwards it, after 6LoWPAN uncompression, to the tunnel interface. Some basic 6LoWPAN to IPv6 and IPv6 to 6LoWPAN functions have also been implemented in Python, to be integrated in the framework, redirecting all the traffic from the tun0 interface to the root node in the network, after compressing the headers. The Ping protocol has been successfully tested using the following command line from a Linux terminal to ping the node 1 in the network represented figure 18(a): ping6 -I tun0 abcd::1063:09ff:fe30:4d3 Moreover, a HTTP CoAP connection has been realized between the simulated network and the real Internet. The basic purpose is to demonstrate the 39

42 1 # c r e a t e v i r t u a l i n t e r f a c e 2 t u n n e l s o c k = os. open ( / dev/ net / tun, os.o RDWR) 3 i f s = i o c t l ( t u n n e l s o c k, TUNSETIFF, 4 s t r u c t. pack ( 16sH, tun%d, IFF TUN ) ) 5 ifname = i f s [ : 1 6 ]. s t r i p ( \ x00 ) 6 7 # c o n f i g u r e IPv6 address 8 v = os. system ( i f c o n f i g + ifname + i n e t 6 add 9 + IPV6PREFIX + : : 1 / 6 4 ) 10 v = os. system ( i f c o n f i g + ifname + i n e t 6 add f e 8 0 : : 1 / 6 4 ) 11 v = os. system ( i f c o n f i g + ifname + up ) # s e t r o u t e 14 os. system ( r o u t e A i n e t 6 add + IPV6PREFIX 15 + : : / 6 4 dev + ifname ) # e n a b l e IPv6 forwarding 18 os. system ( echo 1 > / proc / s y s / net / ipv6 / c o n f / a l l / forwarding ) Figure 20: Creation of an interface under Unix environments (Python) Figure 21: Sequence Diagram of the CoAP Gateway ease to interconnect the constrained networks using CoAP and the standard HTTP-based RESTful environments. A basic web server has been developed, that accepts incoming requests to the URLs constructed as follows: /xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/resource to request Which must be interpreted as a request to the resource to request on the node having the IPv6 address xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx. If the request is directed to the web server s root, an AJAX-based web page is sent back, demonstrating the standard resource discovery mechanism included in CoAP (/well-known resource). The page contains a text field, where the user can type an IPv6 address. Clicking on the button Send Request sends a request to well-known resource of the provided IPv6 address. The response is parsed and used to display a list of resources, their value, and a field that can be used to post a new value for the resource it belongs to. 40

43 5.2 Results on the Excelyo Modules Characteristics of the Ref Design Excelyo SoC The device used in the project is the Ref Design Excelyo System on Chip, developed by Coronis, partner in the Diaforus collaborative project. It has the following characteristics : ˆ Wavenis radio transceiver, ˆ 32-bits ASP3 RISC CPU, GCC based compilation tool, supporting C/C++, GDB based debugging tool (breakpoints, step-by-step, memory observation...), JTAG connection, ˆ 4 kbytes DRAM memory, ˆ 48 kbytes IRAM memory, ˆ 128 kbytes optional EEPROM (SPI Bus connected flash, not available at the moment this report is written), Since the EEPROM driver is not yet available, the total amount of memory is 52 kbytes. Up to 48 kbytes can be allocated to the code, 4kBytes are at least available for RAM data. If necessary, a part of the 48 kbytes in IRAM can be allocated to RAM data as well, but the space available for the code is then reduced IPv6/6LoWPAN on chip The IPv6/6LoWPAN have been tested by spying the packets sent by the nodes, using a Wavenis probe. The tests performed in the simulator have been reproduced on the real platform, in order to validate the ND protocol, the UDP protocol and the Ping protocol RPL on chip This could not be tested at the moment, due to a lack of memory space. The problem should be solved when the use of the 128 kb EEPROM is possible RESTful services on chip using CoAP The implementation of the CoAP protocol has been successfully tested on the Excelyo nodes, under some constraints. Due to memory constraints, the length of the URIs has been limited, which does not allow a deep hierarchy and description of the services (in particular, the./well-known/r resource cannot provide an extensive description of the published resources, otherwise the packets would not fit in the small buffer). The first test has been performed between two nodes, a server and a client. The server configuration included a resource at the URI /leds, represented on the device by 4 LEDs. The state of the resource could be changed, using 4 switches 41

44 located next to the LEDs. The request sent by the client was built statically, except for the value of the lifetime CoAP option, configured using the switches on the client side. The steps of the test were: 1. unsynchronize the client and the server before start (figure 25(a)), 2. Send a GET request from client to server with a lifetime set to 0, ˆ Consequence: the server answers, and the state of the resource is displayed on the client side (figure 25(b)). 3. Change the state of the resource on the server side, ˆ Consequence: the LEDs display the new state on the server side, but nothing happens on the client side. 4. Send a GET request from client to server with a lifetime set to 256, ˆ Consequence: the server answers, and the state of the resource is displayed on the client side. 5. Change the state of the resource on the server side, ˆ Consequence: the LEDs display the new state on the server side, shortly followed by the LEDs on the client side, because the server sent a spontaneous update since the subscription is valid. A second test has been performed for the PUT method, on the same resource. The server node was the same as for the previous test. The client node s application changed, the switches were used to configure the value to sent to the server using the PUT method. Interconnection with the real world: CoAP has be designed to be easily mapped to HTTP. Thus, one should write quite easily a gateway/proxy for the translation HTTP CoAP. The driver for the USB Wavenis Modem arrived late in the work realized on CoAP, but however, a simple application has been written in Java, translating IPv6 to 6LoWPAN and HTTP to CoAP. The same web page as in the simulation test has been used, and the resource discovery and resource access demonstrated Summary The integration of the network layer is thus complete in the simulation environment, including the IPv6 6LoWPAN gateway. For the real platform, some developments remain to be done, because of hardware limitations. Some work is currently being done in order to use the last improvements from Coronis, e.g. the driver for the USB Wavenis Modem, and the new library provided to use the flash memory. 42

45 5.3 Proposition of a New Architecture In the initial definition of the project, all the nodes were supposed to be Excelyo nodes, connected to all possible kind of sensors or actuators. The problem with that is the lack of memory at the moment. After working more than one month on optimizing the code size and reducing the need for memory, the analysis of memory available against memory needs has shown that in the current configuration, Excelyo modules were not yet adapted to the Diaforus project (the analysis is presented figure 5.3). Thus, a new proposal of architecture has been designed in order to keep the project running until the expected improvements happen. Figure 22: Analysis of the needs for memory in the network layer. The negative values in the memory balance cell (IRAM + DRAM - Needs) means that there is not enough memory. The basic project includes the FreeRTOS version provided by Coronis, and the Wavenis layer, nothing more. However, since CoAP was to be included into the nodes already, a new architecture has been proposed, based on the use of more poweful (but still small) nodes and Wavenis USB modems. The publish-subscribe application developed in the project was not to be changed, and cannot be included in the Excelyo nodes at the moment. The idea of the proposed architecture is to use more powerful nodes for routing and publish-subscribe operations, and Excelyo modules as lighter sensor nodes. 43

46 5.3.1 Points taken into account in the design 1. The first point taken into account was to keep the publish-subscribe unchanged. Changing it at this point would undermine the work accomplished in this way, 2. The second point was to keep Wavenis as a data-link layer protocol, as well as keep the Excelyo modules in the list of used devices, because of the features implemented (or that are to be implemented later) and of the good power efficiency of the hardware Brief presentation Figure 23: Alternative network architecture The core nodes, embedding the publisher-subscriber mechanism, form a net- 44

47 work that can be assimilated to the original network. However, they no longer publish a static list of resources, but more a list of services obtained from satellite nodes, running on Excelyo. They can obtain the list of services from a satellite node sending a GET request on the./well-known/r resource, and publish it as their own resource: the basic idea is thus to add an abstraction layer. The CoAP approach presents 2 interests: ˆ The core node to which an Excelyo node is attached has a consistent view of the resource because of the observer-subscriber feature in CoAP, and thus can really be considered as a sensor on the upper abstraction layer, ˆ The satellite nodes (Excelyo) will not send any CoAP packet unless a core node has subscribed to a resource. This happens only when the upper abstraction layer needs to get the resource. It is therefore really power efficient, because 1) the Excelyo does not need to send data if not explicitely requested, 2) the push mechanism spares energy on the corenode side. 45

48 6 Conclusions The global results of the work performed for this thesis are globally satisfying. First, because a full stack has been implemented. It respects the Internet s standards, using standard IPv6 and UDP protocols, and is also better suited than a usual stack to the constrained nodes used in the project. This part of the work consisted of understanding the µipv6 implementation, modifying the framework embedded on the FreeRTOS operating system and verifying the performance of the final system. The tests performed with the Excelyo nodes have shown that standard IPv6 communications were working, including the Neighbor Discovery protocol. The handling of ICMP is included. It has been used to show the interconnection capabilities of the system to a standard network, through a Ping from a standard Linux terminal and a basic gateway to compress IPv6 into 6LoWPAN (and reciprocally from 6LoWPAN to IPv6). Finally, the UDP protocol has been integrated, as an interface between the application and the network. The API we proposed is now used by the other teams working in the Diaforus project, with convincing results. In terms of power consumption, the resulting 6LoWPAN headers have an average length of 10 bytes. This is a significant improvement, as compared to the usual 40 bytes IPv6 headers. Secondly, we proposed a management interface, on top of the CoAP protocol. This implementation has been designed in the same idea as the underlying communication stack, e.g. with a standardization effort. We demonstrated the strong interconnection capabilities to the standard web technologies by accessing and modifying resources located on the physical nodes from a web browser. However, some questions are yet to be solved. The routing protocol we chose, RPL, could not be tested on the real nodes. We only tested it in the simulation environment, because of technical locks on the memory space available on the Excelyo nodes during this thesis was written. This study of the ContikiRPL implementation has been helpful to understand how this protocol works, but it would have been better to be able to build actual networks using real wireless sensors. This should be relatively straightforward, thanks to the recent improvements on the nodes. Another question is to test the final publish-subscribe middleware and innetwork reasoning that are currently under development on the nodes on top of this architecture. The implementation of our stack is very constrained in terms of payload size. Because of memory issues, no fragmentation can be implemented. Thus, the payload on top of UDP is limited to approximatively 100 bytes. This issue will be important in the comming developments of the project. In the case these two problems could not be solved in the next part of the project, we proposed an alternative architecture, that respects the requirements of the Diaforus on the one hand and that should allow the project to keep evolving towards the resolution of the initial problem. 46

49 References [1] Coronis, an Elster Group company - [2] FreeRTOS: Free Real Time Operating System - [3] Swedish institute of computer science - [4] uip - adam/uip/index.php/main page. [5] Wavenis OSA presentation - [6] Alicia Asin and Manuel Caloharra. Sensor networks to monitor air pollution in cities - September [7] Z. Shelby S. Chakrabarti and E. Nordmark. Neighbor discovery optimization for low-power and lossy networks, December [8] S. Deering and R. Hinden. RFC 2460: Internet protocol, version 6 (IPv6) specification, December [9] N. Tsiftes J. Eriksson and A. Dunkels. Low-power wireless ipv6 routing with contikirpl. April [10] Z. Shelby B. Frank and D. Sturek. Constrained application protocol (coap), October [11] K. Hartke and C. Bormann. Observing resources in coap, August [12] J. Hui. Lowpan fragment forwarding and recovery, June [13] J. Hui and P. Thubert. Compression format for ipv6 datagrams in 6lowpan networks, September [14] IEEE. Guidelines for 64-bit global identifier (EUI-64) registration authority. [15] T. Clausen P. Levis J. Hui O. Gnawali J. Ko. The trickle algorithm, January [16] N. Kushalnagar and G. Montenegro. RFC 4944: Transmission of IPv6 packets over IEEE networks, September [17] C. Kaufman R. Perlman and M. Speciner. Network Security: Private Communication in a Public World. [18] N. Kushalnagar G. Montenegro C. Schumacher. RFC 4919: IPv6 over low-power wireless personal area networks (6LoWPANs): Overview, assumptions, problem statement and goals, August [19] Z. Shelby and C. Bormann. 6LoWPAN, The Wireless Embedded Internet [20] T. Narten E. Nordmark W. Simpson and H. Soliman. RFC 4861: Neighbor discovery for IP version 6 (IPv6), September

50 [21] P. Thubert A. Brandt T. Clausen J. Hui R. Kelsey P. Levis K. Pister R. Struik and JP. Vasseur. RPL: IPv6 routing protocol for low power and lossy networks, December [22] S. Thompson and T. Narten. RFC 2462: Stateless address autoconfiguration, December [23] P. Thubert. Rpl objective function 0, January

51 Appendices A Vocabulary ˆ CoAP: Constrained Application Protocol. Defined by the CoRE WG from IETF. ˆ CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. Mechanism used to share the radio channel between different nodes that want to send data at the same moment, based on a ticketing system. ˆ DAG: Directed Acyclic Graph. In a wireless network, DAGs are typically the topology one want to build using a routing protocol: directed, because the fact that a node can reach another one in the network does not imply reciprocity, acyclic because infinite loops would be created otherwise. ˆ DAO: DODAG Advertisement Object, ICMPv6 message used by RPL to build downward routes. ˆ DIAFORUS: DIstributed Applications and Functions Over Redundant Unattended Sensors ˆ DIO: DODAG Information Object, ICMPv6 message used by RPL to advertise routing information. ˆ DIS: DODAG Information Solicitation, ICMPv6 used by RPL to request routing information to the neighboring routers. ˆ DODAG: Direction Oriented DAG. In RPL, it is a routing graph associated to one root in the RPL Instance. ˆ ICMPv6 : Internet Control Message Protocol version 6. ˆ IPv6 : Internet Protocol version 6. ˆ LLN : Low-power and Lossy Networks. Class of wireless networks whose nodes are constrained in terms of energy consumption, built on lossy and low-bandwidth communication channels. ˆ MAC : Media Access Control. Lower sub-layer of the data-link layer in the OSI model. ˆ MTU : Maximum Transmission Unit, the maximum length of a packet encapsulated using the concerned protocol. ˆ ND: Neighbor Discovery, an IPv6 protocol used to detect duplicate addresses, neighbor unreachability, and to obtain the neighbors MAC address or routing information. ˆ Objective Function (OF): the function used by RPL to compute the rank of a node regarding the network topology. It must be unique within a single RPL instance. It is not defined by RPL, and can use different metrics and algorithms (the ROLL WG proposed a default function, OF0, defined in [23]) 49

52 ˆ REST : Representational State Transfer, style of software architecture for distributed systems. It is based on the publication of resources, usually over the HTTP protocol. ˆ RPL: IPv6 Routing Protocol for LLNs. ˆ SoC : System on Chip. ˆ TDMA: Time Division Multiple Access. Mechanism used to share the radio channel between several senders, based on the synchronization of the nodes and the allocation of time slots for emission. ˆ WSN : Wireless Sensor Network. 50

53 B XML Configuration File Specification 1 <xs:schema xmlns:xs= h t t p : //www. w3. org /2001/XMLSchema > 2 <x s : e l e m e n t name= network > 3 <x s : a n n o t a t i o n> 4 <xs: documentation> 5 P r e s e n t a t i o n o f the d i f f e r e n t f i e l d s : 6 The r o o t p a t h i s the l o n g e s t common part o f a l l 7 the path to the firmware 8 The firmware path i s d i f f e r e n c e between the 9 a b s o l u t e path to the firmware and the r o o t p a t h 10 A node i s r e p r e s e n t e d by i t s p o s i t i o n (X,Y), and i t s range 11 ( the maximum d i s t a n c e that can be reached i n e m i s s i o n by the 12 node ), an ID that i s used by the d i s p a t c h e r to r e t r i e v e the 13 node, and by the node to b u i l d i t s MAC a d d r e s s 14 A node can i n c l u d e a sequence o f key value p r o p e r t i e s, that 15 can be used e i t h e r by the node or the d i s p a t c h e r. 16 </ xs: documentation> 17 </ x s : a n n o t a t i o n> 18 <xs:complextype> 19 <x s : s e q u e n c e> 20 <x s : e l e m e n t name= r o o t p a t h type= x s : s t r i n g /> 21 <x s : s e q u e n c e maxoccurs= unbounded minoccurs= 0 > 22 <x s : e l e m e n t name= node > 23 <xs:complextype> 24 <x s : s e q u e n c e> 25 <x s : e l e m e n t name= n o d e i d type= x s : i n t /> 26 <x s : e l e m e n t name= posx type= x s : f l o a t /> 27 <x s : e l e m e n t name= posy type= x s : f l o a t /> 28 <x s : e l e m e n t name= range type= x s : f l o a t /> 29 <x s : e l e m e n t name= firmware path type= x s : s t r i n g /> 30 <x s : s e q u e n c e maxoccurs= unbounded minoccurs= 0 > 31 <x s : e l e m e n t name= property > 32 <xs:complextype> 33 <x s : s e q u e n c e> 34 <x s : e l e m e n t name= key type= x s : s t r i n g /> 35 <x s : e l e m e n t name= value type= x s : s t r i n g /> 36 </ x s : s e q u e n c e> 37 </ xs:complextype> 38 </ x s : e l e m e n t> 39 </ x s : s e q u e n c e> 40 </ x s : s e q u e n c e> 41 </ xs:complextype> 42 </ x s : e l e m e n t> 43 </ x s : s e q u e n c e> 44 </ x s : s e q u e n c e> 45 </ xs:complextype> 46 </ x s : e l e m e n t> </ xs: schema> 51

54 C XML Configuration File for RPL Testing 1 <?xml version= 1. 0?> 2 <network> 3 <r o o t p a t h>/home/ t a i /Debug/</ r o o t p a t h> 4 <node> 5 <n o d e i d>1234</ n o d e i d> 6 <posx>0</ posx> 7 <posy>0</ posy> 8 <range>90</ range> 9 <firmware path>d i a f o r u s p r o j e c t</ firmware path> </ node> 12 <node> 13 <n o d e i d>1235</ n o d e i d> 14 <posx>0</ posx> 15 <posy>75</ posy> 16 <range>90</ range> 17 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 18 </ node> 19 <node> 20 <n o d e i d>1236</ n o d e i d> 21 <posx>75</ posx> 22 <posy>0</ posy> 23 <range>90</ range> 24 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 25 </ node> 26 <node> 27 <n o d e i d>1237</ n o d e i d> 28 <posx>0</ posx> 29 <posy>150</ posy> 30 <range>90</ range> 31 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 32 <property> 33 <key>mykey</ key> 34 <value>myvalue</ value> 35 </ property> 36 </ node> 37 <node> 38 <n o d e i d>1238</ n o d e i d> 39 <posx>150</ posx> 40 <posy>0</ posy> 41 <range>90</ range> 42 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 43 </ node> 44 <node> 45 <n o d e i d>1239</ n o d e i d> 46 <posx>30</ posx> 47 <posy>180</ posy> 48 <range>45</ range> 49 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 50 </ node> 51 <node> 52 <n o d e i d>1240</ n o d e i d> 53 <posx>180</ posx> 54 <posy>30</ posy> 55 <range>45</ range> 56 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 57 </ node> 58 <node> 59 <n o d e i d>1241</ n o d e i d> 60 <posx> 30</ posx> 52

55 61 <posy>180</ posy> 62 <range>45</ range> 63 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 64 </ node> 65 <node> 66 <n o d e i d>1242</ n o d e i d> 67 <posx>180</ posx> 68 <posy>0</ posy> 69 <range>45</ range> 70 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 71 </ node> 72 <node> 73 <n o d e i d>1243</ n o d e i d> 74 <posx>0</ posx> 75 <posy>180</ posy> 76 <range>45</ range> 77 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 78 </ node> 79 <node> 80 <n o d e i d>1244</ n o d e i d> 81 <posx>180</ posx> 82 <posy> 30</ posy> 83 <range>45</ range> 84 <firmware path>d i a f o r u s p r o j e c t</ firmware path> 85 </ node> 86 </ network> 53

56 D Demonstration Board used for testing The Excelyo Ref Design modules used in the Diaforus project can be plugged in a demo board, that provides several different sensors and actuators. In particular, the push button and the switches have been used as sensors during testing, and the LEDs have been used to display the state of the CoAP resource or to show that a message has been received. 54

57 E Network Layer - Activity Diagram Figure 24: Activity Diagram of the Network/Transport Layers Implementation 55

58 Design and Implementation of F CoAP tests (a) Before GET request (b) After GET request Figure 25: CoAP GET request test, server on the left, client on the right. (full video at 56

59 G CoAP simulation, AJAX Web Page This web page is used to demonstrate the interconnection capabilities of CoAP. It is accessible through the gateway/proxy, that does the translation between CoAP and HTTP. The table is not displayed at first, but is generated from the./well-known/r resource of the node. Then the user can get the value of a resource available on the node, and try to post a value to change the resource state. 57