CONCURRENT INTERNET OF THINGS PROTOCOL STACKS

(1)

Oktober 2019

CONCURRENT INTERNET OF THINGS PROTOCOL STACKS

Faizan Ehsan Elahi

Institutionen för informationsteknologi

Department of Information Technology

(2)

(3)

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

CONCURRENT INTERNET OF THINGS PROTOCOL STACKS

Faizan Ehsan Elahi

This work presents the design and implementation of a firmware prototype that allows multiple Internet Of Things (IoT) protocols to coexist such that they share a single radio. 6LoWPAN over Time Slotted Channel Hopping (TSCH) and Bluetooth Low Energy (BLE) are the two network protocols that are explored in this work.

6LoWPAN over TSCH forms a mesh network of low power embedded devices so that they are globally accessible through their IPv6 addresses. BLE is suitable for the direct connectivity between devices in short radio ranges.

Sharing a single radio between diverse protocols is challenging since protocols access the radio in different modes and with different time patterns. The proposed

architecture uses radio abstraction layer for dynamically sharing the radio based on the priority of the requests. Furthermore, concurrent operation of protocols is achieved with the help of priority based multitasking of Micrium operating system.

Finally, the time critical operations of the TSCH and the radio abstraction module are handled with nested interrupts.

The implementation of the firmware is evaluated with mainly two types of

experiments. Overall, it is observed from the experiments that both protocols can coexist concurrently and can maintain their connections. In one set of experiments, periodic data is sent over both protocols every 5 seconds (with small random jitter).

Basically these experiments involve small data traffic on both protocols. It is observed that the protocol with lower radio priority degrades in performance. Approximately 10% of the packets need re-transmissions, and thus have more latency for the protocol with lower radio priority.

The second set of experiments involve file transfers over 3 hops using 6LoWPAN, while one of the middle nodes (acting as a router for the file transfer) also carries BLE session comprising of 17 BLE activities. It is observed that the mean file transfer time with BLE session is delayed compared to the no BLE case. The delay is less than the duration of the two active TSCH slots.

This architecture is suitable for sharing a single radio where the network traffic is sparse. This architecture allows small embedded devices with a single radio to be accessible across many protocols without any modifications to the protocol standards. Although the performance degrades in the simultaneous operations, the protocols still keep their respective connections and complete their operations.

Tryckt av: ASSA ABLOY, RISE Kista IT 19 070

Examinator: Phillip Rummer Ämnesgranskare: Thiemo Voigt

Handledare: Nicolas Tsiftes and Zhitao He

(4)

(5)

Acknowledgments

I would like to show my gratitude for Network Embedded System (NES) group at RISE and ASSA ABLOY. RISE provided the great environment to do my thesis work.

Especially, Nicolas Tsiftes and Zhitao He, my supervisors, helped me throughout the thesis period to complete the thesis work. I would like to thank Tomas Jonsson for valuable feedback to my experiments, results, and thesis report.

I would like to thank Prof. Thiemo Voigt for providing me the right opportunity to do this thesis work. Although I was late in asking about the thesis, he handled the situation very friendly.

I would also like to thank Joakim Eriksson and Niclas Finne for much needed and helpful discussions.

I would like to thank Swedish Institute for their scholarship without whom it was not possible to do my master’s degree.

And especial thanks to my parents, my siblings, and my friends for appreciating and standing beside me to do my master’s degree.

(6)

(7)

List of Tables

Table 3.1: BLE Stack Constraints (taken from Silicon Labs user guide UG136 [36]) 26

Table 3.2: TASKS and their priorities . . . . 27

Table 3.3: Components that run in interrupt context . . . . 28

Table 3.4: Modules and their time sources . . . . 28

Table 5.1: File transfer latency (Mean) . . . . 64

Table 5.2: File transfer latency (Min and Max) . . . . 64

(10)

(11)

List of Figures

Figure 2.1: Contiki-NG NETSTACK . . . . 7 Figure 2.2: Slotframes in TSCH network . . . . 10 Figure 2.3: A typical timeslot of the TSCH protocol. Transmission and reception

of a packet and its acknowledgment within a timeslot. . . . 11 Figure 2.4: A typical 6TiSCH Minimal schedule with slotframe size of 101, while

slot offset and channel offset are 0. . . . 14 Figure 2.5: An illustration of time latency between two nodes using 6TiSCH

minimal configuration. Assuming that there are no collisions. . . . . 15 Figure 2.6: A typical example of an Orchestra schedule with slotframe length

of 2, 3 and 5 for application, rpl and beacons respectively. Orchestra schedule is also shown for the said priorities. . . . 16 Figure 2.7: Architecture of the BLE by Silicon Labs: BLE controller and BLE host

stack depict are two modules that implement all the components of BLE 19 Figure 3.1: Architecture of the dynamic concurrent network stack . . . . 25 Figure 3.2: Time line of different TSCH events inside a TSCH Slot . . . . 31 Figure 3.3: Flow chart depicting interaction of TSCH Tx Slot and RAIL Call Back 33 Figure 3.4: Flow chart depicting interaction of TSCH Rx Slot and RAIL Call Back 34 Figure 3.5: Screen shot from logic analyzer depicting two TSCH nodes synchro-

nized and repeating active TSCH slot with time interval of 30 msec . 35 Figure 3.6: Time drift with respect to TSCH coordinator/root node collected over

a time span of more than 30 minutes. Note that 1 tick is approximately 26.67us. . . . 36 Figure 4.1: Periodic UDP and BLE traffic. Note that there is small jitter in UDP

traffic, in comparison to BLE traffic. . . . 38 Figure 4.2: File transfer from client to server using CoAP . . . . 39 Figure 4.3: BLE session and advertisements . . . . 41 Figure 5.1: Two nodes configured with only BLE stack, BLE GATT client sends

