RFID with MQTT and IoT Protocols

RFID with MQTT and IoT Protocols

MQTT is the de facto standard protocol for connecting IoT devices — including RFID readers and edge gateways — to cloud platforms and enterprise backends. This guide covers MQTT fundamentals as applied to RFID, compares it to alternative IoT protocols, and provides concrete topic-design and integration patterns.

Why MQTT for RFID

RFID readers generate continuous streams of tag read events. The transmission requirements are:

• Low latency — dock-door reads must reach the WMS before the shipment is dispatched
• High throughput — a busy portal reader generates 10,000–100,000 events per hour
• Resilience — network connectivity is intermittent in warehouses and outdoor yards
• Lightweight — edge gateways run on embedded hardware with limited RAM

MQTT satisfies all four requirements. Its binary framing is compact (2-byte fixed header vs. HTTP's multi-kilobyte headers), its QoS levels handle at-least-once delivery without application retransmission logic, and its persistent session feature buffers messages during disconnection.

MQTT Fundamentals for RFID Engineers

Broker-client model:

Reader → Edge Gateway → MQTT Broker → Subscriber (WMS / EPCIS / Analytics)

The broker decouples producers from consumers. Multiple subscribers can receive the same read event without the reader knowing about them — useful when RFID feeds both a WMS (for stock updates) and an analytics platform (for dwell time) simultaneously.

Quality of Service levels:

For most RFID deployments, QoS 1 is appropriate. Duplicate tag reads are handled by deduplication logic in the middleware layer — it is safer to receive a duplicate than to miss a tag read.

Retained messages:

MQTT retained messages deliver the last-known value to new subscribers immediately on subscription. Use retained messages for: - Reader status (online/offline, firmware version) - Last antenna configuration - Zone occupancy (last count per zone)

Do not use retained messages for individual tag read events — this would store the last tag seen at each reader, which is rarely meaningful.

Topic Design for RFID

A well-designed topic hierarchy is essential for scalable RFID deployments. Topics should encode enough hierarchy to enable per-device, per-site, and aggregate subscriptions.

Recommended structure:

rfid/v1/{org}/{site}/{reader_id}/reads      → individual tag reads
rfid/v1/{org}/{site}/{reader_id}/status     → reader health metrics
rfid/v1/{org}/{site}/{reader_id}/config     → configuration (retained)
rfid/v1/{org}/{site}/aggregate             → site-level aggregated events
rfid/v1/{org}/epcis                        → formatted EPCIS events
rfid/v1/{org}/alerts                       → threshold alerts (read-rate drop)

Payload schema (JSON — tag read):

{
  "reader_id": "dock-01-reader",
  "antenna": 2,
  "epc": "3014567890123456789012AB",
  "rssi": -62,
  "timestamp_utc": "2025-06-15T14:23:11.452Z",
  "read_count": 1,
  "tid": "E2003412012345678901234567890123"
}

Fields: reader_id maps to a physical location; antenna distinguishes portal left from right; rssi enables signal-strength-based zone estimation; tid enables TID-based anti-clone verification at the backend.

MQTT vs. Alternative IoT Protocols

LLRP to MQTT bridge is the most common integration pattern: the RFID edge gateway runs an LLRP client (connected to the reader) and an MQTT publisher (connected to the broker). Commercial gateways from Impinj (ItemSense legacy), Zebra (SmartLens), and Convergence Systems include this bridge built-in. Open-source options include llrp4j and custom Python using the sllurp library.

MQTT 5 Features Valuable for RFID

MQTT 5 (released 2019) adds features particularly useful for high-volume RFID:

• Message Expiry Interval — discard tag reads older than N seconds from the queue (prevents stale inventory events from processing after connectivity recovery)
• Shared Subscriptions — multiple WMS instances can share a subscription, load-balancing high-volume read streams
• User Properties — add metadata (site_id, reader_model) to the MQTT header without parsing the JSON payload
• Topic Aliases — reduce bandwidth for high-frequency topics with long names
• Flow Control — prevent fast publishers from overwhelming slow subscribers

For large deployments (100+ readers), MQTT 5 shared subscriptions enable horizontal scaling of the EPCIS processing tier without custom broker-side fan-out logic.

Broker Selection

For edge-local deployments (air-gapped warehouses), Mosquitto or EMQX running on the same hardware as the RFID middleware is common. For cloud connectivity, AWS IoT Core or Azure IoT Hub is the managed option that eliminates broker operations overhead.

Integration with EPCIS

RFID MQTT events are not EPCIS events — they are lower-level tag reads. The translation layer:

1. MQTT subscriber receives raw tag read events
2. Deduplication: suppress re-reads of the same EPC within a time window (typically 2–10 seconds)
3. Business step inference: if EPC seen at dock-door-in reader and not previously seen = arriving event
4. EPCIS event construction: populate What, When, Where, Why, How fields
5. POST to EPCIS repository (REST API per EPCIS 2.0)

See the EPCIS Implementation guide for the complete translation pattern.

Security

• TLS 1.2+ mandatory for all MQTT connections carrying EPC data
• Client certificate authentication for reader gateways (X.509)
• Username/password acceptable only for low-sensitivity internal networks
• Topic ACLs — readers should only publish to their own topic namespace; they should not be able to subscribe to other readers' topics or the aggregate topics
• Avoid publishing raw kill passwords or access passwords over MQTT — use a separate secure channel for tag commissioning commands

See also: RFID Cloud Platform Integration, Edge Computing in RFID, RFID ERP Integration.