Application Layer Protocols for IoT: IoT Part 11

This layer is responsible for formatting and presenting data. The application layer on the Internet is typically based on the HTTP protocol. However, HTTP is not suitable in resource-limited environments because it is extremely heavy and therefore incurs a large parsing overhead. Therefore, there are many alternative protocols that have been developed for IOT environments. Some of the popular IoT application layer protocols are as follows –

•MQTT

•SMQTT

• CoAP

• DDS

•XMPP

• AMQP

• RESTful HTTP

• MQTT-SN

• PISION

•SMCP

• LLAP

• SSI

• LWM2M

•M3DA

• XMPP-IOT

•ONS 2.0

• SOAP

• WebSocket

• Reactive flows

•HTTP/2

• IOT JavaScript

MQTT – Message Queuing Telemetry Transport is a lightweight messaging protocol. It uses the publish-subscribe form of communication and that is why it is used for M2M (machine to machine) communication. It is based on the TCP-IP protocol and is designed to operate in limited bandwidth. In protocol terminology, limited network bandwidth is referred to as “small code coverage area”. However, the exact meaning of limited network bandwidth is not clear from the specification.

This protocol is specially designed for sensor networks and wireless sensor networks. MQTT allows devices to send or publish data information about a given topic to a server. There is an MQTT (Broker-Mosquitto) broker between the publisher and the subscriber. The broker then transfers the information to previously registered customers.

Sensors interface with a broker, which is an IOT device or server that reads and publishes sensor data. The other devices that subscribe to and request data from the sensor are called clients. The sensors themselves are called editors in the network. The client can be a laptop, smartphone, tablet, or other mobile device. Client devices need to subscribe to the network broker to receive sensor data. To receive data, enrolled client devices must establish a connection with the broker and request data. The broker takes the data from the publisher (wireless sensors) and sends it to the client who requests it. Even if the connection to the client device is interrupted after the request has been made, the broker saves the data in a cache so that when the client device reconnects to the broker, it can receive the requested sensor data. Likewise, if the connection between the publisher and the broker is interrupted after the request has been made, the broker forwards the appropriate instructions sent by the publisher so that the client device can reconnect and receive the requested data.

Therefore, MQTT works well even when the connection between broker and publisher or broker and client is interrupted due to limited network bandwidth. This ability to deal with delays or latencies in the network makes this protocol quite suitable for wireless networks.

Figure 1: Image showing the architecture of the MQTT protocol

An MQTT session can be divided into four steps –

1) Connection

2) Authentication

3) Communication

4) Termination

Connection and Authentication – In this step, the client (such as a mobile device or laptop) initiates a TCP-IP connection with the broker (server) using a standard port or a port defined by the network operator. The default ports are generally 1883 for unencrypted communication and 8883 for encrypted communication through SSL or TLS. In encrypted communication, the server sends a server certificate to authenticate itself to the client and the client can also send a certificate to the server to authenticate itself. Although even in encrypted communication, client authentication is not part of the specification and is also not common. Still, typically, customer authentication is done by passing a username and password from the customer to the broker (server).

Communication – Sensor data is communicated to the customer using small codes. Although the term 'small code area' is not exactly specified in the protocol, it generally contains a 2-byte long header, an optional variable-length header, sensor data as message payload limited to 250 Mb in size, and indication of level of service quality. There can be three levels of Quality of Service (QoS) – Unrecognized Service (QoS Level 0), Recognized Service (QoS Level 1) and Guaranteed Service (QoS Level 2). Each exceeding QoS level requires more network bandwidth and latency tolerance.

There can be four types of operations that can be performed by a client – ​​publish, subscribe, unsubscribe and ping. The customer can subscribe to specific topics on the network, just as a mobile device can subscribe to a broker to read the current temperature of a city. To subscribe, the client needs to send a pair of SUBSCRIBE/SUBACK packets to the broker. Similarly, to unsubscribe (from a topic), the client needs to send a pair of UBSUBSCRIBE/UNSUBACK packets to the server. The ping operation can be performed by a client device to verify the active connection to the broker. In the publishing operation, data is communicated between the broker and the client on a specific topic.

4) Termination – The publisher or client can terminate the connection by sending a DISCONNECT message to the broker, after which the TCP-IP connection is terminated. If the connection is suddenly interrupted (due to limited network bandwidth) without a termination request, the broker sends the publisher's cached messages to the client.

SMQTT – Based on MQTT, the Secure Message Queue Telemetry Transport (SMQTT) protocol is a lightweight encryption-based messaging protocol. Compared to an MQTT session, the SMQTT session has four stages – configuration, encryption, publishing, and decryption. It has a broker-based architecture similar to MQTT, however, in this protocol both the subscriber and the publisher need to register with the broker using a secret master key. Data is also encrypted before being published by the publisher and then decrypted at the subscriber's end. There can be any encryption algorithm that can be used by the developer.

