IT 17 077

Examensarbete 30 hpOktober 2017

OpenThread vs. Contiki IPv6: An Experimental Evaluation

Christoph Ellmer

Institutionen för informationsteknologiDepartment of Information Technology

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

OpenThread vs. Contiki IPv6: An ExperimentalEvaluation

Christoph Ellmer

Low-power wireless networks based on the IEEE 802.15.4 standard are widely usedfor emerging Internet of Things applications. So far, however, there is no standardnetwork stack for such networks. Different standardization bodies and industryalliances are driving their own standards, which hinders interoperability of IoT devicesand hence slows down growth in this sector.Furthermore, it is little known how the different stacks compare in performance. Thismaster’s thesis contributes by conducting a comparison between two network stacksfor such low-power networks: the IPv6 network stack of the Contiki operatingsystem and OpenThread. Contiki is a well known operating system tailored forlow-power networks and its IPv6 network stack implements various IETF RFCs.OpenThread is an open source implementation of Thread. Thread focuses onlow-power networks in the home environment and as recently published by theThread group, an alliance of companies active in the field.In this master’s thesis we port OpenThread to Contiki and compare both stacks withrespect to latency, packet loss, and implementation complexity. For this purpose weconduct experiments focusing on point-to-point traffic between devices in alow-power wireless network. The experiments are performed in a testbed of IoTdevices, which is installed in an office environment. We find that neither stackoutperforms the other.

Tryckt av: Reprocentralen ITCIT 17 077Examinator: Arnold Neville PearsÄmnesgranskare: Thiemo VoigtHandledare: Nicolas Tsiftes and Joakim Eriksson

Acknowledgments

I would like to show my gratitude to my supervisors at RISE SICS, Nicolas Tsiftes and JoakimEriksson for their guidance and feedback throughout the last months.

Furthermore I would like to thank Thiemo Voigt and the Networked Embedded Systems Groupat RISE SICS for the friendly working environment.

Special thanks go to Derrick Alabi for the good times and discussions throughout the Thesisand the Master’s Program.

Contents

1 Introduction 11.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 32.1 The Contiki Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Low-Power Wireless Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4.1 Header Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.2 Packet Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.3 Link Layer Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 Contiki IPv6 Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5.1 RPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5.2 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.6.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6.2 Routing Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.6.3 Encryption, Commissioning And Joining . . . . . . . . . . . . . . . . . . 12

2.7 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.8 Alternatives For Low Power Networks . . . . . . . . . . . . . . . . . . . . . . . 13

3 Porting OpenThread to Contiki 153.1 Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Contiki’s and OpenThread’s Platform Abstraction . . . . . . . . . . . . . . . . 16

3.2.1 Radio module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.2 Random Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3 Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.4 Universal Asynchronous Receiver and Transmitter (UART) . . . . . . . 183.2.5 Logging and Misc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.6 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.7 Unimplemented Modules . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Evaluation 214.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

vii

4.2 Measuring Latencies And Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 224.3 Round-Trip Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.4 Packet loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5 Lines of Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.6 Firmware Sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Conclusions and Future Work 33

viii

Chapter 1

Introduction

The initial research of wireless sensor networks was motivated by military considerations; mostnotably the development of surveillance systems was of interest [33]. Nowadays wireless sensornetworks find use in a wide variety of applications like environmental or structural monitoring,industrial processes, or health related systems. The number of devices, also called nodes, in suchapplications ranges from a few to several thousands. The nodes typically perform only a limitedset of tasks like sensing and controlling the surrounding environment. Therefore the nodes areoften low-cost embedded devices with constrained computational resources, equipped with aradio transceiver. They are optimized for low energy consumption and can run on batteriesfor years, which makes them suitable to be placed at remote or non-fixed positions.

Due to the nodes’ low price tag and low energy consumption, low-power wireless networksplay an important role in the emerging Internet of Things (IoT). Examples for IoT applica-tions include smart solutions like power monitoring, heating, and lighting control for cities andbuildings. It is expected that the IoT grows from approximately 6 billion connected devices in2016 to 18 billion devices in 2022 [2]. In this huge market the development of industry stan-dards for communication in low power wireless networks is essential; a common, well-tested,and established standard speeds up application development and enables interoperability be-tween nodes running different operating systems. Different standardization bodies and industryalliances, however, try to establish their own standards.

With the advent and spread of IPv6 in recent years there is a trend to directly implement thisprotocol for low-power wireless networks. Contiki is a well known operating system tailoredfor such networks, which runs on a variety of platforms [16] [11]. Following this trend, itscurrent communication stack implements a variety of open standards1 for low-power wirelessIPv6 networking. The performance of Contiki’s low-power IPv6 stack has been thoroughlytested and it has been awarded the IPv6 Ready Silver logo [22][24][26].

During the last years, an industry alliance, the Thread group, developed a new IPv6-basednetwork stack called Thread [28]. It is specifically designed for smart IoT applications in homeenvironments, and tries to overcome the segregation in this market. It is partially based on openstandards, but until recently only members of the Thread group had access to the completeThread specification. An open source implementation, however, is available: OpenThread[42].

1 IETF RFCs, Internet Engineering Task Force Request For Comments

1

1.1 Problem Statement

In general there is little knowledge on how different communication standards for low-powerwireless networks compare in performance. The focus of this thesis is to conduct such acomparison between OpenThread and the Contiki operating system’s current low-power IPv6stack.

In order to establish similar prerequisites for the performance evaluation, I port OpenThread tothe Contiki operating system. I assess the latency and the packet loss rate of each stack, whichindicate the capability and reliability of the network, respectively. Since I only plan to evaluatethe network stacks in isolation we focus on point-to-point traffic between devices within thenetwork. The experiments are conducted in a testbed of IoT devices which is installed in anoffice environment. Additionally we study the firmware sizes to assess if the stacks are suitablefor the same type of physical devices.

1.2 Limitations

The goal of the thesis is to enable a comparison of OpenThread and Contikis IPv6 stackbased on similar assumptions. Therefore, OpenThread is ported to run on top of the Contikioperating system. It is, however, not the primary goal of this thesis to perfectly integrateOpenThread in Contiki; i.e., not all OpenThread features are incorporated in this port andit is not intended to include the port in the official Contiki repository. This poses potentialinaccuracies for the performance comparison since Contiki’s low-power stack is more tightlyintegrated within the operating system than the OpenThread port.

Furthermore, it is not intended to include other stacks for low-power wireless networks, likeOpenWSN [55], in the the comparison.

1.3 Contributions

This master’s thesis contributes to current research by conducting the first performance com-parison between OpenThread and Contiki’s low-power IPv6 stack. This is to the best of ourbest knowledge also the first comparison of a Thread-based network stack and a network stackwhich is solely based on IETF standards. The thesis shows that neither of the stacks outper-forms the other.

1.4 Thesis Structure

The remaining part of the thesis is organized as follows: Chapter 2 introduces the Contikioperating system and describes both Thread and the standards used in Contiki’s low-powerIPv6 network stack. Chapter 3 narrates the porting of OpenThread to Contiki. Chapter 4describes the experimental setup and discusses the results of the conducted latency and packetloss measurements. It also compares the implementation complexity of both stacks. Finally,Chapter 5 concludes with a summary and outlines future work.

2

Chapter 2

Background

This chapter describes the characteristics and the evolution of low-power wireless networks.It then focuses on the two network stacks of interest for this thesis, Thread and the Contikioperating system’s low-power IPv6 stack, and discusses the similarities and differences betweenthem. The first section shortly presents the Contiki operating system.

2.1 The Contiki Operating System

Contiki is a portable operating system designed for resource-constrained IoT devices [11]. Itincludes a small kernel, reusable application modules and hardware drivers for a variety ofsupported platforms.

Applications running on top of Contiki are implemented using processes which are scheduledand executed by Contiki’s kernel. The kernel uses a cooperative scheduling strategy, i.e., theprocesses either run to completion or return control to the scheduler on a voluntary basis. Aprocess can be preempted by interrupts, the preempted process however resumes directly whenthe interrupt handler returns. In order to obtain a responsive system the processes need toreturn control frequently.

The processes are implemented as Protothreads [17]. They share the stack with Contiki’skernel, which leads to a very small memory overhead and fast context switches. They werespecifically designed to facilitate an event-driven execution model and provide a variety of toolsto communicate with other processes via events. Synchronous events are immediately deliveredto the target process, and the sending process continues when the receiving process returnscontrol. Asynchronous events are inserted in an event queue and dispatched by the kernel.Processes often return control to the scheduler by blocking waiting for an event.

There are three wireless network stacks included in Contiki: Rime [20], an IPv4 stack, and anIPv6 stack. The IPv4 stack, uIP, was the first IP-based network stack for low-power wirelessnetworks [15]. It uses on-demand routing similar to the Ad-hoc On-demand Distance Vectorprotocol [13]: a node broadcasts the desired destination address and neighboring nodes thenadvertise if they have a route to the destination available. The Rime network stack uses asimilar routing strategy and is more lightweight compared to the IPv4 stack. Another on-demand routing protocol is LOADng1, which is still being actively developed [9].1 The Lightweight On-demand Ad-hoc Distance-vector Routing Protocol - Next Generation

3

For many platforms, however, the default network stack is the IPv6 stack, which is used for thecomparison with OpenThread. It uses a different routing strategy than the other two stacksand is described in more detail in the next sections.

2.2 Low-Power Wireless Networks

Before the advent of the IoT, most applications based on low-power wireless networks weredeployed at remote locations, which might be difficult to reach. In order to minimize themaintenance cost and to maximize the expected lifetime of the network, energy efficiency hasbeen a main objective of research. The energy consumption of the nodes is dominated by theradio idle-listening for incoming packets. This led to the development of duty-cycled link layerprotocols which strive to minimize idle listening. Examples of such protocols are B-MAC [46],X-MAC [8] and ContikiMAC [21].

