MQTT Protocol Overview

• MQTT is a lightweight, broker-mediated publish/subscribe protocol that enables scalable communication among resource-constrained devices.
• It supports flexible Quality of Service (QoS) levels, persistent sessions, and efficient data transmission with minimal header overhead.
• Extensions like MQTT+ and MQTTg enhance broker-side processing and geolocation, optimizing network bandwidth and IoT scalability.

Message Queuing Telemetry Transport (MQTT) is an OASIS-standard network protocol employing a broker-mediated publish/subscribe model. Designed for scalable communication among resource-constrained devices, MQTT is distinguished by its minimal header overhead, low code footprint, and flexible Quality of Service (QoS) guarantees. Initially adopted in machine-to-machine (M2M) and wireless sensor network deployments, MQTT now serves as a foundational layer for numerous Industrial IoT (IIoT), mobility, and green communication scenarios, as well as for cloud-scale event-driven architectures (Giambona et al., 2018, Srivastava et al., 2018, &&&2&&&, Reiher et al., 2022).

1. Protocol Architecture and Core Mechanics

MQTT follows a strict client–broker–client communication pattern. Each client establishes a long-lived TCP (default port 1883; 8883 for TLS) connection to a central broker (Srivastava et al., 2018). All messages, whether for data transport or control, are exchanged solely through the broker; direct communication is disallowed. The protocol defines a set of control packets, most critically CONNECT, PUBLISH, SUBSCRIBE, and DISCONNECT, with clearly delimited fixed headers, variable headers, and payloads. The topic space is defined hierarchically via UTF-8–encoded strings, supporting multi-level (“#”) and single-level (“+”) wildcards for flexible publish/subscribe patterns (Giambona et al., 2018, Srivastava et al., 2018).

Quality of Service is enforceable per message, offering:

• QoS 0 (at most once; no acknowledgment, fire-and-forget),
• QoS 1 (at least once; publisher resends until PUBACK is received, allowing duplicates),
• QoS 2 (exactly once; four-stage handshake for full delivery semantics).

Persistent sessions are supported, allowing for resumption of inflight messages or missed subscriptions. Clean session management, keep-alive intervals (default: 60 s), and “Last Will” messages are central features. Payloads are application-opaque, typically raw binary frames or UTF-8–encoded data (Tyrovolas et al., 2021, Giambona et al., 2018, Srivastava et al., 2018).

2. Security and Authentication Methods

MQTT exposes a lightweight authentication interface using username-password fields at connect time; more rigorous deployments mandate TLS. The protocol itself does not require mutual authentication. Two classes of authentication are prevalent:

• TLS-Managed Mutual Authentication: Embeds X.509 certificate validation in the TLS handshake. While robust, session stateful, and requiring no clock synchronization, it imposes higher code and memory demands (full certificate stack) on constrained devices. Client certificate transmission occurs in plaintext during initial handshake, reducing privacy until the session is cryptographically secure (Shingala, 2019).
• JWT-Based Authentication: As used in Google Cloud IoT and similar infrastructures, MQTT can employ JSON Web Tokens (JWT), transmitted via the password field in MQTT CONNECT. A JWT encodes issuer, subject, audience, issued-at, and expiration claims, signed with RS256/ES256. Brokers validate signatures and claims before accepting session establishment. JWT-based auth offers decoupled credential management, improved privacy (no certificates on wire), and stateless tokens but imposes a dependency on accurate device clock and forces periodic session re-establishment on token expiry (Shingala, 2019).

Attribute	JWT Auth	TLS Mutual Auth
On-wire handshake	TLS handshake + CONNECT/JWT	TLS handshake + client cert
Client identity visibility	No cert on wire	Cert visible during handshake
Key/credential provisioning	Signing key only	Key + certificate chain
Compute load (handshake)	JWT sig per CONNECT	TLS Verify + handshake
Session resumption	Requires new JWT + session	Supports TLS tickets
Time synchronization	Required (JWT claims)	Not required

3. Extensions and Broker-Side Functionality

Standard MQTT brokers forward all messages matching a subscriber’s topic filter—raw, unprocessed, and without understanding the semantics of message content. This limitation has led to enhancements such as MQTT+ (Giambona et al., 2018), which augment brokers with:

• Rule-based Subscriptions: Topic-based subscription extended with operators (e.g., $$GT;30/topic) to filter by value or string pattern.</li> <li><strong>Temporal and Spatial Aggregation:</strong> Continuous aggregation of incoming data streams across time windows (e.g.,$$DAILYAVG/topic) or topic wildcards (e.g.,$$AVG/room/+/temp), with statistical computation (sum, avg, min, max) maintained broker-side.</li> <li><strong>Broker-side Data Processing:</strong> Invocation of basic analytics (e.g., people count in images), returning processed results to subscribers (e.g.,$$CNTPPL/topic/image).
• Composite Subscriptions: Chaining of filter, spatial, processing, and temporal operators in subscription syntax with left-to-right precedence.

MQTT+ implementations, such as those based on HiveMQ plugins, offer semantic filtering and aggregation directly within the broker, substantially reducing network bandwidth and endpoint energy consumption; however, broker resource utilization increases proportionally with the complexity of requested in-broker computation (Giambona et al., 2018).

4. Protocol Customization: Geolocation and Green Communication

The original MQTT specification lacks any geolocation-awareness. Recognizing the requirements of location-sensitive IoT deployments, extensions such as MQTTg embed a 21-byte geolocation block (version, latitude, longitude, altitude; all IEEE 754) inline in the control packets. The protocol reuses a reserved flag bit (or dedicates new packet types, such as PUBLISHG = 0xF) to indicate the presence of geodata (Srivastava et al., 2018, Fisher et al., 2019). Brokers can now filter publications for subscribers based on geometric predicates (radius/in-polygon) registered at subscription time (geofences).

Key backward-compatibility properties are maintained by shifting payload offsets, allowing legacy brokers/clients to ignore the geolocation block if not recognized. Android proof-of-concept implementations demonstrate 99.9 % fidelity of geolocation transmission, validating the numerical accuracy of the field encoding (Fisher et al., 2019). Embedding geolocation reduces redundant signaling, network transmission counts, and device energy draw by eliminating discrete position broadcasts and enabling broker-side selective message fanout (Srivastava et al., 2018).

5. Industrial and Mobility Applications

MQTT is widely adopted in industrial environments, notably for PLC inter-communication. In an experimental plant setup, Siemens IoT2020 gateways act as MQTT clients, interfacing with S7-300 PLCs via Modbus RTU and transporting state flags as string-encoded payloads. Only standard TCP (no TLS) is used; QoS 0 (no guarantee) is deemed sufficient for notification-level signaling. The default maximum inflight message limit and clean session mode are retained, and Sessions are transient (no persistence). Broker topic namespace design follows a “Gateway/Flag” model, segregating sources and register addresses. No centralized authentication, encryption, or retained messages are configured in such a minimal, trusted LAN environment, but these controls are recognized as mandatory for broader, less-trusted deployments (Tyrovolas et al., 2021).

In high-throughput, low-latency automated mobility and robotics, MQTT serves as a ROS bridge, with edge-cloud infrastructure over 5G networks achieving ~86 ms round-trip latency for large lidar payloads under moderate load. Per-topic, per-connection QoS and TLS parameters enable tunable reliability and security. Message serialization is performed directly from ROS topics; performance degrades at high message rates (~10 MB/s over 5G), with round-trip times doubling once network saturation is reached. Broker selection and single vs. multi-master overlays affect resilience and fault-tolerance in large-scale deployment scenarios (Reiher et al., 2022).

6. Implementation Guidance and Performance Metrics

For implementation, it is prudent to:

• Select the minimum necessary QoS level: QoS 0 for “fire and forget,” QoS 1 for essential at-least-once semantics, and QoS 2 only where strict exactly-once delivery is required, as it imposes substantial end-to-end handshake latency and CPU cost (Reiher et al., 2022).
• Exploit broker-side data aggregation/processing (e.g., in MQTT+) to minimize wire traffic and device wakeups, reserving heavy analytic computation for cloud or edge brokers if resource constraints are severe (Giambona et al., 2018).
• Employ stateless JWT-based authentication for client privacy and lightweight key provisioning on constrained IoT hardware. Clock synchronization is essential in all JWT configurations. TLS mutual authentication remains preferable for static, non-mobile deployments with no time service (Shingala, 2019).

Performance quantification employs basic metrics:

• Throughput (msgs/s): $\text{#msgs received} / \text{measurement period (s)}$
• End-to-end latency (ms): $t_\text{receive} - t_\text{publish}$
• Packet loss rate: $(\text{sent} - \text{received}) / \text{sent}$
• Bandwidth reduction factors under MQTT+ can be up to order $m\cdot(\lambda/\lambda_\text{A})$ for $m$ publishers, send rate $\lambda$, and aggregate publication rate $\lambda_\text{A}$ (Giambona et al., 2018).
• For geolocation-enabled (MQTTg) Android clients, data integrity of geographic coordinates is verifiable with sub-meter accuracy over commodity networks (Fisher et al., 2019).

7. Limitations, Trade-offs, and Future Directions

MQTT’s extreme simplicity and flexibility entail trade-offs:

• Absence of native access authorization or encrypted transport in baseline protocol—compensated in practice via TLS and broker-level ACLs or authentication plug-ins (Shingala, 2019, Tyrovolas et al., 2021).
• Default QoS 0 approach may lose messages under heavy network load; higher QoS levels incur added handshake and replay overhead (Tyrovolas et al., 2021, Reiher et al., 2022).
• Large-scale analytics, stateful or aggregate operations, and advanced authorization require substantial broker-side extensions or tightly integrated cloud services (e.g., MQTT+, custom plugins).
• Novel protocol enhancements (e.g., MQTTg, rule-based filtering, composite topic operators) require custom broker and client implementations. Backward compatibility is maintained, but only clients aware of the extended semantics can leverage them (Srivastava et al., 2018, Fisher et al., 2019, Giambona et al., 2018).

Future work includes expanding formal benchmarking for performance and energy under security-enhanced deployments, standardization of geolocation and analytic extensions, and integration with emerging edge/6G infrastructures for ultra-low-latency, high-reliability scenarios (Srivastava et al., 2018, Reiher et al., 2022). Interoperability with alternate industrial protocols (e.g., OPC UA) remains an ongoing research theme (Tyrovolas et al., 2021).