MQTT Tutorial | MQTT architecture, MQTT protocol use cases
This MQTT tutorial covers MQTT architecture and MQTT protocol working operation with different MQTT use cases. This tutorial on MQTT protocol architecture describes MQTT message flow between broker and clients.

The figure-1 depicts MQTT architecture. As mentioned MQTT is broker based protocol. In these end devices (i.e. Clients) communicate via a broker. The broker is a server which can be installed on any machine in the cloud. There are different types of brokers such as HiveMQ, Mosquitto etc. The single client and broker can also communicate with each other.
As MQTT runs above TCP/IP layer, it is also connection oriented protocol. The client establishes connection with the broker (i.e. Server) before the communication. MQTT is a publish-subscribe protocol. Here both client and server publish about any information (i.e. A Parameter such as temperature, humidity, event (ON/OFF) etc.) to each other using "PUBLISH" message. Any number of clients or end devices can subscribe for an event with the broker. Due to this subscription, when there is a change in any event or parameter, the broker will intimate to the subscribed clients about the change in event or parameter (i.e. Temperature, humidity, etc.).
MQTT Message format
Following table mentions MQTT protocol messages exchanged between client and Broker.
MQTT message | Description with direction of flow |
---|---|
CONNECT | Client to server (i.e. Broker), the client requests to connect to server. |
CONNACK | Server to client, connect acknowledgment |
PUBLISH | Client to server OR
server to client Publish message |
PUBACK | Client to server OR
server to client Publish acknowledgment |
PUBREC | Client to server OR
server to client Publish received |
PUBREL | Client to server OR
server to client Publish release |
PUBCOMP | Client to server OR
server to client Publish complete |
SUBSCRIBE | Client to server Client subscribe request |
SUBACK | Server to client Subscribe acknowledgment |
UNSUBSCRIBE | Client to server Unsubscribe request |
UNSUBACK | Server to client Unsubscribe acknowledgment |
PINGREQ | Client to server Ping request |
PINGRESP | Server to client PING RESPONSE |
DISCONNECT | Client to server , Client is disconnecting |
MQTT Protocol Message Format

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

Let us understand the working operation of MQTT protocol architecture. The figure-3 depicts MQTT message flow between client and broker. We will take two MQTT use cases to understand the working operation of MQTT architecture.
MQTT Use Case#1: Broker wants to switch ON or OFF the light connected with
remote client#1
➨Initially connection is established by client#1 with a broker using
CONNECT and CONNACK messages.
➨Next Broker communicates with Client#1 to switch ON or OFF
the light interfaced with it. The messages such as PUBLISH and
PUBREC are used for it.
This use case is used to switch ON/OFF the street lights in Zigbee or LoRaWAN network.
The lights are usually connected with end nodes or end devices in
these wireless networks. The single Zigbee or LoRaWAN gateway controls multiple end nodes.
Multiple such gateways are needed to cover the entire city.
MQTT Use Case#2: Client#2 or client#3 wants to update
temperature/humidity status to the broker based on sensors
➨Client#2 and Client#3 will intimate temperature or
humidity update to the broker using PUBLISH message.
This information is stored in the database and will be sent
to all the 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 for subscription to topics
(i.e. Temperature, humidity), it will get the information from
broker using 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 sensor, temperature sensor, etc.)
are interfaced with end nodes. These end nodes publish information (of any event updates) to the broker.
The broker intimates changes to all the subscribed clients. The communication between gateway
There are two dominant data exchange protocol architectures viz. broker based and bus based. In this MQTT tutorial we have studied broker based MQTT protocol architecture. Wireless IoT technologies such as zigbee, LoRaWAN uses MQTT for communication between clients and router. Protocols such as AMPQ, CoAP and JMS also use broker based architecture. Protocols such as DDS, REST and XMPP use bus based architecture. Refer Bus based vs Broker based architecture >> for more information.
Difference between MQTT vs HTTP, MQTT vs DDS, MQTT vs REST, MQTT vs SMQTT, MQTT vs CoAP
MQTT vs HTTP >> MQTT vs REST >> MQTT vs DDS >> MQTT vs SMQTT >> MQTT vs CoAP >>
Zigbee and LoRaWAN Related Links
Main page LoRa tutorial LoRa Frequency Bands LoRa protocol stack LoRa MAC layer LoRaWAN classes LoRa features LoRa Transceiver module what is zigbee Zigbee network architecture basics Zigbee Protocol Stack Zigbee Physical layers Zigbee physical layer frame Zigbee MAC layer frames Zigbee frequency bands Zigbee Gadgets Zigbee Products
IoT Wireless Technologies
➤WLAN
➤THREAD
➤EnOcean
➤LoRa
➤SIGFOX
➤WHDI
➤Zigbee
➤6LoWPAN
➤Zigbee RF4CE
➤Z-Wave
➤NFC
➤RFID
➤INSTEON
What is difference between
Difference between OSI and TCPIP layers Difference between TCP UDP FTP vs HTTP FTP vs SMTP FTP vs TFTP ARP vs RARP NAT vs PAT RIP vs OSPF SLIP vs PPP IMAP4 vs POP3 IPV4 vs IPV6 Difference between Internet and Intranet