Benefits of MQTT-SN over MQTT

Benefits of MQTT-SN over MQTT

MQTT SN is exclusively designed for sensor networks and the specification for the same (MQTT SN specification) is available at MQTT & MQTT SN (MQTT for sensor networks) are both IoT Protocol used most widely for developing IoT devices. This blog is for developers to understand when to use MQTT-SN (SN MQTT for sensor) and the advantages of the same over MQTT message protocol.

MQTT SN Auto Discovery

In the MQTT set up, agents need to be informed where the broker runs. This increases the configuration overhead at the end user. But for MQTT-SN protocol, the sensors and the gateway can propagate messages which is understood by its counterpart and can establish connection to communicate with each other.  This makes it much simpler to configure.

Reduced Bandwidth

The size of the every packet that is transferred in the MQTT-SN has been redesigned. For example in the CONNECT, only the required parameter is sent. The WILL and WILL Message has been split into separate packets and sent only when required. The overall data transferred over the network is reduced to a greater extent to reduce the bandwidth used. Moreover MQTT SN supports four types of QoS (Quality of service) QoS 0,1,2,-1 or 3.

Predefined Topic IDs & Topics Names

The topic names can be predefined in the MQTT SN Gateway with a pre defined topic IDs. The client can directly send packets using the ID and no need to use the topic names. The topic IDs occupies a max of two bytes. The short topic names less than 2 bytes can also be used without topic IDs. If the client wants to use a new topic, then can send a register command for the new topic.

Lower Processing Power

The packet size reduction highly reduces the amount of power required to create and communicate data. Further there are provisions like Sleep of the clients which will stop the gateway from further sending or publishing messages to this client . The client can send a resume message to get all the packets received during the sleep period.  This make this publish subscribe messaging protocol highly suitable for battery powered sensors.


MQTT is over TCP/IP Protocol. TCP has a lot of connection over head which is not required in the MQTT-SN which is over UDP. And it does not depend on TCP/IP networks. This again reduces the amount of data transfer and the power required.

Medium Independence

It can be propagated over Zigbee, Z-Wave , bluetooth in addition to the wired and wireless sensor networks.

You can have a look at the detailed document on how to develop MQTT-SN Clients and how to develop MQTT Clients.

MQTT QoS level – What to use & When

MQTT QoS level – What to use & When

MQTT for IoT defines three QoS levels for message delivery. The QoS level is used when a client sends a subscribe request to a particular topic. When a client subscribes to multiple topics, it can use different QoS level for different topics based on the need.

The amount of data we are going to receive is going to be very large. It is very important we reduce the noise and just give more importance to the signals.

What does each QoS level means ?

QoS 0 — At most once and no guarantee of delivery

QoS 1 — Delivered at least once. It has the possibility of getting the messages multiple times.

QoS 2 — Delivered Exactly once.

Using it in Real time

Take an example of a Fuel level sensor in an manufacturing or an automobile.

The sensors sends data to an indicator which can show the current level of the fuel. The indicator showing the current level just need the live data. It does not need any of the past data and even if it misses to receive a few instances, it does not matter. You can use the QoS 0 (At most Once ) for the Fuel level Indicator.

It can also send data to a cut off valve during filling and fuel low warning when the level recedes the lower optimum level. The fuel cut off or the lower level optimal should not miss the data at any cost. We should use the QoS with the perfect delivery for the warning lights to glow. This mandates the usage of QoS 2 (Exactly Once). Even though the past data is not required in this cases, the exact delivery is a must.

If you build a system that records all the data for future analysis. For example, if we want to study the fuel levels with respect to time, we need all the data to be available for the big data analyser engine. For logging of data and storage, either you should build a engine alongside the broker or you can connect an agent with a QoS 2 (Only Once ) and record all the data remotely.

Don’t Ignore everything as Noise

The determination of whether the data is a Signal or the Noise help decide the QoS level to be used. When we do data publishing and Collection in mission critical industry like healthcare , Nuclear, Defence, etc., every data is important and it mandates the use of QoS 2 for every message. QoS 1 can be used instead of QoS 2, if your client can handle duplicates.

A more detailed document on developing mqtt clients will help you create your own mqtt clients to connect with any mqtt broker.

Leave a comment or write to [email protected] for any questions or suggestions.

Best Practices for developing IoT Agents

Best Practices for developing IoT Agents

Every smart device being built today has the software that reads data and communicate with the other devices to create a completely smart environment. It is very important to have a robust and reliable agent for a smart environment. Few best practices to develop simple, light weight agents are,

Don’t build Intelligence into Agents

The  limited life batteries powers IoT devices at the periphery mostly.  Agents should be programmed to run a very few procedures like listen to the event and send the data to the central server, and when the central server sends a command, the agent should trigger the event based on the command. The only code in the agent should be:

If(message_received == “DO THIS” ) {
else If(message_received == “DO THAT” ) {

A little more to this will ruin the battery at a faster rate. Further upgrading the intelligence inside every agent is going to be a very costly deal. The best thing is to create a dump executor agent. If you are doing a MQTT based implementation, just subscribe to only one topic and publish to only one topic and the rest should be taken care by the central broker or the server behind it.

Let the Agents Sleep

Most devices work based on the event that occurs on the devices. In such a scenario, there is no need for the agent to be continuously connected to the Central server. Select a good Protocol standard that allows your agent to sleep for a stipulated time and then come back live. MQTT-SN provides this option. The agent should reconnect within stipulated time to check for messages (if any) for it from the Central server. Have a check on how critical is the data it collects and decide on the sleep duration.

Avoid local storage. Just send it

Time sensitivity of the data is increasing day by day. The sooner the data is received in the Central server, the better decisions will be made by the central big data engine. The Embrace IoT for Perfection will give a more detailed insight into the fast feedback loop

The agent is not for storing data. As soon as you get the event, send it to the central server. Aggregation of data can also lead to intermittent data loss, so Just Send it.

Set Strong Disconnection message

Disconnection of the devices is going to be a more common phenomenon with the explosion of the number of devices and other physical factors affecting the connection. The device can go out of connection due to factors like loss of power, network issue, etc., Make sure the central server or the manager or the relevant devices get notified when devices go out of connection. Set Stronger messages if the particular agent is mission critical. MQTT provides an option of WILL MESSAGES which can inform the other clients and manager if the particular client goes off.

Perfect Restart and Reconnect routine

Anything and Everything can Fail and everything will come back to life. So are the devices. Make sure you hook  agent  well to the start / stop routine of the device for which you program it. The central server in spite of hosted on highly available data center too is no exception to the failure rule. The agent should have a good reconnection algorithm to check the server availability. Very frequent ping to a non available server will drain the power at a faster pace.

At Bevywise Networks, we have built our IoT agents, enterprise broker & simulator for devices and sensors based out of MQTT and MQTT-SN Protocol.