Even though Contiki supported IPv4 from the beginning, the Internet Protocol was often con-sidered too complex and not appropriate for the characteristics of low-power wireless networks,which are primarily given by constrained access to energy and constrained computational re-sources. The active research in the field produced many lightweight ad-hoc network protocolslike Contiki’s Rime stack. Even industry-driven standardization attempts like ZigBee [4] andZ-Wave [5] were not based on the Internet Protocol. The lack of a common network layer withthe Internet, however, introduces several issues like the need for an application-layer gatewaythat translates between the two protocols. This is often difficult and packets might be droppedif no mapping exists. Furthermore such mappings are often stateful, which implies that onlyone gateway can be used to route the traffic between the sensor network and adjacent networks.This leads to a single point of failure in the application.

In 2008, Hui and Culler demonstrated the feasibility of the Internet Protocol version 6 forlow power wireless networks [31]. IPv6 has several advantages over IPv4, like the StatelessAddress Autoconfiguration (SLAAC) [47] and a huge address space. This way every node ina low-power network is directly addressable using a widespread technology, which simplifiesdevelopment and deployment of IoT applications. Since then several working groups withinthe Internet Engineering Task Force (IETF) worked on IPv6 related standards for low-powerwireless networks, amongst others the IPv6 over Low power Wireless Personal Area Networks(6LoWPAN) group, the Routing Over Low power and Lossy networks (ROLL) group, and theConstrained RESTful Environments (CoRE) group.

Low-power wireless networks often use the widespread IEEE 802.15.4 wireless communicationtechnology. The 6LoWPAN group standardizes the transmission of IPv6 packets using IEEE802.15.4 radios by means of the 6LoWPAN adaption layer [41]. This layer compresses thecomparatively large IPv6 and UDP headers and handles packet fragmentation and reassembly.It is part of Contiki’s IPv6 stack as well as of Thread, and is explained in more detail insection 2.4.

The ROLL group focuses on routing solutions for lossy, low-power networks, and released theRPL routing protocol in RFC6550 [51]. RPL is a major component in Contiki’s IPv6 stack andis discussed in section 2.5.1. The group also standardized the Trickle algorithm, a well-knownmechanism to disseminate information in a network in an energy efficient manner [38][37].Changes or inconsistencies in the network topology lead to a fast communication rate, whichthen decreases exponentially such that only a few routing protocol packets per hour are sent.

4

The Trickle algorithm is used in Thread and Contiki’s IPv6 stack to spread link quality androuting advertisements throughout the network.

The CoRE group focuses on the application layer of the network stack and specified the Con-strained Application Protocol (CoAP) in RFC7252 [49]. CoAP provides functionality similarto the HTTP application layer. It is based on UDP instead of TCP to account for the char-acteristics of lossy low-power networks. Both stacks, Contiki (see the er-coap application) andOpenThread, provide a CoAP implementation.

As is apparent from the previous paragraphs, Thread and Contiki’s stack partially utilize thesame technologies and protocols. The following sections focus first on the common parts, beforediscussing each stack in more detail.

2.3 IEEE 802.15.4

The IEEE 802.15.4 standard defines the physical layer and the medium access control layerfor low power and low data rate wireless personal area networks (WPANs). It either operatesin a region-dependent sub-GHz frequency band or in the worldwide unlicensed 2400 MHz to2483.5 MHz frequency range. The latter uses offset quadrature phase-shift keying (OQPSK)and offers a bit rate of 250 kB/s. The standard offers two different addressing modes: eitherthe unique extended 64-bit address of the low-power network interface is used or a 16-bit shortaddress which is obtained after association to the personal area network (PAN). The 16-bitaddress is unique within the PAN and its usage is preferred according to the standard.

Several revisions of the standard exist, Thread is based on the version published in 2006 [1] anduses the 2.4 GHz band exclusively. Contiki’s IPv6 stack is designed in a modular way and doesnot commit itself to a specific version of the IEEE 802.15.4 standard. Furthermore, Contiki’sIPv6 stack runs on top of other physical technologies like wired power-line communication(PLC) and Ethernet.

IEEE 802.15.4 compliant devices have an energy detection mechanism and provide both RSSI(radio signal strength indication) of received frames and LQI (link quality indication) to theupper layers. This information may be used to establish reliable routes in the network. Trans-mitters perform clear channel assessments (CCA) and implement a CSMA-CA (carrier sensemultiple access with collision avoidance) algorithm to minimize packet losses due to colli-sions.

The 802.15.4 standard defines a slotted and an unslotted mode of operation. In the unslottedmode devices may transmit anytime while in the slotted mode the channel access is organized bymeans of a superframe. A coordinator defines the superframe which is partitioned in timeslotswithin which the transmission of a frame has to be completed. Beside normal timeslots thereare also contentionless guaranteed timeslots (GTS). Devices with special bandwidth needs canexclusively use a GTS without utilizing the CSMA-CA algorithm. Thread operates solely inthe unslotted mode whereas Contiki’s IPv6 stack can be configured to either of both modes.Contiki’s slotted mode implements the IEEE 802.15.4e amendment of the standard which alsouses a channel hopping strategy to increase robustness against multi-path fading [23][32].

The devices in an IEEE 802.15.4-based network form either a peer-to-peer topology or a startopology. In the star topology the end-devices communicate only via a full function device(FFD), which acts as the coordinator. End-devices may either be FFDs or so-called reduced

5

FrameControl

SequenceNumber

AddressingFields

AuxiliarySecurityHeader

Frame Playload FCS

MAC Header MAC Playload MAC Footer

2 1 0-20 0-14 variable 2

Bytes

(a) 802.15.4 MAC frame format.

FrameType

SecurityEnabled

FramePending

ACKRequest

PAN IDCom-

pressionReserved

Dest.Addressing

Mode

FrameVersion

SourceAddressing

Mode

0:2 3 4 5 6 7:9 10:11 12:13 14:15

Bits

(b) 802.15.4 Frame Control field.

Figure 2.1: 802.15.4 frame structure.

function devices (RFDs). The coordinator buffers messages for the end-devices and does notsend them directly. The end-device needs to request the data explicitly before it is transmittedby the coordinator. In the peer-to-peer topology all devices are FFDs, and peers within rangecan exchange messages directly.

There is an upper limit of 127 bytes on the frame size. Figure 2.1 shows the general MAClayer frame format. Depending on the addressing and security options in the header theactual playload carried in the frames may be as low as 88 bytes. The first three bits in theframe control field determine the frame type. The four different frame types are beacon,data, acknowledgment, and MAC command frames. Beacon frames are required for networkdiscovery and are used to define the superframes as discussed above. Data frames carry theapplication-layer playload. The transmitting device usually requests an acknowledgment bysetting bit five in the frame control field. This way it handles link layer retransmissions, whichcontributes to a reliable connection between adjacent devices. In the star topology RFDs pollfor data by issuing a MAC command, Thread utilizes this mechanism as explained in moredetail in section 2.6.

2.4 6LoWPAN

In contrast to IPv4, IPv6 routers do not fragment and reassemble packets on the networklayer in case they are too big for the underlying layers. Instead an ICMPv62 type 2 messagePacket Too Big is returned to the sender and the packet is dropped. IPv6, however, guaranteesthat packets with a size up to 1280 B are always deliverable, which imposes constraints onthe underlying link- and physical layer technologies. But, as discussed in Section 2.3, theIEEE 802.15.4 standard only allows to transmit frames with a size up to 127 B. To overcome

. . .Header type 1 Header type N Payload

Figure 2.2: The general format of a 6LoWPAN packet, it consists of a header stack followedby the encapsulated payload.

2 Internet Control Message Protocol version 6

6

11000 Datagram Size Datagram Tag

11100 Datagram Size Datagram Tag Datagram Offset

0:4 5:15 16:31

Bits

FRAG 1

0:4 5:15 16:31 32:47

Bits

FRAG N

Figure 2.3: 6LoWPAN fragmentation headers.

this limitation the 6LoWPAN group designed the 6LoWPAN adaption layer between the IPv6network layer and the IEEE 802.15.4 link and physical layers.

6LoWPAN encapsulates an IPv6 packet in one or more 6LoWPAN packets, Figure 2.2 showsthe general format of such a packet. 6LoWPAN provides several services, the most importantbeing the fragmentation and reassembling of large IPv6 packets, the compression of IPv6 andUDP headers, and the link layer forwarding of 6LoWPAN packets. Each applied service has itsown header in the header stack. Like in IPv6 the order within the header stack is fixed.

2.4.1 Header Compression

6LoWPAN specifies two header compression algorithms, HC1 for the IPv6 header and HC2for the UDP, TCP, or ICMP header. RFC6282, an extension to 6LoWPAN, additionallydefines the improved header compression algorithm (IPHC) and the next header compression(NHC) [52]. An important aspect in the header compression is the possibility to omit thesource and/or destination IPv6 address. They might be reconstructable from either the 64-bitextended address or the 16-bit short address by using context information shared within thewhole 6LoWPAN. In the best case 6LoWPAN reduces the size of an IPv6 and UDP headerfrom 48 bytes to 6 bytes.

2.4.2 Packet Fragmentation

If, despite of header compression, the IPv6 packet cannot be transmitted in one IEEE 802.15.4frame it is fragmented at the sending node. The fragmentation header identifies how the packetis reassembled at the receiving node, see Figure 2.3. The datagram tag identifies all fragmentsbelonging to the same IPv6 packet and the offset determines the order of the fragments. Theoffset is omitted in the first fragment to save two bytes.

2.4.3 Link Layer Forwarding

In case the receiving and the sending node are multiple hops apart 6LoWPAN specifies aforwarding mechanism by means of the so-called mesh header. When using this mechanismthe fragments of a larger IPv6 packet are only reassembled at the final destination node andnot at every hop. This means that the fragments may take different routes within the network.

7

NETWORK

LLSEC

MACFRAMER

RDC

RADIO

