MQTT for Sensor Networks (MQTT-SN) : IoT Part 39

The Internet of Things have specific network requirements. The traditional TCP/IP protocols usually do not fit to these requirements. That is why there are many protocols designed especially to cater the requirements of IoT applications. Within the IoT domain, sensor networks are one of the applications which are designed using constraint devices and are characterized by limited network bandwidth. A variant of MQTT protocol has been designed for these networks which is called MQTT-SN (MQTT for Sensor Networks).

MQTT and MQTT-SN are different from each other. MQTT is a protocol which is designed to be light weight for M2M, but it needs TCP/IP stack to operate. But if the sensor nodes cannot hold the TCP/IP stack then here comes MQTT-SN which does not depend on TCP/IP for it to operate.

Due to sudden increase of interest in Wireless Sensor Network (because of simplicity, low cost and easy deployment), a light weight pub-sub protocol has been developed called MQTT-SN. The SN or Sensor Network in the protocol name indicates that it is specifically designed for sensor networks. As sensor nodes are specifically made with limited processing capabilities and limited amount of storage, so these sensor nodes cannot have TCP/IP stack with themselves because TCP/IP protocol stack is too heavy to be handled by such tiny sensor nodes due to big payload, retry mechanism, time to live for the packets etc.

MQTT-SN was originally designed for running on top of the Zigbee APS layer. Any network which provides a bi-directional data transfer service between any node and a particular one (gateway) should be able to support MQTT-SN.

How MQTT-SN is different from MQTT?

First thing, MQTT-SN is designed to be as close as possible to MQTT, but is adapted to the particular behavior of wireless communication network such as low bandwidth, high link failures, short message length etc. Second, MQTT-SN is optimized for the implementation on low cost, battery-operated devices with limited processing and storage resources. Third, MQTT-SN needs a bridge to translate MQTT-SN messages into MQTT messages.

Compared to MQTT, MQTT-SN is characterized by following differences –

1) MQTT-SN supports topic ID instead of topic name. First client sends a registration request with topic name and topic ID (2 octets) to the broker. After the registration is accepted, client uses topic ID to refer the topic name. This saves media bandwidth and device memory – it is quite expensive to keep and send topic names like home/livingroom/socket2/meter in memory for each publish message.

2) The Topic name to topic ID can be preconfigured in MQTT-SN gateway, so that even registration message can be skipped before publish.

3) A discovery procedure helps clients without a pre-configured server/gateway’s address to discover the actual network address of an operating server/gateway. Multiple gateways may be present at the same time within a single wireless network and can co-operate in a load-sharing or stand-by mode.

4) The Clients connect to the broker through a gateway device, which resides within the sensor network and connects to the broker.

MQTT-SN Architecture

The architecture of MQTT-SN can be represented by the following figure –

Fig. 1: Image showing MQTT-SN Architecture

There are three kinds of MQTT-SN components – MQTT-SN clients, MQTT-SN gateways (GW) and MQTT-SN forwarders. MQTT-SN clients connect themselves to a MQTT server via a MQTT-SN GW using the MQTT-SN protocol. A MQTT-SN GW may or may not be integrated with a MQTT server. In case of a stand-alone GW, the MQTT protocol is used between the MQTT server and the MQTT-SN GW. Its main function is the translation between MQTT and MQTT-SN. MQTT-SN clients can also access a GW via a forwarder in case the GW is not directly attached to their network. The forwarder simply encapsulates the MQTT-SN frames it receives on the wireless side and forwards them unchanged to the GW. In the opposite direction, it releases the frames it receives from the gateway and sends them to the clients, unchanged too.

There are two types of Gateways depending on how a Gateway performs the protocol translation between MQTT and MQTT-SN:

1) Transparent Gateway – For each MQTT-SN client, transparent gateway will form an individual MQTT connection to the MQTT broker.

2) Aggregating Gateway – In this, for all MQTT-SN clients, the Aggregating gateway will form only one MQTT connection to the MQTT broker. The advantage of using aggregating gateway is shown where WSN network has large number of sensor nodes because it helps in reducing the number of MQTT connections that broker has to create with individual client.

Message Formats –

When client and broker communicate with each other, they follow some set of rules in the message like what are the things will be included in topic, payload etc. The following tree represents the message format in MQTT-SN –

Fig. 2: Image showing MQTT-SN Message Format

Fig. 3: Table listing Message Format of MQTT-SN

Fig. 4: Table listing Message Format of MQTT-SN

Fig. 5: Table listing Flags in MQTT-SN message

Fig. 6: Table listing Flags in MQTT-SN message

MQTT-SN Features

The MQTT-SN protocol has the following distinct features –

1) Gateway Advertisement and Discovery – A gateway continuously advertises itself by sending an ADVERTISE & GWINFO message to all devices that are part of the network. The client discovers the gateway by the Gateway unique ID. A client maintains the list of all active gateways with the network address & UID.

2) Client’s Connection Setup – An MQTT-SN client needs to setup a connection to a GW before it can exchange information with that GW.

Fig. 7: Image showing MQTT-SN Client Connection Procedure

Check out the MQTT-SN specification for more details on Client connection procedure.

3) Procedure for updating the will data – The client can update the previously registered Will topic and Will message at any time by sending the WILLTOPICUPD or WILLMSGUPD message.

4) Topic Name Registration Procedure – Because of the limited bandwidth and small payload, a registration procedure is involved. The client first sends the REGISTER message with the topic name to the gateway then if GW accepts the registration, it assigns the topic ID on that topic name and acknowledge it with the REGACK message. In that way, if client sends any message to that topic, it will not use the long topic name again, it will use only the assigned 2 bytes topic ID.

5) Client Disconnect – A client sends a DISCONNECT message to the GW to indicate that it is about to close its connection. After this point, the client is then required to establish a new connection with the GW before it can exchange information with that GW again.

6) Support of Sleeping Client – The broker or server remains aware of the sleeping clients and buffer the message 0020 to deliver them when they wake up.

In the next tutorial, learn about RSMB Broker for implementing MQTT-SN protocol.