CoAP – Constrained Application Protocol is designed specifically for constrained (limited) hardware. Hardware that does not support HTTP or TCP/IP can use the CoAP protocol. So, basically the designers of this protocol inspired by HTTP designed the CoAP protocol using UDP and IP protocol. It is a lightweight protocol that needs low-power IOT application, such as for communication between battery-powered IOT devices. Just like HTTP, it also follows the client-server model. Clients can GET, PUT, DELETE, or POST information resources over the network.

CoAP uses two types of messages – requests and responses. Messages contain a base header followed by the message body whose length is specified by the datagram. Messages or data packets are small in size so they can be communicated between restricted devices without data loss. Messages can be confirmable or non-confirmable. For confirmable messages, the client needs to respond with an acknowledgment after receiving the data packet. Request messages can contain query strings to implement additional functionality such as searching, sorting, or pagination.

For security, the protocol uses Datagram Transport Layer Security (DTLS) over UDP. In HTTP it is very complicated to know the new state of a variable. in HTTP, the client has to poll repeatedly, which means the client has to ask every second to see if there is any new state of the variable it is watching. In CoAP, CoAP services try to solve the problem by creating a watch flag, so if the original device sends the watch flag with the GET command, every time the server or the other devices notice that there is a change in the state of the variable then the server or devices will send the push notification to the original device that is actually finding the observer beacon.

The protocol also provides an additional mechanism for resource discovery by client devices. The server must provide a list of resources along with metadata that can be accessed such as link or application media type. By browsing the list, a customer can find available resources (information or data) and discover their media types.

The network's sensor nodes themselves act as servers rather than clients. Sensors are directly routable and data communication is individual between the sensor and client devices. To implement these protocols, sensors must be capable of receiving data packets and responding to them.

DDS – Designed by the Object Management Group (OMG), the Data Distribution Service is an M2M application layer protocol for real-time systems. Based on a publish-subscribe standard like MQTT, the protocol architecture has nodes configured as publisher, subscriber or both. The protocol does not require any network middleware, so publishers can release information about specific topics (like a temperature sensor can release the current temperature of a location) and the protocol itself can deliver it to the subscriber (like a mobile device showing the current temperature of a location). The implementation of the protocol does not require any network programming, as the protocol does not require verification of the existence or location of nodes and also does not require confirmation of message delivery.

XMPP – Extensible Messaging and Presence Protocol (XMPP) is an XML-based messaging protocol. XML is a markup language for encoding documents that are readable by humans as well as machines. XML evolved to extend HTML and allow custom tags and elements to be added to the web. As it is an extension of HTML, it allows data structuring along with extensionality. Traditionally, XMPP has been used for real-time communication such as instant messaging, presence, multi-party chat, voice and video calls, collaboration, content distribution, etc.

Using XMPP for IOT allows for scalable and real-time networking between devices or things. Things (devices) have one or more nodes and each node has several (informational) fields. Each field contains a readable and writable value. Nodes need to become friends by sending and accepting friend requests. Once a node's friend request is accepted by the other, it can receive updates from the other node. If another node also needs to get updates from the first node, it also needs to send a friend request and needs confirmation. If both nodes become friends on the network, this is called dual subscription; otherwise, it is called a unilateral signature. Data is communicated between nodes individually, where one node can read or write field values ​​to the other node.

AMQP – Just like XMPP, Advanced Message Queue Protocol (AMQP) is also an open standard application layer protocol for message-oriented middleware. It is used to pass commercial messages between applications or organizations. It connects systems, feeds business processes with the information they need, and reliably transmits instructions that achieve their objectives.

This is an interoperable, cross-platform messaging standard. In the protocol architecture, the message along with a header is passed by the client to a broker or exchange. Therefore, there is a single queue to which the message is passed by a producer. From the exchange or broker, the message can be forwarded to one or more queues. The header contains information about each byte of the message. It also contains the routing information. The broker or exchange remains responsible for reading the headers and receiving, routing and delivering messages to client applications. Communication in this protocol remains one-to-one between two nodes.

RESTful HTTP – Representational State Transfer (REST) ​​or RESTful is a stateless and interoperable communication protocol. The protocol allows you to identify web resources (information resources) by unique URLs and allows you to deliver them as an HTTP, JSON or XML file. Resources are exposed as directory structure URIs. A client can access resources for GET, PUT, DELETE, or POST messages for representations where the representations are data objects and their attributes in HTML, XML, or JSON format. GET, PUT, DELETE and POST are HTTP request methods for receiving, modifying and sending data. As it is a stateless communication, no confirmation is sent or received to confirm the delivery of the message. However, the HTTP request may be responded to by a status code indicating success, redirection, info, client error, or server error.

MQTT-SN – MQTT-Sensor Network is an open and lightweight publish/subscribe protocol specifically designed for constrained devices, i.e., wireless sensor network (WSN). The wireless sensor network that does not have TCP/IP stack on top, such as Zigbee-based wireless sensor network or Bluetooth-based WSN, they can send their data to the Internet with MQTT-SN protocol.