Adaption layer, sicslowpan_driver

Link layer security, nullsec_driver

MAC layer, csma_driver, framer_802154

Radio duty cycling, contikimac_driver

Radio driver, cc2538_rf_driver

Figure 2.4: Contiki’s NETSTACK and its default IPv6 configuration for the zoul platform5.

For this to work forwarding nodes need to maintain a link layer routing table to determinethe appropriate next hop. This link layer forwarding is often referred to a mesh under design.Another approach is to use the route over design which uses no mesh header. Here the networklayer routing protocol needs to ensure that the destination of the 6LoWPAN frame is reachablewithin one hop.

The following sections describe Contiki’s IPv6 stack and Thread and how they utilize IEEE802.15.4and 6LoWPAN.

2.5 Contiki IPv6 Stack

Contiki’s uIPv6 module is an IPv6 implementation and also provides the transport layer pro-tocols UDP and TCP. Contiki encapsulates the lower layers of of the network stack in theso-called NETSTACK, which allows a flexible configuration of the physical, link, and adaptionlayer. Figure 2.4 illustrates such a possible configuration.

By default Contiki’s IPv6 stack uses the CSMA-CA algorithm as specified by IEEE 802.15.4on the MAC layer, i.e. the node senses if the radio channel is idle before transmitting a radioframe. An additional layer between the MAC and the physical layer allows the utilization ofa radio duty cycling protocol like ContikiMAC or X-MAC. This reduces the idle-listening ofthe radio and thus reduces the energy consumption of the node. In this matter Contiki goesbeyond the IEEE 802.15.4 specification, which does not specify these duty cycling protocols.Newer versions of the IEEE 802.15.4 standard, however, incorporate duty cycling by means ofthe coordinated sampled listening (CSL) and the time synchronized channel hopping (TSCH)protocols. The latter is also supported in Contiki3 [23].

The NETSTACK also supports IEEE 802.15.4 link layer security4, which uses a network-widepre-shared key. Contiki’s 6LoWPAN module constitutes the top layer of the NETSTACK.It supports header compression, and packet fragmentation and reassembling. It does not,however, implement link layer forwarding since it chooses a route over design and the nodesact as level 3 routers for the low power network.

3 Since it is based on the IEEE 802.15.4 slotted mode it does not use the radio duty cycling layer of theNETSTACK. See core/net/mac/tsch/README.md for more information.

4 As described in core/net/llsec/noncoresec/README.md.5 The platform used for the measurements, see chapter 3.

8

2.5.1 RPL

Contiki implements the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL)which is specified by the ROLL group [51]. In RPL a destination-oriented directed acyclicgraph (DODAG) is the basis for all routing decisions. There is one root — the destination— in the DODAG, which can assume the role of a border router and provide connectivity tothe Internet or another IPv6-based network. In the tree-like structure the nodes select one so-called preferred parent and may act as such a parent for multiple children. Beside the memoryof the devices there is no constraint on the number of nodes in a DODAG.

The topology of the DODAG naturally supports multipoint-to-point (MP2P) traffic from thenodes towards the root. This kind of traffic typically occurs in applications that collect sensorreadings in the deployment area and report the data to some server. But RPL also supportspoint-to-multipoint (P2MP, querying a node from outside the network) and point-to-point(P2P, communication between two nodes in the low power network) traffic. An extension toRPL allows to discover additional point-to-point routes by means of a subsidiary, temporaryDODAG, which is rosoted at the sending node [27]. Contiki, however, does not support thisextension.

The nodes in a DODAG maintain a property called rank, which indicates the node’s positionwith respect to the root. The rank is strictly increasing, i.e. parents always have a higher rankthan their children. The exact calculation of the rank is determined by an objective function,which has to obey the specifications in a separate RFC [7]. By default, Contiki’s objectivefunction uses the expected transmission count (ETX) [12].

According to the standard there may be several instances of RPL in the same low power networkand different instances may use different objective functions to provide optimized routes fordifferent application goals. Each instance may furthermore consist of several DODAGs, whichall need to use the same objective function.

The nodes construct and maintain a DODAG by means of ICMPv6 control messages, the stan-dard defines DODAG Information Solicitation (DIS) messages, DODAG Information Object(DIO) messages, Destination Advertisement Object (DAO) messages, and DAO acknowledg-ments. As in IPv6 neighbor discovery DIS messages are used to trigger DIOs by nearby nodes.A DIO includes information about the RPL instance, the DODAG id, the so-called DODAGversion number, the rank, and optionally routing information. DIOs are broadcasted periodi-cally by all nodes in a DODAG using the Trickle algorithm. Other nodes use them to maintaina set of parents and to select their preferred parent, which acts as the default route towardsthe root of the DODAG.

Typically the root node acts as the border router for low-power wireless network, and it isalways the root node that initiates a DODAG. Devices striving to attach to the network listen toDIO messages and choose an appropriate preferred parent. They may also attach as a leaf nodeonly if they do not support the DODAG’s objective function. This eases interoperability sincedevices running different RPL implementations do not necessarily support the same objectivefunctions. Contiki’s RPL implementation has successfully passed interoperability tests of theIPSO Alliance’s interoperability program. Additionally, interoperability with TinyRPL, theRPL implementation of TinyOS, has been demonstrated in [35].

RPL defines two modes of operation: storing and non-storing mode. Figure 2.5 illustratestheir different behavior in P2P communication. In storing mode all nodes maintain a downward

9

R

AB

CD

E

F

12

(a) P2P communication in storing mode.

R

AB

CD

E

F

1

234

(b) P2P communication in non-storing mode.

Figure 2.5: A sample DODAG.

routing table covering their sub-DODAG, whereas in non-storing mode only the root maintainssuch a table. Depending on the mode of operation each node sends Destination AdvertisementObjects (DAOs) to either the preferred parent (storing mode) or the root (non-storing mode).These are the used to update the routing table accordingly.

Time varying external conditions such as non-fixed obstacles or temporary high ambient ra-diation can render certain links in the DODAG unusable. RPL has local and global DODAGrepair mechanisms to deal with such cases. A global repair is initiated by the DODAG root,which increments the DODAG version number. This causes the construction of a completelynew DODAG. Local repairs are triggered by nodes when an inconsistency is detected. Poison-ing the sub-DODAG, i.e. by advertising an infinite rank in the DIO, leads to a reconstructionof the node’s sub-DODAG since the children need to select a new preferred parent with lowerrank.

2.5.2 Application Layer

Contiki includes several application layer protocols which run on top of its IPv6 stack. Be-side the already mentioned CoAP module it provides an implementation of the Lightweightmachine-to-machine (LWM2M) protocol from the Open Mobile Alliance [3]. It is especiallywell suited for IoT applications. Another option, Sparrow, is developed by Yanzi Networks. Itis available under an open source license and provides functionality similar to LWM2M. It alsosupports to remotely reprogram an IoT device out of the box.

2.6 Thread

Thread defines two groups of devices, routers and hosts. Routers provide connectivity withinthe low-power network by forwarding messages for each other and participate in the joiningprocess of new nodes. Border routers additionally supply connectivity to the internet or otherIPv6-based networks. In contrast to RPL there may be multiple border routers in a Threadnetwork, which avoids a single point of failure. A Thread network can contain up to 32 routers,where one of them assumes the role of the network leader and is responsible for decisions withinthe network.

The leader may decide to downgrade the functionality of a router device to that of a host.The so-called router-eligible end-device (REED) does not provide any router-service but — ifrequired — it can assume the router role without user interaction. It is worth noting that not

10

all hosts need to be a REED. End-devices generally attach to a parent router and communicateexclusively via this parent.

End-devices may be sleepy, i.e. they are not required to idle-listen for incoming packets.Thread uses the previously explained star topology of the underlying IEEE 802.15.4 protocolfor the communication between routers and hosts. Parent routers act as a coordinator andbuffer messages for their children in case they are sleepy. Upon wake up the sleepy child eithersends data via its parent or it issues an IEEE 802.15.4 data request MAC command. Theparent acknowledges the request with the frame pending bit set if there are buffered messagesfor the child; see also Figure 2.1. If the frame pending bit is set the end-device keeps its radioon awaiting further messages, otherwise it may enter its sleep cycle.

In Thread sleepy end-devices can potentially run on batteries for long periods. Routers, how-ever, have a significantly higher power consumption. Since Thread is designed for home envi-ronments routers may directly attach to mains power.

2.6.1 Addressing

The network shares a locally assigned global 64-bit IPv6 prefix as specified in RFC4193 [29].Together with their 64-bit extended MAC address, the IEEE 802.15.4 devices generate an IPv6address by using stateless address auto configuration. Similarly the nodes configure a mesh-local address with the FE80::0/64 prefix or further addresses using prefixes provided by theborder routers.

All devices joining the network are assigned a 16-bit short IEEE 802.15.4 address. Routeraddresses utilize only the six higher bits with the lower ten bits set to zero. This allows for64 router addresses but only 32 of them are used simultaneously to allow aging and recyclingof router addresses. End-devices use the same high bits as their parent but the lower bitsare non-zero. This way the routing of messages towards end-devices can be inferred by onlyconsidering the higher bits of the target address.

2.6.2 Routing Algorithm

Thread supports full peer-to-peer connectivity between all routers in the network. It usesthe algorithms from the distance-vector routing information protocol (RIP [30][40]), but inconjunction with a different message format. The message format is based upon and extendsthe Internet draft for mesh link establishment (MLE), which was designed for “1) dynamicallyconfiguring and securing radio links, 2) enabling network-wide changes to radio parameters,and 3) detecting neighboring devices” [34].

The routers maintain a next-hop routing table using the short addresses. They populate thetable by exchanging MLE messages which contain path costs to all other routers in the network.The path cost to a router is the minimum sum of link costs to reach that router and the linkcost in turn is an asymmetric measure based on the RSSI of incoming messages. Because ofthe addressing scheme the routing tables contain at most 32 entries, even for large networkswith a lot of end-devices,

