III. Network Layer Routing Protocols
In this section, some standards and protocols for IoT routing are briefly discussed. It should be noted that this paper divides the network layer in the networking stack into two sublayers: routing layer which handles the transfer of packets from source to destination, and an encapsulation layer that forms the packets. Encapsulation standards will be discussed in the next section.
It is based on destination-oriented directed-acyclic graphs (DODAG) that have only one route from each leaf node to the root through which all the traffic from the leaf node will be routed to. Initially, each node sends a DODAG information object (DIO) advertising itself as the root. DIO is propagated on the network and the whole DODAG is gradually built. When communicating, a destination advertisement object (DAO) is sent from the node to its parents, propagated to the root, and the root decides where to route it depending on the destination. New nodes who wish to join the network sends a DODAG information solicitation (DIS) request for joining and the root will reply with a DAO acknowledgment (DAO-ACK) confirmation. RPL nodes can be stateless, which is most common, or stateful. A stateless node keeps track of its parents only. Only root has the complete knowledge of the entire DODAG. Hence, all communications go through the root. A stateful node keeps track of its children and parents and hence when communicating inside a sub-tree of the DODAG, it does not have to go through the root .
First, it introduces opportunistic forwarding which enables the packet to have multiple forwarders set but only the best next hop will be chosen to forward the packet. Then, each node will maintain a forwarding list instead of its parent only and updates its neighbor with its changes using DIO messages. Based on the updated information, each node dynamically updates its neighbor priorities in order to construct the forwarders set .
C. CORPLC. CARP and E-CARP
It considers historical link quality measurements to select the forwarding route. Network initialization and data forwarding are the two scenarios that should be considered in such protocols. In network initialization, a HELLO packet is broadcasted from the sink to all other nodes in the networks. In data forwarding, the packet is routed from sensor to sink in a hop-by-hop fashion. Each next hop is determined independently.
The main problem with CARP is that it does not support the reusability of previously collected data. In other words, if the application requires sensor data only when it changes significantly, then CARP data forwarding is not beneficial to that specific application. An enhancement of CARP was done in E-CARP by allowing the sink node to save previously received sensory data. When new data is needed, E-CARP sends a ping packet which is replied with new data from the sensor nodes. Thus, E-CARP reduces the communication overhead drastically .
This section discussed three routing protocols that can be used in IoT routing sublayers. RPL is the standardized distance vector protocol and, most commonly used one. CORPL is a non-standard extension of RPL that is designed for cognitive networks and utilizes the opportunistic forwarding to forward packets at each hop. On the other hand, E-CARP is the only distributed link quality measurement based routing protocol that is designed for IoT sensor network applications. E-CARP is used for underwater communications mostly. Since it is not standardized, it is not yet used for other IoT applications.
IV. Network Layer Encapsulation Protocols
Addressing IoT devices with IPv6 long addresses and how they can fit in small, lightweight IoT data link frames were challenges that needed to be taken care of through standards. Hence, IETF is developing a set of frame formatting standards to encapsulate IPv6 datagrams in different small data link frames to be used in IoT applications. In this section, we review these standards briefly.
6LoWPAN specifications allow many features including: different length addresses, different networking topologies, low bandwidth, low power consumption, cost efficient, scalable networks, mobility, reliability, and long sleep times. Header compression is used in the standards to reduce transmission overhead, fragmentation to meet the 128-byte maximum frame length in IEEE802.15.4, and support of multi-hop delivery. Frames in 6LoWPAN use four types of headers: No 6loWPAN header (00), dispatch header (01), mesh header (10) and fragmentation header (11). In No 6loWPAN header case, any frame that does not follow 6loWPAN specifications is discarded. Dispatch header is used for multicasting and IPv6 header compressions. Mesh headers are used for broadcasting; while fragmentation headers are used to break long IPv6 header to fit into 128-byte fragments.
This matrix is divided into multiple chunks where each chunk contains time and frequencies and is globally known to all nodes in the network. Within the same interference domain, nodes coordinate and negotiate their scheduling such that they all get to transmit without interruptions. Scheduling becomes an optimization problem where time slots are assigned to a group of neighboring nodes sharing the same application. The standard does not specify how the scheduling can be done and leaves that to be an application specific problem in order to allow for maximum flexibility for different IoT applications. The scheduling can be centralized or distributed depending on the application or the topology used in the MAC layer .
Even though 6LowPAN and 6TiSCH were developed for encapsulation purposes, it became clear that more standards are needed to cover all data link standards. Therefore, 6Lo was formed by IEFT for this purpose. At the time of this writing most of the 6Lo specifications have not been finalized and are in various stages of drafts. For example, IPv6 over IEEE 485 Master-Slave/Token Passing (MS/TP) networks, IPV6 over DECT/ULE, IPV6 over NFC, IPv6 over IEEE 802.11ah, and IPv6 over wireless networks for industrial automation process automation (WIA-PA) drafts are being developed to specify how to transmit IPv6 datagrams over their respective data links . Two of these 6Lo specifications” IPv6 over G.9959” and” IPv6 over Bluetooth Low Energy” have been approved as an RFC and are described next.