design and implementation of an ipv6 architecture for ...415878/fulltext01.pdf · compressing the...

Design and Implementation of an

IPv6 Architecture for Wireless Sensor Networks

Alexandre Sadones

Spring, 2011

Master of Science Thesis

Stockholm, Sweden 2011 TRITA-ICT-EX-2011:78

Master Thesis

Design and Implementation of an

IPv6 Architecture for WirelessSensor Networks

Author:Alexandre [email protected]

Examiner:Markus [email protected]

Supervisor:Mario Lopez-Ramos

[email protected]

April 9, 2011

Design and Implementation ofan IPv6 architecture for WSNs

1


Abstract

The Diaforus project is a collaborative initiative aiming at building aframework for in-network reasoning in a Wireless Sensor Network. Thefocus of this thesis is located between the network layer and the applica-tion layer, articulated in two distincts parts.

The first part aims at providing an API for communication to theembedded application, that must be as simple as possible. Hence, theapplication needs not to have any knowledge about the network’s topol-ogy. Thus, an IPv6-based network layer has been developed on top ofthe Wavenis API provided by Coronis, using an adaptation layer, 6LoW-PAN, in order to adapt the IPv6 standard to the constraints inherent tothe WSNs, in particular reducing the power consumption of the nodes bycompressing the IP headers. Moreover, a routing protocol, RPL, has beenimplemented, that also takes into consideration the optimization aspectsof the network.

Finally, the second part focuses on the design of an interface for themanagement and the monitoring of parameters on the node from a stan-dard network. It has been realized through a RESTful architecture, opti-mized for WSNs using a newly specified protocol, CoAP. The adaptationto the HTTP standard RESTful environments is achieved using a simplegateway.

2


Acknowledgements

In the first place, I would like to thank my supervisor at Thales Com-munications France, M. Lopez-Ramos. He provided me with the guidelinesI needed to become an active member of the Diaforus project. He gaveme the opportunity to get involved not only by setting up the commu-nication stack used in the project, but also by attending meetings withthe members of the project, from Telecom Paristech, LABRI and Coronis.

I would also like to thank these partners. It has always been inter-esting working in the team, and my internship would probably not havebeen as exciting as it was without our debating sessions. I learnt a lotfrom this collaboration.

I thank Markus Hidell, my teacher at Kungliga Tekniska Hogskolan,that accepted to be my examiner for this Master Thesis, and Jean-MarcSteyaert, my examiner at Ecole Polytechnique.

And last but not least, I thank all the members of TAI. I really had agreat time with you in the past 6 months. I will remember all the break-fasts we shared, the poker games we played, and the heated discussionswe had almost every day about everything.

3


Contents

1 Introduction 71.1 Presentation of the company . . . . . . . . . . . . . . . . . . . . 7

1.1.1 Thales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.1.2 TAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2 Introduction to the Diaforus Project . . . . . . . . . . . . . . . . 81.2.1 Scientific Goals . . . . . . . . . . . . . . . . . . . . . . . . 91.2.2 Focus of This Report . . . . . . . . . . . . . . . . . . . . . 9

2 Operating System and Data-link Layer Protocol 112.1 Excelyo modules and Wavenis protocol . . . . . . . . . . . . . . . 112.2 Operating System Architecture . . . . . . . . . . . . . . . . . . . 12

3 Protocols and Implementation of the Stack 143.1 The 6LoWPAN Adaptation Layer . . . . . . . . . . . . . . . . . 14

3.1.1 Low-Power and Lossy Networks . . . . . . . . . . . . . . . 143.1.2 Why 6LoWPAN ? . . . . . . . . . . . . . . . . . . . . . . 143.1.3 Dispatch Byte . . . . . . . . . . . . . . . . . . . . . . . . 153.1.4 Header Compression . . . . . . . . . . . . . . . . . . . . . 163.1.5 Fragmentation and Re-assembly . . . . . . . . . . . . . . 193.1.6 Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Implementation of the Communication Stack in Excelyo Nodes . 213.2.1 Application Task . . . . . . . . . . . . . . . . . . . . . . . 213.2.2 Stack Task . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.3 Interfacing the Application and Stack tasks with UDP . . 23

3.3 IPv6 Routing Protocol for LLNs, RPL . . . . . . . . . . . . . . . 263.3.1 RPL Topology . . . . . . . . . . . . . . . . . . . . . . . . 263.3.2 RPL Mechanism . . . . . . . . . . . . . . . . . . . . . . . 27

3.4 Routing using ContikiRPL . . . . . . . . . . . . . . . . . . . . . . 29

4 REST Architecture and Node Management Interface 304.1 CoAP: Constrained Application Protocol . . . . . . . . . . . . . 30

4.1.1 Header Format . . . . . . . . . . . . . . . . . . . . . . . . 304.1.2 Gateway ↔ CoAP gateway . . . . . . . . . . . . . . . . . 324.1.3 CoAP Subscription Protocol . . . . . . . . . . . . . . . . 32

4.2 Node Management on top of CoAP . . . . . . . . . . . . . . . . . 33

5 Results and expected developments 365.1 Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2 Results on the Excelyo Modules . . . . . . . . . . . . . . . . . . . 41

5.2.1 Characteristics of the Ref Design Excelyo SoC . . . . . . 415.2.2 IPv6/6LoWPAN on chip . . . . . . . . . . . . . . . . . . . 415.2.3 RPL on chip . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.4 RESTful services on chip using CoAP . . . . . . . . . . . 415.2.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3 Proposition of a New Architecture . . . . . . . . . . . . . . . . . 435.3.1 Points taken into account in the design . . . . . . . . . . 445.3.2 Brief presentation . . . . . . . . . . . . . . . . . . . . . . 44

4


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


List of Figures

1 Excelyo SoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Wake-up preamble mechanism . . . . . . . . . . . . . . . . . . . . 123 Inter-task communication using queues . . . . . . . . . . . . . . . 134 6LoWPAN Dispatch Byte . . . . . . . . . . . . . . . . . . . . . . 155 Stateless Header Compression . . . . . . . . . . . . . . . . . . . . 176 Context-Based Header Compression . . . . . . . . . . . . . . . . 187 Node Registration . . . . . . . . . . . . . . . . . . . . . . . . . . 208 The Wavenis stack architecture . . . . . . . . . . . . . . . . . . . 229 UDP architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 2410 Example of RPL Network Startup . . . . . . . . . . . . . . . . . 2811 Stack implementation - distribution between application and stack

task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2912 CoAP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3013 CoAP Header Option . . . . . . . . . . . . . . . . . . . . . . . . 3114 Interconnection of Internet and LLNs in a RESTful environment 3215 Observer-Subscriber mechanism in CoAP . . . . . . . . . . . . . 3316 CoAP Server: Activity Diagram . . . . . . . . . . . . . . . . . . 3417 Simulator Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3718 RPL Testing in the Simulation Environment. . . . . . . . . . . . 3819 Emission rate of RPL packets . . . . . . . . . . . . . . . . . . . . 3920 Creation of an interface under Unix environments . . . . . . . . . 4021 Sequence Diagram of the CoAP Gateway . . . . . . . . . . . . . 4022 Analysis of the needs for memory in the network layer . . . . . . 4323 Alternative network architecture . . . . . . . . . . . . . . . . . . 4424 Activity Diagram of the Network/Transport Layers Implementation 5525 CoAP GET request test . . . . . . . . . . . . . . . . . . . . . . . 56

List of Tables

1 Possible values for the 6LoWPAN Dispatch Byte . . . . . . . . . 162 Stateless vs Context-based Header Compression . . . . . . . . . . 19

6


1 Introduction

1.1 Presentation of the company

1.1.1 Thales

Thales Group is one of the world leaders for mission-critical information systems mainly in the aerospace andspace, defense and security core businesses. Technologieswith both commercial and military uses have come to playa pivotal role, both strategically and economically. The Thales Groups dualtechnology capability is one of its most significant competitive advantages intodays market for total security solutions. With a workforce of about 68,000employees in over 50 countries, Thales realized a turnover of 12.7 G¿.