Thread incorporates an address translation mechanism that relates IPv6 addresses, 64-bitinterface addresses, and 16-bit short addresses. When possible Thread favors the short addressto achieve higher compression on the 6LoWPAN adaption layer. Besides header compression

11

and fragmentation, Thread makes heavy use of 6LoWPAN’s mesh header as described inSection 2.4. This means fragmented IPv6 packets are only reassembled at the destinationnode; i.e. Thread uses a mesh under design.

2.6.3 Encryption, Commissioning And Joining

Beyond IPv6 connectivity Thread also specifies security relevant aspects. All communicationis encrypted using the mechanisms described in IEEE 802.15.4. This implies that no devicecan join the network unless it has a network wide pre-shared key or it undergoes an commis-sioning and joining process, which requires human interaction. Because Thread includes thiscommissioning and joining process in its specification, standalone IoT devices running Threadcan attach to existing Thread networks. There is no need that all devices in the network aredeveloped together; instead they might run completely different applications. Contiki’s IPv6stack differs from Thread in this regard as there is no agreed on commissioning and joiningprocess integrated in the stack itself.

Thread also specifies network discovery; a new device scans all IEEE 802.15.4 channels andissues beacon requests. A beacon response contains network information and indicates if thenetwork accepts new members. If the node is not pre-commissioned a router establishes asession between the device and an application on a smartphone or similar. After receivingthe necessary credentials the device attaches to a parent from whom it obtains a short ad-dress.

After a reboot (for example due to a battery change) the device reattaches directly to thenetwork. For this to work Thread stores relevant parameters like the network credentials innon-volatile memory.

2.7 Related Work

In this section we summarize previous work related to IP-based networking in low-power wire-less networks.

uIP was the first TCP/IP network stack for embedded systems, which “implemented all RFCrequirements that affect host-to-host communication” [15]. It demonstrated the feasibility torun IP-based network stacks on resource constrained embedded systems without sacrificingstandard compliance. In the original paper the performance of uIP was tested using a point-to-point connection over an Ethernet link. The stack, however, proved also suitability forwireless sensor networks [18][19]. uIP implements version 4 of the Internet Protocol, whichis still widely used today but not suitable for the huge amount of devices connected to theIoT. Another shortcoming of IPv4, the missing mechanism for address auto-configuration, wasalready mentioned in the original paper.

Hui et al. “claim that IPv6 is better suited to the needs of WSNs than IPv4 in every dimension”[31]. They argue, that a lot of useful mechanisms from wireless sensor network research like“Sampled-listening, Trickle-based dissemination, hop-by-hop feedback, and collection routing”can be integrated into an IPv6 based network stack. In their paper they outline a layeredarchitecture, that incorporates all these mechanisms, and clearly separates application layerlogic from the networking logic. They show that the performance of their stack outperformsthe performance of prior deployments using other architectures. Furthermore, they contribute

12

by improving the to date 6LoWPAN compression schemes and by adopting a tree-like routingtopology.

Subsequently, the Contiki operating system and TinyOS also included an IPv6 network stack [26][14]. Ko et al. demonstrated interoperability between the two stacks by deploying both stacksin the same network [36]. This highlights the benefits of the layered IP architecture, whichprovides application-agnostic connectivity. Ko et al. also pointed out that the performance ofthe network is sensitive to the configuration of queue sizes, retransmission timers etc.

Another IPv6 stack for low-power networks is OpenWSN [55]. Like Contiki’s uIPv6 it isbased on standards and uses the RPL routing protocol. It was the first open source stack toincorporate the to date new Time Synchronized Channel Hopping (TSCH) standard, whichallows extremely low duty cycles. OpenWSN is designed in a portable way and not tied to aspecific operating system or platform.

Like OpenWSN, OpenThread is designed to be portable. Due to its open source license,OpenThread is also integrated in other systems. RIOT, another operating system for embed-ded IoT devices, recently added a port for OpenThread [10]. Also Nordic Semiconductor, acompany that actively contributes to OpenThread, includes it in its ’nRF5 software develop-ment kit available for their platforms [48].

Unlike the mentioned research, we do not aim to design and implement a network stack, or todemonstrate interoperability of two stacks. Instead, we focus on two existing implementationswith different routing strategies, and compare their performance. We conduct experimentsusing the same operating system and the same application-layer test suite for both stacks.Furthermore, all measurements are carried out in the same testbed of IoT devices at similartimes. This approach increases the overall comparability of the results. In this point we extendthe previous work, which evaluates the performance of a single stack in isolation.

2.8 Alternatives For Low Power Networks

Both Thread and Contiki’s IPv6 stack implement IPv6 on top of IEEE 802.15.4 radios. Thereare, however, attractive alternatives depending on the use case. Thread is designed for home en-vironments with relatively confined spatial coverage. For a lot of such smart devices BluetoothLow Energy, a widely supported wireless communication protocol, is a possible alternative.The successor, Bluetooth 5, adds new features that are tailored for the IoT.

Powered devices in homes can also connect to existing but more power hungry IEEE 802.11WiFi networks. The recently published IEEE 802.11ah protocol focuses, like Bluetooth 5,on the IoT and provides low-power communication for distances of up to one kilometer [50].The LoRa Alliance specifies another long range communication network, which is feasiblefor distances up to some kilometers, depending on environmental conditions like line-of-sightbetween the nodes [6]. This high transmission range requires radios with a higher powerconsumption compared to IEEE 802.15.4 radios. The nodes and the gateway, however, areonly one hop apart and there is no need to maintain a network topology.

Another option are backscatters; i.e., radios that do not actively transmit but modulate am-bient electromagnetic waves. Recent research shows that such devices can communicate overdistances of up to one kilometer while consuming only microwatts instead of milliwatts liketraditional radios in the field [54].

13

Chapter 3

Porting OpenThread toContiki

This chapter describes the porting of OpenThread to Contiki. Although the port aims to beas platform independent as possible, it is only tested on the boards installed in the testbed.These boards are described in the first section.

Since OpenThread is under active development, minor parts of the APIs were subject to changeduring this thesis. Therefore both OpenThread and Contiki were fixed to specific commitsduring the thesis project1.

3.1 Platforms

For each platform Contiki needs to be configured and initialized correctly. To this end allplatforms have their own configuration and initialization files. They are typically found inthe platform folder which contains the matching contiki−main.c and contiki−conf.h files,respectively, and were adapted for the zoul and the native platform.

The native platform allows to run simulations in conjunction with the posix examples providedby OpenThread. These examples route the network traffic through UDP sockets, which re-quired the implementation of a new, compatible radio driver for Contiki. Simulating a Threadnetwork similar to the setup used in the measurements was helpful to test the setup for theexperiments, see chapter 4 for more details.

The measurements were conducted on Zolertia Firefly devices, which are based on Zolertia’szoul module. It incorporates two chips manufactured by Texas Instruments: CC2538 andCC1200. The CC1200 is a sub-1 GHz radio interface and is not used throughout this thesissince OpenThread operates only in the 2.4 GHz range. The Firefly also has an on-boardUSB-to-Serial converter (CP2104), which allows to program the board using its USB port.Furthermore it has built-in user and reset buttons, an RGB LED, and a core temperature andbattery sensor.

The CC2538 contains a 2.4 GHz IEEE 802.15.4-compliant radio transceiver and an ARMCortex

1 Commit 02bd8e1dddd6a5b3a14255fc96657e75f00b0b75 for Openthread and Commit 99402348eb36a2032f98cfa3c4f63947bfc33133 for Contiki.

15

Figure 3.1: A Zolertia Firefly. 25 of these are installed in the testbed.

M3 microcontroller. The microcontroller runs with frequencies up to 32 MHz, has 512 kBprogrammable flash storage, and 32 kB RAM.

3.2 Contiki’s and OpenThread’s Platform Abstraction

Contiki is a highly portable operating system and its modules and libraries are implementedon top of hardware drivers, which, in turn, are implemented for a variety of platforms.OpenThread is also designed with portability in mind: it is “OS and platform agnostic,with a narrow platform abstraction layer and a small memory footprint, making it highlyportable” [42]. OpenThread compiles to a static library, which is then linked to the finalapplication.

The porting thus mostly consists of mapping OpenThread’s platform abstraction to the cor-responding modules in Contiki, as illustrated in Figure 3.2. However, not the whole platformabstraction of OpenThread needs to be implemented in order to get a functional networkstack. As an example consider the memory module, which provides heap memory functional-ity similar posix malloc and free. OpenThread is designed such that multiple instances of thenetwork stack can run on the same device, which requires the allocation of additional memory.A single instance of OpenThread, however, runs just fine without implementing the memorymodule. A guide describing the general porting process in more detail was recently added tothe OpenThread wiki [45].

The following subsections shortly describe the porting of the modules, respectively.

Alarm Random Radio Uart

OpenThread Platform Abstraction Layer

OpenThread Core

Ctimer Random NetstackRadio

SerialLine

Contiki Modules

Contiki Drivers

Figure 3.2: OpenThread’s platform abstraction is mapped on the corresponding Contiki mod-ules. The graphic shows only the modules implemented.

16

3.2.1 Radio module

As discussed in chapter 2 Contiki’s NETSTACK consists of several layers that provide differentfunctionality. All layers operate on a global buffer called packetbuf, which holds exactly onepacket.

On the lowest layer, the radio driver implements the Contiki’s extended radio API defined incore/dev/radio.h. It is accessible through the NETSTACK_RADIO macro and most of OpenThread’sradio abstraction is implemented using this driver. One difference between the two abstrac-tions is that Contiki transmits packets synchronously, whereas OpenThread has a non-blockingtransmit function together with a callback. Since the callback in OpenThread should not beissued before the transmit function returns, it is sent from a Contiki process, which, in turn,is polled after the packet has been transmitted.

