Standardization of IoT protocol stack

The root of the problem with standardization is the constrained environment of IoT characterized with low memory availability, low power, low bandwidth requirement and high packet loss – combined, these do not allow TCP/IP stack and web technologies to be used easily for IoT.

However, to solve this challenge, there are hundreds of proprietary protocols in IoT, M2M (Machine to Machine) and Home Automation space such as ZigBee and Z-Wave. Though these protocols are supported by an alliance of product vendors, they are not standardized like TCP, IP, HTTP or SMTP.

Although the scenario is still a bit cloudy, a set of open, standardized set of protocols has started to emerge. Most Bodies such as IEEE, IETF or W3C have standardized protocols such as 6LowPAN or CoAP. I strongly believe that eventually, these protocols would be standardized like the web standards used today.

The figure below shows the IoT protocols that have been standardized for each layer of TCP/IP model.

Network / Link Layer

IEEE 802.15.4

IEEE 802.15.4 is a standard for wireless communication that defines the Physical Layer (PHY) and Media Access Control (MAC) layers. It is standardized by the IEEE (Institute for Electrical and Electronics Engineers) similar to IEEE 802.3 for Ethernet, IEEE 802.11 is for wireless LANs (WLANs) or Wi-Fi.

802.15 group of standards details a variety of wireless personal area networks (WPANs) for various applications (To give an example, 802.15.1 is for Bluetooth). IEEE 802.15.4 focusses on communication between devices in constrained environment with scant resources (memory, power, and bandwidth).

Internet Layer

6LowPAN

6LowPAN is the secret sauce that allows larger IPv6 packets to flow over 802.15.4 links that support much smaller packet sizes. 6LowPAN is the acronym for IPv6 over Low-Power Wireless Personal Area Networks. So 6LowPAN, as the name implies, is an adaptation layer that allows to transport IPv6 packets over 802.15.4 links. Without 6LowPAN IPv6, Internet protocols would not work in these Low Power Wireless Personal Area Networks that uses IEEE 802.15.4.

6LowPAN is an open standard that’s has been defined in RFC 6282 by the Internet Engineering Task Force (IETF). IETF defines many of the open standards used on the Internet examples include UDP, TCP, and HTTP.

As mentioned before, an IPv6 packet is too large to fit into a single 802.15.4 frame. What 6LowPAN does to fit an IPv6 packet in 802.15.4 frame is -

Fragmentation and Reassembly - It fragments the IPv6 packet and sends it through multiple smaller size packets that can fit in an 802.15.4 frame. On the other end, it reassembles the fragmented packets to re-create the IPv6 packet.

Header Compression – Additionally it also compresses the IPv6 packet header to reduce the packet size.

Transport Layer

UDP

While TCP is predominantly used as Transport Layer Protocol on the Internet, (Exceptions being gaming or video streaming where User Datagram Protocol or UDP is used), most IoT scenarios are well suited for UDP. UDP is a much lighter protocol compared to TCP. UDP is a connection protocol and does not come with resiliency features of TCP, such as guaranteed packet delivery. On the other hand, UDP is much faster than TCP, the header size is much smaller than TCP – making it suitable for the constrained environment of devices and sensors.

Higher level Application Layer IoT protocols like CoAP use UDP rather than TCP.

DTLS

DTLS or Datagram Transport Layer Security is a TLS/SSL counterpart that runs on UDP. The way TLS/SSL takes care of security for TCP communication, DTLS provides the same security features on UDP or Datagrams.

Application Layer

CoAP

CoAP or Constrained Application Protocol is a specialized Web Transfer Protocol for constrained nodes and constrained networks on the Internet of Things. CoAP is an Application Layer protocol in the TCP/IP model (The web uses HTTP as an Application Layer protocol).

The term “Constrained” is used because it is designed specifically from the ground up to work well in constrained environments. The devices, sensors and actuators in IoT operate in a constrained environment with low memory, low power, low bandwidth and high rate of packet failure. HTTP was not designed to work in this sort of environment, so HTTP, which is relatively heavyweight with large header size and text encoding, struggles to work in IoT constrained environment.

In such environments CoAP shines – CoAP has been standardized by IEFT (The Internet Engineering Task Force) Constrained RESTful Environments (CoRE) Working Group. Think of CoAP as web protocols for devices.

CoAP can be transparently mapped to HTTP. Following are the similarities between CoAP and HTTP–

CoAP follows the same request-response pattern used by HTTP that we all are very familiar. The CoAP client (a smartphone, for example) sends a request to the CoAP server (device/things), and the server then sends a response back.

Like the web, devices are addressed using IP address and port number. Access to services exposed by the device is via RESTful URLs.

CoAP uses familiar HTTP features like Methods (Get, Post, Put, and Delete), Status Codes, URLs, and content-type.

CoAP supports discovery so that IoT devices/things could be discovered.

CoAP provides simple proxy and caching capabilities.

CoAP has a few differences as well -

CoAP runs on UDP as compares to HTTP, which typically uses TCP. UDP is lighter than TCP and has less overhead.

CoAP supports only Get, Put, Post and Delete methods. CoAP uses a small and reduced set of headers (header size is limited to 4 bytes), and HTTP status codes to be lightweight.

CoAP supports Confirmable and Non-confirmable message types.

CoAP also adds the feature of “Observation”, which HTTP lacks. This feature is very useful in IoT scenarios.

CoAP Libraries exists practically in all programming languages like C, Java, C#, Python, JavaScript, Go, Erlang, Ruby, etc. There are libraries for iOS and Android as well.

MQTT

MQTT stands for Message Queue Telemetry Transport. MQTT is a publish-subscribe based "light weight" messaging protocol for IoT and M2M (Machine-to-Machine communication). To put it simply, MQTT is the AMQP or JMS for the constrained environment of IoT. Andy Stanford-Clark and Arlen Nipper invented MQTT back in 1999 when their use case was to create a protocol for minimal battery loss and minimal bandwidth connecting oil pipelines over a satellite connection.

MQTT uses a broker based pub-sub architecture in the constrained IoT environment similar to other messaging products that exist in the Web and Client Server world. So there is a

MQTT Publisher - a sensor or device in IoT world that publishes a piece of information.

MQTT Subscriber – anyone who is interested in subscribing and receiving a piece of information one is interested in. It could be a smartphone, a wearable device, or even other devices that are interested to know about other devices around and change themselves based on self-learning.

MQTT Broker – An intermediary that receives information from publisher and forwards them to the subscribers.

MQTT is actively promoted and supported by industry giants and it is part of many popular messaging suites of products. There are also MQTT specific brokers like Mosquitto and HiveMQ. MQTT libraries are available in many programming languages. An Example of a very prominent MQTT Library is Eclipse Paho.

Data Format

CBOR

CBOR (Concise Binary Object Representation) is a data format designed with the goal of providing IoT with tiny message sizes. CBOR is based on the super-successful JSON data model. While JSON uses text encoding, CBOR uses binary encoding that results in compact message size.

Conclusion

The future of IoT lies in standardizing the protocols used across network stack. These set of open and standard protocols like CoAP, MQTT and 6LowPAN would eventually become as successful as the TCP/IP stack used across the web and the Internet.

This article was originally posted on LinkedIn.