If MQTT is already a lightweight protocol and it uses small amount of power and bandwidth, then why do we have MQTT-SN? When is it appropriate to use MQTT and when MQTT-SN?
3 Answers
There are few advantages in MQTT-SN (SN for Sensors Network) over MQTT, especially for embedded devices.
Advantages
- MQTT-SN uses topic ID instead of topic name. First client sends a registration request with topic name and topic ID (2 octets) to a 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 name e.g:
home/livingroom/socket2/meter
in memory for each publish message. - Topic name to topic ID can be configured in MQTT-SN gateway, so that topic registration message can be skipped before publish.
- MQTT-SN does not require TCP/IP stack. It can be used over a serial link (preferred way), where with simple link protocol (to distinguish different devices on the line) overhead is really small. Alternatively it can be used over UDP, which is less hungry than TCP.
Disadvantages
- You need some sort of gateway, which is nothing else than a TCP or UDP stack moved to a different device. This can also be a simple device (e.g.: Arduino Uno) just serving multiple MQTT-SN devices without doing other job.
- MQTT-SN is not well supported.
If you are running out of resources, or you do not have Ethernet/Wifi in your device, use MQTT-SN.

- 11,225
- 9
- 50
- 68
-
3Don't forget the battery power. Preserving a WiFi or Cellular connection requires quite a lot of power (even with power save modes). MQTT-SN practically enables using non-IP networks, such as BLE, which allows significantly less power usage, but compromising on delays, end2end encryption and other features. – lkanab Jan 09 '19 at 03:47
-
@Ikanab: Your argument is absolutely valid. Do you know message brokers supporting MQTT-SN? – Michal Foksa Jan 09 '19 at 07:50
-
1Try this one: https://github.com/eclipse/paho.mqtt-sn.embedded-c In addition this project uses MQTT-SN over BLE: https://blog.benjamin-cabe.com/2017/01/16/using-mqtt-sn-over-ble-with-the-bbc-microbit – lkanab Jan 09 '19 at 08:00
-
@Ikanab: I know about those, thank you! The blog post actually mentions my RSMB fork :) – Michal Foksa Jan 09 '19 at 14:36
-
1@MichalFoksa This is a mqtt-sn gateway written in javascript: https://github.com/Rodmg/aquila-mqtt-sn-gateway – fisehara Apr 05 '19 at 14:11
-
You say "MQTT-SN supports topic ID". Forgive my limited understanding, but what prevents us from using an ultra-simple topic name with regular MQTT (e.g topic = /01)? In general, this should reduce the burden on the transmitting device? Thanks! – teeeeee Jun 29 '20 at 19:10
-
@teeeeee You have to use topic ID instead of topic name, that's how MQTT-SN is defined. – Michal Foksa Jun 30 '20 at 09:17
-
So you mean the advantage comes from the fact that a topic name can't be defined accidentally or otherwise in MQTT-SN? The advantage of "media bandwidth and device memory" that you mention would also apply in MQTT if one *chooses* a simple topic ID (/01/) instead? – teeeeee Jun 30 '20 at 09:22
-
1@teeeeee Sure, short topic name saves resources in both protocols. – Michal Foksa Jun 30 '20 at 10:14
-
1MQTT 5.0 became an OASIS standard in 2019, and also includes the option to use topic IDs. Just FYI for others coming across this in the future. :) – Frodyne Jan 18 '23 at 09:21
MQTT-SN (wher SN means Sensors Network) is different from MQTT. MQTT goes over TCP/IP and it can used for LAN communication or over Internet and the Cloud (if you have a client inside your network but the broker is outside on Internet). MQTT-SN can be used on more protocols suited for sensors network like ZigBee, Z-Wave and so on. The specification is different from MQTT ... so it isn't MQTT not over TCP/IP. It's more lightweight and needs a bridge to translate MQTT-SN messages into MQTT messages.
Paolo.

- 3,124
- 22
- 30

- 9,431
- 1
- 30
- 45
-
Could you explain a scenario where MQTT-SN should be used. And why MQTT cannot be used? – Sasikumar Dec 19 '14 at 09:15
-
1The scenario could be when you have sensors (inside a network) that don't support TCP/IP but they support other protocols like ZigBee, Z-Wave, BLE, .... In this case you can't use MQTT but only MQTT-SN because you haven't a TCP/IP stack. – ppatierno Dec 19 '14 at 09:21
-
So Is MQTT_SN an alternative to ZigBee or Bluetooth? If so, where should I have the broker installed. In case of bluetooth, we'll pair 2 devices directly and communicate without any intermediate effort But for MQTT-SN we need a broker as the inter-mediator. – Sasikumar Dec 19 '14 at 09:52
-
MQTT_SN goes over ZigBee, it isn't an alternative. In the sensor networks you haven't the concept of pairing devices ... you have sensors that publish data and actuators data can receive command in network not in a 1 to 1 communication. So you need a broker or other type of protocols lize 0MQ (but I have never used it) – ppatierno Dec 19 '14 at 10:28
Some problems with MQTT-SN you might not realize from the docs:
You need to retry all messages, until the expected answer gets to you. (MQTT-SN Spec 1.2 6.13)
If you fail to properly send a QoS 1 or 2 message, then you should persist the data. Which in many cases is not possible at all. And watch out for changing topic ids, byte-to-byte copies are sometimes not good enough.
Gateways are too strict in many cases, and if something goes wrong, you find yourself in an error loop. Which is not ideal at all.
If you are doing PUB-SUB for the first time, it is harder than it looks. You need to design your topics well!
Connection establishment is pretty verbose (CONNECT - CONNACK, WILLTOPICREQ - WILLTOPIC, WILLMESSAGEREQ - WILLMESSAGE, REGISTER - REGACK, SUBSCRIBE - SUBACK) If you want many clients to connect at the same time on the same media (a bus or radio waves), they will interfere with each other.

- 587
- 4
- 17