In Contiki, when operating in interrupt mode, the incoming packets enter directly the radio-duty-cycling (RDC) layer of the NETSTACK. In the current port the RDC layer processes thereceived packets and forwards them to OpenThread and the remaining upper layers have nofunctionality. Another, maybe more flexible, approach would be to interact with OpenThreadon the highest layer (NETWORK). OpenThread’s platform abstraction supports hardwarethat handles CSMA timeouts and retransmissions autonomously. Thus the intermediate lay-ers in the NETSTACK could implement this logic, which potentially avoids redundant copyoperations of the radio frame.

The energy scan functionality and the source address matching are not implemented since theyare not provided by the Contiki radio driver and they are not needed for a functional port. Thelatter, however, improves the quality of the port considerable since it leads to energy savingsfor sleepy end devices. The source address match table controls how the frame pending bit inacknowledgments is set, currently this bit is set in every acknowledgment. Sleepy end devicesare thus active longer since they expect incoming packets and thus the efficiency of the mailboxsystem decreases. The zoul platform has hardware support for source address matching and itmight be worth the effort to add this functionality to the radio driver in Contiki.

3.2.2 Random Module

The random module is used in security relevant assets and to generate the extended addressof the device. It provides a true random number generator (TRNG) for the upper layers. Themodule is implemented using Contiki’s random library, which is based on a hardware numbergenerator for the zoul platform.

3.2.3 Alarm

OpenThread requires a free running timer with millisecond resolution. In the default configu-ration of the zoul platform, Contiki’s ctimer has a resolution of roughly 10 ms. This is adjustedto the required millisecond resolution by changing CLOCK_CONF_SECOND from 128 to 1000 incontiki−conf.h.

During the course of this thesis OpenThread added an API for a microsecond resolution timer.Such a timer is needed to fully comply with [1] with respect to backup periods in clear channelassessments. This high resolution timer is not yet added to the port, but might be implemented

17

using Contiki’s rtimer. For zoul, the rtimer provides a sufficient resolution of 1/32768 ≈ 31 µs.In its current implementation the rtimer can only be used for one task in a Contiki application,which is typically the network stack. As the network stack is replaced by OpenThread, thertimer is an option for the high resolution timer. Another option is, as already mentioned, to im-plement the CSMA and retransmission logic on the MAC layer of Contiki’s NETSTACK.

3.2.4 Universal Asynchronous Receiver and Transmitter (UART)

OpenThread comes with a convenient command line interface (cli) application. It was usedthroughout the thesis for testing and for learning purposes. The cli application is based on anUART or a SPI backend. For this port the UART backend is chosen because it is already wellintegrated within Contiki by means of the printf function and the serial-linemodule. The printftransmits characters over the UART while the serial-line module buffers incoming characters.Upon the reception of the newline character ’\n’ an event is broadcasted to all subscribedprocesses.

The port uses a process which subscribes to the serial-line-event. There is, however, a smallconflict: OpenThread’s command line interface also buffers incoming data until a newlinecharacter is received. Contiki, however, replaces the newline character by the string termi-nation character ’\0’. This substitution needs to be reverted before passing the data toOpenThread.

This approach is problematic, however, since it does not work with another example applicationof OpenThread, the Network CoProcessor (NCP). Like Conitiki’s SLIP module (Serial LineInternet Protocol), the NCP routes radio frames over the UART. It thus provides a way toconnect the low-power wireless network to a computer and to other networks like the Internet.In order for the NCP to function properly, it needs exclusive access to the UART and incomingdata may not be buffered. For zoul, this can be accomplished by adapting uart_set_input←↩

(..) in contiki−main.c for reception and puts in cpu/cc2538/dbg.c) for transmission. Debugmessages may then be send using otNcpStreamWrite.

3.2.5 Logging and Misc

The implementation of the logging module is optional, but was valuable for debugging purposes.Currently the printf function is used to transmit the logs over the UART. Failed asserts withinOpenThread also print an error message and the hardware reset functions are not implementedyet. An application should change these modules to comply with to the chosen logging andfault handling strategy.

3.2.6 General

OpenThread signals when it has non-urgent tasks to run. Upon reception of such a signal aContiki process is scheduled, which then runs all queued tasks.

3.2.7 Unimplemented Modules

As already stated above, the memory module and some functionality of the radio module isnot implemented yet. Also the non-volatile storage module is still missing, it is needed to

18

save credentials like the network name, the network channel, the panid, the private key, etc.Without this data, a node cannot rejoin the network after a power loss or a reboot. Thisfunctionality might be added using Contiki’s file system Coffee [53]. OpenThread uses mbedscryptographic library to implement link-layer security [39]. Further performance improvementscan be achieved by enabling hardware acceleration for the this library.

19

Chapter 4

Evaluation

Both Contiki’s IPv6 stack and OpenThread provide the same basic functionality: IPv6 net-working for low power wireless networks. This makes a comparison of both stacks meaningful.This chapter first presents results of experiments measuring latency and packet loss in a testbedof IoT devices and then compares the respective implementation complexity.

Generally a low packet loss rate is essential for any IoT application and one of the main goalsof the underlying network stack. It is thus interesting and meaningful to compare the lossrate of both stacks under similar conditions. The latency is an indication for the capability ofthe network. It is measured as a round-trip time between two nodes to avoid synchronizationissues regarding the clocks of the nodes.

Counting the lines of code serves as one measure of the implementation complexity. It is studiedin order to assess if one of the implementations is overly complex, which might increase theprobability of bugs and might make the code harder to understand. The other measure studiedis the size of the respective firmwares. This is of interest because smaller firmwares may resultin savings due to the use of cheaper IoT devices.

4.1 Experimental Setup

The experiments are carried out in a testbed of IoT devices installed at the office of RISE SICSat Kista, Stockholm. The testbed consists of 25 Zolertia Fireflys as described in the previouschapter. One further Firefly is directly connected to a laptop and used to collect data fromand issue commands to the nodes in the testbed. Figure 4.1 shows the physical distribution ofthe devices.

A serial connection between the additional node and the laptop is used to connect to the low-power wireless network. In case of Contiki this node runs the rpl-border-router applicationfound in Contiki’s examples. It acts as the DODAG root and routes outbound traffic over theUART using the Serial Line IP (SLIP) protocol. On the host the messages are processed bytunslip6, a tool included in Contiki. It creates a network interface in the host operating systemand tunnels the traffic between the serial connection and this interface.

The OpenThread team provides a similar tool called wpantund, but uses the Spinel protocolto communicate over the UART [43] [44]. The node needs to run a so called Network ControlProcessor (NCP) application. OpenThread includes an NCP application and also a ready-to-

21

Figure 4.1: The testbed at SICS. The node connected to the laptop is placed in the office rightof Node C12, close to the door.

run example, which was used during the measurements.

4.2 Measuring Latencies And Packet Loss

The nodes in the testbed run a small application on top of UDP to measure latencies andpacket loss rates within the low-power wireless network. A thin wrapper unifies the stack-specific UDP APIs and provides a common interface to the application layer. The networkstacks use the respective standard configuration, only for Contiki’s IPv6 stack the size of therouting table is increased to accommodate more than 16 routers.

The laptop itself runs a Python script which opens a socket with a fixed IPv6 address. Onstartup the nodes send their IP address to the Python script, which, upon reception of alladdresses, issues commands to the nodes and collects the responses.

In order to assess the latencies in the network the round-trip times for packets are measured asexplained in Figure 4.2. Both timestamps are taken at the same node to avoid inaccuracies dueto unsynchronized clocks. Packet losses are registered along the round-trip time measurements.Adopting the names in Figure 4.2: node D starts a 2 s timer in step (2) and reports a round-triptime of zero if no response is registered before the timeout. Losses along the paths (1) and (4)are not taken into account when analyzing the data.

22

Python ScriptA

B

C D

E

F

G1

42

3

Figure 4.2: Capturing round-trip times: (1) The Python script sends a request to node D tomeasure the round-trip time to Node B. (2) Node D requests a packet of a certain size fromNode B and stores the timestamp. (3) Node B responds by sending an accordingly sized packetto Node D. Node D then calculates the round-trip time. Step 2 and 3 are repeated ten times.(4) Node D sends the round-trip times to the Python script.

The application implements another command to take a snapshot of the current routing topol-ogy in the network. When using Contiki’s IPv6 stack the nodes report the IP address of theirrespective preferred parent, which allows to reconstruct the DODAG. One of the capturedsnapshots is shown in Figure 4.3. In case of OpenThread the routing table is inspected. Eachrouter reports the appropriate next hop router for messages to every other router in the net-work. Nodes that currently act as children report the router ID of their parent. The resultingmesh topology is depicted in Figure 4.4.

4.3 Round-Trip Times

The round-trip times were measured between five different pairs of nodes. The devices in thepairs (1|5) and (9|12) are relatively close to each other. The remaining pairs cover bigger spatialareas with different characteristics; the pair (24|18) lies within a tendential linear region of thenetwork, the pair (14|3), however, represents the mesh part of the network. Finally (23|8)covers both of theses regions.

The sizes of the responses, i.e. the packets sent in the third step in Figure 4.2, range from20 bytes to 440 bytes, which covers the relevant range for IoT applications and ensures that6LoWPAN-fragmented packets are included in the measurements. Figure 4.5 shows the numberof data points captured for each pair of nodes and each packet size. The experiments are doneduring non-office hours to minimize radio interference due to people in the office buildingaccessing the WIFI network, etc. Furthermore the order of the measurements was randomizedto spread the influence of external factors equally.

Figure 4.6 reveals the round-trip times behave similar for both network stacks. It is almostproportional to the packet size with small discontinuities when the number of 6LoWPAN frag-ments needed increases. It is worthwhile to note that the different strategies, route over usedby Contiki’s stack and mesh under, do not have a visible effect on the round-trip times. Eventhough OpenThread splits and reassembles 6LoWPAN fragments only once at the destinationnode instead of at every hop, there is no sign that OpenThread scales better with respect topacket size.

