Design and Implementation of an IPv6 Architecture for Wireless Sensor Networks

(1)

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

(2)

Design and Implementation of an

IPv6 Architecture for Wireless Sensor Networks

Author:

Alexandre Sadones sadones@kth.se

Examiner:

Markus Hidell mahidell@kth.se

Supervisor:

Mario Lopez-Ramos mario.lopezramos

@fr.thalesgroup.com

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.

(5)

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 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¨ogskolan, 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 break- fasts we shared, the poker games we played, and the heated discussions we had almost every day about everything.

(6)

List of Figures

1 Excelyo SoC . . . 11

2 Wake-up preamble mechanism . . . 12

3 Inter-task communication using queues . . . 13

4 6LoWPAN Dispatch Byte . . . 15

5 Stateless Header Compression . . . 17

6 Context-Based Header Compression . . . 18

7 Node Registration . . . 20

8 The Wavenis stack architecture . . . 22

9 UDP architecture . . . 24

10 Example of RPL Network Startup . . . 28

11 Stack implementation - distribution between application and stack task . . . 29

12 CoAP Header . . . 30

13 CoAP Header Option . . . 31

14 Interconnection of Internet and LLNs in a RESTful environment 32 15 Observer-Subscriber mechanism in CoAP . . . 33

16 CoAP Server: Activity Diagram . . . 34

17 Simulator Architecture . . . 37

18 RPL Testing in the Simulation Environment. . . 38

19 Emission rate of RPL packets . . . 39

20 Creation of an interface under Unix environments . . . 40

21 Sequence Diagram of the CoAP Gateway . . . 40

22 Analysis of the needs for memory in the network layer . . . 43

23 Alternative network architecture . . . 44

24 Activity Diagram of the Network/Transport Layers Implementation 55 25 CoAP GET request test . . . 56

List of Tables

1 Possible values for the 6LoWPAN Dispatch Byte . . . 16

2 Stateless vs Context-based Header Compression . . . 19

(9)

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

(10)

Its activities in the field of electronics also cover the Intelligence / Surveil- lance / Reconnaissance segment for Joint services. In 2009, its sales amounted to 1.473 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.

1.1.2 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. Sec- ondly, 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 high- precision 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 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 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

(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 redis- tribute rules and roles.

1.2.1 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. Application- awareness 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.

1.2.2 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

(12)

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

(13)

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 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 Alliance¹ [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 inter- ferences,

– Forward Error Correction, adding redundancy in the communication,

1Involving for instance Elster, Orange, Veolia or Cisco

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

(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 s t r u c t s W a v e n i s B u f f e r { 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.

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

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

3.1.2 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².

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

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

(17)

(102 bytes for IEEE 802.15.4, 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].

3.1.3 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

(18)

From To Allocation

00 000000 00 111111 NALP - Not a LoWPAN frame

01 000000 Reserved for future use

01 000001 IPv6 packet (no 6LoWPAN-specific operation required) 01 000010 LOWPAN HC1 - compressed IPv6 (stateless)

01 000011 01 001111 Reserved for future use

01 010000 LOWPAN BC0 - Broadcast

01 010001 01 011111 Reserved for future use

01 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 packet 11 001000 11 011111 Reserved for future use

11 100000 11 100111 FRAGN - Fragment (not first) 11 101000 11 101011 proposed for fragment recovery 11 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 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³: 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,

3Source/Destination Address Encoding

(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, indi- cating 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

(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⁴).

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

(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 2.

3.1.5 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 802.15.4, 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).

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

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 address collisions, and the neighbor discovery protocol [20] is used to detect neigh- bors in the range of a node⁵. 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 solicited- node 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

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

(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⁶, 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 Ex- celyo 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.

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

6The Node Confirmation is also used when the address is already used and that the registration is refused.

(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 defi- nitions:

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.

3.2.2 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

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

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

(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

(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, request- ing the emission of the data passed as parameter on the specified UDP connection.

(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].

3.3.1 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]:

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

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

(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

(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 difficul- ties. 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.

(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].

4.1.1 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,

(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,

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

4.1.2 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 In- ternet 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

4.1.3 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 observer- subscriber 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

(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

(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

(37)

change the value associated to one or more key⁷. 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.

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

(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

(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⁸, 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]⁹, 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.

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

9They 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.

(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,

(41)

Figure 19: Emission rate of RPL packets (topology from figure 18(a)), tx rate(t) = ^#^{packets emitted betweent−5 andt+5}

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

(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 = o s . open ( ” / dev / n e t / tun ” , o s .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 ( ” 16 sH” , ” tun%d” , IFF TUN ) ) 5 i f n a m e = i f s [ : 1 6 ] . s t r i p ( ”\x00” )

6

7 # c o n f i g u r e IPv6 a d d r e s s

8 v = o s . s y s t e m ( ’ i f c o n f i g ’ + i f n a m e + ’ i n e t 6 add ’

9 + IPV6PREFIX + ’ : : 1 / 6 4 ’ )

10 v = o s . s y s t e m ( ’ i f c o n f i g ’ + i f n a m e + ’ i n e t 6 add f e 8 0 : : 1 / 6 4 ’ ) 11 v = o s . s y s t e m ( ’ i f c o n f i g ’ + i f n a m e + ’ up ’ )

12

13 # s e t r o u t e

14 o s . s y s t e m ( ’ r o u t e −A i n e t 6 add ’ + IPV6PREFIX 15 + ’ : : / 6 4 dev ’ + i f n a m e )

16

17 # e n a b l e IPv6 f o r w a r d i n g

18 o s . s y s t e m ( ’ e c h o 1 > / p r o c / s y s / n e t / i p v 6 / c o n f / a l l / f o r w a r d i n g ’ )

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.

Design and Implementation of an IPv6 Architecture for Wireless Sensor Networks