read request every 5 seconds to which BLE GATT server responds back. 43 Figure 5.2: Experimental setup for baseline tests. Experimental setup is same for

both BLE only periodic tests and mesh only periodic tests . . . . 43 Figure 5.3: CDF and histogram of the Latency for BLE stack only, approximately

120 readings are collected to construct the graph . . . . 44

(12)

Figure 5.4: Two nodes configured with only Contiki-NG stack, UDP client sends a UDP packet approximately every 5 seconds and UDP server responds back . . . . 44 Figure 5.5: CDF and histogram of latency with only mesh network stack i.e.,

6LoWPAN over TSCH . . . . 46 Figure 5.6: MESH and BLE, client nodes are running in the single stack mode

while the server is operating two network stacks . . . . 47 Figure 5.7: Experimental setup for multiprotocol tests comprising of mesh and

BLE. For mesh protocol, UDP client / server application is used. . . 47 Figure 5.8: Multiprotocol experiments, comprising 6LoWPAN with 6TiSCH con-

figuration and BLE, are shown against the baseline of corresponding single stack experiments. Note that there are two different RAIL configurations. . . . 49 Figure 5.9: Multiprotocol experiments, comprising 6LoWPAN with Orchestra

configuration and BLE, are shown against the baseline of corresponding single stack experiments. Note that there are two different RAIL configurations. . . . 50 Figure 5.10: 3 hop mesh network with BLE advertisements . . . . 51 Figure 5.11: Experiment setup for 3 hop network . . . . 53 Figure 5.12: 3 hop mesh network, latency for 90 bytes file transfer versus unicast

slotframe size . . . . 54 Figure 5.13: 3-Hop mesh network, mean latency experimental and mean latency

computed with 5.56% TSCH re-transmissions . . . . 56 Figure 5.14: 3 hop Idle network Radio Usage against different unicast slotframe

sizes, *theoretical/Analytic values for Tx are computed with the assumption that there are only beacons traffic in the network, while for Rx it is assumed that all Rx slots are empty (i.e radio is on for minimal amount of time). . . . 57 Figure 5.15: 3 hop Idle network: average current consumption by the mesh network 59 Figure 5.16: 3 hop mesh network, 90 bytes file is periodically transmitted over 3

hop using CoAP, while router1 also carries BLE sessions every 5 seconds 60 Figure 5.17: Experiment setup for 3 hop network along with intense BLE traffic . 61 Figure 5.18: An example run of 45 seconds with unicast slotframe size of 131 show-

ing file transfers and BLE sessions, shaded regions are for file transfer.

Events for BLE sessions are also shown. . . . 62 Figure 5.19: Box plot for file transfer latency over mesh network with more than

110 readings in each category. Note that only those file transfers are used in which collision between TSCH and BLE happens . . . . 63

(13)

Figure 5.20: Two interesting packet forwarding scenarios, normal case packet forwarding, and delayed packet forwarding. Note that Rx events are shown only for application traffic. Unicast slotframe size for the given scenarios is 131. . . . 65 Figure 5.21: Box plot of time duration for BLE sessions with more than 450 mea-

surements in each category. . . . 66 Figure 5.22: Time duration measurements for BLE session while allowing file

transfer over mesh network in parallel (at the router node). Connec- tion interval for BLE is 37.5 seconds. . . . 67

(14)

(15)

1 Introduction

The Internet of Things (IoT) is composed of embedded devices that can sense their surrounding environment and communicate with each other. These embedded devices are called sensor nodes. Networks of sensor nodes are increasingly used in all aspects of life from industrial or home automation to health care and wearable devices. These diverse applications demand different kinds of network requirements such as bandwidth, energy consumption, and network latency etc., therefore it has given rise to the development of different network protocols. For example, 6LoWPAN, IPv6 over low power wireless personal area networks [1] is designed for running IPv6 on low power, low processing capability and memory-constrained devices. Other technologies such as Bluetooth Low Energy (BLE) [2] are developed for connectivity between different portable devices such as smart phones and tablets. BLE can be used in application areas such as health care, fitness gadgets, home automation, and the entertainment industry.

Many applications scenarios require that nodes, which are part of the mesh network (e.g., 6LoWPAN) are also accessible to the other devices (e.g., smart phone) over a more suitable protocol such as BLE. This motivates the development of an architecture that can enable sensor nodes to communicate over multiple network protocols.

In this master’s thesis, concurrent existence of multiple protocol stacks for sensor nodes is studied. Furthermore, concurrent applications on top of both protocols are developed and studied.

1.1 Problem Statement

Many network protocols (e.g., 6LoWPAN, BLE, and Zigbee [3]) exist for wireless sensor networks. Many applications require that nodes shall be able to communicate with different network devices over different protocols. One approach is to use a dedicated radio for each protocol, but that will increase the cost heavily, since nodes are deployed in large quantities. In this thesis, the feasibility of multiple network protocols over a single radio shall be explored. Network protocols shall operate simultaneously and seamlessly, i.e., without any modification to their standard.

Specifically, the coexistence of the mesh network (6LoWPAN) and Bluetooth (BLE) over a single radio is implemented and studied. 6LoWPAN can operate on top of many MAC layers such as CSMA/CA or TSCH (time slotted channel hopping) [4]. TSCH forms a network of time synchronized nodes with the help of its periodic beacons. In this work, 6LoWPAN over TSCH shall be adopted, since it is designed and suited for the

(16)

network of low power devices. The following three main goals are identified and shall be explored in this thesis.

Thesis Goals

1. Is it feasible to apply a single radio, concurrent stacks design comprising of mesh and BLE?

2. What are the performance limitations and design trade-offs?

3. Are there significantly different programming patterns required, in comparison to the single operating system?