23

Figure 4.3: Snapshot of the DODAG when using Contikis IPv6 stack. The root was connectedto the host running the Python script.

Figure 4.4: Snapshot of the mesh topology when using OpenThread. The children are shownin the light rectangular boxes; the arrow points to their parent. All the other nodes are routersand Node 20 currently has the leader role. The arrows point to all routers which are used asnext hop on some route.

24

Figure 4.5: The number of successful round-trip measurements.

Figure 4.6: The mean values of the round-trip times between the nodes. 80% of the valuesare bigger than the lower end of the interval and 80% are smaller than the upper end of theinterval.

25

(a) The time until the UDP send command re-turns.

(b) The time until the fragments of an UDP packetare transmitted.

Figure 4.7: Time measurements for sending an UDP packet. 80% of the values are biggerthan the lower end of the interval and 80% are smaller than the upper end of the interval,respectively.

It is rather the other way around, all node pairs except the first show lower round-trip times forContiki’s IPv6 stack than for OpenThread. Even though the topologies shown in Figures 4.3and 4.4 are only snapshots and will change with time, they might contain a possible explanationfor that. The nodes (9|12) are only one hop apart in the DODAG compared to (at most)three hops in OpenThread’s mesh. Similar considerations apply for the pair (1|5) and theyalso explain OpenThread’s good performance between (14|3). Here are two three-hop-routespossible in the mesh compared to five hops in the DODAG. However, it needs to be stressedthat these arguments do not hold for the pairs (23|8) and (24|18).

Also the fact that Contiki’s IPv6 stack is more tightly integrated in the operating system thanOpenThread might play a crucial role. This could explain why the time differences for (14|3);i.e., the case when OpenThread shows lower round-trip times, are smaller than for the otherpairs. In order to assess this more quantitatively we measure how long it takes to transmitwhole UDP packets; i.e., the time from issuing the send command until the whole packet leftthe device.

Figure 4.7a shows how long it takes for the UDP-send command to return. It reveals longertimes for Contiki’s IPv6 stack. To understand this we look at the implementations of bothstacks. OpenThread just enqueues the UDP packet in its network layer buffers, informs theoperating system that it has tasks to do, and then returns control. Thus, OpenThread exhibitslow and very predictable times in Figure 4.7a. Contiki’s IPv6 stack, however, directly beginsto process the packet; it issues a route lookup, fragments the packet if necessary, and passesall fragments to the MAC-layer of the NETSTACK, where they are put in a queue1. Thisexplains the higher times for Contiki’s IPv6 stack in Figure 4.7a. The higher variations aredue to variations in the route lookup time for different destination nodes.

The time to actually transmit the packet is considerably higher, though; see Figure 4.7b.Contiki’s stack starts to actually transmit the fragments after an backoff period, which isinitially always zero2. The very predictable timings are due to several reasons. First, themeasurement was done in a two node network and hence there are no varying route lookup

1 Note that this is specific to the CSMA MAC-layer used in the measurements.2 See the macro CSMA_MIN_BE.

26

Figure 4.8: Encryption and decryption times of radio frames measured for OpenThread. Theplots show the mean and standard deviation.

times. Second, after a fragment is successfully transmitted, the next fragment is send directlywithout the usage of additional backoff timers. Since Contiki’s stack sends link-layer packetssynchronously and because of the low link errors rate in the simple network, all fragments are,most of the time, sent directly after each other.

OpenThread transmits link-layer packets asynchronously and therefore returns control to theoperating system after each fragment. This leads to generally higher transmission times forthe whole UDP packet. Furthermore, the overhead compared to Contiki’s IPv6 stack increaseswith the number of fragments. The variations are generally higher since other processes maybe scheduled in-between the transmission of two fragments. As Figure 4.7b reveals, it takes ap-proximately 8 ms longer to transmit a 300 B UDP packet with OpenThread than with Contiki’sIPv6 stack.

Another relevant factor for the latency measurements is security. Contiki’s IPv6 stack doesnot use link-layer encryption by default and hence it is not used in the measurements. Link-layer encryption, however, is mandatory in the Thread specification. Furthermore, the port ofOpenThread to Contiki currently does not support hardware acceleration for encryption anddecryption. This leads to notable additional latency at both the sending and receiving node.Figure 4.8 reveals that this process takes about 1 ms, depending on the size of the radio frame.Hence, for large UDP packets, which are fragmented in multiple frames, the en- and decryptionpenalty on the latency can sum up to the order of 10 ms; without taking into account the en-and decryption at intermediate, forwarding nodes.

Summarizing the above arguments, we can state that the additional latency due to encryptionand asynchronous transmission accounts for a fair amount of the differences observed in theround-trip time measurements. Hence, both routing topologies perform equally well for thechosen pairs of nodes in the given testbed.

4.4 Packet loss

Figure 4.9 shows the packet loss rates. The pairs (1|5), (9|12), and (14|3) show similar behaviorfor both stacks; the loss rate varies only slightly with the packet size. OpenThread, however,exhibits a slightly higher overall loss rate for (1|5) and (9|12), and a clearly higher loss rate for(14|3). High ambient noise close to node 14 might be an explanation for that, but this is only

27

Figure 4.9: Dependency between the packet loss rate and packet size.

speculative.

More interesting, however, are the pairs (23|8) and (24|18); here OpenThread exhibits analmost linear dependency of the packet loss rate on the packet size. On the contrary, thereception rate of Contiki’s IPv6 stack shows no such dependency, but it is also generally higherthan for the other pairs. Overall, the high average loss rate indicates that one or more linksalong the path were not very reliable for both stacks.

The linear dependency shown by OpenThread’s loss rate can be explained by considering thedifferent routing strategies for 6LoWPAN fragments. Since Contiki’s IPv6 stack reassemblesall fragments at every hop, either all fragments or nothing is forwarded at intermediate nodes.In Thread, however, every intermediate node forwards all received fragments. This leads tothe possibility that a lot of fragments, but only few complete UDP packets, arrive at thedestination node. If the buffers are not flushed fast enough, fragments of potentially completeUDP packets may be dropped causing the reception rate to decrease. Since the buffers fillmore quickly for larger packet sizes this explains the size dependency. In OpenThread thedefault timeout for reassembling 6LoWPAN fragments is 5 sec and there are 40 buffers for suchfragments available3. The current design of the experiment described in Figure 4.2 repeatsthe same measurement ten times and it is not unlikely that two or more of such blocks arescheduled within 5 sec. In case of bigger UDP packets more frames need to be sent, and thusthe likelihood that the buffer overflows increases with packet size.

The overall packet loss of OpenThread is almost two times as high as the loss of Contiki’s IPv6

3 See OPENTHREAD_CONFIG_6LOWPAN_REASSEMBLY_TIMEOUT and OPENTHREAD_CONFIG_NUM_MESSAGE_BUFFERS.

28

Figure 4.10: The overall loss rate of both stacks is comparable for the same number of link-layerretransmissions.

stack. A possible cause for is the different standard configuration of the network stacks; themaximum number of link-layer retransmissions in Contiki’s CSMA layer is seven, OpenThread,however, uses only four retries4. Running the same experiment with an equal number of link-layer retransmissions reveals that the overall loss rates are almost the same with 1.7 %; seeFigure 4.10.

4.5 Lines of Code

Table 4.1 summarizes the lines of code for each stack. In order to place the numbers inTable 4.1b in context we need to recall that Contiki’s implementation makes use of the in-frastructure provided by the operating system. Modules like processes or timers are used inthe network stack, but are not included in the counted lines. Hence Table 4.1b underesti-mates the implementation complexity of Contiki’s low-power IPv6 stack. At the same timeseveral MAC layer implementations like ContikiMAC, TSCH, and NullMAC/CSMA are in-cluded in the listing, but only one of them can be used in a specific configuration of Contiki’snetstack.

As discussed in Chapter 2, Thread standardizes the process of commissioning and joining; i.e.,the process that authenticates devices before attaching to the network. In OpenThread thisfunctionality is implemented in the module MeshCoP (Mesh Commissioning Protocol). Thecommissioning and joining part of OpenThread thus adds 5391 lines of code, which should notbe considered as additional complexity as long as no similar mechanism for Contiki is includedin the comparison.

Another cost not present in Contiki’s IPv6 stack but in OpenThread is the API. In Contikithere is no need for an API since the stack is tightly integrated within the whole operatingsystem and there is no ambition to use it unaltered in other systems. OpenThread, however,aims to be platform independent. Since it is written in C++ and because many projects inthe embedded domain are written in C, it needs to export a C API.

4 See the macros CSMA_MAX_MAX_FRAME_RETRIES and OPENTHREAD_CONFIG_MAX_TX_ATTEMPTS_DIRECT respectively

29

Contiki IPv6 OpenThread.C/C++ file 26 % 11 %header file 62 % 67 %

(a) Amount of comments used in both network stacks.

Contiki IPv6 OpenThreadip 4608 thread 15828ipv6 8178 meshcop 5391rpl 4763 net 4971mac/top_dir 2414 mac 2797mac/contikimac 882 common 2532mac/tsch 3519 api 2280llsec 361 coap 1770top_dir 1442 crypto 469apps/er-coap 2650 utils 393

top_dir 25528817 36686

(b) Lines of source code without comments, blank lines, or similar. Generated using David A. Wheeler’sSLOCCount.

Table 4.1: Lines of code. For Contiki’s IPv6 stack the IPv6 related modules in the directorycore/net and the CoAP implementation were considered. On the OpenThread side the linesin src/core were counted.

Considering the above arguments one can state that both stacks have a comparable implemen-tation complexity. Also both code bases are well documented as Table 4.1a reveals.

4.6 Firmware Sizes

The size of the compiled firmware is relevant when selecting appropriate devices for the IoTapplication. Table 4.2 summarizes information about the compiled ELF files used for thelatency measurements as discussed in the next sections. 5

