This layer is responsible for data formatting and presentation. The application layer in the Internet is typically based on HTTP protocol. However, HTTP is not suitable in resource constrained environment because it is extremely heavyweight and thus incurs a large parsing overhead. So, there are many alternate protocols that have been developed for IOT environments. Some of the popular IOT application layer protocols are as follow –

• MQTT

• SMQTT

• CoAP

• DDS

• XMPP

• AMQP

• RESTful HTTP

• MQTT-SN

• STOMP

• SMCP

• LLAP

• SSI

• LWM2M

• M3DA

• XMPP-IOT

• ONS 2.0

• SOAP

• Websocket

• Reactive Streams

• HTTP/2

• JavaScript IOT

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

This protocol has been specially designed for sensor networks and wireless sensor networks. MQTT allows devices to send or publish data information on a given topic to a server. There is a MQTT broker (Broker- Mosquitto) in between publisher and subscriber. The broker then transfers the information to the clients that are previously subscribed.

The sensors are interfaced with a broker which is an IOT device or server that reads and publish sensor data. The other devices that subscribe for and request sensor data are called clients. The sensors themselves are referred as publishers in the network.  The client can be a laptop, smart phone, tablet or other mobile device. The client devices need to subscribe with the broker in the network to receive sensor data. For receiving data, the subscribed client devices have to establish connection with the broker and request data. The broker takes data from the publisher (wireless sensors) and send it to the client requesting for it. Even if the connection with the client device is broken after the request has been made, the broker saves the data in a cache so that when the client device reconnects with the broker, it could receive the requested sensor data. Similarly, if the connection between the publisher and the broker is broken after the request has been made, the broker forwards appropriate instructions sent by the publisher, so that client device can reconnect and receive requested data.

So, MQTT fares well even when connection between the broker and the publisher or broker and the client is broken due to limited network bandwidth. This ability to deal with delay or latency in network makes this protocol quite suitable for wireless networks.

An MQTT session can be divided into four stages –

1) Connection

2) Authentication

3) Communication

4) Termination