The aforementioned questions shall be explored in the context of battery based locks. The battery based locks are connected to each other and to the system via a mesh network.

The mesh network of locks requires that the locks should route messages to each other.

Following are the two specific use cases for the operation of locks.

Use Cases

1. Remote lock configuration and local actuation. An operator sends an encrypted file containing user credentials and authority information to a lock, over multiple (up to three) hops in the wireless mesh; a confirmation message is returned within max 20 seconds.

2. Lock authorization. A user goes to a lock and uses her smart phone to actuate the lock by authorizing the lock over BLE.

Both use cases can happen at the same time.

1.2 Delimitations

This work is based on an experimental evaluation in a lab environment. The results and conclusions are drawn from the experimental readings based on the specific use cases. Single hop experiments are performed over wireless while three hop experiments are conducted with the help of coaxial cables to ensure three hop network topology throughout the experiments.

1.3 Scientific Contribution

In this work, a firmware architecture is designed for the concurrent and seamless operation of two protocol stacks on resource-constrained IoT devices. This architecture allows application development on top of two protocol stacks; i.e., 6LoWPAN over TSCH and BLE. An implementation of the firmware prototype is one of the contributions of this

(17)

work. It involved porting of the TSCH protocol to a new hardware and building of multi-protocol applications.

Furthermore, an experimental evaluation of the proposed architecture is also a contribution of this work. To the best of my knowledge, this is the first time that 6LoWPAN over TSCH and BLE operate together over a single radio.

1.4 Motivation and Challenges

Multiple network protocols on a single device can be combined with the help of separate radios, a technique which is usually found in network gateways. Gateways provide a means of communication between two entirely different protocols. Usually sensor nodes are deployed in large quantity, and equipping each sensor node with multiple radios is costly. It is estimated that the node cost decreases by 40% with a single radio compared to two radios [5]. Therefore a software architecture that can seamlessly operate multiple network protocols over a single radio is needed. Such an architecture for multiple protocols over a single radio must support radio sharing among these protocols.

Since protocols implement their own MAC layers, they have their own constraints for accessing the radio.

For example, Time Slotted Channel Hopping (TSCH) [4] (a MAC layer for the mesh network) is suitable for duty-cycling nodes, where time synchronized nodes wake up at specific times to communicate and sleep most of the time to save energy. On the other hand, contention based protocols (CSMA/CA) keep the radio on most of the time for the incoming traffic, and therefore consume more energy. More specialized protocols such as BLE also rely on time critical communication. These time sensitive protocols, such as TSCH and BLE, also communicate periodically to keep their connections alive. For example, TSCH nodes transmit and receive beacons periodically to keep their connection and synchronization. Similarly, BLE relies on periodic connection events in which two BLE connected devices exchange information with each other. These protocols are quite generic, dynamic, and their radio usage pattern change on the basis of network traffic.

The proposed architecture in this work uses a radio abstraction layer for dynamically sharing the radio between different protocols. The radio abstraction is based on the mechanism of priority and estimated time of the request. Protocols make requests to the abstraction layer for a particular task (such as TX/RX). The abstraction mechanism then checks this request against the ongoing request based on the priority. If the ongoing request is of low priority and taking more time than the estimated time, then it can pre- empt the ongoing request and give the radio to the high priority request. In this way, the abstraction layer provides a means for multiple protocol stacks to coexist over a single radio. At the moment of conflict, only one protocol can access the radio, and therefore protocols should support a retransmission mechanism to ensure stable operation.

In addition to the radio sharing, the proposed architecture should execute both protocols concurrently. This requires that each protocol shall be given sufficient time and

(18)

computation resources for its successful operation. Therefore an operating system (OS) that supports multitasking is needed for a modular and flexible implementation of both protocol stacks. Priority based multitasking is helpful, since the OS takes care of the scheduling on the basis of priority. Otherwise the developer needs to take care of the proper operation of all the tasks during implementation.

1.5 Structure of the Report

The report is structured as follows. In Chapter 2, the reader is introduced with Contiki- NG and its 6LoWPAN over TSCH stack. Then the BLE stack, Micrium operating system, Radio Abstraction Layer Interface (RAIL), and related work are described. Chapter 3 discusses the multiprotocol architecture and its implementation. Chapter 4 describes application development to demonstrate the use cases. Experiments and their results are presented in Chapter 5. The thesis is concluded in Chapter 6.

(19)

2 Background

In this chapter both protocol stacks i.e., 6LoWPAN over TSCH and BLE, are described.

There is an open source implementation of 6LoWPAN over TSCH inside Contiki-NG [6], available at its gihub repository [7]. This TSCH implementation is awarded silver logo [8] and shall be used in this work. Therefore, Contiki-NG is introduced first and then its protocol stack 6LoWPAN over TSCH. Afterwards BLE, Micrium, RAIL and related works are described.

2.1 Contiki-NG: The Next Generation Operating System

Contiki-NG [6] is an open source operating system for low power embedded devices.

Contiki-NG is written in C programming language. It focuses on reliable and secure network stack comprising of all traditional layers of the internet. Its network stack (NETSTACK) enables network devices to construct a mesh network. In the mesh network, all nodes are globally accessible through Ipv6/6LoWPAN. It is tested and verified on many hardware platforms such as MSP430 from Texas Instruments and the ARM Cortex-M3/M4. There is a lot of support and documentation available for porting it to the newer platforms. It is released through its github repository [7]. Details about its network stack comprising of 6LoWPAN over TSCH are given in the following section.

2.1.1 Contiki-NG Network Stack

Contiki-NG network stack (also referred as NETSTACK) is built in layers. NETSTACK in the block diagram format is shown in Figure 2.1.

Complete stack is composed of six layers starting from the application layer down to the radio driver layer.

