Tutorials » IoT » MQTT Architecture: Message Types, Format, and Flow

MQTT Architecture: Message Types, Format, and Flow

mqtt iot message queue architecture protocol

The MQTT (Message Queuing Telemetry Transport) protocol is a lightweight messaging protocol designed for low-bandwidth, high-latency, or unreliable networks.

In this guide, we’ll delve into the architecture of MQTT, exploring its message formats, types, flow diagrams, and the intricate exchanges between server brokers and clients. By understanding these components, you’ll gain insights into how MQTT facilitates efficient communication in real-world use cases, making it an ideal choice for IoT applications and beyond.

MQTT architecture

Figure 1: MQTT Architecture

As mentioned, MQTT is a broker-based protocol. End devices (i.e., clients) communicate via a broker. The broker is a server that can be installed on any machine in the cloud. There are different types of brokers, such as HiveMQ and Mosquitto. A single client and broker can also communicate directly.

As MQTT runs above the TCP/IP layer, it’s also a connection-oriented protocol. The client establishes a connection with the broker (i.e., server) before communication begins.

MQTT is a publish-subscribe protocol. Both client and server publish information (i.e., a parameter such as temperature, humidity, or an event like ON/OFF) to each other using a “PUBLISH” message. Any number of clients or end devices can subscribe to an event with the broker. Due to this subscription, when there’s a change in any event or parameter, the broker will notify the subscribed clients about the change (i.e., temperature, humidity, etc.).

MQTT Message Types

The following table lists the MQTT protocol messages exchanged between a client and a broker:

MQTT messageDescription with direction of flow
CONNECTClient to server (i.e., Broker), the client requests to connect to the server.
CONNACKServer to client, connect acknowledgment
PUBLISHClient to server OR server to client Publish message
PUBACKClient to server OR server to client Publish acknowledgment
PUBRECClient to server OR server to client Publish received
PUBRELClient to server OR server to client Publish release
PUBCOMPClient to server OR server to client Publish complete
SUBSCRIBEClient to server Client subscribe request
SUBACKServer to client Subscribe acknowledgment
UNSUBSCRIBEClient to server Unsubscribe request
UNSUBACKServer to client Unsubscribe acknowledgment
PINGREQClient to server Ping request
PINGRESPServer to client PING RESPONSE
DISCONNECTClient to server, Client is disconnecting

MQTT Message Format

MQTT protocol message format

Figure 2: MQTT Message Format

Figure 2 depicts the MQTT message format. It consists of a fixed message header, a variable header, and a payload. The first two bytes are used by most message types. Few message types use the variable header and payload.

MQTT Architecture Working: Example Use Cases

MQTT message flow

Figure 3: MQTT Message Flow

Let’s understand the working operation of the MQTT protocol architecture. Figure 3 depicts the MQTT message flow between a client and a broker. We will use two MQTT use cases to understand the working operation of the MQTT architecture.

MQTT Use Case #1

Statement: The broker wants to switch ON or OFF the light connected with remote client #1.

  • Initially, a connection is established by client #1 with a broker using CONNECT and CONNACK messages.
  • Next, the broker communicates with client #1 to switch ON or OFF the light interfaced with it. Messages such as PUBLISH and PUBREC are used for this.

This use case is used to switch ON/OFF streetlights in Zigbee or LoRaWAN networks. The lights are usually connected with end nodes or end devices in these wireless networks. A single Zigbee or LoRaWAN gateway controls multiple end nodes. Multiple such gateways are needed to cover an entire city.

MQTT Use Case #2

Statement: Client #2 or client #3 wants to update temperature/humidity status to the broker based on sensors.

  • Client #2 and client #3 will send temperature or humidity updates to the broker using a PUBLISH message.
  • This information is stored in the database and will be sent to all subscribers who have subscribed to these topics (i.e., temperature, humidity).
  • This information is “pushed” to all the subscribed clients of the topics.

If client #1 has already subscribed to these topics (i.e., temperature, humidity), it will get the information from the broker using a PUSH operation.

This use case is used for obtaining different types of sensing information automatically whenever there are any updates. For this purpose, different types of sensors (such as humidity sensors and temperature sensors) are interfaced with end nodes. These end nodes publish information (of any event updates) to the broker. The broker notifies changes to all the subscribed clients.

Communication Between Gateways

There are two dominant data exchange protocol architectures: broker-based and bus-based. In this MQTT tutorial, we’ve studied the broker-based MQTT protocol architecture. Wireless IoT technologies such as Zigbee and LoRaWAN use MQTT for communication between clients and routers. Protocols such as AMPQ, CoAP, and JMS also use broker-based architecture. Protocols such as DDS, REST, and XMPP use bus-based architecture.

Summary

In conclusion, understanding the architecture, message format, and flow of MQTT is essential for leveraging its full potential in various applications, especially in IoT environments.