MQTT (Message Queuing Telemetry Transport)

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish/subscribe messaging protocol designed for constrained devices and low-bandwidth, high-latency, or unreliable networks. It was originally created by Andy Stanford-Clark of IBM and Arlen Nipper of Cirrus Link in 1999 to monitor oil pipelines over satellite links. IBM published it as an open standard, and it is now maintained by OASIS as an official open standard.

MQTT has become the dominant messaging protocol for IoT systems. Its combination of minimal overhead (a 2-byte fixed header), guaranteed delivery options, and broker-based decoupling makes it well suited to RFID and sensor networks where readers must stream tag events to multiple downstream consumers reliably.

How it works

MQTT uses a broker-based publish/subscribe model. Devices do not communicate directly with each other; instead, every message is routed through a central broker:

• Publishers connect to the broker and send messages to a named topic (e.g. site/dock-1/reader/antenna-2/tag-read). Publishers have no knowledge of who, if anyone, is receiving the messages.
• Subscribers connect to the broker and declare interest in one or more topics using exact names or wildcards. The broker forwards every matching message to all active subscribers.
• Broker is the hub that accepts all connections, routes messages by topic, enforces QoS, stores retained messages, and handles last-will notifications. Common brokers include Eclipse Mosquitto, HiveMQ, EMQX, and AWS IoT Core.
• Topics are UTF-8 strings with a slash-delimited hierarchy. The single-level wildcard + matches one segment; the multi-level wildcard # matches all remaining segments. A subscriber to site/+/reader/# receives messages from any reader at any dock on that site.
• Retained messages: A publisher can flag a message as retained. The broker stores the last retained message for a topic and immediately delivers it to any new subscriber. Useful for publishing the current state of a reader so late-connecting clients do not have to wait for the next update.
• Last Will and Testament (LWT): A client registers a will message at connect time. If the client disconnects unexpectedly (without sending a clean DISCONNECT), the broker publishes the will message on the client's behalf. RFID deployments use LWT to notify downstream systems when a reader goes offline.

QoS levels

MQTT defines three Quality of Service levels that govern the delivery guarantee between a publisher and the broker, and separately between the broker and each subscriber:

When a publisher and subscriber use different QoS levels, the broker delivers at the lower of the two levels. A QoS 2 publication to a QoS 0 subscriber is delivered at QoS 0.

MQTT versions

Two versions of MQTT are in active use. Most brokers and clients support both.

• MQTT 3.1.1 (2014): The version that drove mainstream IoT adoption. Widely supported across all major brokers, embedded SDKs, and cloud platforms. The baseline assumption for any MQTT deployment today.
• MQTT 5.0 (2019): A significant update that adds several capabilities important for enterprise RFID deployments:
  • Message expiry: Publishers can set a TTL on messages so stale tag reads are discarded rather than delivered to late-joining subscribers.
  • Reason codes: All acknowledgements carry a reason code, enabling precise error reporting (e.g. quota exceeded, topic alias invalid).
  • User properties: Arbitrary key/value metadata on every message - useful for attaching reader ID, antenna number, or RSSI without embedding them in the payload.
  • Shared subscriptions: Multiple subscribers share a single subscription for load balancing. Tag reads are distributed across a consumer pool rather than broadcast to all.
  • Topic aliases: Long topic strings can be replaced with a short integer alias after the first use, reducing per-message overhead on high-frequency read streams.
  • Request/response pattern: Correlation data and response topic fields enable a basic request/response interaction over MQTT, which is absent from 3.1.1.

MQTT in RFID and IoT

RFID readers generate continuous streams of tag read events. MQTT is a natural fit for transporting these events from the edge to backend systems:

