Contiki is defined by a network stack of four layers, as shown in Table 4.1: the network layer, the MAC layer, the Radio Duty Cycle (RDC) layer and the radio layer. The network layer includes support for Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Protocol version 6 (IPv6), Internet Protocol version 4 (IPv4), RPL routing protocol and 6LoWPAN. IPv6 over Low Power Wireless Personal Area Networks (6LoW- PAN) is a header compression and fragmentation format for IPv6 packet delivery over IEEE 802.15.4 networks [47]. Contiki implements a minimal set of IPv6 protocol features and
Contiki IoT/IP Applications
Network
Application HTTP
Transport TCP, UDP
Network, Routing IPv6, IPv4, RPL
Adaptation 6LoWPAN
MAC MAC CSMA/CA
RDC Duty Cycling ContikiMAC
Radio Radio IEEE 802.15.4
Anonymous best effort single hop broadcast Identified best effort single hop broadcast
Best effort single hop unicast
Reliable single hop unicast
Reliable multi hop unicast
Best effort multi hop unicast
Identified receiver Identified sender Best effort network flooding UNICAST BROADCAST
Figure 4.1: Rime stack communication layering
the 6LoWPAN adaptation layer for IPv6 header compression and fragmentation, which is routed over the Low Power and Lossy Network (LLN) in RPL. Contiki’s configuration op- tions for communication, buffer management and network interface are explained below.
4.2.1 Communication Stacks
Contiki contains two communication stacks, uIP and Rime. Micro Internet Protocol (uIP) [30] is a small RFC-compliant TCP/IP stack that is designed to contain only the essential features to provide Contiki with TCP/IP networking support, to allow Contiki to communi- cate over the Internet, compared to the traditional TCP/IP that requires high resources to fit in the limited RAM capability of a sensor. The minimal set of features includes IP, ICMP, UDP and TCP protocols. The uIP deals with the TCP and IP protocols [25, 26].
Rime is Contiki’s lightweight communication stack that aims to simplify the sensor network protocol implementation by reusing codes in a layered manner [31]. Rime com- bines layers of simple communication abstractions to form a powerful high-level abstraction ranging from the best-effort anonymous broadcast to reliable network flooding. Figure 4.1 shows part of the communication layers in Rime. An as example, a reliable multi hop uni- cast communication consists of the combination of best effort single hop broadcast, best effort single hop unicast and reliable single hop unicast. Parts of the Contiki lightweight
IEEE 802.15.4 Application TCP / UDP Rime / uIPv6 RPL Chameleon CSMA ContikiMAC Network layer MAC layer RDC layer Radio layer
Figure 4.2: Contiki stack
communication stack (Rime) can be used by the underlying MAC or link layer. Additional protocols that are not in Rime can be implemented on top of the stack, such as TCP/IP.
Applications in Contiki can decide to use either one, both or none of the communica- tion stacks available. Rime is an alternative option for simpler communication without the need for IP addresses, which means the nodes can be labelled locally (e.g. numbered) but not globally, as the labelling can overlap. uIP can run over Rime and similarly, Rime can run over uIP [32]. This allows protocols or applications that are not in Rime or uIP to be implemented directly on top of the communication stack, such as running TCP/IP on Rime.
4.2.2 Buffer Management
Chameleon [34] is a communication architecture in Contiki that consists of the Rime com- munication stack and a set of packet transformation modules. It uses an abstract represen- tation of the information, which allows access to the low-level features of the underlying MAC and link layer protocol from the applications and layers implemented on top of the Chameleon architecture, as shown in Figure 4.2. It also allows the output from the proto-
PC as LPBR Border Router RDC Other nodes LPBR Slip radio RPL uIP ContikiMAC IEEE 802.15.4 Figure 4.3: MCRP implementation
col stack to be adapted by other communication protocols. In Chameleon architecture, the parsing of its header is separated from the communication stack. This allows uIP or Rime communication stack to be used as described in Section 4.2.1. Chameleon architecture enables the layers to access information without violating the layering principle.
In the buffer management module of Chameleon architecture, all incoming and outgo- ing packets from the applications and packet attributes are stored in a single buffer called the Rime buffer [30, 34, 31, 29]. All layers of Contiki’s network stack including uIP, Rime and the underlying link layer operate on the same packet buffer for the buffer management. The Rime buffer has no locking mechanisms as it is a single priority level buffer. The buffer only holds the current packet.
Protocols that need to queue packets allocate the queue buffer dynamically. The queue buffer is used to hold the queued packets, such as for MAC protocol that has a high rate of incoming and outgoing messages before it can send or process the receiving packets, or when the radio is busy and the MAC protocol has to wait for the radio medium to be free before proceeding with transmissions. The Rime buffer contents are copied into the queue buffer when there is a queue buffer allocated.
4.2.3 Tunslip
Serial Line Internet Protocol (SLIP) [91] is a protocol that has a low complexity and small overhead commonly used to encapsulate IP packets for point-to-point communication be- tween the sink (LPBR) and the device connected, such as an embedded PC across the serial connection. The communication between the devices can take place on any reliable net-
work, such as the Ethernet where the LPBR can be connected to an embedded PC, which contains an Ethernet interface as shown in Figure 4.3 labelled Slip radio.
Contiki provides support to communicate with devices using SLIP through its tunslip tool. Tunslip is used to bridge the IP traffic between the LPBR and the embedded PC over a serial line. The other side of the serial line does a similar job to bridge the embedded PC to the LPBR using the network interface. It constructs a SLIP tunnel between a virtual network interface (tun) and SLIP, the physical serial interface to encapsulate and pass the IP traffic to and from the other side of the serial line. The tun interface is used as any real network interface, such as for routing and traffic forwarding [54, 1].
Figure 4.3 shows the overall view of MCRP. The protocol implementation is separated into two types of nodes: (i) the centralised LPBR where the bridging (Tunslip) takes place between the border router on a PC to the nodes, and (ii) the decentralised transmission nodes referred to as the other nodes.