Product
Alp Protocol Stack
A protocol stack for next generation IoT applications.
1 INTRODUCTION
In recent years, there is an increased interest toward Wireless Sensor Networks (WSNs) with the introduction of application areas such as m-Health and Smart Grid. WSNs consist of sensors with wireless capability operating autonomously and reporting application specific parameters to a central entity. The reported parameters depend on the application and vary in terms bandwidth, delay and Quality of Service (QoS) requirements. For example, as shown in Figure 1.1, a Smart Grid application requires reporting of metering data with predefined intervals to a central server through a concentration point. For this application, delay experienced in the network should be deterministic to guarantee a reliable control of the electricity grid. This brings about the challenge of having a WSN with a deterministic network delay. Having a deterministic network delay in a WSN is challenging in the best case when traditional Medium Access Control (MAC) protocols and routing mechanisms are employed.
In 2012, IEEE has published an amendment document to 802.15.4 MAC protocol to enable time slotted access to the communication medium called as 802.15.4e (will be called as 4e MAC from now on). Furthermore, the nodes using 4e MAC can use channel hopping to improve communication reliability. While 4e MAC provides mechanisms for having deterministic and reliable one hop connectivity, it is a requirement for many WSN applications to make use of this technology over multiple hops. Therefore, a standardization effort is needed to bring together 4e MAC and established IPv6 based sensor routing protocols (6LowPAN). This will enable a deterministic mesh networking protocol which can be an enabler for future Machine to Machine communications. This protocol is conveniently named as 6TiSCH (IPv6 routing over time slotted channel hopping MAC). This document describes the development efforts for implementing 6TiSCH protocol in Contiki Operating System.
2 A BRIEF INTRODUCTION TO 6TISCH
As motioned in the previous section, the main goal of 6TiSCH is to enable IPv6 routing over 4e MAC. The previous efforts to bring IPv6 routing to 802.15.4 domain required and adaptation layer to enable reliable transmission of large IPv6 frames (with a minim MTU size of 1280 bytes). For example, an un-fragmented IPv6 packet is too large to fit in a 15.4 frame. Furthermore, the overhead due to the 40-byte long IPv6 header wastes a large part of available bandwidth at the PHY layer [RFC4944]. For these reasons, the 6LoWPAN working group defined an adaptation layer [RFC6282]. 6LowPAN adaptation layer also encompasses the auto- configuration of IPv6 addresses [RFC2460][RFC4862], the reduction of routing and management overhead [RFC6606], the adoption of lightweight application protocols (or novel data encoding techniques), and the support for security mechanisms such as bootstrapping of the devices which want to join to the existing network.
The same solution in principal can run on top of a time slotted channel hopping (TSCH) MAC, but there are some challenges to be addressed to enable this. The most obvious difference between traditional low power MACs and a TSCH MAC that TSCH requires scheduled access to the wireless medium. While TSCH defines the mechanisms to execute a communication schedule, it is the responsibility of a scheduling entity to allocate resources between communicating pairs and establish routes within the network.
An example communication schedule is given in Figure 2.1. As it can be seen from the figure, the schedule is designed to have 31 cells (cells and slots represent the same resource, slot is a term used in 14e MAC and cell is a term used in 6Tisch that represents slot-channel pair). The 310 ms period is called slot frame where each cell is 10 ms in this example and schedule repeats itself over each slot frame. Each cell can be scheduled between pairs of nodes within the network unless marked otherwise. The node pairs use a scheduling entity to allocate resources for communicating with each other. The local cells should be allocated in a way that neighboring nodes do not cause interference to each other during the communication. On the other hand, the nodes sufficiently far apart can reuse the same cell for communicating simultaneously.
Scheduler can be implemented using a centralized approach where all the nodes request cells from a central entity upon joining to the WSN. But, this approach may not scale since 2 it may result in a significant control overhead in large sensor networks. Another scheduling approach can be based on a distributed algorithm where pairs of nodes negotiate resources between each other taking their neighbour’s resource usage into account. This approach guarantees a scalable WSN, but may suffer from in-network interference. 6Tisch makes use of a distributed scheduling entity named as 6Top. 6Top layer is responsible for allocating resource to communication pairs and it also can differentiate between traffic types. This lets the networks to create different quality of service classes based on application requirement. Furthermore, the 6Top layer can forward traffic between pairs without the help of routing layer since the schedule between the nodes explicitly creates a flow from the source to destination node named tracks. This approach is quite similar to Multiprotocol Label Switching (MPLS) protocol in wired networks.
Figure 2.2 shows the outline of the 6Tisch protocol stack being developed by us for Contiki OS. The network-wide synchronization is achieved by the SYNCH module which uses Beacon and ACK frames to fix and adjust timings of the nodes in the network. The data packets coming from the network layer are inserted to 6Top/MAC buffer prior to being transmitted to the destination. The 6Top/MAC buffer is organized as a linked list where a buffer is created per destination.