Thales Communications France, where this thesis was written, is part ofThales Land & Joint Systems, although it is a legal company. Land & JointSystems is the Thales Division that brings together Thales’ activities in infor-mation and communications systems, optronics systems, ground surveillanceradars, ground robotics and armaments. The majority of these activities werepreviously part of the Communications and Optronics business groups.

The creation of this Division, with a strong Franco-British base, providesThales’ Land customers with clear access to reinforced prime contractorshipcapabilities. It also reinforces Thales’ position as a proven international primecontractor and as the leading European company for Joint Operations in thedomain 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 itsexpertise in communications and optronics equipment, offering its Land, Air andNaval customers the benefits of a comprehensive approach, which is key to theeffective ”tri-service” integration and allied interoperability required in the field.

Thales Communication France’s headquarters are located in Colombes (nearParis) and the three manufacturing plants are situated at Laval, Cholet andBrive. Thales Communications employs a total of 5,400 employees. ThalesCommunications France is a major player in the field of tactical, airborne andnaval communications.

7


Its activities in the field of electronics also cover the Intelligence / Surveil-lance / Reconnaissance segment for Joint services. In 2009, its sales amountedto 1.473 M¿. Thales Communications France is a major supplier of informationand communications systems to the French Land Forces. In addition, 30 % ofits sales are to customers outside France.

1.1.2 TAI

Within Thales Communications France, the TAI laboratory, which stands forTechnologies Avances pour l’ Information (Advanced Information Technologies),is responsible for the development and evaluation of new technologies for thesector of computer science and networking.

To fulfill those objectives, the role of TAI is threefold. Firstly, it has to studyand evaluate technologies that rise in academic and industrial contexts. Sec-ondly, it plays an important role by acting as a privileged intermediary betweenthe company and the exterior world in order to facilitate the sharing of knowl-edge in the field of advanced technologies. Thirdly, TAI should do the samework as an external expertise group by structured and precise research reports,sharing its knowledge in the different research domains in order to support thedecision-makers.

For these reasons, the TAI laboratory is involved in leading European ITresearch projects on the design and specification of systems as well as securityand telecommunication architectures. Hence, the laboratory is in touch withuniversities and other research companies and research laboratories in orderto share knowledge and results in innovative technologies. The topics of theprojects are very often placed, evaluated and enhanced in the context of mobilenetwork infrastructures.

1.2 Introduction to the Diaforus Project

The Diaforus project (DIstributed Applications and Functions Over RedundantUnattended Sensors) aims at creating new exploitation opportunities for net-works of unattended, affordable wireless sensors through a distributed middle-ware that allows a cross-layer optimization of the infrastructure and an overalloptimization of energy usage allowing longer sensor autonomy.

The target application, area security surveillance whether of critical indus-trial facilities, crowded events, or country borders presently relies on high-precision and costly sensors generally connected with high-bandwidth links,strongly fitted, and carefully calibrated. With the commercial availability oftiny, long-lived, and affordable wireless sensors, surveillance systems using nu-merous unattended wireless sensors are being deployed, for many purposes:pollution surveillance in Stockholm for instance (presented in [6]) However, ex-ploitable solutions coupling sensors with different kind of transducers in anautonomous, efficient, and flexible way are yet to appear. Diaforus takes advan-tage of the modal and spatial redundancy in the sensor networks where sensingranges overlap to achieve higher accuracy and better reliability while enhancingthe energy efficiency through an orchestration of the detection functions, an

8


appropriate distribution of in-network computing thus minimizing the amountof data exchanged.

To achieve this optimization, Diaforus creates a novel middleware providingthe support for in-network reasoning, allowing the direct cooperation betweenneighbor sensors as requested by real-time surveillance applications (monitoring,identification, and tracking), with a special emphasis on security of operationsand an easy-to-manage and flexible on-the-fly configuration capability to redis-tribute rules and roles.

1.2.1 Scientific Goals

The ultimate objective of this project is to develop a framework for in-networkreasoning and cooperation in heterogeneous wireless sensor networks, wherenodes can autonomously interpret the context and meaning of sensor data toinfer high-level phenomena through filtering, aggregation and correlation. It ismeant to constitute a reusable software base at the sensor, gateway and applica-tion level for the development of sensing solutions where complex autonomousprocessing is required.

In such a complex environment, flexibility and management capabilities aremajor objectives: the Diaforus framework will provide the tools for networksupervision, live fine-tuning of sensors and gateways, on-the-fly reconfigurationof the network intelligence behavior and definition of cooperative tasks.

The Diaforus middleware will provide mechanisms for injecting applica-tion knowledge into the infrastructure and the sensor network. Application-awareness will significantly improve the resource and energy efficiency in nodes,for example by application-specific aggregation at intermediate levels. Thisapplication knowledge will be situated in the knowledge plane which will be dis-tributed and hierarchical in order to satisfy application requirements and takeinto account network elements constraints.

In terms of non-functional objectives, the framework will integrate low-levelenergy optimization functions to achieve energy-aware reasoning and coopera-tion. Security is very energy-consuming: first because it implies computationallyexpensive tasks, such as encryption or integrity and authentication checks, sec-ondly because it may involve additional communications in order to establisha shared security context (some commonly used algorithms and key exchangeprotocols are presented in [17]). It is however an essential aspect, especially insurveillance scenarios. Diaforus has the ambitious objective of using the cooper-ative reasoning framework to dynamically adapt security mechanisms to threatsin order to deliver a cost-effective security and trust solution.

1.2.2 Focus of This Report

The area covered by the Diaforus project is wide, from the hardware design ofthe wireless sensors and gateways, to the application level. The report focuseson two distinct parts : it deals first with networking issues such as IPv6 and

9


routing between the nodes, then with the RESTful architecture built on top ofCoAP.

10


Figure 1: Excelyo SoC

2 Operating System and Data-link Layer Pro-tocol

2.1 Excelyo modules and Wavenis protocol

The project is based on the chip proposed by one of the industrial partners inthe Diaforus project, Coronis, member of the Elster group (the company and itsproducts are presented in [1]). This chip is part of the several Wavenis-enabledplatforms developed by Coronis. The Wavenis protocol is a data-link protocol,that targets industrial automation and telemetry applications in particular. Itis supported by the Wavenis Open Standard Alliance1 [5].

Technically speaking, Wavenis has been designed to be ultra-low power andwith long-range capabilities. In the context of the Diaforus project, this technol-ogy is particularly interesting since it provides longer lifetime to the deployednode, and can be used in wide areas (for border surveillance applications forinstance). It is a proprietary protocol, hence one cannot have a look to thepractical implementation provided by Coronis. However, some informationscharacterizing Wavenis are listed hereafter:

� Designed for worldwide deployment, operating in 3 possible frequencybands:

– 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 inter-ferences,

– Forward Error Correction, adding redundancy in the communication,

1Involving for instance Elster, Orange, Veolia or Cisco

11


– 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 notlisten to the radio channel continuously. They work in duty cycles, divided intwo periods : a sleeping period, which normally represents the major part of thecycle, 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 nodethat a packet will be sent soon. As it is not useful but power consuming towake up all the nodes within range, the preamble includes the MAC address ofthe destination node, and only the destination will wake up when receiving thispreamble.

Figure 2: Wake-up preamble mechanism

2.2 Operating System Architecture

The operating system running on the Excelyo modules developed by Coronisis FreeRTOS (for Free Real Time Operating System, [2]). It is a very genericoperating system coded in C, that revolves around the idea of parallel taskssharing CPU time using a system of task priorities. The version proposed forthe module has 3 parallel tasks : the highest priority task is dedicated to net-work functionalities, the middle priority task is dedicated to the application,and finally, the lowest priority task is the idle task. The tasks communicatewith each other using 2 queues of messages (figure 3).

12


Figure 3: Inter-task communication using queues

This mechanism is used to build event-driven programs for both application andnetworking tasks. Every message on the queues is built using a sWavenisBufferstructure, constituted as follows:

1 struct sWavenisBuffer {2 u i n t 8 t event type ;3 u i n t 1 6 t da ta l en ;4 u i n t 8 t * data ;5 }

