As a sequel of my previous blog on MQTT, this blog will discuss in detail about the IoT messaging protocol MQTT-SN.


MQTT for Sensor Networks (MQTT-SN) is a variant of MQTT designed specifically to suit battery operated devices and constrained wireless environment with low bandwidth, high link failure and short message length. MQTT-SN is originally developed to work on top of Zigbee APS layer. It can also work on top of any un-ordered, lossy and bi-directional network protocols. As MQTT, it is also a topic based publish-subscribe messaging protocol.

Operational behaviour

Message flow in a MQTT-SN based solutions is as follows,

  • MQTT-SN clients searches for a gateway in the local network using search gateway broadcast message. MQTT-SN gateway broadcasts advertise messages in the local network it is connected.
  • MQTT-SN gateways should be connected to a MQTT broker before advertising or should be a MQTT broker by itself.
  • MQTT-SN clients finds the gateway destination using dynamic discovery and connects to the gateway.
  • MQTT-SN clients can either be a publisher or subscriber.
  • Publishers registers the topics that it is going to publish with gateway to get 2 byte topic id’s which helps to reduce the message size.
  • Subscribers sends subscribe messages with topic name or predefined short topic id or 2 bytes short topic name. MQTT-SN gateways uses subscription acknowledgement message or separate register message to inform IDs of topic names to subscribers.
  • MQTT broker and MQTT-SN gateways controls the message flow, receives the messages from publishers and routes them to subscribers.

Following figure illustrates MQTT-SN and MQTT entities in an example of home automation,

Figure 1 : MQTT and MQTT-SN entities
Please refer “Credits” section to know credits for image resources used.

In the above example,

  • IoT devices like smart thermostat and smart lock acts as MQTT-SN clients, dynamically discovers and connects to the MQTT-SN gateway.
  • Smart door lock and thermostat communicates with Home gateway using MQTT-SN to register, publish and subscribe to interested topics.
  • Smart devices publishes data regarding their current status and subscribes to control messages. These devices connects to MQTT broker via MQTT-SN gateway.
  • Connected home gateway acts as MQTT-SN gateway as well as MQTT client and connects to a MQTT broker. Gateway is responsible for maintaining MQTT sessions with broker and route the messages to MQTT-SN clients. It is also responsible to translate MQTT-SN messages to MQTT and vice versa.
  • A smartphone application acts as a MQTT client and connects to the MQTT broker. It subscribes to current status of smart devices and publishes control messages to smart devices.
  • MQTT broker runs in the cloud. MQTT broker and MQTT-SN gateway controls the message flow between control application and smart physical devices.

Types of MQTT-SN gateways
Transparent gateways are gateways that maintains separate MQTT sessions with the broker for each connected MQTT-SN client.

Aggregating gateways maintains only one MQTT session with the broker and it uses this single connection to exchange the messages from and to multiple MQTT-SN clients. Aggregating gateway is more complex to implement, but it will be useful in reducing the number of concurrent connections to a MQTT broker.

MQTT-SN Forwarder
MQTT-SN forwarders can be used to encapsulate and forward MQTT-SN frames from wireless sensors to MQTT-SN gateway and vice versa. It can be used in scenarios where MQTT-SN clients cannot access the gateway directly.

Key differences between MQTT and MQTT-SN
MQTT-SN is almost similar to MQTT with the following differences,

  • Works on top of un-ordered, lossy and bidirectional network protocols.
  • To reduce message size, topic names are reduced to 2 bytes. Pre-defined and normal topic IDs, short topic names and register procedure are introduced to avoid UTF-8 encoded string payloads (topic names) in every publish messages.
  • MQTT-SN clients can discover a gateway dynamically using ADVERTISE, SEARCHGW and GWINFO control messages.
  • Supports sleeping clients. Power constrained devices can go to sleep state by disconnecting with a sleep duration. Gateway will buffer the messages that should be delivered to such sleeping clients. Sleeping clients can come online only when it needs to send or receive messages.


MQTT-SN is not standardized yet. It is a copyright of IBM published with a royalty free license.

Message format

MQTT-SN defines twenty seven type of control messages for the communication between clients and gateways such as CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, DISCONNECT etc.

Every MQTT-SN message contains a 2 or 4 bytes message header and variable payload. Size of the smallest MQTT-SN message is 2 bytes.  Largest MQTT-SN message is of size 65535 bytes. But, for MQTT-SN over UDP,  it is recommended to frame MQTT-SN messages to fit in a single IP datagram to avoid fragmentation and packet loss issues.

Message delivery

MQTT-SN offers four type of QoS (Quality of Service) for message delivery as described below. QoS 0, 1 and 2 inherited from MQTT as it is.

  • QoS 0 – At most once delivery
  • QoS 1 – At least once delivery
  • QoS 2 – Exactly once delivery
  • QoS -1 – Simple clients
    Defined for very simple clients to publish messages to a pre-known gateway without the need for connection setup and teardown. Such client does not care whether the gateway is active and whether the message is delivered.

Real world implementations

MQTT-SN is not widely adopted and it is hard to find popular implementations of MQTT-SN. There are few interesting project works on MQTT-SN and you can find one here. Eclipse Paho and Mosquitto projects provides open source implementations of MQTT-SN components.


MQTT-SN does not define any security mechanism at protocol level. For MQTT-SN over UDP, DTLS can be used for transport layer security. In addition to this, application layer security mechanisms can be used.

Where MQTT-SN fits in IoT ecosystem ?

As MQTT-SN is defined to work on top of un-ordered and lossy network protocols, it can be used as a messaging protocol between the devices and gateway connected in wireless networks or local network as stated in the examples below,

  • Gateway to devices and vice versa in a local network – In an ecosystem, where multiple battery operated devices are connected to a IoT gateway in a local network, MQTT-SN can be used for messaging between IoT gateway and battery operated devices.


With most of the strengths inherited from MQTT, MQTT-SN have some additional strengths as listed below,

  • MQTT-SN is specifically defined to run on low powered wireless networks and battery operated devices.
  • Designed to work on top of wireless networks like Zigbee or BLE (Bluetooth Low Energy). Can work on top of un-ordered and lossy networks such as UDP/IP.
  • Supports dynamic discovery of gateway.
  • Explicitly supports sleeping clients.
  • Avoids UTF-8 encoded string payloads to carry topic names in every publish message by using pre-defined topic IDs, short topic names and dynamic topic IDs. This reduces the size of publish messages considerably.
  • Provides three level of QoS for message delivery as in MQTT. In addition, it provides QoS -1 for very simple client implementations to avoid connection setup, teardown and to publish messages to a pre-known gateway without worrying about the current status of gateway and message delivery.


  • MQTT-SN over UDP is not a best fit for IoT solutions which requires ordered delivery of  messages. If MQTT-SN over UDP is used in such cases, explicit mechanisms and message contracts should be defined to maintain the ordered delivery of messages.
  • In MQTT-SN over UDP, message size should be relatively small to avoid IP fragmentation and packet loss issues.
  • No security mechanism defined at messaging protocol level.
  • Cannot subscribe to multiple topics (without specifying a wildcard) in one SUBSCRIBE message.

Follow-up links

CoAP :

Entire content of this series of blogs is available here.


  • MQTT-SN v1.2 specification by Andy Stanford-Clark and Hong Linh Truong, IBM,
    14 Nov 2013.
  • Aquila 2.0 – MQTT-SN based IoT Platform, project, Rodmg, 9 Oct 2016.


Resources used in “Figure 1” are downloaded from web as follows,