What is MQTT? Where is it Used, What Does it Do? Comprehensive IoT & IIoT Guide

1. Introduction: What is MQTT and Why is it Essential?

MQTT (Message Queuing Telemetry Transport) is an extremely lightweight, open-standard messaging protocol designed explicitly for constrained hardware devices, high-latency or unreliable networks, and low-bandwidth communication channels. First developed in 1999 by Dr. Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link), MQTT was initially engineered to monitor sensitive oil and gas pipelines situated across vast deserts and oceans via expensive, bandwidth-limited satellite connections.

Today, standardized under ISO/IEC 20922 and OASIS, MQTT serves as the foundational communication backbone for the Internet of Things (IoT), Industrial Internet of Things (IIoT), smart cities, smart buildings, automotive systems, and modern energy management platforms. Traditional web protocols such as HTTP (Hypertext Transfer Protocol)—built upon a synchronous client-server, request-response architecture—introduce substantial header overhead with every transmitted data packet. Furthermore, their reliance on continuous server polling quickly exhausts the battery life of remote sensors and overburdens limited network links. In contrast, MQTT utilizes a minimal fixed header size of just 2 bytes, dramatically reducing network traffic, latency, and power consumption.

2. MQTT Architecture and Working Principles

Rather than adopting a point-to-point architecture where devices connect directly to one another, MQTT decouples data producers from data consumers temporally and spatially through a central mediator using the Publish-Subscribe pattern. The system comprises three core elements:

2.1. MQTT Client

An MQTT client is any software library or hardware node capable of establishing a TCP/IP or WebSocket connection to an MQTT Broker to send (publish) or receive (subscribe to) messages. Depending on system requirements, clients operate in two primary functional roles:

• Publisher: Edge devices such as physical sensors, Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), or smart meters that collect environmental or operational metrics and send payloads under designated Topic strings to the Broker.
• Subscriber: Applications or systems that register interest in specific topic hierarchies with the Broker. When new messages arrive on these topics, the Broker instantly forwards the payloads to all subscribed clients—such as SCADA dashboards, cloud analytics platforms, databases, or mobile apps.

2.2. Broker (Central Server)

The MQTT Broker is the central intelligence node managing all message routing and client states across the entire ecosystem. It accepts incoming TCP connections, parses topic headers, verifies client credentials, enforces access control lists, and dispatches messages to authorized subscribers. Core responsibilities include:

• Managing client connection states, authentication, and authorization protocols.
• Maintaining topic hierarchies (Topic Tree) and active subscriber registries.
• Ensuring guaranteed message delivery according to configured Quality of Service (QoS) levels.
• Handling unexpected client disconnections via Last Will and Testament (LWT) routines.
• Caching Retained messages to deliver current state data immediately to new subscribers.

2.3. Topic Architecture and Wildcard Expressions

In MQTT, a "Topic" acts as a UTF-8 case-sensitive string channel that dictates message routing across the broker. Topics are structured hierarchically using forward slashes (/), enabling seamless logical categorization of thousands of field variables. A typical industrial topic path appears as follows:

factory/building1/line3/plc01/temperature

Subscribers can leverage wildcard expressions to subscribe to multiple topic channels simultaneously without needing to declare each topic individually:

