The Internet of Things

The Internet Engineering Task Force (IETF) has developed alternative protocols for communication between IoT devices using IP because IP is a flexible and reliable standard. The Internet Protocol for Smart Objects (IPSO) Alliance has published various white papers describing alternative protocols and standards for the layers of the IP stack and an additional adaptation layer, which is used for communication between smart objects.

1. Physical and MAC Layer (IEEE 802.15.4). The IEEE 802.15.4 protocol is designed for enabling communication between compact and inexpensive low power embedded devices that need a long battery life. It defines standards and protocols for the physical and link (MAC) layer of the IP stack. It supports low power communication along with low cost and short range communication. In the case of such resource constrained environments, we need a small frame size, low bandwidth, and low transmit power.
   
   Transmission requires very little power (maximum one milliwatt), which is only one percent of that used in WiFi or cellular networks. This limits the range of communication. Because of the limited range, the devices have to operate cooperatively in order to enable multihop routing over longer distances. As a result, the packet size is limited to 127 bytes only, and the rate of communication is limited to 250 kbps. The coding scheme in IEEE 802.15.4 has built in redundancy, which makes the communication robust, allows us to detect losses, and enables the retransmission of lost packets. The protocol also supports short 16-bit link addresses to decrease the size of the header, communication overheads, and memory requirements.
   
   Readers can refer to the survey by Vasseur et al. for more information on different physical and link layer technologies for communication between smart objects.
   
   
2. Adaptation Layer. IPv6 is considered the best protocol for communication in the IoT domain because of its scalability and stability. Such bulky IP protocols were initially not thought to be suitable for communication in scenarios with low power wireless links such as IEEE 802.15.4.
   
   6LoWPAN, an acronym for IPv6 over low power wireless personal area networks, is a very popular standard for wireless communication. It enables communication using IPv6 over the IEEE 802.15.4 protocol. This standard defines an adaptation layer between the 802.15.4 link layer and the transport layer. 6LoWPAN devices can communicate with all other IP based devices on the Internet. The choice of IPv6 is because of the large addressing space available in IPv6. 6LoWPAN networks connect to the Internet via a gateway (WiFi or Ethernet), which also has protocol support for conversion between IPv4 and IPv6 as today's deployed Internet is mostly IPv4. IPv6 headers are not small enough to fit within the small 127 byte MTU of the 802.15.4 standard. Hence, squeezing and fragmenting the packets to carry only the essential information is an optimization that the adaptation layer performs.
   
   Specifically, the adaptation layer performs the following three optimizations in order to reduce communication overhead:
   
   (i) Header compression 6loWPAN defines header compression of IPv6 packets for decreasing the overhead of IPv6. Some of the fields are deleted because they can be derived from link level information or can be shared across packets.
   (ii)  Fragmentation: the minimum MTU size (maximum transmission unit) of IPv6 is 1280 bytes. On the other hand, the maximum size of a frame in IEEE 802.15.4 is 127 bytes. Therefore, we need to fragment the IPv6 packet. This is done by the adaptation layer.
   (iii)  Link layer forwarding 6LoWPAN also supports mesh under routing, which is done at the link layer using link level short addresses instead of in the network layer. This feature can be used to communicate within a 6LoWPAN network.
   
   
3. Network Layer. The network layer is responsible for routing the packets received from the transport layer. The IETF Routing over Low Power and Lossy Networks (ROLL) working group has developed a routing protocol (RPL) for Low Power and Lossy Networks (LLNs).
   
   For such networks, RPL is an open routing protocol, based on distance vectors. It describes how a destination oriented directed acyclic graph (DODAG) is built with the nodes after they exchange distance vectors. A set of constraints and an objective function is used to build the graph with the best path. The objective function and constraints may differ with respect to their requirements. For example, constraints can be to avoid battery powered nodes or to prefer encrypted links. The objective function can aim to minimize the latency or the expected number of packets that need to be sent.
   
   The making of this graph starts from the root node. The root starts sending messages to neighboring nodes, which then process the message and decide whether to join or not depending upon the constraints and the objective function. Subsequently, they forward the message to their neighbors. In this manner, the message travels till the leaf nodes and a graph is formed. Now all the nodes in the graph can send packets upwards hop by hop to the root. We can realize a point to point routing algorithm as follows. We send packets to a common ancestor, from which it travels downwards (towards leaves) to reach the destination.
   
   To manage the memory requirements of nodes, nodes are classified into storing and nonstoring nodes depending upon their ability to store routing information. When nodes are in a nonstoring mode and a downward path is being constructed, the route information is attached to the incoming message and forwarded further till the root. The root receives the whole path in the message and sends a data packet along with the path message to the destination hop by hop. But there is a trade-off here because nonstoring nodes need more power and bandwidth to send additional route information as they do not have the memory to store routing tables.
   
   
4. Transport Layer. TCP is not a good option for communication in low power environments as it has a large overhead owing to the fact that it is a connection oriented protocol. Therefore, UDP is preferred because it is a connectionless protocol and has low overhead.
   
   
5. Application Layer. The application layer is responsible for data formatting and presentation. The application layer in the Internet is typically based on HTTP. However, HTTP is not suitable in resource constrained environments because it is fairly verbose in nature and thus incurs a large parsing overhead. Many alternate protocols have been developed for IoT environments such as CoAP (Constrained Application Protocol) and MQTT (Message Queue Telemetry Transport).
1. Constrained Application Protocol: CoAP can be thought of as an alternative to HTTP. It is used in most IoT applications. Unlike HTTP, it incorporates optimizations for constrained application environments. It uses the EXI (Efficient XML Interchanges) data format, which is a binary data format and is far more efficient in terms of space as compared to plain text HTML/XML. Other supported features are built in header compression, resource discovery, autoconfiguration, asynchronous message exchange, congestion control, and support for multicast messages. There are four types of messages in CoAP: nonconfirmable, confirmable, reset (nack), and acknowledgement. For reliable transmission over UDP, confirmable messages are used. The response can be piggybacked in the acknowledgement itself. Furthermore, it uses DTLS (Datagram Transport Layer Security) for security purposes.
2. Message Queue Telemetry Transport: MQTT is a publish/subscribe protocol that runs over TCP. It was developed by IBM primarily as a client/server protocol. The clients are publishers/subscribers and the server acts as a broker to which clients connect through TCP. Clients can publish or subscribe to a topic. This communication takes place through the broker whose job is to coordinate subscriptions and also authenticate the client for security. MQTT is a lightweight protocol, which makes it suitable for IoT applications. But because of the fact that it runs over TCP, it cannot be used with all types of IoT applications. Moreover, it uses text for topic names, which increases its overhead.

MQTT-S/MQTT-SN is an extension of MQTT, which is designed for low power and low cost devices. It is based on MQTT but has some optimizations for WSNs as follows. The topic names are replaced by topic IDs, which reduce the overheads of transmission. Topics do not need registration as they are preregistered. Messages are also split so that only the necessary information is sent. Further, for power conservation, there is an offline procedure for clients who are in a sleep state. Messages can be buffered and later read by clients when they wake up. Clients connect to the broker through a gateway device, which resides within the sensor network and connects to the broker.