• Application layer (optional) of the NETSTACK provides support for protocols such as CoAP (Constrained application protocol) [9] for building web applications.

CoAP is an application layer protocol that is built on top of UDP (user datagram protocol) [10]. Although UDP is unreliable data transfer protocol, however CoAP provides support for acknowledged messages. Therefore it can be used for the applications that demand reliability such as file transfers etc. For more details on CoAP in Contiki-NG see [11].

• Transport layer provides support for protocols such as user datagram protocol (UDP). UDP is a connection-less protocol to transfer data between two network

(20)

Figure 2.1: Contiki-NG NETSTACK

devices. It needs no prior handshake. Applications can use UDP to send data to other devices based on their IP (internet protocol) addresses. In Contiki-NG stack, it is built on top of Ipv6 network layer.

• Network layer is composed of two protocols i.e., IPv6 (internet protocol version 6) [12] and RPL (routing protocol for low power and lossy networks) [13]. Ipv6 provides identification to the devices in the network, while RPL provides routing across the network of sensor nodes. RPL uses Ipv6 packets to get the network information and construct routing table. RPL maintains a destination oriented directed acyclic graph (DODAG) structure. A DoDAG root is usually a border router. All the nodes are ranked according to their distance (distance metric is based on some cost function such as ETX) from the root. Nodes send packets to the root by forwarding to their neighbors with smaller ranks. Root send packets to the nodes with the help of reverse links. For communication between one node to any other node in the network, there are two approaches in RPL. First one is known as storing mode, in this mode, packets are sent upstream (towards root) until a common ancestor is reached then the packet is sent downstream (away from the node) to the destination. Second approach is non storing mode i.e., nodes send packet upstream to the root node and then root node sends them to the destination.

Both implementations of RPL i.e., storing and non storing mode (RPL lite) are

(21)

available in Contiki-NG. In this work, RPL lite version is used, it needs less memory than the storing mode implementation, since only the root node (typically border router) stores routing information.

• Adaptation Layer: NETSTACK is powered with adaptation layer that implements 6LoWPAN [1]. Purpose of this adaptation is to compress the data from the upper layers and also perform fragmentation (if compressed data is still large) before passing to the MAC layer (e.g., IEEE 802.15.4). Similarly on receiving data from MAC layer, it decompresses and also combines the fragments (if needed). This adaptation is very useful for low power lossy networks of sensor nodes since it enables them to connect to the internet and globally accessible through their IPv6 address.

• MAC Layer: Contiki-NG stack implements IEEE 802.15.4e [14] for its MAC and physical layer. IEEE 802.15.4e mainly defines two MAC layers i.e., unslotted CSMA-CA and Time Slotted Channel Hopping (TSCH). TSCH provides better robustness against interference than single channel MAC protocols such as CSMA- CA MAC of IEEE 802.15.4-2011. TSCH is suitable for sensor nodes since it provides a mean of duty cycling radio and thus saves energy. Core of the TSCH protocol is its time scheduled slot operations where nodes can communicate during that slots only. TSCH implementation and its evaluation for Contiki-NG is given in [8].

• Radio driver Layer: Contiki-NG has a radio driver layer that handles low level radio operation for the specific hardware. Radio driver layer provides control to the MAC layer for specific radio operations. For example, TSCH MAC can select any of the channels (given in the standard) for its communication.

Contiki-NG network stack is built on top of Contiki-NG kernel. It uses many significant features from Contiki-NG kernel for its successful operations. These features of the Contik-NG kernel are given in the following section.

2.1.2 Contiki-NG Kernel

is extended from Contiki-OS [15], therefore it inherits all the significant features such as, processes, protothreads, events and timers etc.

• Processes: Processes are C functions that are built on top of protothreads. Processes provide a mean of multitasking.

• Protothreads: Protothreads are stack less, lightweight threads that provide a mechanism of blocking function.

• Events: Contiki-NG OS provides many types of system events like expiration of a timer, arrival of a packet etc.

(22)

• Timer: Contiki-NG OS provides different types of timer for application development such as etimer (generates an OS event on expiry), ctimer (provides a call back mechanism to execute some function) and rtimer (real time timer for time crticial applications).

Since Contiki-NG is based on stack less threading, so all the programs and the kernel itself share the same stack. This gives it an advantage of very low memory requirement.

However processes need to take care of its own state whenever it blocks itself and resume its operation later.

It is an event driven operating system, and provides processes for multitasking. How- ever, it is pertinent to note that it provides cooperative scheduling i.e., all the processes should split their work load on the basis of events and suspend their execution so that scheduler can run other processes as well. In short, processes should not run for longer period of times so that all the processes can get sufficient execution time. This cooperative scheduling of processes shall be taken care for developing Contiki based applications. For more details on Contiki processes, multitasking and events see [6].

Since this thesis involves porting of the TSCH protocol to a newer hardware platform, therefore it’s concepts are elaborated further in the following Section 2.2.

2.2 Time Slotted Channel Hopping (TSCH)

TSCH (time slotted channel hopping) [4] is a protocol for establishing a network of low power devices. It features channel hopping for robustness against interference. It accesses radio in duty cycled fashion thus saving energy. It operates at 2.4 GHz frequency band. Core of the TSCH consists of one or many slotframes that repeat forever. Slotframe and its components are defined below:

• Slotframe: A slotframe is a set of timeslots.

• Slotframe size: slotframe size is the number of timeslots in the slotframe.

• Timeslot: Timeslot or slot is the smallest cell of the TSCH slotframe where node can communicate with each other. It is marked by slot offset and channel offset.

It is typically 10 ms long. This time duration is long enough to send a packet and receive its acknowledgment in a single timeslot.

• Slot offset: It is a number ranging from 0 to slotframe size - 1 that defines the position of slot inside the slotframe.