• Single-Level Wildcard (+): Replaces a single level within the topic tree. For example, factory/+/line3/plc01/temperature subscribes to PLC01 temperature readings across all factory buildings.
• Multi-Level Wildcard (#): Matches all remaining sub-levels in the hierarchy and must be placed at the end of the topic string. For instance, factory/building1/# captures every topic stream originating under Building 1.

3. Core Technical Features of MQTT

3.1. Clean Session Management

During the initial TCP handshake, an MQTT client submits a Clean Session flag to the Broker. This controls how connection state and message queues are handled upon disconnection:

• Clean Session = True (1): The Broker discards all prior session data, subscriptions, and queued messages upon connection or disconnection. The client starts with a completely clean state. Ideal for non-critical live dashboard displays.
• Clean Session = False (0): The Broker preserves subscription trees and queues undelivered QoS 1 and QoS 2 messages while the client is offline. Upon reconnection using the same Client ID, the Broker flushes queued messages to the client automatically, preventing data gaps during intermittent cellular connections.

3.2. Quality of Service (QoS) Levels

MQTT offers three distinct Quality of Service levels to strike an optimal balance between network bandwidth consumption and message delivery guarantees:

QoS 0: At Most Once (Fire and Forget)

Messages are transmitted once without delivery acknowledgments (PUBACK). While delivery is not guaranteed and packets may be lost over unstable links, duplicate delivery is impossible. This level provides maximum throughput and minimal overhead, suited for high-frequency, non-critical telemetry such as ambient temperature updates.

QoS 1: At Least Once

Guarantees message delivery via a mandatory PUBACK confirmation packet sent from receiver to sender. If the sender does not receive an acknowledgment within a specified timeout, it retransmits the message. While message loss is eliminated, network retries may occasionally yield duplicate messages at the subscriber end. This is the most widely deployed QoS level for meter reading, alarms, and state telemetry.

QoS 2: Exactly Once

Employs a rigorous four-step handshake mechanism (PUBLISH → PUBREC → PUBREL → PUBCOMP) to guarantee that each message is received exactly once without packet loss or duplication. Although it requires additional network round-trips and processing, QoS 2 is essential for mission-critical industrial control commands, financial transactions, and billing operations.

3.3. Last Will and Testament (LWT)

LWT provides proactive health monitoring for edge devices. Upon initial connection, a client registers a Last Will message, topic, and QoS level with the Broker. If the client unexpectedly drops its connection without issuing a formal DISCONNECT packet (e.g., due to power failure or loss of cellular signal), the Broker automatically publishes the LWT message to designated monitoring clients, alerting operators immediately of edge offline events.

3.4. Retained Messages

When a message is published with the Retain = True flag, the Broker caches the message payload as the "last known good value" for that topic. When a new client subsequently subscribes to that topic, the Broker immediately dispatches the cached retained message to the client, providing instant visibility into device status without waiting for the next publishing cycle.

3.5. Timestamping and Historical Data Backfilling

Industrial RTU and PLC edge devices (such as Mikrodev automation controllers) can embed millisecond-precision timestamps directly into MQTT payloads. During network outages, edge controllers buffer time-stamped telemetry into non-volatile memory. Once connectivity is restored, the buffered messages are backfilled to central SCADA systems and databases, preserving historical trend integrity without data loss.

4. Where is MQTT Used? (Real-World Applications & Use Cases)

Thanks to its low overhead, exceptional scalability, and asynchronous nature, MQTT serves as the primary protocol across a vast spectrum of enterprise and industrial sectors:

4.1. Industrial Automation & Smart Factories (IIoT)

In modern manufacturing environments, legacy fieldbus protocols (Modbus, Profinet, EtherNet/IP) are translated into MQTT via IIoT gateways and PLCs. Real-time production counts, downtime reasons, machine health metrics, and OEE (Overall Equipment Effectiveness) data are streamed seamlessly to Cloud platforms, MES, and enterprise ERP systems.

4.2. Smart Energy & Power SCADA

Deployed across electrical transmission sub-stations, transformer sites, and solar/wind renewable energy plants to monitor power quality analyzers, protective relays, and solar inverters in real time with minimal latency.

4.3. Water & Wastewater Management

Remote water reservoirs, pumping stations, and flow control valves often run on solar or battery power connected over cellular (4G/5G/NB-IoT) modems. MQTT's change-of-value (COV) publishing and small header size minimize cellular data charges significantly.

4.4. Smart Cities & Urban Infrastructure

MQTT connects intelligent street lighting networks, parking occupancy sensors, air quality monitoring stations, and traffic management systems into centralized smart city dashboards.

4.5. Automated Meter Reading (AMR / OSOS)

Utility companies leverage MQTT gateways to convert DLMS/COSEM or M-Bus smart meter readings into standardized MQTT payloads, aggregating millions of residential utility metrics into central billing databases effortlessly.

5. MQTT Security and the Sparkplug B Specification

5.1. MQTT Security Architecture

Despite its lightweight footprint, MQTT supports robust enterprise-grade security mechanisms:

• Transport Layer Security (TLS/SSL): Encrypts TCP traffic to prevent eavesdropping and man-in-the-middle attacks.
• Authentication: Enforces client identity verification via username/password pairs or TLS X.509 client certificates.
• Access Control Lists (ACL): Defines granular permissions on the Broker, restricting which clients can publish to or subscribe from specific topic patterns.

5.2. Sparkplug B Specification

While standard MQTT allows arbitrary payload formats (JSON, XML, raw binary), the Sparkplug B specification developed under the Eclipse Foundation introduces standardized topic structures, Google Protocol Buffers (Protobuf) binary payload compression, and auto-discovery mechanisms (STATE, BIRTH, DEATH messages) to deliver true plug-and-play interoperability for industrial SCADA architectures.

5.3. Popular MQTT Brokers in the Ecosystem

Choosing the right MQTT Broker is essential for scaling IoT and enterprise deployments. The most widely adopted open-source and commercial brokers include:

• Eclipse Mosquitto: Written in C, Mosquitto is an extremely lightweight, open-source broker suitable for embedded Linux devices, Raspberry Pi nodes, and small-to-medium deployments.
• EMQX (EMQ X): Built on Erlang/OTP, EMQX is a massive-scale enterprise broker capable of handling millions of concurrent connections and messages per second with native clustering, high availability, and rule engine integrations.
• HiveMQ: A Java-based enterprise MQTT platform engineered for mission-critical automotive and industrial applications, offering rich monitoring interfaces, Kafka data streaming bridges, and robust cloud capabilities.
• VerneMQ: An Erlang-based distributed MQTT broker optimized for horizontal scalability and high availability across multi-datacenter environments.

5.4. Best Practices for MQTT Topic Design and Architecture

Designing a structured, scalable topic hierarchy is critical for long-term maintainability and performance in enterprise IoT architectures:

• Enforce Consistent Naming Conventions: Use lowercase UTF-8 strings separated by underscores (_). Avoid space characters, special symbols, and non-ASCII characters in topic strings.
• Structure from General to Specific: Order your topic path logically from top-level organization down to the edge telemetry variable (e.g., region/site/building/device_id/metric).
• Avoid Leading or Trailing Slashes: Adding a slash at the start or end creates unnecessary empty root levels (e.g., use factory/pump01 instead of /factory/pump01/).
• Separate Command and Telemetry Channels: Maintain distinct topic streams for inbound device telemetry versus outbound control commands (e.g., site/device01/telemetry vs site/device01/cmd).

6. Detailed Comparison: MQTT vs. HTTP/REST

Comparison Metric	MQTT	HTTP / REST
Architecture	Publish-Subscribe	Client-Server (Request-Response)
Fixed Header Size	2 Bytes (Extremely Low)	200 - 800 Bytes (High)
Communication Model	Asynchronous (Bi-directional)	Synchronous (Request-driven)
Data Format	Binary, JSON, Protobuf, Text	Primarily JSON, XML, HTML
Bandwidth & Power Usage	Very Low (Battery & Cellular Friendly)	High (Continuous Polling overhead)
Delivery Guarantees (QoS)	Built-in (QoS 0, QoS 1, QoS 2)	None (Application layer required)
Connection State Monitoring	Native (LWT and Keep-Alive)	None (Request-time checks only)

7. Conclusion

MQTT (Message Queuing Telemetry Transport) has firmly established itself as the undisputed standard messaging protocol for IoT and industrial automation. Its lightweight footprint, high reliability, bandwidth efficiency, and flexible topic hierarchy bridge the gap between tiny edge sensors and cloud-scale AI analytics. When configured with appropriate QoS levels, secure TLS encryption, and resilient Broker architecture, MQTT accelerates industrial digital transformation and powers modern connected ecosystems worldwide.