The treatment applied by a task on a message arrived on its queue is definedby the event type, and the parameters are the pointer to the data buffer andthe length of this buffer.

13


3 Protocols and Implementation of the Stack

The Swedish Institute of Computer Science (SICS, [3]) has been working onan operating system for small and constrained devices for a few years. Thisoperating system, Contiki, includes a TCP/IP stack, µIP, a very compact stack[4]. However, the basic implementation of µIP is not necessarily meant to beused in wireless devices. This class of nodes has new constraints, related topower consumption, since emission and reception of packets become more costlyin 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 areaof embedded Internet technologies. However, they are not suitable for all thedevices that are considered in the context of the Internet of Things, e.g. theInternet embedded on small and constrained devices. In particular, the so-calledLow-Power and Lossy Networks, that are considered in the Diaforus project,present strong constraints for the protocols in use.

3.1.1 Low-Power and Lossy Networks

The Low-Power and Lossy Networks (LLNs) consist of several connected wirelessdevices, with limited hardware capabilities. The low-power characteristic resultsfrom the need for long lifetime for devices powered using small batteries. Thelossy characteristic results from the lower reliability of the wireless channels,compared to the wired links. The ”air” as a communication medium is muchmore complicated to manage than a wired link, and the loss rate is high in aLLN, implying the need for retransmission. One other characteristic that canbe responsible for packet loss in this context is the small memory capacity of thedevices, which cannot buffer more than a few packets (in the case of the Diaforusproject, there is room for only one single packet in memory, which means thatthe nodes drop all incoming packets while handling the buffered packet).

3.1.2 Why 6LoWPAN ?

The Internet of Things idea is to attach small devices to the Internet cloud usingstandard protocols and design patterns. Thus, IP is to be used as a networklayer 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 ofwireless sensors. First, IPv6 are rather wide, considering that sensors usuallydo not need to send a long payload. Indeed, transmission and reception ofpackets is the most power consuming operation for low-power wireless nodes,and having long headers represents a greater power consumption. Moreover, theminimal MTU of IPv6 is much bigger than the usual MTU of wireless protocols

2IPv4 is still widely used all around the world, but needs the use of Network AddressTranslation to increase the amount of connected devices

14


(102 bytes for IEEE 802.15.4, 150 bytes for Wavenis for instance), with as aconsquence a strong limitation on the path MTU: an optimized fragmentationmechanism 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 Thingsapplications are identified in [18]:

� The infrastructure for using IP is already widely deployed

� IP-based technologies already exist, are well-known, and proven to beworking

� IP technologies are an open standard, with many open implementationsavailable

� All the maintenance and monitoring tools already exist

� There is no need for complex translation gateways in order to connect aLoWPAN to the Internet cloud

The following problems inherent to the usage of IPv6 in LLNs are solved by6LoWPAN:

� Small MTU of Data-Link layer protocols (fragmentation features morestraightforward than the one available using IPv6 header extensions)

� Wide 40-byte headers (using stateless or context-based header compres-sion)

� Complex and power consuming Neighbor Discovery procedures

6LoWPAN is therefore a good tool to adapt IPv6 to the constraints of smallwireless, battery-powered devices. This is why it is presented as an adaptionlayer, since it does not redefine a new protocol but optimizes an existing onetaking into account power consumption, packet loss and memory constraints[18].

3.1.3 Dispatch Byte

6LoWPAN packets all start with a dispatch byte [16] (as shown figure 4), used toapply the proper treatment on the incoming packet upon reception. The tableof possible values is shown int table 1. The 2 Most Significant bits categorizethe type of packet (Fragment, Compression ...), the other bits give informationabout the parameters that must be used to treat the packet.

Figure 4: 6LoWPAN Dispatch Byte

15


From To Allocation

00 000000 00 111111 NALP - Not a LoWPAN frame

01 000000 Reserved for future use01 000001 IPv6 packet (no 6LoWPAN-specific operation required)01 000010 LOWPAN HC1 - compressed IPv6 (stateless)01 000011 01 001111 Reserved for future use01 010000 LOWPAN BC0 - Broadcast01 010001 01 011111 Reserved for future use01 100000 01 111111 LOWPAN IPHC - compressed IPv6 (context-based)01 111111 Additional Dispatch Byte follows

10 000000 11 111111 MESH

11 000000 11 000111 FRAG1 - First fragment of a packet11 001000 11 011111 Reserved for future use11 100000 11 100111 FRAGN - Fragment (not first)11 101000 11 101011 proposed for fragment recovery11 101100 11 111111 Reserved for future use

Table 1: Possible values for the 6LoWPAN Dispatch Byte [19]

3.1.4 Header Compression

The 6LoWPAN specification includes 2 types of header compression: the state-less and the context-based schemes, which have both pros and cons. They arebased on the same main ideas, e.g. elide any field from the IPv6 header thatcan be inferred from the lower level protocol headers, and optimize the usualaddressing scheme.

Stateless Header Compression The first header compression scheme tobe 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 concernsthe IPv6 header (figure 5). The included fields are :

� SAE/DAE3: This represents the way IPv6 source (resp. destination) ad-dress is handled for this packet, using the following codes :

– 0b00: prefix sent in-line, IID (Interface Identifier, often derived fromthe 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]), IIDsent in-line,

3Source/Destination Address Encoding

16


Figure 5: Stateless Header Compression

– 0b11: prefix elided and assumed to be link-local, IID elided andderived from L2 address.

� C: if set to 1, the Traffic Class and Flow fields from the IPv6 header areelided and assumed to be zero. Otherwise, they are sent in-line,

� NH: some transport layer protocols are really common, which is used by6LoWPAN 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 com-pression,

� 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, namedHC2. 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, indi-cating the the UDP length is sent in-line.

Thus, stateless (HC1/HC2) compression may be used to avoid sending upto 41 bytes in the best case for a UDP packet, link-local with IID built fromthe L2 address. But it is not likely to be the case very often, and the averageheader length is generally located between 25 and 30 bytes, depending on thecontext in which 6LoWPAN is used. The main advantage of this compressionscheme is that it does not rely on any context information that would need tobe maintained within the network.

Context-Based Header Compression Although the context-based headercompression (LOWPAN IPHC specification is described in [13]) takes advan-tage of the same redundancies and addressing optimization than the statelessscheme, it adds context information that increases average efficiency of header

17


compression.

The basic header when using LOWPAN IPHC is 13-bit long, 5 of themare located in the rightmost bits of the dispatch byte, which enables a betteruse 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 headerlength 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 = hoplimit is 64, 0b11 = hop limit is 255 [13])

� S/SAM and D/DAM: IPv6 address compression scheme (S for Source, Dfor Destination),

� M: if set, the destination address is a multicast address and consequentlythe multicast compression scheme is used.

The SCI and DCI fields (Source and Destination Context Identifiers) areused whenever context information is needed to compress and uncompress theIPv6 addresses. It allows up to 16 different context for each address, that needto be shared by both end-points of the communication and all routers along thepath between them. It is particularly useful when using a global prefix withinthe LoWPAN, that is to say most of the cases in most applications.

Header compression for the transport layer protocols is also included inLOWPAN IPHC. It is called LOWPAN NHC (Next Header Compression). Itis not yet defined for many protocols, but just for the most common ones. Inparticular, the UDP port compression is extended from HC1/HC2 and allowsa more flexible compression (the source and destination ports can be encodedindependently from each other to more possible values4).

4with stateless HC2, each port is encoded using 4 bits or sent in-line with 16 bits.

18


Stateless HC Context-based HC

Pros - No need for synchronization - Lower average header lengthbetween 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 headerfor compressed IPv6 datagrams is 3 bytes when using stateless header compres-sion. That is 1 byte more than context-based header compression, which needsonly 2 bytes. But the average length of the header with LOWPAN IPHC ismuch lower than with HC1, since context information allows global prefixes tobe 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 withina 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 compres-sion schemes can be observed in table 2.

3.1.5 Fragmentation and Re-assembly

