Introduction to MQTT-SN (MQTT for Sensor Networks)

Due to the large number of sensors in IOT Sensor networks these sensors will be mainly wireless.

MQTT-SN (MQTT for Sensor networks) was designed specifically to work on wireless networks.

The main characteristics of these networks that drove the design are:

  • Low Power battery operated sensors with very limited processing power and storage.
  • Limited payload size
  • Not always on (sleeping)

MQTT-SN is designed, as far as possible, to work in the same way as MQTT.

It uses the pub/subscribe model and can be considered as a version of MQTT.


The main differences involve reducing the size of the message payload and removing the need for a permanent connection by using UDP as the transport protocol.

The MQTT-SN specification lists these differences.

  1. Connect message split into three messages two are optional and are used for the will message
  2. Topic id’s used in place of topic names.
  3. Short Topic names
  4. Pre-defined topics.
  5. Discovery process to let clients discover the Gateway
  6. Will Topic and messages can be changes during the session
  7. Offline keep alive procedure for sleeping clients.

Architecture and Components

The specification lists three components:

  1. MQTT-SN client
  2. MQTT-SN Gateway
  3. MQTT-SN forwarder.

What seems to be missing is a broker/server as in the MQTT sense.

However the architectural diagram in the specification does appear to show one and the RSMB server does implement one.

The diagram below is taken from the MQTT-SN specification:

MQTT-SN architecture-diagram
Ref: MQTT-SN Specification -pdf
and The question I had was:

When client 1 talks to client 2 does it require the MQTT broker to do so? Specifically is it

MQTT-SN >MQTT-SN -In this case the gateway is also a broker.

or is it

MQTT-SN >MQTT>MQTT-SN -In this case the gateway is only a gateway..

The answer it turned out was it depends on the gateway you use (see later RSMB and the Paho Eclipse Gateway)

GateWay Types

The specification defines two gateway types.

A transparent gateway were each MQTT-SN connection has a corresponding MQTT connection. This is the easiest type to implement.

An aggregating gateway were multiple MQTT-SN connections share a single MQTT connection



MQTT-SN Operation

Although MQTT-SN uses UDP as the transport protocol and not TCP it is designed, as far as possible., to work in the same way as MQTT.

In that regard MQTT-SN usually requires a connection to the broker before it can send and receive messages.

This connection is in effect a virtual connection.

However there is a mode of operation that doesn’t require a connection but this doesn’t work with pure Gateways. (see below).

QOS Levels

MQTT-SN supports QOS 0,1,2 as per MQTT, but it also supports a special publish QOS of 3 or -1.

Note: it is known as QOS -1 but the QOS flag in the message is set to 11 or decimal 3.

Publishing messages with a QOS of -1 or 3 doesn’t require an initial connection to have been set up and requires the use of short topic names or pre-defines topics.

Subscribing to MQTT-SN Topics

You can subscribe to a topics using 3 different formats:

  • A long topic name as per MQTT e.g. house/sensor1
  • A short topic name of 2 characters only e.g. s1
  • A pre-defined topic id (integer) e.g. 1

Wildcards can be used as per MQTT, but they only make sense for long topic names.

Note: Predefined topics are defined on the Gateway and client using a list.

Publishing Messages With an Established Connection

You can publish a message using:

  • A topic ID
  • A short topic name- 2 characters

You can a get a topic ID by either:

  • Subscribing to the long topic name.
  • Registering the Long topic name.
  • Using a pre-defined topic-id

The Subscribe and register functions return a topic ID that you use in place of the long topic name when publishing.

Topic ids are assigned to each client, and they are not broker wide. For example:

A client may subscribe to topic house/bulb1 and get a topic ID of 1.

A second client may subscribe to topic house/bulb2 and get a topic ID of 1.

Topic id 1 for client 2 refers to house/bulb2, and for client1 topic id 1 refers to house/bulb1

Note: When using QOS of 1 or 2 you need to wait for a PUBACK message before you publish a new message.

So the format is

  1. PUB
  2. Wait PUBACK
  3. PUB
  4. etc

In MQTT_SN you can get a PUBACK even to a QOS level 0 message.

This is because it is used to return a error if the publish was rejected.

Publishing Messages Without a Connection

You can publish messages without first creating a connection by using QOS of -1 or 3.

You can publish a message without registering a topic or subscribing to a topic using:

  • A pre configured topic ID
  • A short topic name – 2 characters.

Published messages aren’t acknowledged.

This mode of publish is ideal for simple sensors.

Gateway Discovery

MQTT-SN clients have the ability to discover brokers/gateways.

There are two mechanisms used:

  • Advertising by a broker or Gateway
  • A Search by the client

Both methods use a multicast packet.

Currently there is no standardized multicast packet address.

I did come across a proposal on Github for testing you will have to use a known free multicast address.

How it Works

The broker of gateway advertising on a multicast address.

In the packet is the name of the advertising Gateway the advertising duration and the Gateway number.

The client maintains a list of active gateways and can use the duration to determine if a gateway is still active.

The client must be listening on the multicast address.

Alternatively the client can search for a gateway by sending a search packet on a multicast address.

This can be answered by either another client or a Gateway.

However for some reason the Gateway response doesn’t contain the Gateway address but a response from another client does.

Topic Registration

A client can register a topic with a broker and a broker can also register a topic with a client.

Client Registration

The client registers a long topic name with the broker and the broker returns a topic ID that the client uses to refers to that topic name when it publishes messages.

Broker or Gateway Registration

If a client subscribes to a wildcard topic e.g. house/#

What happens when a broker receives a publish for topic house/bulb2, as the client doesn’t have a topic ID for house/bulb2.

In the case the broker assigns a topic ID and notifies the client using topic registration.

MQTT-SN Brokers and Gateways

To test MQTT-SN you will need a broker. There currently aren’t many NQTT-SN brokers available.

The RSMB broker developed by Ian Craggs of IBM was the first and was the basis for the Mosquitto MQTT broker.

This broker hasn’t been actively developed for many years but I’m hopeful it will be soon.

At the moment predefined topics and sleeping clients aren’t implemented.

The broker functions as a MQTT-SN broker and MQTT-SN to MQTT Gateway. Here are the download  install and configuration instructions.

Paho Eclipse Gateway

This started I believe as a fork of RSMB and works as a pure Gateway.

This git page has the download and install instructions.


your might need to use:

git clone

and not

git clone -b experiment

MQTT-SN Python Client

The RSMB src files also have a Python client. The client is written in python2.7


I have ported it to python3 and have modifed it to work similar to the MQTT client but the files have lots of print statements that I have used to try and understand how it works. If you want them then use the contact form and I’ll email them.

Here are my current usage notes

C Client

Because MQTT-SN is for low level hardware this will be the most popular client used.

You can download this client here.

MQTT-SN Pub and Sub Tools

These are the MQTT-SN equivalent to the mosquitto_pub and sub tools.

Download here

Useful Links

Please rate? And use Comments to let me know more
[Total: 0    Average: 0/5]


    1. I have edited the notes and added more details for the compile.You need to do this on Linux and run the make program when in the src folder. There are lots of .c and .h files in this folder but only one makefile.
      Once compiled you only the need the broker_mqtts file and should copy it into another folder away from the src files. The documentation is in the doc folder and also has install instructions.

Leave a Reply

Your email address will not be published. Required fields are marked *