MQTT-SN is designed to be as close as possible to MQTT, but is adapted to the peculiarities of a wireless communication environment, such as low bandwidth, high link failures, short message length, etc. low-cost, battery-operated devices with limited processing and storage resources.

Compared to MQTT, the following changes have been introduced in MQTT-SN –

• Topic names are replaced with topic IDs, which reduces transmission overhead.

• Topics do not require registration, as they are pre-registered.

• Messages are also divided so that only the necessary information is sent.

• For energy conservation, there is an offline procedure for customers who are in a suspended 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 in the sensor network and connects to the broker.

In the MQTT-SN architecture, there are three types of MQTT-SN components – MQTT-SN clients, MQTT-SN gateways (GW), and MQTT-SN forwarders. MQTT-SN clients connect to an MQTT server through an MQTT-SN GW using the MQTT-SN protocol. An MQTT-SN GW may or may not be integrated with an MQTT server. In case of a standalone GW, the MQTT protocol is used between the MQTT server and the MQTT-SN GW. Its main function is the translation between MQTT and MQTT-SN.

Figure 2: Image showing the architecture of the MQTT-SN protocol

MQTT-SN clients can also access a GW through a forwarder if the GW is not directly connected to their network. The forwarder simply encapsulates the MQTT-SN frames it receives on the wireless side and forwards them unchanged to the GW; in the opposite direction, it releases the frames it receives from the gateway and sends them to clients, also unchanged.

STOMP – Simple or Streaming Text Oriented Messaging Protocol (STOMP) is a text-based protocol for message-oriented middleware. It is based on TCP and uses commands similar to HTTP. It is designed to provide interoperability across platforms, languages, and exchanges. Data is communicated between a client and a broker in multi-line frames containing command, header, and content. The command can be CONNECT, DISCONNECT, ACK, NACK, SUBSCRIBE, UNSUBSCRIBE, SEND, BEGIN, COMMIT or ABORT.

SMCP – Simple Media Control Protocol (SMCP) is a CoAP protocol stack for embedded devices. It is developed in C language and can be used to send and receive asynchronous CoAP responses.

LLAP – Lightweight Local Automation Protocol is a simple and short messaging protocol that can be executed on any communication medium. The protocol is designed for direct messaging between embedded devices, regardless of the low-level physical layer protocol used by the devices.

SSI – Simple Sensor Interface (SSI) is an application layer protocol designed for communication between computers and sensors. Based on UART, the protocol allows you to probe sensors and transmit sensor data. Data is communicated by sensors to computers in small spaces of code. In the protocol, the message between the sensor and the computer contains a 2-byte header and the message payload. The header contains a single-byte address and a single-byte command or message type.

LWM2M – Lightweight M2M (LWM2M) is a device management protocol for sensor networks. The Open Mobile Alliance (OMA) developed this protocol to manage lightweight, low-power devices across a variety of networks. The protocol stack is based on REST and CoAP.

M3DA – M3DA is a protocol stack for communicating binary data between M2M servers and applications running on embedded gateways. It is designed for device and asset management so that network bandwidth is optimally utilized.

XMPP-IOT – Just as XMPP is used for interoperable communication, XMPP-IOT is a protocol stack for machine-independent M2M communication.

ONS 2.0 – Object Name Service (ONS) is a protocol stack for locating metadata and services using a given GS1 identification key. GS1 is an electronic business messaging standard for automating business transactions in a supply chain.

SOAP – Simple Object Access Protocol (SOAP) is an XML-based protocol stack used for implementing web services on the Internet. It uses HTTP request methods for messages between clients on a network.

Websocket – The WebSocket JavaScript interface defines a full-duplex single-socket connection over which messages can be sent between the client and the server. The standard simplifies the complexity of two-way web communication and connection management.

Reactive Streams – Reactive Streams is a protocol stack for asynchronous stream processing with non-blocking backpressure. It is a specification that can be implemented in Java or JavaScript. It is used to handle live data streams whose volume is not known.

HTTP/2 – HTTP version 2 will be the next version of the HTTP protocol. It will use header field compression to reduce latency and allow multiple simultaneous exchanges on the same connection.

IOT JavaScript – This is not any standard or protocol. It refers to the use of JavaScript and particularly Node.js (a server-side JavaScript) with IOT boards for various applications. Some of the JavaScript based IOT projects include NodeMCU, Jerryscript, Socket.IO, Ruff, NodeRed, KinomaJS, CHIRIMEN, Mosca, Nodebots, heimcontrol.js, Resin, UPM, i2C, node-http2, onoff, node-serialport, mdns, IoT.js, Favor, Serverless, noduino, duino, Pijs.io, etc.

In the next tutorial, IOT cloud and services will be discussed.