IPv6 designers have decided that all IPv6 enabled nodes must have a 1280 bytesminimal MTU. This size has been chosen to fit inside an Ethernet frame, ontop of which IPv6 is typically used: the path MTU is then of 1500 bytes, whichis enough for including a 128 byte payload, an IPv6 header and its extensions.Fragmentation might not be necessary then. But IEEE 802.15.4, the data-linklayer 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 theIPv4 specification was decided to reduce processing time in the routers. Insteadof adapting the fragmentation to the next link’s MTU, IPv6 routers send back anerror 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 touse fragmentation [8]. In that case, fragmentation is performed only by thesource node, and re-assembly by the destination node. 6LoWPAN includes itsown fragmentation mechanism, more suitable for constrained devices, using ashorter 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 thefragments are retransmitted).

19


This mechanism is suitable when the nodes exchange quite small packets(e.g. when the amount of fragments necessary to send a fragmented IP packetis not too significant). Some discussions currently happen within the 6LoWPANWork Group to include a simple fragment recovery protocol[12], because in someapplications, bigger packets might be necessary (typically when upgrading afirmware).

3.1.6 Neighbor Discovery

The IPv6 protocol includes auto-configuration and neighbor discovery features:duplicate address discovery [22] for instance is a mechanism used to avoid ad-dress collisions, and the neighbor discovery protocol [20] is used to detect neigh-bors in the range of a node5. An important part of those features, however, arenot suitable for LLNs. Thus, the designers of 6LoWPAN have included somespecific mechanisms.

Duplicate Address Detection Usual Duplicate Address Detection (DAD)consists of sending a Neighbor Solicitation ICMP packet to the multicast solicited-node address, based on the last 6 bits of the IPv6 address that is to be checkedfor duplication and from the unspecified address [22]. Any node that would usethe target address would receive the NS, and inform the sender back that theaddress is already in use. But in the case of LoWPANs, this protocol is replacedby an address registration protocol. In terms of architecture, the edge routerof the LoWPAN, which does not have the same constraints as the nodes withinthe LoWPAN, keeps a white-board up to date, containing all the addresses cur-rently used in the LoWPAN (figure 7). For that purpose, 6LoWPAN introduces2 new ICMP messages, Node Registration and Node Confirmation [7].

Figure 7: Node Registration at the Edge Router

5In the case of wireless networks, which is what 6LoWPAN is about.

20


The operations required by this optimization are :

1. The node sends a Node Registration message, that is relayed up to theedge router,

2. The edge router checks in the white-board if the target address is alreadyused, sends back a Node Confirmation message6, and updates its addresswhite-board,

3. The node keeps its state up to date at the edge router in time, by repeatingthe operation on a regular basis.

3.2 Implementation of the Communication Stack in Ex-celyo Nodes

As stated in the section 2.2, the operating system revolves around the repartitionof CPU time between 2 tasks, one dedicated to the stack, with the highestpriority, and one dedicated to the execution of the application. The work carriedout consists of 2 major points :

1. Integration of the µIP library in the stack task, on top of the Wavenislibrary provided by Coronis,

2. Design of a new event-driven API for networking with UDP in the appli-cation task.

3.2.1 Application Task

Our first attempt to port µIP to the FreeRTOS operating system provided byCoronis was located in the application task. The application task’s originalimplementation 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 Wavenisprotocol in this project. The input function from µIP was only called from thecallback used by the application to process Wavenis incoming packets. Thissimple approach has the advantage of presenting a loose coupling between thenetwork and transport layers implementation and the operating system imple-mentation (even if Coronis changes the implementation of the stack task, theevent-driven framework will not change).

However, we observed that this implementation is not the most efficient wayto proceed. First, network layer operations and application functionnalities arenot dependent of each other, meaning that it is possible to hide the IPv6 androuting related operations from the application developer. Secondly, includingthese operations in the stack task implies that they will be handled with thehighest priority. Thus, the global processing time for the packets that do notneed to be transmitted to the application (ICMP, routing) is lower, which meansthat the µIP buffer is freed faster.

6The Node Confirmation is also used when the address is already used and that the regis-tration is refused.

21


This led us to the decision of redefining the event-driven application frame-work, in order to build a UDP API on top of it, with the following event defi-nitions:

� tick event

The application task receives this event on regular basis. The tick beingthe time unit in FreeRTOS, it is sent periodically, every N ticks. This iswhere the application actually performs its work, that is implemented ina specific callback function. The frequency can be adjusted in order tolower power consumption.

� udp input

This message is posted by the stack task to the application queue, signalingthat a UDP message has been received, and is ready for handling by theapplication task.

� transmission complete

This event happens when a message has been successfully sent. If it wasbroadcasted, it just means that it has been sent out. If it was unicast, itmeans it has been acknowledged at the Wavenis layer (data-link).

� no acknowledge

This event means that the message was sent but never acknowledged.

3.2.2 Stack Task

Since we took the decision of including the network layer implementation in thestack task, we had to modify the stack task implementation. Our main idea isto cross all the layers from the OSI model by applying short treatments at eachlevel, 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


task. The proposed architecture integrates the network and transport layerswithin the stack task, which offers more reactivity in the networking code ex-ecution. The figure illustrates the layered implementation of the stack taskwithout µIP (the original version, figure 8(a)) and with µIP (figure 8(b)). Theactivity diagram of our network/transport layers implementation can also befound 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 packetis 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 theresult 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 beenreceived. The packet is passed to the input function (6LoWPAN treat-ment, then IPv6 treatment), then passed to the application task (postedon the application’s queue).

� mac rx enable confirm

The MAC layer informs the network layer that it is ready to receive dataagain after sending a packet on the air.

3.2.3 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, inorder to keep the state of the communication up to date. This is not suitable interms of power consumption. Secondly, the state of a connection has a footprintthat must not be neglected when the available space in RAM is limited. UDPis therefore much more suitable in the context of highly constrained networks.

The µIP implementation of the TCP/IP stack only includes a limited supportfor UDP. In standard computer software, the socket API is usually used, butno such API is available on constrained nodes. Thus, a system of callbackis proposed as an alternative solution for reception of UDP packets from thestack. The basic idea is that the transport layer, that is managed by the stacktask, 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 callingthe corresponding callback (figure 9).

23


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 remoteport, a remote network (here, IPv6) address, a local port and a localnetwork address. In practice, the uip udp conn structure gathers a localport and a callback function that must be used upon reception of a UDP

24


packet belonging to this port. If lport is set to NULL, the program selectsany 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 valueThe value returned is the pointer to the structure stored by the networklayer 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 thatmust 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 thatmust 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, request-ing the emission of the data passed as parameter on the specified UDPconnection.

25


– Parameters:

* struct uip udp conn * to: pointer to the UDP connection thatmust be used. The remote port and IP address must have beenconfigured 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 doesnot concerns the actual sending, just that the message was successfullypassed 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 basedon the registration of callbacks. The callback corresponding to a UDPconnection is registered during the creation of the connection.

– Parameters

* u8 * data: pointer to the first byte of the received payload (exclud-ing the UDP header),

* u16 len: the length of the UDP payload,

* struct uip udp conn * conn: the connection that received thepacket, in order to be able to differentiate the treatment of pack-ets incoming on different ports.

3.3 IPv6 Routing Protocol for LLNs, RPL

The Diaforus project aims at building large networks, which means that routingconsiderations are important for the project to work efficiently. Since nothingbut small, autonomous, low-power devices can be deployed, both routers andtheir connected nodes are constrained. Thus, routers must embed an optimizedrouting protocol in order to cope with their own limitations. The RoutingOver Low-power and Lossy networks working group from IETF (ROLL WG)is currently designing a new optimized routing protocol : the so-called IPv6Routing Protocol for LLNs (RPL) [21].

3.3.1 RPL Topology

RPL is routing protocol designed for wireless networks working using IPv6. Newchallenges arise in wireless networks, because of the nature of the links: in wirednetworks, a link is usually not oriented. On the contrary, between two wirelessinterface, 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 DirectionOriented Directed Acyclic Graph (DODAG). Then, 4 different values are usedto structure and maintain it [21]:

