The general formula for how telecommunications are established is represented globally by the OSI (Open Systems Interconnection) Model. The model divides the structure into 7 different layers, as shown in the figure below.
The uppermost layers, layer 5-7 (Session, Presentation, and Application Layer), are constructed to deal with data processes. The application layer, which stands as the last layer, would be the only layer to interact with the end-users.
The application layer commonly used for IoT applications include:
Another application layer that’s commonly used in telecommunication systems is HTTP or HyperText Transport Protocol. However, it is arguably not suitable for IoT applications due to its characteristics:
- Only able to support one-to-one communication i.e. would only serve one client to one broker/server.
- High power consumption, for every one-to-one connection established, an underlying TCP connection should be open as well. This will put a heavy load on the server and hence, consume more power than an edge device can sustain.
- Operates on a request-based response. Sensors, which act as a continuously reporting client (subscriber) in an IoT system typically don’t have any computational feature implemented together with it.
CoAP (Constrained Application Protocol)
The CoAP was designed to enable communication using constrained nodes and networks for IoT applications, and connecting them to the internet. Since IoT systems would require numerous nodes, where each node might not have high memory for cost efficiency, CoAP was designed to allow data transmission to occur with minimum resources with only a 4-byte fixed header. CoAP uses UDP exclusively to enhance its compact communication process. This being said, the communication process between devices would be able to occur without needing any connection to be established prior.
CoAP, like HTTP, is standardized by the IETF Constrained RESTful Environments (CoRe) Working Group. The server provides resources in the form of URLs, and the clients will access the resources by using several specified functions like GET, PUT, POST, and DELETE.
MQTT (Message Queuing Telemetry Transport)
Developed as an open OASIS standard and an ISO recommended protocol, the MQTT was aimed to operate on data transmissions with a small bandwidth and minimum resources (e.g. on microcontrollers). It usually uses the TCP/IP protocol suite, which runs by first establishing connections, then allows multiple exchanges of data until one party finally disconnects itself.
The MQTT technology runs using the MQTT Publish/Subscribe architecture and establishes the network from 2 different component categories: Clients (Publisher and Subscriber) and Brokers.
The Publish/Subscribe architecture first divides the network’s client devices into 2 categories, publishers and subscribers. These publishers are devices or nodes that input data to the system. On the other hand, the subscribers are the end devices or nodes that receive the data.
The data sent are in the form of different topics, in which the broker sorts the topic sent from the publisher, and sends it out to the appropriate client which has previously subscribed to the said topic.
AMQP (Advanced Message Queueing Protocol)
AMQP, like MQPP, is a message queueing protocol. This means that the subscriber and publisher of the system communicate by sending and requesting messages from a ‘message queue’. This standard satisfies the need for IoT applications on asynchronous communication, ensuring that the system is flexible enough to enable communication across numerous ‘things’.
The MQPP itself is an open OASIS standard protocol with ISO and IEC certification. It operates in a similar fashion to how messaging operators operate: a broker assigns received and transmitted messages, and several clients generate or receive the subscribed messages.
OASIS, as its publisher, had stated that AMQP is an appropriate protocol for business communications in 2015. Due to its reliable, secure, interoperable, open, and standard properties, along with its low overhead characteristics, AMQP has become a good solution for IoT applications. Since AMQP serves as a more advanced protocol than MQPP, some might choose AMQP to be a better solution for their IoT systems. Despite this, it’s worth noting that the AMQP would require a more complicated solution for wired connection, but it all depends on how you set up your system.
XMPP (Extensible Messaging and Presence Protocol)
XMPP, developed in the year 1999, is an open-source protocol that was based on XML (Extensive Markup Language). Hence, it supports rapid structured data exchange between two or more network entities and enables the addition of extension for operation.
The structure of an XMPP network is very similar to that of an email, giving the protocol its decentralized property. This means that anyone could establish their own server with the protocol anywhere.
The XMPP protocol is used commonly for instant messaging purposes, including voice and video calls, multi-person chats, etc. However, the protocol also serves IoT function properly as it’s flexible for connection protocols, secure, and enables middleware communication without requiring human intervention. A few applications of IoT with XMPP include the Google Cloud Print and Logitech Harmony Hub (home automation and media control).
DDS (Data Distribution Service)
DDS is the first open interoperable middleware protocol, developed by the Object Management Group (OMG). Its operation claims to provide a secure and real-time data distribution. Like MQTT, DDS works in a Publisher/Subscriber architecture. However, the protocol doesn’t implement the use of Brokers together with its Clients, hence its topic distribution occurs across its Global Data Space (GDS) by applying a QoS (Quality of Service) contract system.
The GDS acts as a ‘memory’ during DDS transmission application. However, it’s actually not a physical memory in the DDS server, it’s just a virtual concept. The GDS is actually the combination of local stores in nodes connected to the system.
Image source: RTI
When a publisher client sends out information and declares a topic, a QoS contract gets created and offered -- then when a subscriber requests information about a topic, the QoS contract is then requested, and the data exchange will be established.
DDS is commonly used within the industrial parts of IoT, playing a huge role in industry 4.0.
Free Resource: Guide to LoRaWAN E-Book