MQTT Protocol

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol built on the publish-subscribe model. It was originally designed for telemetry in low-bandwidth, high-latency satellite links, and has since become the dominant application-layer protocol for IoT systems. Its minimal overhead makes it ideal for microcontrollers, embedded Linux systems, and any device where memory and power are limited.

Core Concept Explanation

MQTT operates over TCP/IP and uses a central broker to route messages. Devices that send data are called publishers. Devices that receive data are called subscribers. Publishers and subscribers never communicate directly. All communication passes through the broker, which decouples the data source from the data consumer.

Messages in MQTT are organized by topics, which are hierarchical UTF-8 strings like home/room1/temperature. A subscriber uses wildcard characters to subscribe to multiple topics at once. The plus sign (+) matches a single level, and the hash sign (#) matches multiple levels. For example, home/+/temperature matches home/room1/temperature and home/room2/temperature.

MQTT uses only four packet types for most communication: CONNECT, PUBLISH, SUBSCRIBE, and DISCONNECT. The entire MQTT fixed header is just 2 bytes, making it far more efficient than HTTP for IoT data transmission.

Quality of Service Levels

MQTT defines three QoS (Quality of Service) levels that balance reliability against overhead. QoS 0 is fire-and-forget — the message is sent once with no acknowledgment. QoS 1 guarantees at least one delivery but may result in duplicates because the sender retransmits until it receives an acknowledgment. QoS 2 guarantees exactly one delivery using a four-step handshake, adding overhead but ensuring no duplicates.

Mathematical Expression

The overhead ratio of MQTT compared to HTTP can be quantified. An HTTP POST with JSON payload for a single sensor reading typically requires 200–400 bytes of headers. An MQTT PUBLISH packet for the same payload requires only 2 bytes fixed header plus variable header (topic length + topic string + packet ID).

MQTT overhead = Fixed Header (2 B) + Topic Length (2 B) + Topic String (N B) + Payload (M B)

For a topic of 20 characters and a 10-byte payload, total MQTT packet = 2 + 2 + 20 + 10 = 34 bytes, versus HTTP which would be 200+ bytes — roughly 6x more efficient per transmission.

Practical Understanding

Consider a smart irrigation system with 50 soil moisture sensors spread across a farm. Each sensor publishes to its own topic (farm/zone1/moisture, farm/zone2/moisture, ...) every 5 minutes. A central controller subscribes to farm/+/moisture and receives all readings. When a reading falls below a threshold, the controller publishes to farm/zone1/valve/open, and the actuator subscribed to that topic opens the irrigation valve. The broker handles all routing, and no sensor knows anything about the actuators or vice versa.

Given:
50 sensors publishing every 5 minutes via HTTP vs MQTT
HTTP packet size per message = 300 bytes
MQTT packet size per message = 40 bytes
Link bandwidth = 9.6 Kbps (GSM/GPRS)

Why this formula applies:
Transmission time = total data / bandwidth

Formula:
Time = (N_sensors x packet_size x messages_per_hour) / bandwidth

Substitution (HTTP):
Time = (50 x 300 x 12) / 9600 bps = 180000 / 9600 = 18.75 s/hr

Substitution (MQTT):
Time = (50 x 40 x 12) / 9600 = 24000 / 9600 = 2.5 s/hr

Calculation:
MQTT uses 7.5x less airtime than HTTP in this scenario.

Final Answer: MQTT reduces transmission time from 18.75s/hr to 2.5s/hr for 50 sensors.

Exam Tip: QoS 0 = at most once (no guarantee), QoS 1 = at least once (possible duplicates), QoS 2 = exactly once (4-step handshake). QoS 2 has the highest overhead and is rarely used in resource-constrained IoT devices.

MQTT Key Features Summary

• Broker-based pub-sub model completely decouples publishers from subscribers.
• Topics are hierarchical strings; + matches single level, # matches multiple levels.
• Retain flag: broker stores the last message on a topic for new subscribers.
• Last Will and Testament (LWT): pre-set message sent by broker if a client disconnects unexpectedly.
• Runs over TCP port 1883 (unencrypted) or port 8883 (TLS encrypted).

Quick Revision

• MQTT uses publish-subscribe model with a central broker for all message routing.
• Topics are hierarchical strings. Wildcards: + (one level), # (multi-level).
• QoS 0: at most once. QoS 1: at least once. QoS 2: exactly once.
• Fixed header is only 2 bytes — far smaller overhead than HTTP.
• LWT (Last Will and Testament) allows graceful handling of unexpected disconnections.
• Retain flag ensures new subscribers get the most recent message immediately on connecting.
• Trap: MQTT does not define data format. Payload can be JSON, binary, or plain text — format is the application's responsibility.