26


� RPL Instance IDThis value identifies a set of one or more DODAGs. It is possible to useseveral RPL Instance IDs within a single network, but in that case, allDODAGs in the same instance use the same objective function.

� DODAG IDEach DODAG within a RPL instance is identified by a DODAG ID.

� DODAG Version NumberWhen a change happens in a DODAG’s structure, the version numberassociated to it increases, which indicates to the network that the changeoccurred when it is disseminated, which triggers a ”global repair” opera-tion.

� RankThe rank is computed using the Objective Function (OF) of the RPLinstance. It defines a hierarchy in the DODAG, since all nodes must havea strictly greater rank than any potential parent.

RPL is designed to allow the use of several topologies in parallel, when mul-tiple RPL instances are defined. This is a way to use different topologies fordifferent purposes. For instance, one can define a first RPL instance whose OFuses the bandwidth metric, and a second one whose OF is related to packet lossrate. Thus, if a packet must be delivered very fast, a node would use the firstinstance, if the fact that it is not lost is more important, it would be routedusing the second one.

Finally, RPL topology offers a quite good robustness. First, the multiplicityof DODAGs within each instance can be used to avoid single points of failure,since it allows multiple edge routers. Moreover, each node within the networkcan handle multiple parents (a DAG is not necessarily a tree), which allowsfaster local repairs.

3.3.2 RPL Mechanism

The RPL protocol is based on the use of a few new ICMPv6 messages, calledRPL Control Messages, used to detect the neighboring routers and to advertiseRPL information within the network. They use the ICMP message type 155 (tobe confirmed by IANA [21]). The most important are:

� DODAG Information Solicitation (DIS): used to detect the neighboringrouters. When joining the network, a node will broadcast this message toall routers in the area, and if any, they will send back a DIO,

� DODAG Information Object (DIO): used to advertise a DODAG anddisseminate 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 isthen forwarded up to the DODAG root.

27


Upward routes An upward route is a route a packets follows towards theDODAG root. Building upward routes in RPL is quite straightforward: whena node wants to connect to a network, it requests the routers in its range toinform it of available DODAGs it can join, sending out a DIS. If any router isaround, it sends back a DIO, with all necessary information (the 4 identifiersmentioned in 3.3.1). From the DIS it receives, the node computes its rank andchooses his preferred parent.

Downward routes A downward route, on the contrary, is a route a packetsfollows from the DODAG root towards a node in the DODAG. When a node hasreceived a DIO and accepts the router that issued it as a parent, it sends back aunicast DAO to its new parent. DAOs are then forwarded up to the root. RPLsupports 2 different downward routing modes: storing and non-storing mode. Inboth cases, P2P packets have to go up towards the DODAG root using preferredparents at each hop. In non-storing mode, the packet will necessarily go throughthe root node, but in storing mode, it may start going down towards the finaldestination from the first common ancestor.

Figure 10: Example of RPL Network Startup

Maintaining the Topology In time, the topology can change. In order tokeep the topology-related information up to date for all the nodes, RPL specifies2 mechanisms. First, when a router detects a change (for instance, a routerbecomes unreachable), it will send out a DIO with an incremented DODAG

28


Figure 11: Stack implementation - distribution between application and stacktask

version number. If a router receives a DIO with a greater version number thatthe one it had in memory, it recomputes its rank, performs the appropriateoperations on its table of parents, and sends out a new DIO with the newversion number. This makes sure that the information is disseminated withinthe network, and is called a global repair. Secondly, all routers regularly emit aDIO, in order to inform their children that nothing has changed. This emissionof DIO is triggered by the Trickle Algorithm [15], which aims at minimizing therate 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, itwas natural to use this implementation, in order to avoid integration difficul-ties. However, ContikiRPL does not include all the possibilities offered by theROLL WG in the specification of RPL. In particular, it works with only oneRPL instance, which does not allow the superposition of different metrics inthe network and the differentiation of the metric depending on the message’spriority.

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 weperformed here has been testing this implementation in several configurations,and evaluating its performance. The conclusions are presented in the Resultssection of this report.

29


4 REST Architecture and Node ManagementInterface

The Diaforus project includes some on the fly node configuration requirements.The manageable parameters can be of various kinds. For instance, one couldneed 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 stan-dard 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, usingthe HTTP protocol. However, HTTP is an ASCII protocol, not optimized interms of message length. Thus, it is not adapted for the publication of resourcesfrom nodes located in highly constrained networks such as LLNs. In this context,the Constrained Application Protocol, CoAP, is an attempt to palliate to thelack of optimized protocol that can be used to build RESTful architectures inthese networks [10].

4.1.1 Header Format

Packet headers can usually be efficiently modified to shorten the average lengthof the packets. The first important point in CoAP is indeed its short header.It starts with 4 bytes that contain header information, organized following theschema presented figure 12.

Figure 12: CoAP Header

More options can be added after this header, depending on the operationperformed, 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 possiblevalue 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 anyacknowledgment,

– ACKNOWLEDGMENT,

30


– RESET: if a received message does not correspond to any coherentcontext, the receiver must send a RESET message to the sender.

� OC: Option Count, the amount of options added to the standard CoAPheader.

� 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 HTTPcode:

– 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, thatdetermine the code of the option, then the option length, and finally the option’sdata. The option’s code itself is not put in the 4 first bits. The value of this fieldis actually the difference between the currently processed option’s code and theone of the previous option processed (option delta). Consequently, if there aremore than one option included in the message, they must appear following aspecific order. The way options are included in the CoAP header depends alsoon 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 CoAPspecification. They are close to the options available in HTTP. Some or themore common are:

� URI-Path, e.g. the string representation of the resource concerned by therequest/response,

� Token, used for security uses,

31


� Max-Age, for caching,

� Content-Type, in order to know how to handle the payload of the re-quest/response,

� Subscription-Lifetime, used in the publisher-subscriber specification.

Finally, a payload can be added in the requests and responses. PUT andPOST requests can include payload in order to create or modify a resource on aserver node, and responses from the server node include the state of the resourcein the payload. No length field is included in the header, since this length canbe inferred from the UDP length and the processing of the CoAP header.

4.1.2 Gateway ↔ CoAP gateway

The fact CoAP designers sticked to the HTTP specification regarding the meth-ods and the response codes used allows the interconnection of the standard In-ternet cloud and nodes publishing resources using CoAP from a LLNs usingsimple gateways. The general architecture of the system is shown figure 14.

Figure 14: Interconnection of Internet and LLNs in a RESTful environment

4.1.3 CoAP Subscription Protocol

In some applications, the resource consumers need to be constantly up to datewith the resource owner. The CoAP design includes support for the observer-subscriber design pattern, so the information is pushed to all the resource con-sumers on the network when a change occurred in the resource’s context. It isspecified in [11].

If the operation is unicast (multicast is also a supported possibility, withsome constraints), the publisher must implement a node list, that keeps trackof the subscribers, using their network address, the associated UDP port, anda lifetime for the subscription. One node list is associated to one particularresource.

The messages pushed to the subscribers can request an acknowledgment ornot. This choice must be done depending on the application’s needs: it is a

32


Figure 15: Observer-Subscriber mechanism in CoAP

trade off between power consumption, since sending an acknowledgment costsenergy to the subscriber, and the necessity for the system to make sure that thesubscribers are up to date at any moment.

4.2 Node Management on top of CoAP

Two types of management parameters have been distinguished: runtime param-eters and startup parameters. The first ones are essential to be able to alterthe behavior of the system once it has been deployed and started running. Thesecond ones are necessary in order to keep track of changes in time, even afterthe nodes have been switched off.

Thus, the management of the current and startup parameters on the chip isan important part of the project. It has been decided to expose the 2 followingREST web services from the nodes :

� Current configuration, under the URI /run mgt, which represents a set ofvariables that can be changed on the fly when the system is running,