• Reader event streaming: Fixed RFID readers (UHF dock doors, conveyor tunnels) publish each tag observation - EPC, RSSI, antenna port, timestamp - as a small JSON or binary payload to a topic representing that reader location. Backend services subscribe and react in near real time.
• Impinj readers: Impinj Speedway and xArray readers support MQTT natively through the ItemSense platform and via the LLRP -to-MQTT bridge pattern. The Impinj IoT Device Interface (IDI) publishes tag events over MQTT, enabling direct cloud integration without a middleware layer.
• Zebra readers: Zebra FX-series fixed readers support MQTT output, publishing tag reads to a configurable broker address and topic. This is a standard feature in Zebra's reader management firmware and is often used in warehouse deployments alongside Zebra's Savanna IoT cloud.
• Edge-to-cloud architecture: A local Mosquitto broker aggregates reads from multiple readers on a site. An edge service filters, de-duplicates, and enriches events before forwarding them to a cloud broker (AWS IoT Core, HiveMQ Cloud, Azure IoT Hub via MQTT). This pattern limits cloud ingestion costs and provides resilience if the WAN link is temporarily lost - the local broker queues events and delivers them when connectivity is restored.
• Sensor fusion: RFID readers often co-locate with environmental sensors (temperature, humidity, motion). MQTT's topic hierarchy lets a single broker handle both tag read events and sensor telemetry under a unified namespace, simplifying the backend.

Advantages

• Lightweight: The minimum fixed header is 2 bytes. MQTT imposes far less per-message overhead than HTTP or AMQP , making it practical on low-power embedded readers.
• Low bandwidth: Small packet sizes and persistent TCP connections (no HTTP handshake per message) make MQTT efficient on cellular or satellite uplinks.
• Reliable delivery: QoS 1 and QoS 2 guarantee that tag events are not silently dropped, even on unreliable networks.
• Decoupled architecture: Publishers and subscribers have no direct dependency on each other. A backend service can be restarted, upgraded, or scaled out without affecting readers.
• Persistent sessions: A subscriber can connect with a persistent session so the broker queues messages published while it was offline, preventing data loss during maintenance windows.
• Widespread broker support: Eclipse Mosquitto (open source, embeddable), HiveMQ (enterprise), EMQX (high throughput), AWS IoT Core, Azure IoT Hub, and Google Cloud IoT Core all support MQTT natively.
• TLS security: MQTT runs over TLS 1.2/1.3 for transport encryption, with username/password or client certificate authentication.

Limitations

• Broker is a single point of failure: All communication depends on the broker. A clustered broker (HiveMQ, EMQX) or managed cloud service is required for high-availability deployments. A standalone Mosquitto instance with no HA is a common deployment risk.
• No native request/response (MQTT 3.1.1): MQTT 3.1.1 is strictly pub/sub. Sending a command to a reader and receiving a reply requires convention - typically a separate reply topic per client. MQTT 5.0 adds correlation data to address this, but requires both sides to support 5.0.
• Topic-based routing only: Routing is by topic string. There is no content-based routing, filtering by message header, or query capability. Complex routing logic must be implemented in application code.
• No message ordering guarantees across topics: Messages on a single topic are delivered in order to a given subscriber, but there is no ordering guarantee across different topics or across multiple subscribers.
• Limited message size guidance: The protocol supports up to 256 MB payloads, but brokers and clients often impose lower limits. Large payloads (e.g. bulk inventory snapshots) are better served by chunking or using a different transport.
• Security model is basic: The built-in security model (username/password, TLS) is sufficient for most deployments but lacks fine-grained per-topic ACLs in the base protocol. Brokers implement ACLs as extensions, with varying syntax and capability.

Common applications in RFID

• Dock-door read events: Each portal reader publishes tag reads to a topic like warehouse/dock/3/reads. A backend WMS subscribes and updates inventory in real time as pallets pass through.
• Asset tracking dashboards: Readers publish location updates continuously. A WebSocket -bridged dashboard subscribes via the broker to display live asset positions without polling.
• Reader health monitoring: Readers publish heartbeat and diagnostic messages (antenna status, read rate, temperature) on a dedicated topic. Operations teams subscribe for alerting and dashboards.
• Reader configuration and command: A management system publishes configuration changes or inventory start/stop commands to a reader-specific topic. The reader subscribes to its own command topic and acts on incoming messages.
• Multi-site aggregation: Each site runs a local broker. A central cloud broker subscribes to all site brokers via MQTT bridge, aggregating events from hundreds of readers into a single stream for enterprise analytics.
• Cold chain monitoring: RFID tags with integrated temperature sensors publish readings alongside tag EPC. A single MQTT stream carries both identity and environmental data to a food safety compliance backend.

MQTT vs AMQP vs HTTP

Related