• Channel offset: Channel offset is a number associated to a given slot to help in determining the radio channel for the communication. Channel offset is important in randomizing channel selection thus facilitates channel hopping.

• Absolute slot number (ASN): ASN is a global identifier of the slots and it increments with every slot irrespective of the slotframe. ASN is same throughout the network.

(23)

In a typical TSCH operation, TSCH slotframes keep repeating itself so as the timeslots inside those slotframe. However the radio channel for the same slot keeps changing to incorporate channel hopping. TSCH slotframe operation is illustrated in the Figure 2.2 for two cases i.e., single slotframe and multiple slotframe. In Figure 2.2a a simple case of 4 slots in a slotframe. ASN increments by 1 with every timeslot and is globally same in all the network. It is also shown that the same timeslot such as marked by ’X’ translates to a different frequency each time. Selection of the radio channel is explained below.

(a) A single slotframe of size 4 with 16 channels. Channel for timeslot 2 with channel offset 1 (marked as ’X’) is also shown. Channel for the marked slot keeps changing as ASN grows.

(b) Multiple slotframes with slotframe 1 comprising of 5 slots and slotframe 2 comprising of 3 slots

Figure 2.2: Slotframes in TSCH network

Radio Channel Selection

Radio channel for a given timeslot is selected on the basis of ASN, channel offset and available frequency channels. Frequency channel for a given slot is computed as following:

f requency=F((ASN+channelO f f set) mod nFreq) (2.1) where ASN is absolute slot number, channelO f f set is channel offset for the given slot and nFreq is the total number of frequencies (channels). F()is typically a look up table for available set of channels. ASN, channelO f f set and nFreq for a given slot in the slotframe are known to every node in the network. Therefore nodes compute correct channels locally without any other information from the network. The consequence of channel hopping is that node keep changing their radio frequencies in a deterministic, pseudo random manner. So, if a transmission fails at a particular frequency due to

(24)

multipath fading or interference, next time the communication occurs at a different frequency mitigating the effects of the environment. Watteyne et al. analyzed channel hopping effects in detail in [16]. It also allows multiple nodes to communicate with each other during the same slot, however at different frequency.

Types of Timeslots in TSCH

Timeslots in the TSCH are of many different types. Broadly, slots can be separated into two categories i.e., dedicated and shared. Dedicated slots are for a specific link between two nodes (one transmitter and one receiver) to communicate with each other resulting into direct and deterministic traffic. While in the shared slots, multiple nodes (multiple transmitters and receivers) can participate in communication, thus collisions are expected that can result into unpredictable behavior. However, shared slots are suitable for high throughput and low energy consumption when per-node work load is low. Shared slots also offer higher network scalability. Furthermore a slot can be TX only or Rx only or both. There can be dedicated slots for beacons as well.

Structure of a Typical TX and RX Slot

TSCH standard does not define duration of the timeslot. However, in the literature, it is typically 10 ms [4], [8] long which is sufficient to send a IEEE 802.15.4 frame and receive its acknowledgment. Typical structure of Tx and Rx timeslots of the TSCH are shown in the Figure 2.3.

Figure 2.3: A typical timeslot of the TSCH protocol. Transmission and reception of a packet and its acknowledgment within a timeslot.

Important Concepts about Working of TSCH

Many aspects about the TSCH network are discussed in the literature. However following three are quite interesting to discuss from its working point of view.

• Network Formation

• Time synchronization

• TSCH Schedule for its slots

Each of these concepts are discussed in the following sections.

(25)

2.2.1 Network Formation

TSCH has a central node known as TSCH coordinator/root (typical it is also RPL root node) that transmits enhanced beacons (EBs) periodically usually at different radio channels. Other nodes begin a joining process by scanning i.e., looking for beacons. Once the node listens TSCH beacon from a beaconing node. It gets the network information i.e., absolute slot number (ASN), join priority (sometimes referred as join metric), TSCH basic schedule, timeslot template and hopping sequence template. With this information, node synchronizes itself with the beaconing node, switches itself to the TSCH mode and becomes part of the network. In TSCH mode, it starts following the given schedule.

Moreover, it also starts transmitting beacons so that more nodes can listen and join the network as well.

Join Priority

Join priority is a number between 0 and 255. For any node in the network, join priority is the measure of how far the given node is from the root node in topological sense i.e., lower the join priority, nearer to the root node. In case, multiple beacons are received from the network, then a mechanism for choosing the best parent is provided with the help of join priority. For the shorter distance to the root, nodes can select the parent with smaller join priority.

In the presence of RPL, join priority is based on the rank of the node. Lower rank results into smaller join priority which in turn results into better chance of being selected as the parent.

2.2.2 Time Synchronization

TSCH timeslots occur at precise intervals, this requires that all the nodes in the network should be synchronized with each other. On joining the network, node synchronizes itself with the beacon source (parent node). This one time synchronization is not enough since time source (usually crystal oscillators) at each sensor node suffers from the time drift. Due to this time drift, nodes will lose their synchronization. To address this problem, nodes must have some mechanism to correct its time drift. In TSCH implementation of the Contiki-NG [8], nodes synchronize with its parent in two ways:

• Packets from the parent: Nodes compute time difference between the arrival of a packet from its parent and its expected arrival time inside that timeslot. This time difference is used to correct its drift from the time source.

• Acknowledgments: Parent calculates drift (the time difference between the arrival of a packet and its expected time) for the unicast packet from its child and send it in the acknowledgment. Child node then corrects its time drift with respect to the parent.

(26)

In this way, child nodes keep their time synchronization towards their parents (time source).

2.2.3 TSCH Schedule for its slots

