MQTT is the acronym for Message Queue Telemetry Transport and behind them is a protocol designed by IBM and released so that anyone can use it focused on Machine-to-Machine (M2M) connectivity.
MQTT was created by Dr. Andy Stanford-Clark of IBM and Arlen Nipper of Arcom — now Eurotech — in 1999 as a cost-effective and reliable way to connect monitoring devices used in the oil and gas industries to remote enterprise servers. When challenged with finding a way to send sensor data from oil pipelines in the desert to external SCADA (supervisory control and data acquisition) systems, they decided to use a TCP/IP-based publish/subscribe topology. which would rely on events to keep transmission costs for satellite links down.
It is focused on sending data in applications where very little bandwidth is required. Furthermore, its characteristics allow it to boast of having really low consumption as well as requiring very few resources for its operation.
These characteristics have made it quickly become a widely used protocol in sensor communication and, consequently, within the Internet of Things how can it be the best solution with Parangat Technologies?
The Internet of Things market is projected to experience an 18% growth and achieve a staggering 14.4 billion active connections(2022), as mentioned in the research report titled “Status of the IoT Spring 2022” by IoT Analytics.
MQTT is a protocol designed for IoT that is at the same level as HTTP or CoAP:
MQTT and CoAP comparison
An important aspect to take into account about IoT devices is not only being able to send data to the Cloud/Server but also being able to communicate with the device, in short, bi-directionality. This is one of the benefits of MQTT: it is a brokered model, and the client opens an outbound connection to the broker, even if the device is acting as a Publisher or subscriber. This usually avoids problems with firewalls because it works behind them or via NAT.
In the case where the main communication is based on HTTP, the traditional solution to send information to the device would be HTTP Polling. This is inefficient and has a high cost in terms of traffic and/or energy. A newer way to do this would be with the WebSocket protocol, which allows you to create a full bidirectional HTTP connection. This acts as a socket channel (similar to the typical TCP channel) between the server and the client. Once established, it is the system’s job to choose a protocol to tunnel over the connection.
MQTT is aimed at large networks of small devices that need monitoring or control by a back-end server on the Internet. It is not designed for device-to-device transfer. It is also not designed to “multicast” data to many receivers. MQTT is simple and offers few control options. Applications that use MQTT are generally slow in the sense that the definition of “real-time” in this case is typically measured in seconds.
More information:
MQTT is also a protocol that is gaining a lot of importance in the industry (IIoT). MQTT (Message Queuing Telemetry Transport) is a publish/subscribe protocol designed for SCADA. It focuses on a minimal header (two bytes) and reliable communications. It is also very simple. Just like HTTP, the MQTT payload is application-specific, and most implementations use a custom or binary JSON format.
MQTT is interesting to use when bandwidth is low and you don’t know your infrastructure. Make sure your provider has an MQTT broker to whom you can publish information, and always secure communication with TLS (Transport Layer Security).
For example, MQTT would be a good option for monitoring and controlling solar panels. MQTT is a publish/subscribe protocol with central message brokers. Each solar panel can contain an IoT node that publishes voltage, current, and temperature messages.
MQTT is designed to minimize bandwidth, making it a good choice for satellite transmission line monitoring, but there is a catch. The absence of metadata in message headers means that the interpretation of messages is entirely up to the system designer.
To compensate for unreliable networks, MQTT supports three levels of Quality of Service (QoS):
- Fire and Forget (0) – Fire and Forget – At most once
- At least once (1) – At least once
- Exactly once (2) – Exactly once
If QoS level 1 or 2 is requested, the protocol manages message retransmission to ensure delivery. The quality of service can be specified by publishing clients (covers the transmission from the publisher to the broker) and by subscriber clients (covers the transmission from a broker to a subscriber).
MQTT QoS 2 will increase latency because each message requires two complete round-trip handshakes from sender to receiver (four total from publisher to subscriber).
In a publish/subscribe pattern it’s hard to tell the difference between “It’s been a long time since I heard from my publisher” and “My publisher died.” That’s where MQTT’s last will (LWT) comes into play. Clients can post messages on specific topics.
MQTT at a glance
- Very low bandwidth
- TCP/IP
- Publish/subscribe message transfer
- Many-to-many topology through a central broker
- No metadata
- Three levels of QoS
- Testament reveals disconnected nodes
The advantages of using the MQTT protocol are:
- It is asynchronous with multiple different levels of quality of service, which turns out to be important in cases where Internet connections are unreliable.
- It sends short messages which become suitable for low bandwidth situations.
- It doesn’t require much software to implement a client, which makes it great for devices like Arduino with limited memory.
- We can encrypt the data sent and use a username and password to protect our shipments.
- If you would like to record in a database with MQTT, a subscriber to a series of topics is responsible for recording the data every time a value changes or every certain time, for example with a Python script or running Node-RED in a virtual machine or on the server itself (or Raspberry Pi) where the broker (Mosquitto) runs.
NodeRed is nothing more than software that is installed on a node even if it is installed on the same server as the broker.
MQTT architecture
MQTT (Message Queue Telemetry Transport), is a protocol used for machine-to-machine (M2M) communication in the Internet of Things. This protocol is aimed at sensor communication because it consumes very little bandwidth and can be used in most embedded devices with few resources (CPU, RAM,…).
An example of using this protocol is the Facebook Messenger application for both Android and iPhone. The MQTT architecture follows a star topology, with a central node that acts as a server or “broker”. The broker is in charge of managing the network and transmitting messages. To keep the channel active, clients periodically send a packet (PINGREQ) and wait for the broker’s response (PINGRESP). Communication can be encrypted among many other options.
In this form of communication, the clients who publish ( Publisher ) are decoupled from those who consume the data ( Subscribers ). That means that the clients do not know each other, some publish the information and others simply consume it, everyone simply has to know the message broker.
Decoupling occurs in three dimensions:
- In space: The publisher and the subscriber do not have to know each other.
- In time: The publisher and the subscriber do not have to be connected at the same time.
- In synchronization: Operations on either component are not interrupted while messages are published or received.
It is precisely the broker that is in charge of managing the network and transmitting messages.
An interesting feature is MQTT’s ability to establish encrypted communications, which provides our network with an extra layer of security.
Communication is based on “topics” that the client that publishes the message creates and the nodes that wish to receive it must subscribe to it. Communication can be one-to-one or one-to-many.
Within the MQTT architecture, the concept of “topic” or “theme” in Spanish is very important since communication is articulated through these “topics” since senders and receivers must be subscribed to a common “topic” to be able to communicate. establish communication. This concept is practically the same as that used in queues, where there are publishers (who publish or broadcast information) and subscribers (who receive said information) as long as both parties are subscribed to the same queue.
This type of architecture has another interesting characteristic associated with it: communication can be one-to-one or one-to-many.
Examples of Valid MQTT Topics:
home/test/topic
home/+/topic
home/#
house/+/+
+/#
#
Single-level wildcard explanation:
MQTT scaling
MQTT allows me great scalability. Adding a new Arduino or a subscriber is very simple within the hierarchy seen
By scalable we mean the ability of a system to be expanded. Sensor systems in general, particularly in our case we are talking about the world of the Internet of Things, are characterized by sending a lot of small data in real-time since many sensors are transmitting simultaneously and for very short periods, whose information needs to be consumed by other elements in real-time.
In a Broker-based Architecture, it is essential to avoid SPOF (single point of failure).
In the MQTT context there are 2 main strategies:
Bridging: forwards messages to another MQTT broker. It is the solution of HiveMQ, Mosquitto, IBM MQ
Clustering: supporting dynamic addition of nodes to the cluster. It is used by ActiveMQ, HiveMQ, or RabbitMQ.
When a system of these characteristics begins to be saturated, communications are blocked and the “real-time” characteristic is lost.
Until now, all the systems we had seen were based on a client communicating with a server. If any client tries to communicate with a server that is processing so much information that, at that moment, it is not capable of working with more content, the entire system will fail, either because it becomes saturated and blocks at a global level or because it begins to discard that information. information that it cannot process (which is unacceptable in many cases, imagine an Explosion Risk alarm in your kitchen because a gas leak has been detected…).
There are several ways to address this problem but, today, one of the most used is to use queuing systems where all the information is left and the person in charge of processing it “takes” the information from this queue. In this way, if we put more “processing managers” they can empty the queue faster if we see that it is starting to fill up and, in terms of the sensors, it would not be necessary to make any changes, since they always send the same place.
MQTT does not do the same thing since, to begin with, there are no queues but “topics” but the philosophy is very similar, allowing large systems to operate with total fluidity and, together with its optimizations that seek, among other things, to reduce consumption and sizes of the frame to be able to operate on embedded elements, which is the reason why it is a protocol so widely used in M2M communications.
In addition, it allows us reasonably simple security management that makes it easier for our systems to behave more robustly and the best is that Parangat Technologies is one of the best when it comes to 3.0 solutions to create an impact.
MQTT will be the link between hardware (sensor) and all the typical elements of the software world (servers, databases, Big Data). In this layer, we worry that the information reaches a system that subsequently takes care of distributing it among the other parts and we don’t care what there is from that moment on or its size. We may have nothing more than a visualization website or we may have a complex Machine Learning and Big Data system. We may be an individual sending temperature data to a display panel on their Raspberry or we may be a multinational that controls its global ammonia production in real time, lowering and raising the production load in its different factories according to costs. transportation and consumption of its different distribution centers. It is not the same at this level because we do only one thing and we do it well: send data from a hardware device to a much larger system.
Is MQTT the optimal protocol for IoT?
If you want to create an IoT platform, use an open standard messaging protocol such as MQTT. This protocol is lightweight and works with devices that have limited hardware and bandwidth resources. It also supports a wide range of application situations, making it an excellent solution for IoT developers at Parangat Technologies. MQTT is also secure, offering end-to-end encryption for sensitive data. This safeguards data transfers between client devices, preventing sensitive information from being leaked to unauthorized users. Furthermore, because MQTT is open source, it is interoperable with a wide range of bespoke MQTT libraries that are already on the market.
The MQTT protocol is well-established, and there are several multilingual MQTT client and broker implementations available. For developers, there are also sizable, vibrant communities and excellent technical documentation accessible. Programmers find it attractive because of its simplicity. MQTT can be implemented in the Internet of Things with little understanding and a short learning curve.
Conclusion
With the comparative analysis, the common characteristics that the studied cases have were listed, as well as the added characteristics that each case increases to the development of the different IoT systems. Furthermore, it was shown that the 3-layer architecture and the ITU model compete in usability, although the former is a much simpler model.
For IoT systems that have a more business-oriented approach, the 5-tier architecture is a clear choice. Control and monitoring are necessary to observe growth and make correct decisions when developing a business along with the best Artificial Intelligence services. It was shown that each case studied has certain advantages and disadvantages, one concerning the other. It is important to know these characteristics when selecting an architecture or model for the deployment of an IoT system.