The text section in the ELF file contains the program’s executable instructions, the data sectionholds the initialized data and the bss section consists of uninitialized data. The sizes of thedata and bss sections are of the same order, but the text section is almost three times as largewhen using OpenThread instead of Contiki’s IPv6 stack.

Table 4.2b shows the contribution of the respective network stack to the size of the textsection and reveals that the cause for the big differences is indeed due to the network stack.The biggest contribution in the case of OpenThread is the Mle namespace, which implementsThreads logic to build and maintain the mesh topology. It is bigger than the text section of thewhole Contiki IPv6 network stack and almost four times as big as the corresponding modulein Contiki: rpl.

5 Both firmwares were compiled using version 7.1.0 of the gnu compiler for ARM. The Contiki sourcewas compiled with the following flags: arm−none−eabi−gcc −mcpu=cortex−m3 −mthumb −mlittle←↩−endian −ffunction−sections −fdata−sections −fshort−enums −fomit−frame−pointer −fno−←↩strict−aliasing −Wall −Os. The OpenThread static library was generated with the following flags:arm−none−eabi−g++ −fdata−sections −ffunction−sections −Os −Wimplicit−fallthrough=0←↩−mcpu=cortex−m3 −mfloat−abi=soft −mthumb −mthumb −fno−exceptions −fno−rtti −Wall −←↩

Wextra −Wshadow −Werror −std=gnu++98 −Wno−c++14−compat.

30

Contiki IPv6 OpenThreadtext 44577 120481data 525 322bss 15871 17375

60973 138178(a) The sizes of the respective sections in the firmware.

Contiki IPv6 OpenThreadipv6 13042 Mle 30497rpl 8950 MeshCoP 8620mac 3362 MeshForwarder 7612net top dir 2178 Ip6 7362llsec 1700 NetworkData 7274ip 1570 Mac 6984. . . Coap 4386

Lowpan 3782AddressResolver 2706. . .

28540 91435(b) Composition of the text sections. For Contiki’s IPv6 stack the contributions are shown per subdi-rectory whereas for OpenThread the sections are grouped by namespace. Only the contributions withmore than 2 kB are listed for OpenThread.

Table 4.2: The sizes of the firmwares used for the latency and packet-loss measurements inbytes.

The additional contributions from the platform wrapper described in chapter 3 are not listed inthe table as well as the 4234 B added by mbeds cryptographic library. They are small comparedto the contributions by the OpenThread static library.

Even though the size differences in the bss and data sections are small they lead to consequencesfor the zoul platform used in the testbed. The devices have 32 kB of RAM, but 16 kB thereof areswitched off when entering a deep sleep power mode. In case of Contiki running OpenThreadas in the measurement the size of the data exceeds this limit whereas Contiki running Contiki’snative stack fits in one half of the RAM.

In summary we can conclude that the RAM usage, given by the data and bss sections, iscomparable, but the ROM requirements are significantly higher when using OpenThread asthe network stack.

31

Chapter 5

Conclusions and Future Work

This master’s thesis compares the performance of two open source software stacks for low-power wireless networks: Contiki’s low-power IPv6 stack and OpenThread. It also highlightsthe commonalities and differences of their underlying protocols. We conduct measurements ina testbed of IoT devices and assess the performance of both stacks with respect to latency andpacket loss rates. The results reveal that both stacks perform well. Nevertheless, Contiki’snative stack exhibits slightly lower latencies and packet loss rates, which is primarily due thetighter integration of Contiki’s native stack within the operating system.

As future work we propose to perform further experiments, which address additional propertiesof the stacks. The conducted experiments, for example, considered only sequential trafficbetween pairs of nodes, and hence avoided artifacts due to congestion in the network. Becauseof the underlying routing topology, however, Contiki’s IPv6 stack stack is prone to congestionclose to the root of the DODAG. Therefore we suggest to investigate the behavior of bothstacks under high, concurrent traffic loads, and check if some of the benefits of OpenThread’sunderlying mesh topology are revealed.

Another important, but not studied factor for low-power wireless networks is the energy con-sumption of the nodes. OpenThread routers do not adopt any form of duty cycling and henceprovide a reactive infrastructure for the sleepy end-devices. ContikiMAC aims to combineresponsiveness and power consumption by using special modes, which accelerate the forward-ing of packets: streaming and snooping [24]. It would be interesting to relate latency andthroughput of the network to the energy consumption of sleepy devices.

Duquennoy et al. recently pointed out, that there are no established criteria to evaluate theperformance of low-power wireless networks. They suggest to create reproducible benchmarksfor such networks, which leads to comparable results of performance evaluations [25]. It wouldbe valuable to apply such standard benchmarks to both stacks.

In order to create similar prerequisites for the performance evaluation, we ported OpenThreadto the Contiki operating system. A more recent version of the port is available online1. At thetime of writing this report, the port additionally implements the logic for non-volatile storagein terms of Contiki’s Coffee file system and supports source matching on the zoul platform.Furthermore we plan to run OpenThread on top of the NETSTACK’s MAC layer instead ofthe NETSTACK’s RADIO layer. This way we can reuse Contiki’s CSMA-CA module and

1 See https://github.com/chel8413/contiki-openthread.

33

handle retransmissions solely within Contiki, and hence save redundant copy operations of theradio frame. It might be also worthwhile to run Contiki’s CoAP implementation on top ofOpenThread such that many real world applications can simply switch the underlying networkstack without changing the application code itself.

34

Bibliography

[1] 802.15.4-2006 IEEE Standard for Information Technology- Telecommunications and In-formation Exchange Between Systems- Local and Metropolitan Area Networks- SpecificRequirements Part 15.4: Wireless Med. Sept. 2006. url: https://standards.ieee.org/findstds/standard/802.15.4-2006.html.

[2] Ericsson AB. Internet of Things forecast. url: https : / / www . ericsson . com / en /mobility-report/internet-of-things-forecast (visited on 06/09/2017).

[3] Open Mobile Alliance. url: http://openmobilealliance.org/ (visited on 06/21/2017).[4] The Zigbee Alliance. url: http://www.zigbee.org (visited on 06/21/2017).[5] The Z-Wave Alliance. url: http://www.z-wave.com (visited on 06/21/2017).[6] Aloÿs Augustin, Jiazi Yi, Thomas Clausen, and William Mark Townsley. “A Study of

LoRa: Long Range & Low Power Networks for the Internet of Things”. In: Sensors 16.9(2016), p. 1466.

[7] Dominique Barthel, JP Vasseur, Kris Pister, Mijeom Kim, and Nicolas Dejean. RoutingMetrics Used for Path Calculation in Low-Power and Lossy Networks. Tech. rep. 6551.Mar. 2012. 30 pp. doi: 10.17487/RFC6551. url: https://rfc- editor.org/rfc/rfc6551.txt.

[8] Michael Buettner, Gary V. Yee, Eric Anderson, and Richard Han. “X-MAC: a shortpreamble MAC protocol for duty-cycled wireless sensor networks”. In: Proceedings ofthe 4th international conference on Embedded networked sensor systems. SenSys ’06.Boulder, Colorado, USA: ACM, 2006, pp. 307–320. isbn: 1-59593-343-3. url: http ://dx.doi.org/10.1145/1182807.1182838.

[9] Thomas H. Clausen, Axel Coli Verdiere, Jiazi Yi, Afshin Niktash, Yuichi Igarashi, HirokiSatoh, Ulrich Herberg, Cedric Lavenu, Thierry Lys, and Justin Dean. The LightweightOn-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng).Internet-Draft draft-clausen-lln-loadng-15. Work in Progress. Internet Engineering TaskForce, July 2016. 75 pp. url: https://datatracker.ietf.org/doc/html/draft-clausen-lln-loadng-15.

[10] RIOT OpenThread Commit. url: https://github.com/RIOT- OS/RIOT/commit/1a2097e97e90daa4479d5c9ce4dcecd3f57d31dc (visited on 07/05/2017).

[11] Contiki. url: http://www.contiki-os.org/ (visited on 06/10/2017).[12] D. S. J. De Couto, D. Aguayo, J. Bicket, and R. Morris. “A high-throughput path metric

for multi-hop wireless routing”. In: Proceedings of the International Conference on MobileComputing and Networking (ACM MobiCom). San Diego, CA, USA, 2003. isbn: 1-58113-753-2. doi: http://doi.acm.org/10.1145/938985.939000.

35

[13] Samir R. Das, Charles E. Perkins, and Elizabeth M. Belding-Royer. Ad hoc On-DemandDistance Vector (AODV) Routing. Tech. rep. 3561. July 2003. 37 pp. doi: 10.17487/RFC3561. url: https://rfc-editor.org/rfc/rfc3561.txt.

[14] S. Dawson-Haggerty. “Design, Implementation, and Evaluation of an Embedded IPv6Stack”. MA thesis. UC Berkeley, 2010.

[15] A. Dunkels. “Full TCP/IP for 8-Bit Architectures”. In: Proceedings of The InternationalConference on Mobile Systems, Applications, and Services (MobiSys). San Francisco, CA,USA, May 2003.

[16] A. Dunkels, B. Grönvall, and T. Voigt. “Contiki - a Lightweight and Flexible OperatingSystem for Tiny Networked Sensors”. In: Proceedings of the IEEE Workshop on EmbeddedNetworked Sensor Systems (IEEE Emnets). Tampa, FL, USA, Nov. 2004.

[17] A. Dunkels and O. Schmidt. Protothreads – Lightweight Stackless Threads in C. Tech.rep. T2005:05. Swedish Institute of Computer Science.

[18] A. Dunkels, T. Voigt, and J. Alonso. “Making TCP/IP Viable for Wireless SensorNetworks”. In: Proceedings of the European Conference on Wireless Sensor Networks(EWSN). Berlin, Germany, Jan. 2004.