TSCH schedule for its timeslots is beyond the scope of TSCH standard and leaves it to the implementation. This allows optimization of performance trade-offs for a given application. However, there is a minimal configuration know as 6TiSCH [17] for successful operation of TSCH protocol. This minimal configuration provides a minimal schedule that shall be incorporated by all the device in the TSCH network.

Many other schedules are also presented in the literature such as WirelessHART [18], ISA100.11a [19] and Orchestra [20]. Former two focuses on centralized scheduling i.e., a central entity collects information about the network and disseminates the schedule to all the nodes in the network. Other than centralized schedule, TSCH standard also allows distributed schedules in which nodes can negotiate with its neighbor about the slots and can then insert/remove the slots from the schedule. Orchestra, however is different from both central and distributed approaches. It provides a mechanism of building autonomous schedule such that the nodes compute it locally with the help of routing information.

Currently there are two schedules that are available in the Contiki-NG i.e., 6TiSCH- Minimal [17] and Orchestra [20]. Both are described in the following sections.

2.2.4 6TiSCH

6TiSCH is an acronym for Ipv6 over the TSCH mode of IEEE 802.15.4e configuration.

Its minimal configuration is known as 6TiSCH minimal. This minimal mode shall be implemented and supported by all the TSCH devices irrespective of the presence of some other schedule. In this thesis, 6TiSCH is used in its minimal configuration.

In 6TiSCH minimal configuration, only one slotframe is used. In each slotframe, only one timeslot is scheduled and all the other slots are off i.e., not scheduled. Scheduled cell/slot can be at any slot offset/channel offset, however these offsets shall be communicated in the beacons. Type of this scheduled cell/slot is TX/RX/Shared/EB i.e., this slot handles all types of communication in the network. Therefore, this slot is contention based i.e., collisions in the radio transmission are expected. A typical TiSCH minimal schedule for slotframe size of 101 is shown in the Figure 2.4.

6TiSCH Performance

Since 6TiSCH is based on contention based slot and contains only one active slot in the slotframe. Therefore its slotframe size, which is the numbers of timeslots in a slotframe, gives trade off between energy consumption and the bandwidth of the network. Smaller slotframe size results into higher bandwidth at the cost of higher energy consumption.

In this configuration, two types of collisions are possible that will effect its performance.

(27)

Figure 2.4: A typical 6TiSCH Minimal schedule with slotframe size of 101, while slot offset and channel offset are 0.

• Radio collision: Two or more nodes transmitting packet at the same time.

• Protocol collision: The transmitting node has two or more packets to transmit e.g., beacons and the application traffic.

Frequent collisions can be costly for the network performance since it costs more energy for re-transmissions and also degrades network performance i.e., latency is increased.

TSCH re-transmission mechanism is based on the random back off period, which grows exponentially with the number of failures for a given packet. Domenico De Guglielmo et. al. discussed and evaluated TSCH and its re-transmission performance in detail in [21].

Along with collisions, application jitter also affects TSCH performance. Application jitter is the time difference between the application level sending and the actual radio transmission. This jitter occurs due to the fact that the communication can happen only in active TSCH slots. The jitter can be as low as 0 (application sends data just at the occurrence of the scheduled slot) and can go upto maximum of 1 slotframe length (application sends right after the occurrence of the slot).

Round Trip Time in 6TiSCH Configuration

Round trip time (latency) of packets exchange between two neighboring nodes with out collisions latencywcis illustrated in Figure 2.5. Note that Node 2 can send response at application level before the next slot and does not affect the latency.

Mathematically, expected latency can be written as

latency_wc=latency_min+Jitter_app, (2.2) where Jitterapp is application jitter and latency_min is minimum latency with out jitter and collisions. Minimum latency is(SF_size+1) ×T_slot, substituting in 2.2, then expected latency with out collisions is

(28)

Figure 2.5: An illustration of time latency between two nodes using 6TiSCH minimal configuration. Assuming that there are no collisions.

latency_wc= (SF_size+1) ×T_slot+Jitter_App≈SF_size×T_slot+Jitter_App. (2.3) Where SF_sizeis the slotframe size and T_slot is the slot time (usually 10 msec). Approx- imation used in 2.3 is valid usually because of the very high SF_size compared to the individual duration of the slot T_slot. The expressions for minimum and maximum latency without collision are given int 2.4 and 2.5 respectively. Since application jitter can be maximum of one slotframe duration.

latency_min=SF_size×T_slot (2.4) latency_max=2×SF_size×T_slot (2.5) 2.2.5 Orchestra

Orchestra is a locally computed schedule for TSCH networks. It is composed of multiple slotframes of different sizes. Slotframes are dedicated for different types of traffic.

Particularly, it identifies three overlapping slotframes based on the traffic types which are given below:

• EB slotframe: A slotframe for the TSCH enhanced beacons.

• Broadcast slotframe: A slotframe typically for the routing messages i.e., RPL traffic.

• Unicast slotframe: A slotframe for the application traffic.

Sizes of all three slotframes are chosen co-prime so that their active slots collide with each other with minimum probability. To resolve a collision scenario, a priority mechanism is described. Slots with low priority are skipped in case of conflict. Priorities are defined at the compile time on the urgency of traffic i.e., beacons are the highest, then comes the routing traffic, and the application traffic has the lowest priority. A typical example

(29)

run of an Orchestra schedule is shown in Figure 2.6. It can be seen that beacons are the highest priority while the application is given the slot only when there is no other traffic.

Figure 2.6: A typical example of an Orchestra schedule with slotframe length of 2, 3 and 5 for application, rpl and beacons respectively. Orchestra schedule is also shown for the said priorities.

Instead of getting information about the slots (its slot offset and channel offset) from the network, nodes compute these parameters locally. It is computed on the basis of either node’s own identity (e.g., MAC address) or the neighbor’s identity. In this way nodes does not need to communicate any other information for the slot selection and therefore no signaling overhead.