� Startup configuration, under the URI /start mgt, which represents a setof variables that are loaded when the power is switched on and the systemboots.

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. Thisserver is initialized during the application task initialization, in particular byopening a UDP connection on the CoAP default port. The core function ofthe server is thus the callback associated to this connection, that is responsible

33


for parsing and handling CoAP requests on the server’s UDP port (the activitydiagram of the Application Task Loop is shown in figure 16, with CoAP serverfunctionalities).

Figure 16: CoAP Server: Activity Diagram

These resources are actually an aggregation of several fields, correspondingto an ASCII key. The reason for proceeding this way is that we wanted tominimize the memory footprint in RAM: this aggregation allows transfering thememory needs from RAM to ROM (in the code).There are two kind of REST methods accepted on the management : the GETmethod to obtain the value associated to one or more keys, the PUT method to

34


change the value associated to one or more key7. The payload of the requestsmust be formatted as following:

� For the GET method:

– No payload, if the request concerns all the values included under thename of the resource,

– key + 0x0, repeated for each key covered by the request, key is inASCII characters.

� For the PUT method:

– key + 0x0 + n + 0x0 + value, repeated for each key covered bythe request, key is in ASCII characters, n is the amount of bytesnecessary for coding the value associated to the key,

– No payload, and then the PUT request is equivalent to a global GETrequest.

7The policy to access and read or modify the management resources is out of scope of thisreport.

35


5 Results and expected developments

5.1 Simulation Results

In the first step of the project, the target devices were not available, and a sim-ulation environment has been developed in order to test the stack. It was notbuilt from scratch, but based on a first, simplistic version used by one of thepartners in the Diaforus project (Telecom ParisTech). Its architecture is basedon a dispatcher in Python on the one hand, and a FreeRTOS-Wavenis simulatoron the other hand. The code to be tested is included in the FreeRTOS-Wavenissimulator (figure 17).

In order to simulate a real network, the dispatcher uses a XML configurationfile to be able to decide whether a packet must be dispatched, and to whichnode it must be delivered (using a matrix containing booleans, representing thelinks between the nodes). This feature is important because it is the only wayto test the Neighbor Discovery protocol implementation, as well as the RPLimplementation. This file is also seeded to the FreeRTOS part of the simulator,so the simulated nodes can be configured dynamically. We defined a XMLschema so the simulator can be reused easily in the future (appendix B).

Communication Protocols The first tests where performed in order to con-firm the successful integration of IPv6/6LoWPAN in the FreeRTOS operatingsystem. Two tests were successfully operated:

� Auto-configuration and Neighbor discovery,

– Due to the fact that no gateway was implemented at first, DuplicateAddress Detection was tested as in wired networks, not as specifiedin the 6LoWPAN specification,

– Neighbor discovery was tested sending a Neighbor Solicitation to astatic address that is supposed to be in the neighborhood. The neigh-bor receives a Neighbor Solicitation with its solicited-node multicastaddress, and sends a Neighbor Advertisement including its link-layeraddress,

– Neighbor reachability has been successfully tested by simply killingthe process of the destination node, and observing the reaction of thesender (it sends a few Neighbor Soliciation to the destination nodein unicast).

� ICMPv6 and UDP communication, validating in particular the manage-ment 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 net-work using the XML configuration file (the file is joined in Appendix C). Thesimulated network was constituted of 11 nodes, configured with specific rangesthat do not give more than one possible graph for RPL, using the Objective

36


Figure 17: Simulator Architecture

Function 0 [23]. The characteristics of this network can be observed in figure18(a). We also developed a simple GUI, that reads the configuration file anddraws the different nodes in the network. Then, the messages that are dis-patched by the network simulator are spied, and when a DAO is detected8, alink between the source and destination of the packet is drawn. The resultingtopology is shown figure 18(b) (page 38). The graphical interface can also de-tect the emission/forwarding of ICMPv6 packets (Echo Request and Echo Replytypes), by enlightening in red the node that sends the packet. When a Pinghas been performed from outside the simulator to the very ”bottom” of thenetwork, the enlightened nodes have shown that the forwarding functionalitieswere functioning properly.

RPL has been designed using the Trickle algorithm in order to decrease theaverage number of packets needed to maintain a coherent network. An analysison the packet emission rate within this same network has been realized. Weobtained a result similar to [9]9, and is presented figure 19.

The time scale is not representative, because the simulation environmentcannot be assimilated to the actual platform in terms of speed, but several factscan be observed :

� The rate is decreasing fast,

� Some peaks of emission can be observed, triggered by the expiration ofthe RPL timer at one of the nodes in the network. The peaks are moreand more distant in time.

8A DAO is always sent by a node to its direct ancestor, and thus reflects directly a routebetween these nodes.

9They actually measured the power consumption of RPL, but since the transceiver isthe most power-consuming component, we can assume that the correlation between powerconsumption and emission rate is close.

37