[19] A. Dunkels, T. Voigt, J. Alonso, H. Ritter, and J. Schiller. “Connecting Wireless Sensor-nets with TCP/IP Networks”. In: WWIC2004. Feb. 2004.

[20] Adam Dunkels. “Rime — A Lightweight Layered Communication Stack for Sensor Net-works”. In: Proceedings of the European Conference on Wireless Sensor Networks (EWSN),Poster/Demo session. Delft, The Netherlands, Jan. 2007. url: http://dunkels.com/adam/dunkels07rime.pdf.

[21] Adam Dunkels. The ContikiMAC Radio Duty Cycling Protocol. Tech. rep. Rev 1.0. SICS,Dec. 2011. url: http://soda.swedishict.se/5128/.

[22] Adam Dunkels, Joakim Eriksson, Niclas Finne, Fredrik Österlind, Nicolas Tsiftes, JulienAbeillé, and Mathilde Durvy. “Low-power IPv6 for the Internet of Things”. In: NetworkedSensing Systems (INSS), 2012 Ninth International Conference on. IEEE. 2012, pp. 1–6.

[23] S. Duquennoy, B. Al Nahas, O. Landsiedel, and T. Watteyne. “Orchestra: Robust MeshNetworks Through Autonomously Scheduled TSCH”. In: Proceedings of the InternationalConference on Embedded Networked Sensor Systems (ACM SenSys). Seoul, South Korea,2015.

[24] S. Duquennoy, N. Wirström, N. Tsiftes, and A. Dunkels. “Leveraging IP for SensorNetwork Deployment”. In: Proceedings of the workshop on Extending the Internet to Lowpower and Lossy Networks (IP+SN 2011). Chicago, IL, USA, Apr. 2011.

[25] Simon Duquennoy, Olaf Landsiedel, Carlo Alberto Boano, Marco Zimmerling, Jan Beutel,Mun Choon Chan, Omprakash Gnawali, Mobashir Mohammad, Luca Mottola, LotharThiele, et al. “A Benchmark for Low-power Wireless Networking”. In: Proceedings of theInternational Conference on Embedded Networked Sensor Systems (ACM SenSys). 2016,pp. 332–333.

[26] M. Durvy, J. Abeillé, P. Wetterwald, C. O’Flynn, B. Leverett, E. Gnoske, M. Vidales, G.Mulligan, N. Tsiftes, N. Finne, and A. Dunkels. “Making Sensor Networks IPv6 Ready”.In: Proceedings of the International Conference on Embedded Networked Sensor Systems(ACM SenSys). Raleigh, NC, USA, Nov. 2008.

[27] Mukul Goyal, Emmanuel Baccelli, Matthias Philipp, Anders Brandt, and Jerry Martocci.Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks. Tech.rep. 6997. Aug. 2013. 40 pp. doi: 10.17487/RFC6997. url: https://rfc-editor.org/rfc/rfc6997.txt.

36

[28] Thread Group. url: http://www.threadgroup.org (visited on 06/21/2017).[29] Brian Haberman and Robert M. Hinden. Unique Local IPv6 Unicast Addresses. Tech.

rep. 4193. Oct. 2005. 16 pp. doi: 10.17487/RFC4193. url: https://rfc-editor.org/rfc/rfc4193.txt.

[30] C Hedrick. Routing Information Protocol. RFC 1058. The Internet Engineering TaskForce (IETF), June 1988. url: https://tools.ietf.org/html/rfc1058.

[31] Jonathan W Hui and David E Culler. “IP is dead, long live IP for wireless sensor net-works”. In: Proceedings of the 6th ACM conference on Embedded network sensor systems.ACM. 2008, pp. 15–28.

[32] Institute of Electrical and Electronics Engineers, eds. IEEE Standard for Local andmetropolitan area networks – Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer. IEEE Std. Apr. 2012.

[33] Internet of Things: Wireless Sensor Networks. Tech. rep. IEC, 2014. url: http://www.iec.ch/whitepaper/internetofthings.

[34] Richard Kelsey. Mesh Link Establishment. Internet-Draft draft-kelsey-intarea-mesh-link-establishment-06. Work in Progress. Internet Engineering Task Force, May 2014. 19 pp.url: https://datatracker.ietf.org/doc/html/draft- kelsey- intarea- mesh-link-establishment-06.

[35] J. Ko, J. Eriksson, N. Tsiftes, S. Dawson-Haggerty, M. Durvy, J. Vasseur, A. Terzis, A.Dunkels, and D. Culler. “Beyond Interoperability: Pushing the Performance of Sensor-net IP Stacks”. In: Proceedings of the International Conference on Embedded NetworkedSensor Systems (ACM SenSys). Seattle, WA, USA, Nov. 2011.

[36] JeongGil Ko, Joakim Eriksson, Nicolas Tsiftes, Stephen Dawson-Haggerty, Jean-PhilippeVasseur, Mathilde Durvy, Andreas Terzis, Adam Dunkels, and David Culler. “Industry:beyond interoperability: pushing the performance of sensor network IP stacks”. In: Pro-ceedings of the 9th ACM Conference on Embedded Networked Sensor Systems. ACM.2011, pp. 1–11.

[37] P Levis, Thomas H. Clausen, Omprakash Gnawali, Jonathan Hui, and JeongGil Ko. TheTrickle Algorithm. Tech. rep. 6206. Mar. 2011. 13 pp. doi: 10.17487/RFC6206. url:https://rfc-editor.org/rfc/rfc6206.txt.

[38] Philip Levis, Neil Patel, David Culler, and Scott Shenker. “Trickle: A Self-regulatingAlgorithm for Code Propagation and Maintenance in Wireless Sensor Networks”. In:Proceedings of the 1st Conference on Symposium on Networked Systems Design andImplementation - Volume 1. NSDI’04. USENIX Association, 2004, p. 2. url: http ://portal.acm.org/citation.cfm?id=1251177.

[39] ARM Limited. url: https://tls.mbed.org/ (visited on 08/25/2017).[40] G Malkin and R. Minnear. RIPng for IPv6. RFC 2080. The Internet Engineering Task

Force (IETF), Jan. 1997. url: https://tools.ietf.org/html/rfc2080.[41] G Montenegro, N Kushalnagar, J Hui, and D Culler. IPv6 over Low Power Wireless

Personal Area Networks (6LowPAN). RFC 4944. The Internet Engineering Task Force(IETF), Sept. 2007. url: https://tools.ietf.org/html/rfc4944.

[42] OpenThread. url: https://github.com/openthread/openthread (visited on 06/10/2017).[43] OpenThread. url: https://github.com/openthread/wpantund (visited on 06/10/2017).[44] OpenThread. url: https://github.com/openthread/spinel-spec (visited on 06/10/2017).[45] OpenThread. Porting Guide. Apr. 27, 2016. url: https://github.com/openthread/

openthread/wiki/Porting-Guide (visited on 06/10/2017).

37

[46] Joseph Polastre, Jason Hill, and David Culler. “Versatile Low Power Media Access forWireless Sensor Networks”. In: Proceedings of the 2Nd International Conference on Em-bedded Networked Sensor Systems. SenSys ’04. ACM, 2004, pp. 95–107. isbn: 1-58113-879-2. url: http://dx.doi.org/10.1145/1031495.1031508.

[47] S. Thomson, T. Narten, and T. Jinmei. IPv6 Stateless Address Autoconfiguration. RFC4862. IETF, Sept. 2007.

[48] Nordic Semiconductor. url: https://www.nordicsemi.com/News/News-releases/Product- Related- News/Nordic- Semiconductor- launches- its- first- Thread-networking - solution - via - a - new - Thread - SDK - for - its - nRF52840 - multi -protocol-SoC-that-supports-both-Bluetooth-low-energy-and-IEEE-802.15.4(visited on 07/04/2017).

[49] Zach Shelby, Klaus Hartke, and Carsten Bormann. The Constrained Application Protocol(CoAP). Tech. rep. 7252. June 2014. 112 pp. doi: 10.17487/RFC7252. url: https://rfc-editor.org/rfc/rfc7252.txt.

[50] Weiping Sun, Munhwan Choi, and Sunghyun Choi. “IEEE 802.11 ah: A long range 802.11WLAN at sub 1 GHz”. In: Journal of ICT Standardization 1.1 (2013), pp. 83–108.

[51] P Thubert, A Brandt, J Hui, R Kelsey, P Levis, K Pister, R Struik, JP Vasseur, andR Alexander. RPL: IPv6 routing protocol for low power and lossy networks. RFC 6550.The Internet Engineering Task Force (IETF), Mar. 2012. url: https://tools.ietf.org/html/rfc6550.

[52] Pascal Thubert and Jonathan Hui. Compression Format for IPv6 Datagrams over IEEE802.15.4-Based Networks. Tech. rep. 6282. Sept. 2011. 24 pp. doi: 10.17487/RFC6282.url: https://rfc-editor.org/rfc/rfc6282.txt.

[53] N. Tsiftes, A. Dunkels, Z. He, and T. Voigt. “Enabling Large-Scale Storage in SensorNetworks with the Coffee File System”. In: Proceedings of the International Conferenceon Information Processing in Sensor Networks (ACM/IEEE IPSN). San Francisco, CA,USA, Apr. 2009.

[54] Ambuj Varshney, Oliver Harms, CP Penichet, Christian Rohner, Frederik Hermans, andThiemo Voigt. “A Backscatter architecture that achieves a long communication range”.In: Proceedings of the International Conference on Embedded Networked Sensor Systems(ACM SenSys). 2017.

[55] Thomas Watteyne, Xavier Vilajosana, Branko Kerkez, Fabien Chraim, Kevin Weekly,Qin Wang, Steven Glaser, and Kris Pister. “OpenWSN: a standards-based low-powerwireless development environment”. In: Transactions on Emerging TelecommunicationsTechnologies 23.5 (2012), pp. 480–493.

38