MQTT (Message Queuing Telemetry Transport) has established itself as the de facto standard in the Industrial IoT in recent years. In modern production environments, MQTT often forms the backbone of a Unified Namespace (UNS). The UNS defines a standardized data space that serves as a single source of truth for all real-time information in a factory. This article provides an overview of the development of MQTT and highlights its key features. The article also highlights the benefits with a focus on the unified namespace in the manufacturing industry.
MQTT: From IBM to the standard in Industrial IoT
MQTT (Message Queuing Telemetry Transport) was developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (then at Arcom). Originally designed for oil pipelines and satellite communication, the protocol was aimed at use in particularly low-bandwidth and unstable networks. The name is a historical relic: “Message Queuing” refers to the IBM MQ infrastructure used at the time – not to the actual capabilities of the protocol. From the very beginning, the focus was on the lightweight and reliable transport of telemetry data.
In 2010, IBM published MQTT 3.1 as an open standard in order to promote its dissemination. In 2013, MQTT was handed over to the OASIS consortium and ratified as an official OASIS standard (version 3.1.1) in 2014. Today, MQTT is an open OASIS and ISO standard (ISO/IEC 20922). Thanks to its efficiency and simplicity, it has quickly established itself as the preferred protocol in the IoT and especially in the Industrial IoT. Many IoT platforms – from cloud services to SCADA systems – support MQTT, further cementing its position as an industry standard.
How does MQTT work?
MQTT follows the publish/subscribe principle with a central intermediary – the so-called broker. All participating systems act as MQTT clients and connect to this broker. A client can publish messages on a specific topic or subscribe to topics in order to receive corresponding messages. The broker takes over the routing: it automatically distributes incoming messages to all clients that have subscribed to the respective topic. This architecture means that the sender and receiver are completely decoupled. The data producer does not need to know the number, identity or location of the recipients. Likewise, receiving systems do not need any information about the source of the data.
This loose coupling principle creates high flexibility, scalability and ease of maintenance – especially in the context of distributed industrial systems. The data is organized in a hierarchical topic structure (topic namespace), which is similar to the structure of a file system (e.g. Fabrik1/Halle3/Linie2/OfenX/Temperatur). This makes it possible to arrange information logically according to the organizational structure. Recipients can subscribe to entire sub-trees via so-called wildcards in order to receive specific information from certain areas.
The Most Important Properties
MQTT offers a number of features that make it particularly attractive for IoT and industrial applications, including
1. Lightweight and Efficient
The protocol was developed for environments with low bandwidth and high latencies. The message headers are extremely small and communication takes place in compact binary formats. MQTT therefore causes only minimal overhead. This means that MQTT can be operated on simple microcontrollers. In addition, MQTT is robust and reliable in data transmission even under difficult conditions – for example via mobile or satellite connections.
2. Decoupled and Highly Scalable
The central role of the broker means that the sender and receiver are completely decoupled. New devices or applications can be integrated into the communication at any time without having to adapt existing systems. They simply publish or subscribe to the topics relevant to them. This loose coupling considerably simplifies the integration of heterogeneous systems and supports an agile, modular system architecture. At the same time, MQTT is extremely scalable: a single broker can coordinate the exchange of messages for thousands to millions of clients.
3. Reliable Transmission
MQTT was specially designed for use in unstable or latency-prone networks. Three defined quality of service levels (QoS 0, 1 and 2) can be used to control the delivery reliability of each message – from “at most once” to “exactly once”. Depending on the application, a suitable compromise between latency, network load and delivery reliability can be selected.
4. Event-Driven (Push Instead of Polling)
MQTT is based on the “report by exception” principle – instead of requesting data cyclically (polling), it is only sent when a status changes or a relevant event occurs. This event-driven push communication minimizes unnecessary data traffic and reduces the load on networks and end devices. At the same time, it ensures that all subscribers are always provided with the latest information – without the latency of traditional polling cycles.
5. Open Standard
MQTT is an open OASIS standard. It is freely available and is supported by a large community and all major cloud platforms. There are numerous implementations and client libraries for almost all programming languages. This allows companies to set up manufacturer-independent IoT infrastructures in which all participants speak the same language. Another reason why many companies rely on MQTT.
What is the Unified Namespace (UNS)?
A paradigm shift is taking place in industrial automation: away from rigid, hierarchical communication structures towards event-driven, real-time capable data networks. A unified namespace (UNS) serves as a central, context-related data platform that standardizes all of a company’s real-time information across all levels (from OT to IT). It acts as a source of information for all production data, replacing individual point-to-point connections with a central message broker.
All IT and OT systems publish their data centrally in the Message Broker and only subscribe to the information relevant to them. This eliminates the need for dedicated point-to-point connections between individual systems and significantly reduces the number of integrations required. IT applications such as BI tools, MES or cloud services can access production data in real time without having to interact directly with PLC protocols. Conversely, control commands from higher-level systems can be transmitted to machines and control systems on this basis. Find out more about the basic principles of the Unified Namespace (UNS) here.
MQTT in the Unified Namespace (UNS)
In order to technically fulfill the role of a central data platform in the factory, a messaging system must meet a number of specific requirements. MQTT has precisely the properties required for this – systematically broken down below.
1. Low Latency: Make Events Available in Real Time
Industrial use cases such as condition monitoring, predictive maintenance or process-related control logic require latencies in the range of a few milliseconds. MQTT is designed for the transmission of messages with minimal overhead:
- The protocol structure is binary and extremely lean (fixed header: 2 bytes)
- The connection remains permanently open (TCP + optional TLS),
- Message transmission is event-driven (push) without polling.
This means that MQTT in the Unified Namespace (UNS) enables very low end-to-end latency – typically in the single-digit millisecond range for local infrastructure.
2. High Availability: Redundancy at System Level
Production systems require a highly available messaging infrastructure. MQTT fulfills this requirement by:
- Broker clustering: Modern MQTT brokers support horizontal scaling across multiple nodes.
- Persistent Sessions & Message Retention: Messages and statuses are stored in the broker and transferred as soon as the recipient is online again.
- Last-will mechanism: In the event of unexpected disconnections, the broker can automatically distribute status changes – e.g. set machine status to “offline”.
These functions allow MQTT to be integrated into highly available, fault-tolerant UNS architectures, even via replication across multiple locations if required.
3. Quality of Service: Delivery Guarantee Depending on Use Case
A UNS must support both high-frequency telemetry data transmission and critical transactions. MQTT offers three clearly defined quality of service levels for this:
- QoS 0 – At most once: Unsecured, latency-optimized communication, e.g. for live telemetry.
- QoS 1 – At least once: Messages are sent until an acknowledgement of receipt is received. Ideal for general operating data.
- QoS 2 – Exactly once: Delivery exactly once – for transactions, control data or MES connections.
In addition, MQTT supports delivery mechanisms that ensure that messages are retained even in the event of network interruptions. This allows the desired reliability to be defined granularly per topic or message type. Further details on QoS can be found here.
4. Edge/Cloud Scalability: Distributed Architecture with Consistency
A modern US is not monolithic, but hierarchically structured and geographically distributed. MQTT is ideally suited for such architectures:
- Edge deployability: MQTT clients only require minimal resources. Even small gateways or PLC-related devices can act as MQTT publishers.
- Cloud and cluster capability: MQTT brokers scale horizontally, can run in Kubernetes environments and serve globally distributed clients.
- Namespace structuring: The hierarchical MQTT topics enable logically delimited data spaces (e.g. per plant, line or machine). Entire subsystems can be selectively subscribed to or forwarded using wildcards.
This allows local UNS instances per location to be logically and technically integrated with a central, company-wide namespace – with a consistent semantic structure.
5. Additional Properties
There are numerous other properties that make MQTT particularly predestined for the Unified Namespace (UNS):
- Retained messages: MQTT allows the last known value of a topic to be stored in the broker – essential for a state-based UNS.
- Push communication (publish/subscribe): Instead of cyclical queries, data distribution is event-based, which reduces latency and conserves resources.
- Security: MQTT offers TLS encryption, authentication and ACLs for role-based access – industry-standard and compliant.
MQTT 3.1.1 vs. MQTT 5 in the Unified Namespace (UNS)
While MQTT 3.1.1 is widely used in the industry and fulfills the requirements of a UNS, MQTT 5 brings some interesting technical enhancements. These are particularly relevant for complex and dynamic UNS architectures.
1. User-Defined Properties (User Properties)
MQTT 5 allows any key-value pairs to be attached to each message. These “user properties” allow additional semantic information (e.g. units, limit values, source metadata) to be transported directly via the payload – without changing the payload format. In the UNS, context information can thus be passed on in a machine-readable and standardized manner.
Example: A sensor publishes a temperature value on the topic: factory1/hall3/line2/ovenX/temperature. The payload only contains the pure measured value. Additional context information – such as unit, threshold value or location – is not encoded in the payload, but is sent as structured metadata via MQTT 5 User Properties. These are located in the header of the MQTT message, more precisely in the properties area of the publish packet.
2. Reason Codes & Negative Acknowledgements
In contrast to MQTT 3.1.1, MQTT 5 allows granular feedback in the event of failed connection or publishing attempts – with a specific error code. This facilitates error diagnosis and enables robust operational monitoring in the UNS, especially in complex production networks with changing topologies.
Example: An edge gateway attempts to send sensor data to the broker. The broker rejects the message due to a lack of authorization. Unlike MQTT 3.1.1, MQTT 5 now provides an explicit response with reason code in the PUBACK or CONNACK packet.
3. Topic Aliases
To save bandwidth for frequently recurring topics – for example in high-frequency sensor data transmission – MQTT 5 supports the definition of topic aliases. The actual topic string only needs to be transmitted once, after which an alias index (e.g. Topic Alias: 5412) is sufficient. In large and complex UNS structures, this can significantly reduce latency and CPU load.
4. Improved Session and Message Control
MQTT 5 offers extended control options for resource-limited clients with a low interaction frequency. These can be devices that only send or receive data occasionally. Important parameters are:
- Session Expiry Interval: Determines how long a client session is retained on the broker after the connection is terminated (including subscriptions and unassigned QoS messages).
- Message Expiry Interval: Specifies how long a message remains stored in the broker if the recipient is not currently connected – it is then discarded to avoid outdated data.
- Maximum Packet Size: Defines the maximum size of MQTT messages that a client or broker accepts – useful for limiting load and resource consumption on low-performance devices.
5. Request-Response Semantics
With the optional response topic field, MQTT 5 supports structured request/response communication, which is helpful for diagnostic processes or commands between IT and OT systems within the UNS, for example. This means that MQTT can be used in the Unified Namespace (UNS) not only for event streaming, but also for transaction-type communication.
Example: An IT system (e.g. a maintenance tool) wants to query the current status of a specific drive on the store floor. To do this, it publishes a message on a defined request topic. The drive (or its controller or gateway) is configured to subscribe to this topic and generate a response when a request is received. The response is published back. The IT system can clearly assign the response to the original request using the correlation data.
6 Subscription Identifier and Shared Subscriptions
Subscriptions can be systematically managed and evaluated using unique subscription IDs. Shared subscriptions enable load balancing among several subscribers, which is a decisive scaling factor for distributed data processing (e.g. microservices).
Summary
| Criterion | MQTT 3.1.1 | MQTT 5.0 |
|---|---|---|
| Standardization | OASIS standard (2014), widely used | OASIS standard (2019), backwards compatible with 3.1.1 |
| Topic structuring | Fully supported (hierarchical, wildcards) | Identical to 3.1.1 |
| Quality of Service (QoS) | 0, 1, 2 | 0, 1, 2 |
| Retained Messages | Supported | Supported |
| Session management | Simple (Clean Session / Persistent Session) | Advanced parameters (Session Expiry, Message Expiry, Max Packet Size) |
| Metadata (user properties) | Not supported | User-defined key-value pairs per message |
| Error feedback (reason codes) | Only connection errors with generic reason | Detailed reason codes for all MQTT actions |
| Request-response support | Must be realized via topic convention | Native via response topic and correlation data |
| Topic Aliases | Not available | Reduced overhead for long/redundant topic names |
| Subscription Identifiers | Not available | Clear differentiation of parallel subscriptions |
| Shared subscriptions | Not specified | Native load balancing across multiple subscribers |
| Diagnostics & fault tolerance | Limited (only basic feedback) | Comprehensive control through reason codes, disconnect packages etc. |
| Suitability for distributed UNS architecture | Basic capability | Optimized for scalable, dynamic UNS structures |
Conclusion
MQTT is now an established standard in the Unified Namespace (UNS) – lightweight, robust and highly scalable. MQTT 3.1.1 already supports central principles such as decoupling, push-based communication and hierarchical topic structures. MQTT 5 builds on this and specifically extends the protocol with functions for complex and very dynamic systems: for example, semantically enriched messages, detailed session management, structured error feedback and native load distribution via shared subscriptions.