(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 satisfyingregarding several points :

� The routing/forwarding functionalities have been successfully integrated,

38


Figure 19: Emission rate of RPL packets (topology from figure 18(a)),

tx rate(t) =#{packets emitted between t−5 and t+5}

10 .

� The routing algorithm is working well, since all the nodes tend to get thesmaller possible rank within the DODAG,

� The emission rate tends to be small, increasing the potential lifetime ofthe node’s battery.

Application Protocol, RESTful architecture The implementation of theCoAP-based web services started using the Contiki beta v2.5. However, thisimplementation of the CoAP protocol is not complete, and some work has beendone to make it compliant with [11]. The first tests have been performed inCoAP-only context, simulating a client node, running FreeRTOS on top of thedispatcher, and a server node, publishing resources in the same context. Thetests have been successful, including using the network topology shown figure18(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 sendpackets from outside the LoWPAN to a node simulated inside the LoWPAN.The root of the RPL DODAG forwards the traffic to the simulator, that forwardsit, after 6LoWPAN uncompression, to the tunnel interface.

Some basic 6LoWPAN to IPv6 and IPv6 to 6LoWPAN functions have alsobeen implemented in Python, to be integrated in the framework, redirectingall the traffic from the tun0 interface to the root node in the network, aftercompressing the headers. The Ping protocol has been successfully tested usingthe following command line from a Linux terminal to ping the node 1 in thenetwork represented figure 18(a):

ping6 -I tun0 abcd::1063:09ff:fe30:4d3

Moreover, a HTTP ↔ CoAP connection has been realized between the sim-ulated network and the real Internet. The basic purpose is to demonstrate the

39


1 # crea te v i r t u a l i n t e r f a c e2 tunne l sock = os . open ( ”/dev/net /tun” , os .ORDWR)3 i f s = i o c t l ( tunne l sock , 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” )67 # con f i gure IPv6 address8 v = os . system ( ’ i f c o n f i g ’ + ifname + ’ in e t 6 add ’9 + IPV6PREFIX + ’ : : 1 / 6 4 ’ )

10 v = os . system ( ’ i f c o n f i g ’ + ifname + ’ in e t 6 add f e80 : : 1 / 6 4 ’ )11 v = os . system ( ’ i f c o n f i g ’ + ifname + ’ up ’ )1213 # se t route14 os . system ( ’ route −A ine t6 add ’ + IPV6PREFIX15 + ’ : : / 6 4 dev ’ + ifname )1617 # enab le IPv6 forwarding18 os . system ( ’ echo 1 > /proc / sys /net / ipv6 / conf / a l l / forward ing ’ )

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 standardHTTP-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 thenode having the IPv6 address xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx. Ifthe request is directed to the web server’s root, an AJAX-based web page issent back, demonstrating the standard resource discovery mechanism includedin CoAP (/well-known resource). The page contains a text field, where theuser can type an IPv6 address. Clicking on the button ”Send Request” sends arequest to well-known resource of the provided IPv6 address. The response isparsed and used to display a list of resources, their value, and a field that canbe used to post a new value for the resource it belongs to.

40


5.2 Results on the Excelyo Modules

5.2.1 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 thefollowing 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 ob-servation ...),

– JTAG connection,

� 4 kBytes DRAM memory,

� 48 kBytes IRAM memory,

� 128 kBytes optional EEPROM (SPI Bus connected flash, not available atthe moment this report is written),

Since the EEPROM driver is not yet available, the total amount of memoryis 52 kBytes. Up to 48 kBytes can be allocated to the code, 4kBytes are atleast available for RAM data. If necessary, a part of the 48 kBytes in IRAMcan be allocated to RAM data as well, but the space available for the code isthen reduced.

5.2.2 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 re-produced on the real platform, in order to validate the ND protocol, the UDPprotocol and the Ping protocol.

5.2.3 RPL on chip

This could not be tested at the moment, due to a lack of memory space. Theproblem should be solved when the use of the 128 kB EEPROM is possible.

5.2.4 RESTful services on chip using CoAP

The implementation of the CoAP protocol has been successfully tested on theExcelyo nodes, under some constraints. Due to memory constraints, the lengthof the URIs has been limited, which does not allow a deep hierarchy and descrip-tion of the services (in particular, the ./well-known/r resource cannot providean extensive description of the published resources, otherwise the packets wouldnot fit in the small buffer).The first test has been performed between two nodes, a server and a client. Theserver configuration included a resource at the URI ”/leds”, represented on thedevice by 4 LEDs. The state of the resource could be changed, using 4 switches

41


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 switcheson 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 isdisplayed 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, butnothing 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 isdisplayed 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 serversent a spontaneous update since the subscription is valid.

A second test has been performed for the PUT method, on the same re-source. The server node was the same as for the previous test. The clientnode’s application changed, the switches were used to configure the value tosent to the server using the PUT method.

Interconnection with the real world: CoAP has be designed to be easilymapped to HTTP. Thus, one should write quite easily a gateway/proxy for thetranslation HTTP ↔ CoAP. The driver for the USB Wavenis Modem arrivedlate in the work realized on CoAP, but however, a simple application has beenwritten in Java, translating IPv6 to 6LoWPAN and HTTP to CoAP. The sameweb page as in the simulation test has been used, and the resource discoveryand resource access demonstrated.

5.2.5 Summary

The integration of the network layer is thus complete in the simulation environ-ment, including the IPv6 ↔ 6LoWPAN gateway. For the real platform, somedevelopments remain to be done, because of hardware limitations. Some workis 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 usethe flash memory.

42


5.3 Proposition of a New Architecture

In the initial definition of the project, all the nodes were supposed to be Excelyonodes, connected to all possible kind of sensors or actuators. The problem withthat is the lack of memory at the moment. After working more than one monthon optimizing the code size and reducing the need for memory, the analysisof memory available against memory needs has shown that in the current con-figuration, Excelyo modules were not yet adapted to the Diaforus project (theanalysis is presented figure 5.3). Thus, a new proposal of architecture has beendesigned in order to keep the project running until the expected improvementshappen.

Figure 22: Analysis of the needs for memory in the network layer. The negativevalues in the memory balance cell (IRAM + DRAM - Needs) means that there isnot enough memory. The basic project includes the FreeRTOS version providedby Coronis, and the Wavenis layer, nothing more.

However, since CoAP was to be included into the nodes already, a newarchitecture has been proposed, based on the use of more poweful (but stillsmall) nodes and Wavenis USB modems. The publish-subscribe applicationdeveloped in the project was not to be changed, and cannot be included in theExcelyo nodes at the moment. The idea of the proposed architecture is to usemore powerful nodes for routing and publish-subscribe operations, and Excelyomodules as lighter sensor nodes.

43


5.3.1 Points taken into account in the design

1. The first point taken into account was to keep the publish-subscribe un-changed. Changing it at this point would undermine the work accom-plished in this way,

2. The second point was to keep Wavenis as a data-link layer protocol, aswell as keep the Excelyo modules in the list of used devices, because ofthe features implemented (or that are to be implemented later) and of thegood power efficiency of the hardware.

5.3.2 Brief presentation

Figure 23: Alternative network architecture

The core nodes, embedding the publisher-subscriber mechanism, form a net-

44


work that can be assimilated to the original network. However, they no longerpublish a static list of resources, but more a list of services obtained from satel-lite nodes, running on Excelyo. They can obtain the list of services from asatellite node sending a GET request on the ./well-known/r resource, and pub-lish 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 viewof the resource because of the observer-subscriber feature in CoAP, andthus can really be considered as a sensor on the upper abstraction layer,

� The satellite nodes (Excelyo) will not send any CoAP packet unless acore node has subscribed to a resource. This happens only when theupper abstraction layer needs to get the resource. It is therefore reallypower efficient, because 1) the Excelyo does not need to send data if notexplicitely requested, 2) the push mechanism spares energy on the core-node side.

45


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’sstandards, using standard IPv6 and UDP protocols, and is also better suitedthan a usual stack to the constrained nodes used in the project. This part ofthe work consisted of understanding the µIPv6 implementation, modifying theframework embedded on the FreeRTOS operating system and verifying the per-formance of the final system.

The tests performed with the Excelyo nodes have shown that standard IPv6communications were working, including the Neighbor Discovery protocol. Thehandling of ICMP is included. It has been used to show the interconnectioncapabilities of the system to a standard network, through a ”Ping” from a stan-dard Linux terminal and a basic gateway to compress IPv6 into 6LoWPAN (andreciprocally from 6LoWPAN to IPv6). Finally, the UDP protocol has been in-tegrated, as an interface between the application and the network. The API weproposed is now used by the other teams working in the Diaforus project, withconvincing results. In terms of power consumption, the resulting 6LoWPANheaders 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 proto-col. This implementation has been designed in the same idea as the underlyingcommunication stack, e.g. with a standardization effort. We demonstrated thestrong interconnection capabilities to the standard web technologies by access-ing and modifying resources located on the physical nodes from a web browser.

However, some questions are yet to be solved. The routing protocol wechose, RPL, could not be tested on the real nodes. We only tested it in thesimulation environment, because of technical locks on the memory space avail-able on the Excelyo nodes during this thesis was written. This study of theContikiRPL implementation has been helpful to understand how this protocolworks, but it would have been better to be able to build actual networks usingreal wireless sensors. This should be relatively straightforward, thanks to therecent improvements on the nodes.

Another question is to test the final publish-subscribe middleware and in-network reasoning that are currently under development on the nodes on topof this architecture. The implementation of our stack is very constrained interms of payload size. Because of memory issues, no fragmentation can be im-plemented. Thus, the payload on top of UDP is limited to approximatively 100bytes. 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 theproject, we proposed an alternative architecture, that respects the requirementsof the Diaforus on the one hand and that should allow the project to keepevolving towards the resolution of the initial problem.

46


References

[1] Coronis, an Elster Group company - http://www.coronis.com.

[2] FreeRTOS: Free Real Time Operating System - http://www.freertos.org/.

[3] Swedish institute of computer science - http://www.sics.se/.

[4] uIP - http://www.sics.se/ adam/uip/index.php/main page.

[5] Wavenis OSA presentation - http://www.wavenis-osa.org/.

[6] Alicia Asin and Manuel Caloharra. Sensor networks to monitor air pollutionin cities - http://www.libelium.com/libeliumworld/articles/102732734500,September 2010.

[7] Z. Shelby S. Chakrabarti and E. Nordmark. Neighbor discovery optimiza-tion for low-power and lossy networks, December 2010.

[8] S. Deering and R. Hinden. RFC 2460: Internet protocol, version 6 (IPv6)specification, December 1998.

[9] N. Tsiftes J. Eriksson and A. Dunkels. Low-power wireless ipv6 routingwith contikirpl. April 2010.

[10] Z. Shelby B. Frank and D. Sturek. Constrained application protocol (coap),October 2010.

[11] K. Hartke and C. Bormann. Observing resources in coap, August 2010.

[12] J. Hui. Lowpan fragment forwarding and recovery, June 2010.

[13] J. Hui and P. Thubert. Compression format for ipv6 datagrams in 6lowpannetworks, September 2010.

[14] IEEE. Guidelines for 64-bit global identifier (EUI-64) registration author-ity.

[15] T. Clausen P. Levis J. Hui O. Gnawali J. Ko. The trickle algorithm, January2010.

