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

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 (MQTT for Sensor networks) was designed specifically to work on wireless networks, and , as far as possible, to work in the same way as MQTT.

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


The main differences involve:

  • Reducing the size of the message payload
  • 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 changed during the session
  7. Off line 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:

When client 1 talks to client 2 does it require the MQTT broker to do so? Specifically in the diagram aboce for cleints 3 and 4. Is it

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

or is it

MQTT-SN >MQTT>MQTT-SN -In this case the gateway is an MQTT-SN gateway and an MQTT broker.

GateWay Types

The specification defines two gateway types.

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

An aggregating gateway was 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-defined topic ids.

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 both 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 advertises 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 an MQTT-SN broker and MQTT-SN to MQTT Gateway.

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 modified it to work similar to the Paho  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.

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

News and Views (Dec 2019)

MQTT-SN has stalled in development and there aren’t the variety of brokers and client that you have with MQTT.

However, having said that it is likely to become more popular and there is a move now to have it developed as an OASIS standard.

Personally I think MQTT-SN will eventually be the main protocol for connecting sensors to MQTT networks and MQTT will become more of a backbone protocol.

Leave a Reply

Your email address will not be published.