Low-Bandwidth MQTT Sparkplug B Telemetry over Cat-M1 and NB-IoT Networks
Definition: Sparkplug B is an Eclipse Foundation specification that defines MQTT topic structure, Protocol Buffers payloads and session state for industrial telemetry, so SCADA and edge devices from different vendors can exchange data consistently.
Sparkplug B works over Cat-M1 and NB-IoT, but the data plan is rarely consumed by the measurements themselves. It goes on TLS handshakes, birth certificates and reconnects. A gateway that reports a few values by exception can stay very lean, while the same gateway on a weak NB-IoT cell that reconnects every hour can burn through several times its expected budget republishing its full metric list. Budget for sessions, not just samples.
How Sparkplug uses MQTT
Sparkplug sits on top of a standard MQTT broker. Version 3.0, released by the Eclipse Sparkplug Working Group in 2022, works with MQTT 3.1.1 and MQTT 5.0. It adds three things that plain MQTT leaves open.
A fixed topic namespace. Topics follow the pattern spBv1.0/group_id/message_type/edge_node_id/device_id, so a host application knows where every message came from without custom mapping.
State awareness. When an edge node connects, it publishes an NBIRTH message listing all its metrics, and DBIRTH messages for each attached device. It registers an NDEATH message as its MQTT Will, which the broker publishes if the connection is lost. A bdSeq number ties each birth to the matching death, and a sequence number on every message lets the host spot gaps and request a rebirth.
Compact payloads. Payloads in Sparkplug B are encoded with Google Protocol Buffers. Metrics can be given numeric aliases in the birth message, and later NDATA and DDATA messages carry only the alias, value and timestamp instead of a full metric name.
Where the bytes go on a low-bandwidth link
Cat-M1 and NB-IoT were introduced in 3GPP Release 13 for low-power devices. LTE-M (Cat-M1) offers higher throughput and better mobility; NB-IoT trades speed for coverage depth and power, and its latency can run to seconds. On both, every extra round trip and kilobyte matters. This is the budget to build before choosing a plan:
| Traffic item | What drives its size | How to reduce it | What to measure in the pilot |
|---|---|---|---|
| TLS handshake | Certificate chain length and cipher negotiation, repeated on every new TCP connection | Short certificate chains, session resumption, fewer reconnects | Bytes per full handshake versus resumed handshake |
| MQTT CONNECT with NDEATH Will | Client ID, credentials and Will payload | Keep identifiers short | Size per connection |
| NBIRTH and DBIRTH | Number of metrics, metric names, properties and metadata | Trim metadata, publish only metrics the host needs, use aliases | Birth size per node and per device |
| NDATA and DDATA | Change rate and deadbands, timestamp and alias overhead | Report by exception with sensible deadbands; batch where latency allows | Messages per day and average size |
| Keep-alive | MQTT PINGREQ/PINGRESP plus TCP/IP and TLS framing | Longest keep-alive the operator network tolerates | Idle timeout of the operator path |
| Rebirths | Sequence gaps, host restarts, reconnects | Stable sessions; avoid unnecessary host-side rebirth requests | Rebirths per device per week |
Real numbers depend on your tag list, firmware and network, so treat the table as a measurement plan. A one-week pilot with traffic counters on the router or module usually tells you more than any spreadsheet estimate.
Session behavior: the part that surprises teams
Keep-alive versus operator idle timeouts
MQTT keeps a TCP session open. Carrier-grade NAT and firewalls in mobile networks drop idle connections after a timeout that varies by operator. If your keep-alive interval is longer than that timeout, the connection dies silently, the broker eventually publishes NDEATH, and the gateway reconnects with a full TLS handshake and a fresh set of births. Under MQTT, the broker treats a client as gone after one and a half keep-alive periods without traffic. Find the idle timeout for your path during testing; a private APN can sometimes give you more control over it.
Power saving and always-on sessions
PSM and eDRX save battery by making the device unreachable for long periods. That conflicts with a permanently connected MQTT client. Mains-powered gateways usually stay connected and accept the keep-alive cost. Battery devices that must sleep are often better served by a different pattern, such as connecting on a schedule, publishing and disconnecting cleanly, with the host application designed to expect that rhythm.
Reconnect storms
When a cell or broker recovers, hundreds of gateways can reconnect at once and each sends its births. Add randomized reconnect delays in the gateway configuration, and size the broker and the data plan for that event, not only for steady state.
When Sparkplug nodes run on batteries, every reconnect costs energy as well as bytes; battery-powered IoT sensors: power budgets and LPWAN choice works through power budgets, PSM and eDRX timers and retry limits for such devices.
Cat-M1 or NB-IoT for Sparkplug?
For gateways with many tags, frequent changes or any mobility, Cat-M1 is usually the safer choice because birth messages and reconnects complete faster. NB-IoT can suit fixed sites with small tag lists and slow-changing values, especially where its deeper coverage is the deciding factor. Check that the module, the operator network and the roaming agreements in each country support the technology you choose; LTE-M and NB-IoT availability is not uniform, and fallback to LTE or 2G behaves differently by module.
For sites that cannot lose telemetry, consider a multi-network SIM or a dual-SIM router so the gateway has a failover path if one operator’s LPWA layer is unavailable. Sparkplug’s death and birth messages will make any switchover visible to the host, which is useful for diagnosing coverage problems.
How this maps to Quanqiu IoT
Our guide to MQTT Sparkplug gateways and unified namespace projects covers architecture choices, and Modbus telemetry for low-bandwidth remote sites covers the polling side that often feeds a Sparkplug edge node. For hardware selection, see IoT SIM for industrial routers, RTUs and DTUs and the remote telemetry SIM page.
For a small pilot, catalog pricing is usually enough: choose a Global IoT SIM plan with headroom and measure real usage. Once you know bytes per gateway per month, the device count and the countries involved, the procurement decision becomes a pooled plan or a project quote. Buyers should confirm LTE-M or NB-IoT support per country: a coverage map does not guarantee that a roaming IoT SIM is allowed onto an operator’s LPWA layer, which depends on roaming agreements and operator authorization. When you have pilot data, request a project quote with those figures and we will check network technology support and plan sizing with you.
FAQ
How much data does a Sparkplug B gateway use per month?
It depends on tag count, change rate, keep-alive interval and how often the session reconnects. Measure it during a pilot before the wider rollout; reconnects and birth messages often matter more than the telemetry itself.
Can Sparkplug B run over NB-IoT?
Yes, if the module supports TCP and TLS reliably on the operator network and the tag list is small. High latency and lower throughput make large birth messages slow, so keep the metric set lean and test reconnect behavior.
Should we use MQTT 3.1.1 or MQTT 5.0 with Sparkplug 3.0?
Sparkplug 3.0 supports both. Choose the version your broker, edge software and host application all support; mixed environments are common, so confirm integration in the lab before field deployment.
What happens to data when the cellular link drops?
The broker publishes the node’s NDEATH so the host marks its data stale. Whether readings collected during the outage are kept depends on the edge software’s store-and-forward feature, which is outside the core Sparkplug messaging rules.
Does a private APN help with MQTT over cellular?
It can. A private APN keeps broker traffic off the public internet and can give more predictable addressing and idle timeouts, but it adds setup and cost. It is usually worth it for larger fleets with a central broker.