Connection and Authentication – In this stage, the client (like 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 standard ports are generally 1883 for non-encrypted communication and 8883 for encrypted communication through SSL or TLS. In encrypted communication, the server sends server certificate to authenticate itself by the client and client may also send a certificate to the server to authenticate itself. Though even in encrypted communication, the client authentication is not part of the specification and also not common. Still, usually, the client authentication is done by passing a username and password by the client to the broker (server).

Communication – The sensor data is communicated to client using small code footprints. Though the term ‘small code footprint’ is not exactly specified in the protocol, it usually contains 2-byte long header, an optional variable length header, sensor data as message payload limited to 250 Mb in size and Quality of Service Level Indication. There can be three Quality of Service (QoS) levels – Unacknowledged Service (QoS Level 0), Acknowledged Service (QoS Level 1) and Assured Service (QoS Level 2). Each exceeding QoS level requires more network bandwidth and tolerance to latency.

There can be four types of operations that can be performed by a client – publish, subscribe, unsubscribe and ping. The client can subscribe for specific topics in the network, like a mobile device might subscribe with a broker to read current temperature of a city. For subscribing, the client needs to send a SUBSCRIBE/SUBACK packet pair to the broker. Similarly, for unsubscribing (from a topic), the client needs to send a UBSUBSCRIBE/UNSUBACK packet pair to the server. The ping operation can be performed by a client device to check the live connection with the broker. In the publish operation, the 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 closed. If the connection is broken suddenly (due to limited network bandwidth) without termination request, the broker sends the cached messages from the publisher to the client.

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

CoAP – Constrained Application Protocol is specifically designed for constrained (limited) Hardware. The hardware that doesn’t support HTTP or TCP/IP can use CoAP Protocol. So, basically the designers of this protocol taking inspiration by the HTTP had designed the CoAP protocol using UDP and IP protocol. It is a lightweight protocol that needs low power IOT application like for communication between battery powered IOT devices. Like HTTP, it also follows client-server model. The clients can GET, PUT, DELETE or POST informational resources over the network.

CoAP makes use of two message types – requests and responses.  The messages contain a base header followed by message body whose length is specified by the datagram. The messages or data packets are small in size, so that they can be communicated among constraint devices without data losses. The messages can be confirmable or non-confirmable. For confirmable messages, the client need to respond with an acknowledgement after receiving the data packet. The request messages can contain query strings to implement additional functionalities like search, sort or paging.

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

The protocol also provides an additional mechanism for resource discovery by the client devices. The server has to provide a list of resources along with meta data which can be accessed as link or application media type. By navigating through the list, a client can find available resources (information or data) and discover their media types.

The sensor nodes in the network themselves act as server instead of clients. The sensors are directly routable and the data communication is one to one between sensor and the client devices. For implementation of this protocols, the sensors must be able to receive data packets and able to respond them.

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

 XMPP – Extensible Messaging and Presence Protocol (XMPP) is an XML based messaging protocol. XML is a mark up language for encoding documents which are both human readable as well as machine readable. XML evolved to extend HTML and allow addition of custom tags and elements to the web. As an extension of HTML, it allows structuring of data along with extensionality. Traditionally, XMPP has been used for real time communication like instant messaging, presence, multi-party chat, voice and video calls, collaboration, content syndication etc.

The use of XMPP for IOT allows real-time and scalable networking between devices or things. The things (devices) have one or more nodes and each node has several (informational) fields. Each field contains a readable and writable value. The nodes need to friend each other by sending and accepting friend requests. Once the friend request from one node is accepted by the other, it can receive updates from the other node. If other node also need to get updates from the first node, it also needs to send a friend request and need confirmation. If both nodes become mutually friend over the network, it is called dual subscription, otherwise, it is called single sided subscription. The data is communicated between the nodes on a one to one basis where a node can read or write field values in the other node.

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

This is an interoperable and cross platform messaging standard. In the protocol architecture, the message along with a header is passed by the client to a broker or exchange. So, there is a single queue to which the message is passed by a producer. From the exchange or broker, the message can be passed on to one or many queues. The header contains information about each byte of the message. It also contains the routing information. The broker or exchange remains responsible to read headers and receive, route and deliver messages to the client applications. The 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 identifying web resources (informational resources) by unique URLs and let deliver them as HTTP, JSON or XML file. The resources are exposed as directory structure URIs. A client can access resources to GET, PUT, DELETE or POST messages to representations where representations are data objects and their attributes in HTML, XML or JSON format. The GET, PUT, DELETE and POST all are the HTTP request methods of receiving, modifying and sending data. Being a stateless communication, no acknowledgement is sent or received for confirmation of the message delivery. However, the HTTP request may be responded by a status code indicating success, redirection, informational, client error or server error.

MQTT-SN – MQTT-Sensor Network is an open and light-weight publish/subscription protocol designed specifically for constrained devices i.e. wireless sensor network (WSN). The wireless sensor network which does not have TCP/IP stack on the top of it like 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. It is also optimized for the implementation on low-cost, battery-operated devices with limited processing and storage resources.

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

• 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.

• 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.

In the architecture of MQTT-SN, there are three kinds of MQTT-SN components – MQTT-SN clients, MQTT-SN gateways (GW), and MQTT-SN forwarders. MQTT-SN clients connect themselves to a MQTT server via a MQTT-SN GW using the MQTT-SN protocol. A MQTT-SN GW may or may not be integrated with a MQTT server. In case of a stand-alone 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.

MQTT-SN clients can also access a GW via a forwarder in case the GW is not directly attached 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 the clients, unchanged too.

STOMP – Simple or Streaming Text Orientated Messaging Protocol (STOMP) is a text based protocol for message oriented middleware. It is based on TCP and uses HTTP like commands. It has been designed to provide interoperability among platforms, languages and brokers. The data is communicated between a client and 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 for sending and receiving asynchronous CoAP responses.

LLAP – Lightweight Local Automation Protocol is a simple and short messaging protocol which can run on any communication medium. the protocol has been designed for direct messaging between embedded devices independent 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 polling sensors and streaming sensor data. The data is communicated by the sensors to the computers in small code footprints. In the protocol, the message between 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. Open Mobile Alliance (OMA) has developed this protocol to manage lightweight and low power devices on a variety of networks. The protocol stack is based on REST and CoAP.

M3DA – M3DA is a protocol stack for communication of binary data between M2M servers and applications running on embedded gateways. It is designed for device and asset management so that the network bandwidth is best used in optimum manner.

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

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

SOAP – Simple Object Access Protocol (SOAP) is an XML based protocol stack used for implementation of web services over internet. It uses HTTP request methods for messaging between clients over a network.

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

Reactive Streams – Reactive Streams is a protocol stack for asynchronous stream processing with non-blocking back pressure. It is a specification which may be implemented on Java or JavaScript. It is used for handling live data streams whose volume is not known.

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

JavaScript IOT – 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.