[16] N. Kushalnagar and G. Montenegro. RFC 4944: Transmission of IPv6packets over IEEE 802.15.4 networks, September 2007.

[17] C. Kaufman R. Perlman and M. Speciner. Network Security: Private Com-munication in a Public World.

[18] N. Kushalnagar G. Montenegro C. Schumacher. RFC 4919: IPv6 overlow-power wireless personal area networks (6LoWPANs): Overview, as-sumptions, problem statement and goals, August 2007.

[19] Z. Shelby and C. Bormann. 6LoWPAN, The Wireless Embedded Internet.2009.

[20] T. Narten E. Nordmark W. Simpson and H. Soliman. RFC 4861: Neighbordiscovery for IP version 6 (IPv6), September 2007.

47


[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 andlossy networks, December 2010.

[22] S. Thompson and T. Narten. RFC 2462: Stateless address autoconfigura-tion, December 1998.

[23] P. Thubert. Rpl objective function 0, January 2011.

48


Appendices

A Vocabulary

� CoAP : Constrained Application Protocol. Defined by the CoREWG fromIETF.

� CSMA/CA: Carrier Sense Multiple Access with Collision Avoidance. Mech-anism used to share the radio channel between different nodes that wantto send data at the same moment, based on a ticketing system.

� DAG : Directed Acyclic Graph. In a wireless network, DAGs are typicallythe topology one want to build using a routing protocol: directed, becausethe fact that a node can reach another one in the network does not implyreciprocity, acyclic because infinite loops would be created otherwise.

� DAO : DODAG Advertisement Object, ICMPv6 message used by RPL tobuild downward routes.

� DIAFORUS : DIstributed Applications and Functions Over RedundantUnattended Sensors

� DIO : DODAG Information Object, ICMPv6 message used by RPL toadvertise routing information.

� DIS : DODAG Information Solicitation, ICMPv6 used by RPL to requestrouting information to the neighboring routers.

� DODAG : Direction Oriented DAG. In RPL, it is a routing graph associ-ated 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 whosenodes are constrained in terms of energy consumption, built on lossy andlow-bandwidth communication channels.

� MAC : Media Access Control. Lower sub-layer of the data-link layer inthe OSI model.

� MTU : Maximum Transmission Unit, the maximum length of a packetencapsulated using the concerned protocol.

� ND : Neighbor Discovery, an IPv6 protocol used to detect duplicate ad-dresses, neighbor unreachability, and to obtain the neighbors MAC addressor routing information.

� Objective Function (OF): the function used by RPL to compute the rank ofa node regarding the network topology. It must be unique within a singleRPL instance. It is not defined by RPL, and can use different metrics andalgorithms (the ROLL WG proposed a default function, OF0, defined in[23])

49


� REST : Representational State Transfer, style of software architecture fordistributed systems. It is based on the publication of resources, usuallyover the HTTP protocol.

� RPL: IPv6 Routing Protocol for LLNs.

� SoC : System on Chip.

� TDMA: Time Division Multiple Access. Mechanism used to share theradio channel between several senders, based on the synchronization ofthe nodes and the allocation of time slots for emission.

� WSN : Wireless Sensor Network.

50


B XML Configuration File Specification

1 <xs:schema xmlns :xs=” ht tp : //www.w3 . org /2001/XMLSchema”>2 <xs : e l ement name=”network”>3 <xs : annota t i on>4 <xs :documentat ion>5 Presenta t i on o f the d i f f e r e n t f i e l d s :6 − The root path i s the l ong e s t common part o f a l l7 the path to the f irmware8 − The f i rmware path i s d i f f e r e n c e between the9 abso lu t e path to the f irmware and the root path

10 − A node i s r ep r e s en ted by i t s p o s i t i o n (X,Y) , and i t s range11 ( the maximum d i s t anc e that can be reached in emis s ion by the12 node ) , an ID that i s used by the d i spa t che r to r e t r i e v e the13 node , and by the node to bu i ld i t s MAC address14 − A node can inc lude a sequence o f key−value p rope r t i e s , that15 can be used e i t h e r by the node or the d i spa t che r .16 </ xs :documentat ion>17 </ xs : annota t i on>18 <xs:complexType>19 <xs : s equence>20 <xs : e l ement name=” root path ” type=” x s : s t r i n g ”/>21 <xs : s equence maxOccurs=”unbounded” minOccurs=”0”>22 <xs : e l ement name=”node”>23 <xs:complexType>24 <xs : s equence>25 <xs : e l ement name=”node id ” type=” x s : i n t ”/>26 <xs : e l ement name=”posx” type=” x s : f l o a t ”/>27 <xs : e l ement name=”posy” type=” x s : f l o a t ”/>28 <xs : e l ement name=” range ” type=” x s : f l o a t ”/>29 <xs : e l ement name=” f i rmware path ” type=” x s : s t r i n g ”/>30 <xs : s equence maxOccurs=”unbounded” minOccurs=”0”>31 <xs : e l ement name=”property ”>32 <xs:complexType>33 <xs : s equence>34 <xs : e l ement name=”key” type=” x s : s t r i n g ”/>35 <xs : e l ement name=”value ” type=” x s : s t r i n g ”/>36 </ xs : s equence>37 </xs:complexType>38 </ xs : e l ement>39 </ xs : s equence>40 </ xs : s equence>41 </xs:complexType>42 </ xs : e l ement>43 </ xs : s equence>44 </ xs : s equence>45 </xs:complexType>46 </ xs : e l ement>4748 </xs:schema>

51


C XML Configuration File for RPL Testing

1 <?xml version=” 1 .0 ”?>2 <network>3 <root path>/home/ t a i /Debug/</ root path>4 <node>5 <node id>1234</ node id>6 <posx>0</posx>7 <posy>0</posy>8 <range>90</ range>9 <f i rmware path>d i a f o r u s p r o j e c t</ f i rmware path>

1011 </node>12 <node>13 <node id>1235</ node id>14 <posx>0</posx>15 <posy>75</posy>16 <range>90</ range>17 <f i rmware path>d i a f o r u s p r o j e c t</ f i rmware path>18 </node>19 <node>20 <node id>1236</ node id>21 <posx>75</posx>22 <posy>0</posy>23 <range>90</ range>24 <f i rmware path>d i a f o r u s p r o j e c t</ f i rmware path>25 </node>26 <node>27 <node id>1237</ node id>28 <posx>0</posx>29 <posy>150</posy>30 <range>90</ range>31 <f i rmware path>d i a f o r u s p r o j e c t</ f i rmware path>32 <property>33 <key>myKey</key>34 <value>myValue</ value>35 </ property>36 </node>37 <node>38 <node id>1238</ node id>39 <posx>150</posx>40 <posy>0</posy>41 <range>90</ range>42 <f i rmware path>d i a f o r u s p r o j e c t</ f i rmware path>43 </node>44 <node>45 <node id>1239</ node id>46 <posx>30</posx>47 <posy>180</posy>48 <range>45</ range>49 <f i rmware path>d i a f o r u s p r o j e c t</ f i rmware path>50 </node>51 <node>52 <node id>1240</ node id>53 <posx>180</posx>54 <posy>30</posy>55 <range>45</ range>56 <f i rmware path>d i a f o r u s p r o j e c t</ f i rmware path>57 </node>58 <node>59 <node id>1241</ node id>60 <posx>−30</posx>

52


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

53


D Demonstration Board used for testing

The Excelyo Ref Design modules used in the Diaforus project can be plugged ina demo board, that provides several different sensors and actuators. In particu-lar, 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 toshow that a message has been received.

54


E Network Layer - Activity Diagram

Figure 24: Activity Diagram of the Network/Transport Layers Implementation

55


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. (fullvideo at http://tinyurl.com/6dny6on)

56


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 betweenCoAP and HTTP. The table is not displayed at first, but is generated fromthe ./well-known/r resource of the node. Then the user can get the value of aresource available on the node, and try to post a value to change the resourcestate.

57

design and implementation of an ipv6 architecture for ...415878/fulltext01.pdf · compressing the...

Documents