MQTT-SN is a variant of MQTT designed for sensor networks where TCP is too heavy or simply not available. In this article you will learn how MQTT-SN differs from regular MQTT, what topic IDs, gateways and sleeping clients are, and how to forward MQTT-SN devices into a standard broker so the rest of your stack never needs to know they exist.
What Is MQTT-SN?
MQTT-SN stands for MQTT for Sensor Networks. It was originally published by IBM researchers in the late 2000s (first as MQTT-S) to bring publish/subscribe to wireless sensor networks such as Zigbee, where nodes have tiny radios, tiny batteries and no TCP/IP stack. The widely implemented version is MQTT-SN 1.2; OASIS has since worked on a standardized successor.
The design goal is simple: keep the MQTT programming model (topics, publish, subscribe, QoS) but strip out everything that is expensive on a constrained link. MQTT-SN does not require a connection-oriented transport. It works over UDP, and over non-IP datagram networks such as Zigbee or BLE-based mesh layers, as long as the network can deliver addressed datagrams.
The important consequence: an MQTT-SN client cannot talk to a normal MQTT broker directly. It needs a gateway that speaks MQTT-SN on one side and MQTT over TCP on the other.
MQTT-SN vs. MQTT at a Glance
| Feature | MQTT (3.1.1 / 5.0) | MQTT-SN 1.2 |
|---|---|---|
| Transport | TCP, TLS, WebSocket | UDP or other datagram networks |
| Topic in PUBLISH | Full UTF-8 string | 2-byte topic ID or 2-char short name |
| Gateway discovery | Not applicable | ADVERTISE, SEARCHGW, GWINFO |
| Sleeping clients | Not built in | ASLEEP and AWAKE states with buffering |
| QoS levels | 0, 1, 2 | 0, 1, 2 and QoS -1 (publish without connecting) |
| Will message setup | Inside CONNECT | Separate WILLTOPIC and WILLMSG exchanges |
| Security | TLS and authentication | Left to the network layer or DTLS |
Topic IDs: Saving Bytes on Every Publish
A topic like factory/izmir/hall2/line4/temperature costs dozens of bytes in every PUBLISH packet. On a link where a whole frame might carry around a hundred bytes, that is unacceptable. MQTT-SN replaces the string with a two-byte number.
There are three ways to get one:
- Registered topic IDs. The client sends
REGISTERwith the full topic name; the gateway replies withREGACKcontaining an ID. The client then publishes with that ID. Mappings live for the duration of the session. - Predefined topic IDs. Client and gateway agree on IDs in advance through configuration, so no registration is needed. This is the most efficient option for fixed firmware.
- Short topic names. Exactly two characters, such as
t1, carried directly in the ID field.
When a client subscribes with a full topic name, the gateway returns the ID it will use when forwarding matching messages. Wildcard subscriptions are supported, but the gateway then has to register each concrete topic with the client before delivering it, which adds round trips.
Gateways and Forwarders
The gateway is the heart of every MQTT-SN deployment. The specification describes two styles:
- Transparent gateway. For every MQTT-SN client, the gateway opens a separate MQTT connection to the broker. Simple and faithful to per-client semantics, but the broker sees as many connections as you have sensors.
- Aggregating gateway. The gateway keeps one MQTT connection to the broker and multiplexes all sensor traffic over it. Fewer broker connections, more logic in the gateway.
A forwarder is an even simpler node that just wraps MQTT-SN messages and relays them between clients and a gateway without understanding them, useful when clients are several radio hops away.
Gateways announce themselves with periodic ADVERTISE messages. A client that has not heard one can broadcast SEARCHGW, and gateways (or other clients that know a gateway) answer with GWINFO.
Sleeping Clients
Battery-powered sensors spend most of their life with the radio off. MQTT-SN models this explicitly:
- The client sends
DISCONNECTwith a sleep duration and enters the asleep state. - While it sleeps, the gateway buffers messages addressed to it.
- The client wakes, sends
PINGREQwith its client ID, receives any buffered messages, and getsPINGRESPwhen the buffer is empty. - It goes back to sleep.
Plain MQTT has nothing equivalent: a device that drops its TCP connection is simply offline, and only persistent sessions on the broker can hold messages for it.
QoS -1: Publish Without a Connection
MQTT-SN adds a level sometimes written as QoS -1 (or QoS 3 in later drafts). A client can send a PUBLISH to a known gateway address using a predefined topic ID or short name without ever connecting. There is no acknowledgement and no session. It is ideal for very simple beacons that just shout a value every few minutes.
Forwarding MQTT-SN into a Standard MQTT Broker
Because the gateway converts MQTT-SN into regular MQTT, the cloud side can be any standards-compliant broker. A common open-source choice is the Eclipse Paho MQTT-SN Gateway (from the paho.mqtt-sn.embedded-c project), which runs on Linux, listens for MQTT-SN on UDP and connects to an upstream broker.
A configuration that points the gateway at a managed MQTT broker such as ConnectMQ looks roughly like this. Key names come from the gateway's sample gateway.conf; check the README of the version you build, as options change between releases.
# gateway.conf (Paho MQTT-SN Gateway, excerpt)
GatewayID=1
GatewayName=site1-mqttsn-gw
KeepAlive=60
# Upstream MQTT broker (ConnectMQ, TLS)
BrokerName=broker.connectmq.com
BrokerPortNo=1883
BrokerSecurePortNo=8883
LoginID=YOUR_USERNAME
Password=YOUR_PASSWORD
# Use one TLS connection for all sensors
AggregatingGateway=YES
TransparentGateway=NO
# MQTT-SN side: UDP listener for sensors
GatewayPortNo=10000
MulticastIP=225.1.1.1
MulticastPortNo=1883
Two things to watch on ConnectMQ specifically:
- Client IDs are bound to credentials. Each broker credential set comes with its own client ID, so a transparent gateway that opens one upstream connection per sensor needs one credential set per sensor. An aggregating gateway with a single upstream identity is usually the better fit.
- Connection quotas. The free Serverless plan allows up to 25 connections and the paid Serverless plan up to 1,000. Aggregation keeps you well inside those limits even with large sensor fields.
Verify the cloud side
Once the gateway is running, subscribe from a laptop to see sensor data arriving as ordinary MQTT. During a proof of concept you can point the gateway at the public MQTT test broker instead (anonymous, port 1883, unique topic prefix):
mosquitto_sub -h broker.connectmq.com -p 1883 -i mqttsn-check-4d1e \
-t "connectmq/demo/4d1e/#" -v
With production credentials, add -p 8883 --capath /etc/ssl/certs -u YOUR_USERNAME -P YOUR_PASSWORD and the client ID from the portal. Everything downstream (dashboards, Node-RED flows, historians) consumes the data exactly as if the sensors spoke MQTT natively.
When to Choose MQTT-SN (and When Not To)
Use this checklist before committing:
- Is there an IP stack with TCP on the device? If the device has Wi-Fi or cellular with TCP, plain MQTT over TLS is simpler and better supported. The ESP32 MQTT tutorial is a good example.
- Is the radio datagram-only? Zigbee, 6LoWPAN, raw LoRa-style links or custom sub-GHz radios are natural MQTT-SN territory.
- Is battery life the top constraint? Sleeping clients and topic IDs pay off when every transmitted byte costs energy.
- Can you run and secure a gateway? The gateway becomes a critical component. Plan for monitoring, restarts and its upstream credentials.
- What about security? MQTT-SN has no built-in encryption. Rely on link-layer security or DTLS on the sensor side, and TLS on the gateway-to-broker leg.
- Library availability. Client libraries exist for C and embedded platforms, but the ecosystem is far smaller than for MQTT.
For many projects a hybrid is best: constrained nodes speak MQTT-SN to a local gateway, while everything else, including the gateway's upstream link, speaks standard MQTT. If you are still learning the base protocol, start with the MQTT tutorial and the explanation of whether MQTT uses TCP or UDP.
Common MQTT-SN Pitfalls
- Topic ID drift. Registered IDs are per session. After a gateway restart, clients must re-register or they will publish to the wrong topic. Predefined IDs avoid this but must be kept in sync between firmware and gateway config.
- UDP packet loss. QoS 0 over UDP really can lose data. Use QoS 1 for anything that matters and size retry timers for your radio.
- Fragmentation. Keep payloads small; MQTT-SN messages are meant to fit in a single network frame.
- Gateway as single point of failure. If the gateway goes down, sensors buffer nothing. Design for a quick restart and alerting.
Bring Your Sensor Network to ConnectMQ
The gateway is yours; the broker does not have to be. ConnectMQ gives your MQTT-SN gateway a TLS endpoint on 8883, MQTT 3.1.1 and 5.0 support, and a live topic explorer to confirm data is flowing. Create a free Serverless broker at app.connectmq.com with no credit card, copy the generated credentials into your gateway config, and your sensors are in the cloud.
Frequently Asked Questions
Can an MQTT-SN client connect directly to an MQTT broker?
Not to a standard one. MQTT-SN uses a different packet format and transport, so a gateway must translate it into MQTT over TCP for the broker.
Does MQTT-SN support QoS 2?
Yes. MQTT-SN 1.2 supports QoS 0, 1 and 2, plus the connectionless QoS -1 mode for simple publishers.
Is MQTT-SN secure?
The protocol itself has no encryption. Use link-layer security or DTLS between sensors and the gateway, and TLS between the gateway and the broker.
What port does MQTT-SN use?
There is no single registered port; it depends on the gateway configuration. Many examples use a UDP port such as 10000 or reuse 1883 over UDP.