Orchestra Slots

TSCH slots can be of different types i.e., dedicated/shared and TX/RX/Common.

6TiSCH employs only common and shared (CS) type slots i.e., any node can communicate with anyone in that slot. In addition to the common shared (CS), Orchestra identifies three other types of slots:

• Receiver based shared (RBS) slots: A slot for communication between two neighbors, with its slot offset and channel offset computed on the basis of receiver’s identifier (ID). To incorporate RBS, a given node should keep one Rx slot (based on node’s own ID) and one Tx slot per neighbor (based on the corresponding neighbor’s ID).

• Sender based shared (SBS) slots: It is very similar to RBS, however, slot parameters are based on sender’s ID. Therefore, it creates one Tx slot (based on node’s own ID) and one Rx slot per neighbor (based on the corresponding neighbor’s ID).

• Sender based dedicated (SBD) slots: Orchestra identifies SBD slots for the contention free communication i.e., a dedicated slot for communication with each neighbor. SBD requires that the slotframe size should be large enough to incorporate all the dedicated slots. Slot offset can be hard coded before deployment or obtained from a network manager at the run time.

RBS offers single Rx slot corresponding to a given node, therefore all its neighbors contend for that slot to communicate with it, hence collisions are expected. On the

(30)

other hand, SBS keeps a separate Rx slot for every neighbor, hence no contention, but it requires more energy than RBS. Since the node has to wake up and listen for every neighbor.

Orchestra Setup

Orchestra presents following two alternative architectures or setups for its practical demonstration:

• Setup with RBS unicast slots:

Beacons or EB slotframe (S0) consists of (sender based dedicated) SBD slot, therefore every node keeps one Tx (EB transmission) and one Rx slot (listening EB from time source). Slots in S0 are contention free and EBs provide child-parent synchronization.

Broadcast slotframe (S1) for RPL employs (common shared) CS slot. This slot periodically collides with S0 and thus skipped.

Unicast slotframe (S2), in this setup, comprises of receiver based shared slot (RBS).

Thus every node expects incoming traffic in the slot based on its own ID. Nodes transmit in that particular slot for the communication. This slot has the lowest priority and can be skipped due to collision with S0 or S1.

All these slotframes S0, S1 and S2 repeat with three different slotframe lengths X, Y and Z (co prime numbers) respectively. X should be longer than the number of nodes in the network. Typical choice is X > Y > Z.

• Setup with SBS unicast slots:

EB slotframes and Broadcast slotframe are same as described in the above setup.

However, unicast slotframe (S2) contains sender based sharded (SBS) slots instead of RBS. Thus each node has one Tx slot (based on its own id) and multiple Rx slots to listen their children.

The advantage of SBS bases setup over the RBS is low contention due to mulitple Rx slots compared to single Rx slot in RBS setup. This advantage is at the cost of increased energy consumption i.e., maintaining many RX slots.

Orchestra Performance

Orchestra performance depends on the traffic type since it incorporates three different slotframes. Network latency in Orchestra is proportional to the slotframe size of that particular traffic e.g., latency for application traffic is proportional to the unicast slotframe size. Since Orchestra schedule splits traffic load into three different planes, therefore it avoids network contention a lot compared to the 6TiSCH schedule. For more details on the Orchestra contention, Simon Duquennoy et al. [20] presents probabilistic model and experiments for the performance analysis.

(31)

2.3 Micrium Operating System

Micrium operating system [22] is a priority based, preemptive real time kernel designed for embedded systems. It is mostly developed in C programming language. It was initially launched in 1991 and it’s two variants uC/OS I and II were quite popular in embedded systems community. It’s latest release is Currently it is developed and maintained by Silicon Labs. It is available freely for educational and proof of concept purposes. Micrium kernel is used for its priority based multitasking capability and its compatibility with BLE stack. Its key concepts are:

• Tasks: A task is simply a C function that usually contains an infinite loop. If it does not contain an infinite loop, it will kill itself once it completes its execution. A task is a basic block for creating multitask applications.

• Task Management: Micrium provides task management such as creating, running, suspending, resuming and deleting a task. In addition it offers control of task stack and its priority.

• Scheduling: Micrium offers preemptive scheduling based on priorities. It always runs the highest priority task among the available tasks.

• Other significant features are: mutual exclusion semaphore (mutexes), semaphores, events, timers and message queues. These features are suitable for building flexible applications. Mutexes and semaphores are good for safe signaling and sharing of the resources among tasks. While message queues are good in data exchange between tasks. Micrium provides mainly two types of timers i.e., one time timer and periodic timers. These timers are mostly needed and helpful in building embedded applications.

Preemptive scheduler of Micrium can take care of scheduling the tasks based on priorities. Otherwise developer should take care of managing software modules so that every module can get fare share of time for its execution. Extensive documentation and support material about Micrium OS is given at [23]. Both BLE stack, given in Section 2.4, and RAIL, given in Section 2.5, by Silicon Labs are compatible with Micrium OS, and both are tested and operated with Micrium OS by the vendor.

2.4 Bluetooth Low Energy

Bluetooth low energy (BLE) [24] is a wireless technology designed by Bluetooth special interest group (SIG). It is designed for low powered battery operated devices that can work for years on single coin battery. Particularly, it is suitable for direct connectivity with portable devices such as smart phone, tablet and wearable devices etc. Target area of applications is home automation, wearable devices and health care etc.

Silicon Labs releases BLE stack implementation dedicated for their hardware. In this

(32)

work, BLE stack by Silicon Labs is used for the development of BLE application. Silicon Labs user guide [25] provides basic understanding of the BLE fundamental concepts and their working. In the Figure 2.7, component level details of BLE stack are shown.

