We all know HTTP (hypertext transfer protocol). These are the first 4 alphabets which see on any URL of a website you open in your browser. In simple terms, it is a list of rules that define do’s and don’ts of communication between web browser and web server. It is like you (web browser) going to ATM (webserver) to get some cash (request). Here the HTTP will describe the complete procedure – enter pin, amount, etc. You get your cash (result) once you follow the mentioned steps. Quite simple.
The World Wide Web (WWW) works on HTTP as it is the only protocol used there for the data transfer. However, this is not the case in the Industrial (I) IoT world. Here we have a bunch of protocols to choose depending on the type of application or so-called “use case”. The most common among them are MQTT, CoAP and of course HTTP. Before we discuss them, let us first have a look at certain networking terminologies and definitions.
Transport layer protocols (TCP, UDP)
Transport layer protocol, as the name implies, is responsible for transportation of message or information from one computer to another. The transport of the information can be done in two ways:
- Connectionless protocol (UDP): This kind of protocol is preferred in cases where speed and efficiency are more important than the reliability. In this case the data is sent without establishing or waiting for a connection. This means that a bit or segment of data can get lost during transportation. A typical example of such protocol is live video streaming where sometimes bad connection results in the fragmented video. For example, imagine yourself bringing a bunch of letters to the postbox and dropping them inside. You are just dropping the letters inside the box without knowing whether they will be delivered to their recipients. This is the case with connectionless protocols. On the other hand, bringing all these letters to the post office and ordering a return receipt for them, thus ensuring their delivery, can be compared to a connection-oriented protocol.
- Connection-oriented protocol (TCP): Here the protocol ensures the receipt of a message at the other end without any data loss on the way, thus ensuring a reliable transport. The connection-oriented protocol needs extra overhead (discussed later) as compared to the connectionless protocol. Just like, it takes extra resources (time, money) to order a registered letter with return receipt.
Packet and Packet size
A packet contains data (payload) along with information (header) like source, destination, size etc. Just like a DHL packet that contains stuff to be shipped along with information like address, weight, dimension etc. packet size in networking, is the amount of data (in bytes) carried over the transport layer protocols.
It is the extra information (in bytes) or features associated with the packet which ensures the reliable delivery of the data. In other terms, it is that bubble wrap foil around your shipment that is not necessarily needed but provides an extra layer of safety and reliability for a safe shipment of your parcel.
The amount of overhead associated with the packet depends on the type of transport protocol used. UDP in comparison to TCP has smaller overhead.
Bandwidth is the rate (bits/MB/GB per seconds) at which the data transfer takes place. The larger the bandwidth, the more data can be transferred at a given time.
So that was a crash course on networking. Now let us try to understand the mentioned IIoT protocols using these terminologies.
Message Queue Telemetry Transport or simply MQTT is a lightweight messaging protocol for industrial and mobile applications. It is best suited for application where network bandwidth and power usage are limited, for example, small sensor, remote location applications, machine to machine communication. MQTT communicates with a server over TCP and unlike HTTP works on publish subscriber model (see figure below).
Fig. Example of a publish subscriber model used in MQTT
In order to understand the concept behind the MQTT, one should try to understand the underlying architecture “The publish-subscriber model”. Here a client publishes a message or a topic (temperature, humidity) to a broker that in turn sends these topics out to clients interested in subscribing to that message.
The publish subscriber model used in MQTT offers a couple of advantages as compared to the standard client-server model used in HTTP. Multicast, scalability and low power consumption are among the top three. These advantages are due to the fact that the publish-subscriber model overcomes some of the structural (one to one communication, tight coupling, fault sensitive) drawbacks of the traditional client-server model.
Let’s have a look at an analogy in order to understand the difference. Let us assume that MQTT and HTTP are two publishing companies:
MQTT publishes magazines on various topics (sports, politics, cars, etc.) and provides them to a broker who in turn distributes them to subscribers interested in one or more topics. This way MQTT can cater many (multicast) subscribers at a given time, thus it is scalable. Since he only has to deal with a broker whom he contacts once a day, his investment (power consumption) in maintaining the business is not high.
HTTP, another publisher, likes to deal with one customer at a time. He highly relies on his customer and on his value chain (server to server). This, however, comes at a cost of relatively high business investment (power consumption) since he has to visit his customer each time for a handshake.
MQTT in contrast to HTTP is best suited for an application where bandwidth, packet size and power are at a premium. An industry generator with battery-powered temperature and humidity sensor cannot afford to maintain a connection with server each time it has to push the measured values (event or message) into the cloud. MQTT is just designed to overcome such constraints where the connection is maintained by using a very little power and the commands and events can be received with as little as 2 bytes of overhead (extra resources needed for operation).
Constrained Application Protocol or simply CoAP, is a UDP based protocol, which is mostly interpreted as a light version of HTTP (except the fact that HTTP works over TCP). It is specially designed to work in a constrained environment with limited bandwidth and power constraints, where communication has to be fast and ongoing. Unlike HTTP, CoAP can support one to many (multicast) requirements and is faster than other TCP based protocols which makes it a good choice for M2M.
It is quite common to see the device to device (D2D) or device to gateway (D2G) communication done over CoAP and the communication between gateway and cloud is HTTP job. This is due to the fact that there is a well-defined mapping between these two protocols.
So, if both MQTT and CoAP are good for the constrained environment, then what makes one better than another? The answer lies in the underlying transport layer their use. MQTT is better suited for event-based communication in a constrained environment where data needs to be sent in batches (for instance temperature and humidity values) and at regular intervals over a reliable channel.
CoAP is a better choice for continuous conditioning monitoring scenario in a constrained environment. Since it runs over UDP, CoAP offers faster communication among the devices which makes it a better option for M2M/D2D/D2G communication. CoAP is also best suited for web-based IIoT application where it has to work along with HTTP. In such a setup, you have CoAP at sensor side and HTTP running between proxy/gateway and cloud.
What about HTTP? It is on demand whenever you want to push a big chunk of data from gateway/industry modem/computer into the cloud or a web-based application without compromising on security. Here regardless of how data is collected and sent to a gateway (CoAP vs MQTT) if it comes to reliable big package delivery, then HTTP takes the front seat. Moreover, HTTP is still used as a standard protocol for devices who do not support any other protocols.
MQTT or CoAP or HTTP, it is a matter of speed vs reliability vs security, whichever suits your use case the best.
I hope you enjoyed reading the article and that it helped you to get at least a basic understanding of the major IIoT protocols. Your feedback, comments or suggestions are always welcome.