MQTT Protocol Explained (PDF)

What is MQTT? ------------- MQTT is a standards-based messaging protocol used for machine-to-machine communication. Smart sensors, wearables, and other Internet of Things (IoT) devices typically have to transmit and receive data over a resource-constrained network with limited bandwidth. These Io...

What is MQTT? ------------- MQTT is a standards-based messaging protocol used for machine-to-machine communication. Smart sensors, wearables, and other Internet of Things (IoT) devices typically have to transmit and receive data over a resource-constrained network with limited bandwidth. These IoT devices use MQTT for data transmission, as it is easy to implement and can communicate IoT data efficiently. MQTT supports messaging between devices to the cloud and the cloud to the device. Why is the MQTT protocol important? ----------------------------------- The MQTT protocol has become a standard for IoT data transmission because of the following benefits: ### **Lightweight and efficient:** MQTT implementation on the IoT device requires lessresources, so it can even be used on small microcontrollers. ### **Scalable:** MQTT implementation requires less amount of code that consumes very little power in operations. ### **Reliable :** Many IoT devices connect over unreliable cellular networks with low bandwidth and high latency. ### **Secure:** MQTT makes it easy for developers to encrypt messages and authenticate devices and users using modern authentication protocols, such as OAuth, TLS1.3, Customer Managed Certificates, and more. ### **Well-supported:** MQTT protocol implementetion is supported by many languages like python. What is the history behind MQTT protocol? ----------------------------------------- The MQTT protocol was invented in 1999 for use in the oil and gas industry. Engineers needed a protocol for minimal bandwidth and minimal battery loss to monitor oil pipelines via satellite Initially, the protocol was known as Message Queuing Telemetry Transport due to the IBM product MQ Series that first supported its initial phase. In 2010, IBM released MQTT 3.1 as a free and open protocol for anyone to implement, which was then submitted, in 2013, to Organization for the Advancement of Structured Information Standards (OASIS) specification body for maintenance. In 2019, an upgraded MQTT version 5 was released by OASIS. Now MQTT is no longer an acronym but is considered to be the official name of the protocol.  What is the principle behind MQTT? ---------------------------------- MQTT uses a publish/subscribe model where a central message broker manages communication, decoupling publishers from subscribers. The broker filters incoming messages and delivers them to the appropriate subscribers. , The broker decouples the publishers and subscribers as below: #### **Space decoupling** Publishers and subscribers communicate without knowing each other\'s network details, like IP addresses or ports. #### **Time decoupling** The publisher and subscriber don't run or have network connectivity at the same time. #### **Synchronization decoupling** Publishers and subscribers operate independently, allowing messages to be sent or received without waiting for each other. -------------------------------------------------------------------------------------------------------------------------- What are MQTT components? ------------------------- MQTT implements the publish/subscribe model by defining clients and brokers as below. MQTT: publish / subscribe architecture ### **MQTT client** An MQTT client is any device running an MQTT library, acting as a publisher when sending messages and as a subscriber when receiving them. ### **MQTT broker** The MQTT broker coordinates communication by receiving, filtering, and distributing messages to subscribed clients.. It is also responsible for other tasks such as: - - - ### **MQTT connection** Clients connect to the MQTT broker via a TCP/IP stack, initiating with a CONNECT message and receiving a CONNACK response to confirm the connection. Communication occurs only between clients and the broker, not directly between clients. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- How does MQTT work? ------------------- An overview of how MQTT works is given below.  1. 2. 3. Let's break down the details for further understanding.  ### **MQTT topic** The term 'topic' refers to keywords the MQTT broker uses to filter messages for the MQTT clients. Topics are organized hierarchically, similar to a file or folder directory. For example, consider a smart home system operating in a multilevel house that has different smart devices on each floor. In that case, the MQTT broker may organize topics as: *ourhome/groundfloor/livingroom/light* *ourhome/firstfloor/kitchen/temperature* ### **MQTT publish** MQTT clients publish messages that contain the topic and data in byte format. The client determines the data format such as text data, binary data, XML, or JSON files. For example, a lamp in the smart home system may publish a message *on *for the topic *livingroom/light*. ### **MQTT subscribe ** MQTT clients send a* SUBSCRIBE* message to the MQTT broker, to receive messages on topics of interest. This message contains a unique identifier and a list of subscriptions. For example, the smart home app on your phone wants to display how many lights are on in your house. It will subscribe to the topic *light* and increase the counter for all *on *messages.  What is MQTT over WSS? ---------------------- MQTT over WebSockets (WSS) is an MQTT implementation to receive data directly into a web browser. The MQTT protocol defines a JavaScript client to provide WSS support for browsers. In this case, the protocol works as usual but it adds additional headers to the MQTT messages to also support the WSS protocol. You can think of it as the MQTT message payload wrapped in a WSS envelope. Is MQTT secure? --------------- MQTT communication uses SSL protocol to protect sensitive data transmitted by IoT devices. You can implement identity, authentication, and authorization between clients and the broker using SSL certificates and/or passwords. The MQTT broker typically authenticates clients using their passwords as well as unique client identifiers it allocates to each client. In most implementations, the client authenticates the server with certificates or DNS lookups. You can also implement encryption protocols with MQTT.  Is MQTT RESTful? ---------------- MQTT is not RESTful. Representational state transfer (REST) is an architectural approach to network communication that uses the request-response pattern of communication between message senders and receivers. In contrast, MQTT uses the publish/subscribe model of communication in the application layer and requires a standing TCP connection to transmit messages in a push manner. However, MQTT version 5 adds a new request/response method to act in a way similar to REST, wherein the publisher can attach a special response topic, which the receiver processes and generates an appropriate response. The Advantages and Disadvantages of MQTT in IoT ----------------------------------------------- While MQTT can have higher connection overhead than HTTP for single-message TCP sessions, its efficiency shines with multiple messages in the same session. Its flexibility enables solutions where clients share information, brokers chain together, and MQTT gateways map messages to cloud services. Features like over-the-air updates and broker-based queuing handle interruptions and support constrained devices. **MQTT and HTTP Comparison Summary** ---------------------- -------------------------------------------------------------------------------------------- -------------------------------------------------------------- **MQTT** **HTTP** Full name MQTT (the OASIS standardization group decided it would not stand for anything) Hyper Text Transfer Protocol Architecture Publish subscribe (MQTT does have a request/reply mode as well) Request response Command targets Topics URIs Underlying Protocol TCP/IP TCP/IP Secure connections TLS + username/password (SASL support possible) TLS + username/password (SASL support possible) Client observability Known connection status (will messages) Unknown connection status Messaging Mode Asynchronous, event-based Synchronous Message queuing The broker can queue messages for disconnected subscribers Application needs to implement Message overhead 2 bytes minimum. Header data can be binary 8 bytes minimum (header data is text - compression possible) Message Size 256MB maximum No limit but 256MB is beyond normal use cases anyway. Content type Any (binary) Text (Base64 encoding for binary) Message distribution One to many One to one Reliability Three qualities of service: 0 - fire and forget, 1 - at least once, 2 - once and only once Has to be implemented in the application ---------------------- -------------------------------------------------------------------------------------------- -------------------------------------------------------------- MQTT and CoAP Comparison Summary -------------------------------- -- -- -- -- -- -- **Modbus TCP Vs. MQTT** Modbus TCP is a point-to-point connection client server-based protocol that doesn't need any intermediaries. This works well in on-premise machine-to-machine communication but doesn't scale for machine-to-enterprise or cloud use cases. This is where MQTT excels. As a publish-subscribe based protocol it manages connections between publishers and subscribers efficiently through a broker. This is ideal for enterprise data movement as it bridges data between OT and IT systems.  Here is a table summarizing which protocol is preferred based on the use case. ------------------------------------------------------------------------------- ---------------- ---------- **USE CASE** **MODBUS TCP** **MQTT** Factory on-premise communication with spotty or no internet access Ideal Yes Connecting globally distributed systems Yes Ideal Complex network architecture with changing addresses or unknown addresses No Ideal Simple network architecture with static addresses Ideal Yes Data security or access control needed No Yes Scalability is needed Possible Ideal ACK needed for requests and response Ideal Yes Ability to send data without waiting for a request No Ideal Unreliable network connectivity, limited bandwidth, limited battery power No Ideal Small on-premise system communication with a controlled number of connections Ideal Yes Sending data to the enterprise or cloud software like AWS, Azure, and GCP No Yes ------------------------------------------------------------------------------- ---------------- ----------