Silicon Labs implements BLE stack in two modules i.e., ’BLE controller’ and ’BLE host stack’. For details about BLE stack and its software API see [26].

Figure 2.7: Architecture of the BLE by Silicon Labs: BLE controller and BLE host stack depict are two modules that implement all the components of BLE

Components of the BLE stack are described below:

• RF and PHY: It handles radio reception and transmission. BLE operates at 2.4GHz (2402 MHz to 2480 MHz) and has 40 channels. Three out of 40 channels are chosen for advertisements, that minimizes interference from other radio communications.

Typical BLE range is 160 meters for 0 dBm and 295 meters for 10 dBm

• Link layer:It handles low level time critical connection management. In a typical BLE connection, one device is master and the second is client. A device that scans and initiates the connection is master while the device that advertises and con- nectable is slave. Connection management is based on connection event/interval, connection latency and connection timeout.

Connection eventis the time period, with which a master sends a packet to a slave and then slave responds back within 150 us. It is also referred as connection interval.

(33)

Connection latencydefines the number of connection events that a slave can skip without responding back and still have valid connection.

Connection timeoutis the maximum amount of time without any successful communication, after which the connection is lost.

Other link layer operations are advertising and scanning. It also handles encryp- tion and decryption of the packets at MAC level.

• Host controller interface (HCI):An interface layer between host and controller modules of the BLE stack implementation .

• Logical Link Control and Adaption Protocol (L2CAP): This protocol provides adaptation mechanism to handle large data packets. It fragments large packets to make it compatible with the link layer and on reception of the fragments, it assembles them into the correct packet for higher layers.

• Generic Access Profile (GAP):GAP is a top layer that lets application to control link layer operations. Through GAP, applications can control and operate its different BLE modes such as:

Broadcaster: A device that is transmitting advertisements and broadcasts data. It does not receive.

Observer: A device that only listens for BLE advertisements and broadcasts. It does not transmit.

Peripheral (slave): A device that transmits advertisements making it discover-able, so that other devices can find it and make connection. This is always slave mode.

In this mode, device can perform both radio operations i.e., transmitting and receiving.

Central (master): A device that does not advertise, however scans and connects to other devices. Similar to the peripheral device, a central device also performs both operations (Tx and Rx).

• Attribute Protocol (ATT):ATT is composed of attributes and procedures. An attribute is a state stored in a BLE device. It is an array that holds data. Attribute has a unique identifier called UUID, through which it can be identified and accessed.

ATT procedures are used to exchanged information stored in theses attributes.

Common ATT procedures are read/write/notify etc.

Based on the access of a given attribute, a BLE device can be in one of the following two roles,

CLIENT: A BLE device that access the attributes of another BLE device,

SERVER: A BLE device that stores attributes and other devices can access these attributes.

A BLE client can access attributes of BLE server through ATT procedures such as read/write requests. Server can also inform client about state of its attributes through notifications/indications type procedures. A given BLE device can act as

(34)

BLE client or server or both, however at a given time it will be in one of those roles.

This client/server roles is independent of GAP master/slave mode.

In short, attribute protocol provides procedures for communication between BLE devices. It offers robust data transfer between the connected BLE devices. There are typically two types of ATT procedures i.e., acknowledged (e.g., read, write, and indications) and non-acknowledged (e.g., notifications). Acknowledged type procedures need two connection intervals for its completion. While non-acknowledged can make multiple transactions inside a connection interval.

• SM (security manager):Security manager handles security mechanisms such as pairing, key distribution, hashes and short term keys. In this way, it provides safe, secure and protected communication between BLE devices.

• GATT (Generic Attribute Profile): GATT is a profile that is built on top of attribute protocol (ATT). A typical GATT profile consists of one or more services (designated by unique identifier UUID), each service further consists of one or many characteristics. A characteristics is composed of attribute (transported by ATT protocol) and its description (such as name, UUID, type, length and allowed ATT procedures). It also inherits ATT roles of client and server as GATT client and GATT server respectively.

Special interest group (SIG) defined many standardized GATT services and characteristics such as ’Health Thermometer’ and ’Battery Level Indication’ etc. For more details on GATT services see [27].

2.5 Radio Abstraction Interface Layer

Radio abstraction interface layer (RAIL) is used as an abstraction layer for dynamically sharing radio between multiple protocols. It is designed and tested by Silicon Labs for its range of products including mighty gecko EFR32 which is used in this work.

RAIL [28] is an abstraction between software and the radio hardware. It resides between MAC layer of a network stack and physical layer. To port a given network stack e.g., Contiki-NG 6LoWPAN over TSCH, a wrapper shall be needed to interface the TSCH port with the RAIL. The most significant feature of this abstraction is to provide support for multiprotocol operations. Core of the RAIL is based on the following components:

• Start time:An indication of the start time of the radio operation. It can be right now or some time in the future.

• RAIL priority: In multiprotocol operation, every request for radio operation is composed of RAIL priority. It helps RAIL to decide between two or more requests in case of conflict.

CONCURRENT INTERNET OF THINGS PROTOCOL STACKS

Oktober 2019

CONCURRENT INTERNET OF THINGS PROTOCOL STACKS

Faizan Ehsan Elahi

Institutionen för informationsteknologi

Department of Information Technology

CONCURRENT INTERNET OF THINGS PROTOCOL STACKS

Acknowledgments

Table of Contents

List of Tables

List of Figures

1 Introduction

1.1 Problem Statement

1.2 Delimitations

1.3 Scientific Contribution

1.4 Motivation and Challenges

1.5 Structure of the Report

2 Background

2.1 Contiki-NG: The Next Generation Operating System

2.2 Time Slotted Channel Hopping (TSCH)

2.3 Micrium Operating System

2.4 Bluetooth Low Energy

2.5 Radio Abstraction Interface Layer