When I was reading the document, I remembered that I had compiled some literacy content about the MQTT protocol before, so I would like to share it.

1. Introduction to MQTT protocol

MQTT (Message Queuing Telemetry Transport, Message Queuing Telemetry Transport Protocol) is a "lightweight" communication protocol based on the publish/subscribe (publish/subscribe) model. The protocol is built on the TCP/IP protocol and was developed by IBM in 1999. Released in year.

The biggest advantage of MQTT is that it can provide real-time and reliable messaging services for connecting remote devices with very little code and limited bandwidth. As a low-cost, low-bandwidth instant messaging protocol, it has wide applications in the Internet of Things, small devices, mobile applications, etc.

Compared to HTTP

In traditional Internet applications, HTTP is widely used. Under normal circumstances, the client's device configuration and network environment are relatively controllable, and requests usually transfer a large amount of data based on various services.

However, for the Internet of Things, network instability and insufficient equipment capabilities are key factors to consider. Furthermore, the message size transmitted by the Internet of Things is much smaller than the business data of the traditional Internet. If TCP is connected/disconnected every time data is sent, the more data is sent, the greater the total data communication volume will be.

Furthermore, the HTTP request-response model is not as flexible as the MQTT publish/subscribe model. The device must actively send data to the server, and it is difficult for the server to actively push data to the device. It is barely suitable for single data collection and other scenarios, but for frequent control scenarios, the only way is to use the device to actively pull it regularly, which greatly reduces the cost and real-time performance.

2. MQTT protocol design specification

Since the environment of the Internet of Things is very special, MQTT follows the following design principles:

Streamlined, without adding dispensable functions;
Publish/subscribe (Pub/Sub) mode to facilitate message transmission between sensors;
Allows users to dynamically create topics with zero operation and maintenance costs;
Minimize the amount of transmission to improve transmission efficiency;
Take factors such as low bandwidth, high latency, and unstable networks into account;
Support continuous session control;
Understand that client computing power may be low;
Provide service quality management;
It is assumed that the data is agnostic, and the type and format of the transmitted data is not forced to maintain flexibility.

The inventor was developing a project to use satellite communications to monitor oil pipelines. In order to realize this project requirement, they need to develop a communication protocol for embedded devices. Designed from the ground up for low-bandwidth, high-latency, or unreliable networks. Although it has gone through decades of updates and changes, the above features are still the core features of the MQTT protocol. But what is different from the original is that the MQTT protocol has expanded from embedded system applications to the open Internet of Things (IoT) field.

Version

There are currently two mainstream versions of MQTT, namely MQTT3.1.1and MQTT5. MQTT3.1.1It was released in October 2014, MQTT5but it was released in March 2019. MQTT5 is MQTT3.1.1upgraded on the basis of , adding more functions and improving the MQTT protocol. Therefore MQTT5 is fully compatible MQTT3.1.1.

3. The difference between MQTT and message queue MQ

MQTT is not a message queue. Although many behaviors and features of the two are very similar, such as publishing and subscribing models, etc., the scenarios they target are significantly different.

Message queues are mainly used for message storage and forwarding between server applications. This type of scenario often has a large amount of data but a small amount of access.
MQTT is oriented to the IoT field and the mobile Internet field. The focus of such scenarios is the access, management and message transmission of massive devices.

In actual scenarios, the two are often used in combination. For example, MQTT Broker first receives data uploaded by IoT devices, and then forwards the data to specific applications for processing through message queue MQ.

4. MQTT protocol for Internet of Vehicles

There is an important role in the Internet of Vehicles: TSP (Telematics Service Provider) car remote service provider. TSP connects to cars, vehicle equipment manufacturers, and network operators, and connects to content providers below.

Since it is in the core position, various interactions with other links are naturally indispensable, such as the message access between the cloud platform and the car terminal.

MQTT is an IoT communication protocol based on the publish/subscribe model. It is simple and easy to implement, supports QoS, and has small message sizes. In the Internet of Vehicles scenario, MQTT is capable of flexibly, quickly, and securely accessing massive vehicle-machine systems. And ensure the real-time and reliability of messages in complex network environments. Main advantages:

Open message protocol, simple and easy to implement. There are a large number of mature software libraries and hardware modules on the market, which can effectively reduce the difficulty and cost of vehicle-machine access;
Provides flexible publishing, subscription and topic design, and can communicate messages through a large number of topics to cope with various types of Internet of Vehicles businesses;
The payload format is flexible and the message structure is compact, which can flexibly carry various business data and effectively reduce vehicle network traffic;
Provides three optional QoS levels to adapt to different network environments of vehicle equipment;
Provides online status awareness and session retention capabilities to facilitate management of vehicle online status and offline message retention.

5. Introduction to MQTT protocol features

1. Client and server

Implementing the MQTT protocol requires communication between the client and the server. During the communication process, there are three identities in the MQTT protocol: 发布者（Publish）, 代理（Broker）（服务器）, 订阅者（Subscribe）.

Among them, the publisher and subscriber of the message are both clients, and the message agent is the server.

client

The MQTT client can publish information to the server and receive information from the server.

We call the behavior of the client sending information publishing information. If the client wants to receive information from the server, it must first subscribe to the server. The operation of subscribing to information is very similar to subscribing to a certain type of TV series on a video website. When a new TV series is released, the video website will send a message to users who have subscribed to the series to tell them that a new series is online.

Publish information to which other clients may subscribe
Subscribe to messages published by other clients
Unsubscribe or delete app messages
Disconnect from server

server

The MQTT server is usually a server, also known as a “消息代理”（Broker）. Located between the message publisher and the subscriber, it is the hub of MQTT information transmission and is responsible for delivering the information sent by the MQTT client to the MQTT client.

The MQTT server is also responsible for managing the MQTT clients. Ensure smooth communication between clients and ensure that MQTT messages are correctly received and accurately delivered.

Accept network connections from clients
Accept application information released by customers
Handle subscribe and unsubscribe requests from clients
Forward application messages to subscribed clients

2.Theme

When we just explained MQTT client subscription information, we used the example of users subscribing to TV series on a video website. In MQTT communication, what the client subscribes to is definitely not a TV series, but a topic. The MQTT server uses topics to control when managing MQTT information communication.

Let's give another example:

在以上图示中一共有三个MQTT客户端: 

它们分别是汽车，手机和电脑。

假设我们需要利用手机和电脑获取汽车的速度，
那么我们首先要利用电脑和手机向MQTT服务器订阅主题“汽车速度”。

接下来，当汽车客户端向服务端的“汽车速度”主题发布
信息后，服务端就会首先检查以下都有哪些客户端
订阅了“汽车速度”这一主题的信息。

当它发现订阅了该主题的客户端有一个手机和一个电脑，
于是服务端就会将刚刚收到的“汽车速度”信息转发给订阅了
该主题的手机和电脑客户端。

在以上实例中，汽车是“汽车速度”主题的发布者，
而手机和电脑则是该主题的订阅者。

In addition, the message publisher can also be a subscriber . See the picture:

上图中的所有客户端都是围绕“空调温度”这一主题
进行通讯的。

对于“空调温度”这一主题，手机和电脑客户端成为
了MQTT信息的发布者，而汽车则成为了MQTT信息的
订阅者（接收者）。

所以，针对不同的主题，MQTT客户端可以切换
自己的角色。它们可能对主题A来说是信息发布者，
但是对于主题B就成了信息订阅者。

3. MQTT publish/subscribe features

As can be seen from the above examples, the core hub of MQTT communication is the MQTT server. With the server receiving, storing, processing and sending MQTT information, the client can be independent of each other, separated in space, and asynchronous in time when publishing and subscribing information.

Independent

MQTT clients are independent individuals. They don't need to know each other's existence to still exchange information.

For example, when the car client publishes "car speed" information in the above example, the car client itself may not know how many MQTT clients have subscribed to the "car speed" topic. The mobile phone and computer clients subscribed to the "Car Speed" theme are completely unaware of each other's existence.

As long as everyone subscribes to the "Car Speed" topic, the MQTT server will send the information to the client subscribed to the "Car Speed" topic every time it receives new information.

space separable

The necessary condition for the MQTT client to communicate is that it is connected to the same MQTT communication network. This network can be the Internet or a local area network. As long as the clients are connected to the Internet, they can communicate with each other no matter where they are.

Time can be asynchronous

MQTT clients do not need to synchronize when sending and receiving messages. This feature is especially important for IoT devices. Sometimes IoT devices go offline unexpectedly. For example, when our car is driving, it may suddenly enter a tunnel. At this time, the car may disconnect from the MQTT server.

Assume that at this time our mobile client publishes information to the "air conditioning temperature" topic subscribed by the car client, but the car is not online. At this time, the MQTT server can save the new information on the "air conditioning temperature" topic. After the car comes online again, the server will push the "air conditioning temperature" information to the car.

4. Session

The sequence of message sending and receiving from the time the client initiates an MQTT connection request to the server, to the interruption of the connection, and until the session expires is called a session.

Therefore, a session may last only one network connection, or it may exist across multiple network connections if the client can reestablish the connection before the session expires.

Use of session state

If the client's connection is temporarily interrupted due to network fluctuations, etc., but it re-establishes a connection with the server before the session expires, then it can continue to use the subscription relationship established by the last connection without re-subscribing.

In low-bandwidth, unstable network scenarios, network interruptions may occur frequently. The method of saving session state avoids the need to re-subscribe for each connection, reducing resource consumption on the client and server during reconnection.

The server retains unconfirmed and subsequently arrived messages for the client while it is offline, and forwards them together when the client reconnects. This can avoid message loss and reduce the user's perception of network changes in certain scenarios. Spend.

5. QoS (Quality of Service)

Some information in an IoT system is very important, and we need to ensure that this type of important information can be sent and received accurately. If some information is lost in transmission but does not affect the operation of the system, it is relatively unimportant.

MQTT Quality of Service (QoS) is used to inform the IoT system which information is important and needs to be transmitted accurately, and which information is not so important and will not be a problem even if it is lost.

MQTT is designed with 3 QoS levels:

QoS 0: The message can be sent at most once and takes up the lowest network resources.

Once the sender has finished sending the message, the task is completed. The sender does not check whether the sent message has been received correctly.

When the network environment is stable, there will generally be no problems with information transmission. However, when the environment is unstable, MQTT messages may be lost during the transmission process, so it is suitable for transmitting less important information.

QoS 1: The message is sent at least once, but the receiving end may receive the same message repeatedly.

After the message is sent, the sender will check whether the receiver has successfully received the message.

After the sender sends the message to the receiver, it will wait for confirmation from the receiver. After the receiving end successfully receives the message, it will send a confirmation message PUBACKto the sending end. If the sender receives this PUBACKconfirmation message, then it knows that the message has been successfully received.

PUBACKIf the sending end does not receive the message after a period of time, the sending end will send the message again, and then wait for the PUBACK confirmation message from the receiving end again. PUBACKTherefore, the sender will send the same message repeatedly before receiving the confirmation message from the receiver .

When the sender repeatedly sends a message, the PUBLISH message dupFlagwill be set to True, in order to tell the receiver that this message is a repeated message.

QoS 2: Messages are guaranteed to be received once.

The MQTT protocol ensures that the receiving end only receives the message once. However, the sending and receiving process is relatively more complicated, and the sending end requires the receiving end to confirm the message twice. Therefore, QoS 2the most secure service level is also the slowest service level. This type of service level is suitable for important message transmission.

The sender sends a QoS 2 PUBLISH message to the receiver (sending you a message)
The receiving end replies the PUBREC confirmation message to the sending end (I received it)
After receiving the PUBREC message, the sender will store the message and return the PUBREL message as a response (this transmission can be completed)
After receiving the PUBREL message, the receiving end will respond to the sending end with a PUBCOMP message (OK, end it)

Tips: Since both QoS1 and QoS2 can ensure that the client receives the message, QoS1 occupies smaller resources than QoS2. Therefore, it is recommended to use QoS1 to transmit important information in environments where network resources are precious.

Service quality degradation

For clients that publish and subscribe to messages, the server will actively use lower-level QoS to implement message transmission.

scene 1:

If the message 客户端Apublished 主题1is adopted QoS = 2, but 客户端Bthe subscription 主题1is adopted QoS = 1.

In this case, the server will use a lower level to provide the service.

Although the message Asent to is adopted , since it is adopted when subscribing , the message sent to is adopted .主题1QoS为2B主题1QoS为1服务端主题1BQoS为1

Scenario 2:

If it is used when 客户端Apublishing a message , and `QoS is 1 when subscribing to a message.主题1QoS为0客户端B主题1

Although when 客户端Bsubscribing to 主题1a message QoS为1, because when 客户端Asending 主题1a message QoS为0, 服务端the message is sent Bto QoS为0.

6. Hold messages

There is such a scene:

一套智能家居物联网系统，有一个检测室温的
MQTT客户端，每整点时把当前室温
向MQTT服务端发布。

系统中还有另一个客户端用于显示温度信息，
客户端一启动就会订阅室温主题。

正常情况下：假如上午7：00，室温检测客户端
将最新的室温消息发布到了服务端，那么订阅了
室温消息的显示客户端也就马上获取到室温消息
并且显示在屏幕上。

但是，7点10分的时候，显示客户端的插头被
碰掉了，手动恢复通电后，客户端启动后会立刻
订阅室温主题。

Here’s the problem, the room temperature client only publishes temperature information every hour. The last published time is 7：00and the next published time is 8：00. Therefore, even though the display client is subscribed to the room temperature topic, it will have to wait until 8：0012 seconds to receive the latest room temperature message. In the8：00 first few dozen minutes, the display client was unable to obtain the current room temperature information.

保留消息In order to avoid the above situation, you can let the room temperature measurement client use this mode to publish temperature information to the server every time it publishes a message to the room temperature topic . In this way, no matter whether the display client subscribes to the room temperature topic at any time, it will immediately receive the information in the topic 保留消息.

7. Heartbeat mechanism

When the client does not send information to the server, it can send a message to the server regularly. This message used for the heartbeat mechanism is also called a heartbeat request (PINGREQ).

The purpose of the heartbeat request is to inform the server that the current client is still online.

After receiving the client's heartbeat request, the server will reply with a message. This reply message is called a heartbeat response (PINGRESP).

heartbeat interval

We can set it when developing the client.

After setting the heartbeat interval, the client knows how often it needs to send a heartbeat request to the server. When the client connects to the server, the heartbeat interval information is put into CONNECTthe message keepAlive.

The values in the figure keepAliveare 60. This means that the client's heartbeat interval is 60秒.

During the heartbeat interval, if the client publishes a message, it publishes the message directly without issuing a heartbeat request.
If the client does not publish a message, it will publish a heartbeat request to the server.

Client disconnected

In addition, in actual operation, if the server does not 1.5倍心跳时间间隔内receive a message (PUBLISH) or a heartbeat request (PINREQ) from the client, then the server will consider this 客户端已经掉线.

To summarize, the heartbeat mechanism allows the server to keep track of the client's connection status at any time. When the client's "heartbeat" is normal, the server knows that the client is still alive 在线（活着）. Once the heartbeat stops, the server will find that the client has stopped 断线（死亡）.

8. Will mechanism

In order to allow the client to function better and facilitate server management, the MQTT protocol allows the client to write a will while "alive", so that once the client is connected, the server can make the client's will public 意外断线.

Note: The client's will will only be published when it is accidentally disconnected. If the client disconnects from the server normally, the will mechanism will not be started, and the server will not publish the client's will.

Accidental disconnections include but are not limited to:

Due to network failure or network fluctuation, the device failed to communicate during the keep-alive period, and the connection was closed by the server.
Device unexpectedly loses power
The device attempted to perform an impermissible operation and the connection was closed by the server, such as subscribing to topics beyond its own permissions, etc.

9. Data packet structure

The whole consists of 3 parts:

固定报头 Fixed header: Exists in all MQTT data packets, indicating the data packet type and grouping class identifier of the data packet;
可变报头 Variable header: Exists in some MQTT data packets. The data packet type determines whether the variable header

The overall MQTT message format is as shown in the figure below:

The data package is not currently expanded, and will be introduced in a separate chapter when further contact is needed.

MQTT protocol learning: introduction to related concepts

background

From this chapter onwards, unless otherwise specified, the MQTT version in the article is 3.1.1.

MQTT protocol is one of the common protocols in the Internet of Things, "Lightweight IoT Message Push Protocol". MQTT and HTTP belong to the seventh layer (application layer).

For those who are not familiar with network layering, please click: "Network OSI seven-layer model and the functions of each layer and TCP/IP"
Reference: "What is the difference between MQTT and Modbus in IoT gateways", "Introduction to MQTT"
Documentation: "Chinese version of MQTT protocol", "English version of MQTT protocol"

The development history of MQTT

In the Internet of Things, open source and open standards are fundamental elements. The development history of MQTT is roughly as follows:

In 1999, IBM and its partners jointly invented the MQTT protocol.
In 2004, MQTT.org opened the forum for broad participation.
In 2011, IBM established the Eclipse open source project Paho and contributed code. Eclipse Paho is the Java implementation of MQTT.
In 2013, the OASIS MQTT Technical Specification Committee was established.
In 2014, MQTT officially became the recommended IoT transmission protocol standard.

concept

MQTTis a machine-to-machine ( M2M)/Internet of Things ( IoT) connectivity protocol. It was designed as an extremely lightweight 发布/订阅messaging protocol. Useful for remote connections where a smaller code footprint is required and/or network bandwidth is at a premium. Designed for constrained devices and low-bandwidth, high-latency, or unreliable networks. These principles also make the protocol ideal for connected devices in the emerging machine-to-machine ( M2M) or Internet of Things ( Internet of Things ) world, as well as mobile applications where bandwidth and battery power are very high. IoTFor example, it has been used for sensors communicating with agents via satellite links, dial-up connections to healthcare providers, and a range of home automation and small device scenarios. It is also ideal for mobile applications because it is small, consumes low power, has minimal data packets, and can efficiently distribute information to one or more receivers.

Why not choose among the many other network protocols?

Most developers are already familiar with HTTP Web services. So why not let IoT devices connect to web services? A device can send its data in the form of HTTP requests and receive updates from the system in the form of HTTP responses. This request and response pattern has some serious limitations:

HTTP is a synchronous protocol. The client needs to wait for the server to respond. Web browsers have this requirement, but it comes at the expense of scalability. In the IoT world, large numbers of devices and potentially unreliable or high-latency networks make synchronous communication problematic. Asynchronous messaging protocols are more suitable for IoT applications. Sensors send readings, allowing the network to determine the best route and time to deliver them to target devices and services.

HTTP is one-way. The client must initiate the connection. In IoT applications, devices or sensors are typically clients, meaning they cannot passively receive commands from the network.

HTTP is a 1-1 protocol. The client makes a request and the server responds. Delivering messages to all devices on the network is difficult and expensive, a common use case in IoT applications.

HTTP is a heavyweight protocol with many headers and rules. It is not suitable for restricted networks.

For these reasons, most high-performance, scalable systems use asynchronous message buses for internal data exchange rather than Web services. In fact, the most popular messaging protocol used in enterprise middleware systems is called AMQP (Advanced Message Queuing Protocol). However, in high-performance environments, computing power and network latency are usually not an issue. AMQP strives for reliability and interoperability in enterprise applications. It has a huge feature set but is not suitable for resource-constrained IoT applications.

In addition to AMQP, there are other popular messaging protocols. For example, XMPP (Extensible Messaging and Presence Protocol) is a peer-to-peer instant messaging (IM) protocol. It is highly dependent on features that support IM use cases, such as presence and media connectivity. It requires significantly more resources on both the device and the network than MQTT.

So, why is MQTT so lightweight and flexible? Because a key feature of the MQTT protocol is the publish and subscribe model. Like all messaging protocols, it separates publishers and consumers of data.

Let's first take a look at what a typical MQTT network topology looks like, and then introduce related concepts.

Role

Implementing the MQTT protocol requires communication between the client and the server. During the communication process, there are three identities in the MQTT protocol: publisher (Publish), agent (Broker) (server), and subscriber (Subscribe). Among them, the publisher and subscriber of the message are clients, the message agent is the server, and the publisher of the message can be the subscriber at the same time . When application messages are transmitted via MQTT, they have an associated quality of service (QoS) and topic (Topic).

Complete process

1) Start the server agent.
2) The subscriber subscribes to the relevant topic with the server agent.
3) The publisher publishes topic information to the server agent.
4) The server agent pushes messages to all subscribers who subscribe to the topic.

Client Client
is a program or device that uses MQTT. The client always connects to the server over the network. it can

1) Publish application messages to other related clients.
2) Subscribe to request to receive relevant application messages
3) Unsubscribe to remove the request to receive app messages.
4) Disconnect from the server.

Server
A program or device that acts as an intermediary between clients sending messages and clients requesting subscriptions. Server

1) Accept network connections from clients
2) Accept application messages published by the client
3) Handle the client's subscription and unsubscription requests.
4) Forward application messages to eligible clients to subscribe.

Related terms

Subscription Subscription
includes a topic filter (Topic Filter) and a maximum quality of service (QoS) level. Subscriptions are associated with a single session. A session can contain more than one subscription. Each subscription to a session has a different topic filter.

Topic Name
is a label attached to application messages that is known to the server and matches the subscription. The server sends a copy of the application message to each matching client subscription.
Topic name is used to identify the channel in which the message has been published. Subscribers use it to confirm receipt of the information they care about. It is a hierarchical structure, using slash "/" as the separator (this is somewhat similar to restful style).

Topic filter
An expression contained in a Topic Filter subscription is used to represent one or more related topics. Theme filters can use wildcards.

Topics can also be filtered by wildcards. Among them, + can filter a level, and # can only appear at the end of the topic to filter any level of level.
It is worth noting that MQTT allows the use of wildcards to subscribe to topics, but does not allow the use of wildcards to broadcast.

for example:

building-b/floor-5：代表B楼5层的设备。

+/floor-5：代表任何一个楼的5层的设备。

building-b/#：代表B楼所有的设备。

Session
State interaction between Session client and server. Some sessions last as long as the network connection, others can extend across multiple consecutive network connections on the client and server.

Control message MQTT Control Packet
is an information packet sent through a network connection. The MQTT specification defines fourteen different types of control messages, one of which (PUBLISH message) is used to transmit application messages.

The messages transmitted by MQTT are divided into two parts: topic and payload:

(1) Topic can be understood as the type of message. After a subscriber subscribes, he will receive the message content (payload) of the topic;
(2) Payload can be understood as the content of the message, which refers to the specific content that the subscriber wants to use.

Network structure

design specifications

Since the environment of the Internet of Things is very special, MQTT follows the following design principles:

(1) Streamlined and do not add dispensable functions;
(2) Publish/subscribe (Pub/Sub) mode to facilitate message transmission between sensors and one-to-many message publishing;
(3) Allow users to dynamically create themes with zero operation and maintenance costs;
(4) Reduce the transmission volume to a minimum to improve transmission efficiency;
(5) Taking factors such as low bandwidth, high latency, and unstable network into consideration;
(6) Support continuous session control;
(7) Understand that the computing power of the client may be low;
(8) Provide service quality management;
(9) Assuming that the data is agnostic, the type and format of the transmitted data are not required to maintain flexibility.

Features

Open message protocol, easy to implement
Publish and subscribe mode, one-to-many message publishing
Based on TCP/IP network connection, it provides orderly, lossless, two-way connection.
1-byte fixed header, 2-byte heartbeat message, minimizing transmission overhead and protocol exchange, effectively reducing network traffic.
Message QoS support, reliable transmission guarantee

application

The MQTT protocol is widely used in the Internet of Things, mobile Internet, intelligent hardware, Internet of Vehicles, electric energy and other fields.

IoT M2M communication, IoT big data collection
Android message push, WEB message push
Mobile instant messaging, such as Facebook Messenger
Smart hardware, smart furniture, smart appliances
Vehicle networking communication, electric station pile collection
smart city, telemedicine, distance education
Power, oil and energy industry markets

Subscriptions, topics, sessions in the MQTT protocol

1. Subscription

Subscriptions include topic filters (Topic Filter) and maximum quality of service (QoS). A subscription is associated with a session. A session can contain multiple subscriptions. Each subscription in each session has a different topic filter.

2. Session

After each client establishes a connection with the server, it is a session, and there is stateful interaction between the client and the server. A session exists between a network and may span multiple consecutive network connections between a client and a server.

3. Topic Name

A tag attached to an application message that matches the server's subscription. The server will send the message to every client subscribed to the matching tag.

4. Topic Filter

A wildcard filter for topic names, used in subscription expressions to indicate multiple topics matched by the subscription.

5. Payload

The specific content received by the message subscriber.

A brief introduction to the MQTT-SN protocol

This chapter was found in the download of the MQTT code source code and supplemented after consulting the information.

MQTT-SN (Sensor Networks) is the sensor version of the MQTT protocol. MQTT based on the TCP protocol is still too heavy-loaded for some sensors. These sensors may only have dozens of bytes of memory and cannot run the TCP protocol. MQTT-SN has appropriately optimized MQTT for memory-limited microprocessors so that it can run on such processors.

In other words, MQTT and MQTT-SN need to be converted to communicate with each other. The conversion operation is completed by the MQTT-SN gateway.

MQTT-SN name origin

The original name was MQTT-S, but it caused people's misunderstanding, so it was renamed to MQTT-SN:

As part of the job of applying the same or similar license terms to the MQTT-S specification as those on the MQTT specification, we are proposing a small name change. The new name would be MQTT-SN, standing for exactly the same long name, MQTT for Sensor Networks. Some people had assumed that the S in MQTT-S stood for secure, so we hope this change will avoid that confusion. – Ian Craggs

Purpose of MQTT-SN

MQTT for Sensor Networks is aimed at embedded devices on non-TCP/IP networks, such as Zigbee. MQTT-SN is a publish/subscribe messaging protocol for wireless sensor networks (WSN), with the aim of extending the MQTT protocol beyond the reach of TCP/IP infrastructure for Sensor and Actuator solutions.

A specific version of the MQTT protocol for adaptive sensing devices (abbreviated as SA), generally runs in embedded battery-driven electronic components, and is transmitted through a wireless sensor network (WSN) based on the wireless low-speed network based on the IEEE 802.15.4 specification. It also has enterprise-level features with data-centric subscribe/publish features.

In short, it is customized for low-power, battery-driven, devices with limited processing and storage, and electronic devices that do not support TCP/IP protocol stack networks, such as the common ZigBee (or XBee), which is agnostic to the underlying transmission network it relies on. But as long as the network supports two-way data transmission and gateways, it can support the higher-layer MQTT-SN protocol transmission. For example, the simple datagram service only needs to support a source endpoint to send data to a specific destination endpoint, which is enough to support the MQTT-SN protocol. The broadcast datagram transport service is also required for the automatic discovery process of gateways and endpoints. To reduce broadcast storms, MQTT-SN defines broadcast path depth (broadcast range or broadcast radius).

some nouns and terms

topic id, topic identifier, a natural number represented by two bytes of 16 bits (java language short type, range 0-65535), corresponding to the topic topic name
Gateway/server (gateway/server), uniformly called gateway in MQTT-SN, mainly handles interaction with MQTT-SN clients, abbreviated as gateway
MQTT-SN terminals and clients are collectively called clients. They are actually embedded sensing devices or electronic components with limited resources and run in a wireless area personal network.
IEEE 802.15.4, the entire data limit of the complete stack is 128 bytes, and UDP is generally selected (compared to the 20-byte TCP protocol, the UDP message header only requires 8 bytes) protocol to transmit data
Low-speed network/current network refers to LR-WPAN (low-rate wireless personal area network,), low-rate wireless personal area network

MQTT-SN VS MQTT

Although MQTT-SN is designed to be as close as possible to MQTT, those low-power, battery-driven, resource-constrained devices are in network scenarios with low-speed bandwidth, high connection failures, and physical layer packets of 128 bytes. The documentation makes the following differences:

The CONNECT message is split into three messages (CONNECT, WILLTIPIC*, WILLMSG*), the latter two are used by the client to transfer the will topic and will message, etc.
In the PUBLISH message, the topic (topic name) is replaced by a two-byte natural number (topic id). This requires the client to obtain the corresponding topic id through the registration process.
Predefine (define in advance) topic id and topic name, eliminating the need for intermediate registration processes. Clients and gateways are required to specify them in their firmware in advance.
The automatic discovery mechanism introduced by the protocol can help clients discover potential gateways. If there are multiple gateways, they can coordinate with each other to be master-slave, mutual backup or load balancing.
"clean session" can be used for subscription persistence, and has also been extended to work on will features (will topic and will message)
Add offline keep-alive mechanism support for dormant devices. When there is a message, the agent needs to cache it and send it again when the client wakes up.

MQTT-SN architecture diagram

In the MQTT-SN architecture diagram, there are three components:

MQTT-SN client
The MQTT-SN gateway can exist alone or be integrated into the MQTT server. Need to undertake the conversion work between MQTT-SN and MQTT protocols
The MQTT-SN forwarder is responsible for forwarding the current client data to the gateway that is not directly accessible. For the client, when the gateway is not directly accessible, the role of the forwarder becomes prominent. The forwarder encapsulates the MQTT-SN message and forwards it to the gateway, and decapsulates the message from the gateway and sends it to the client. The gateway cannot tamper with the original data.

MQTT-SN transport gateway

MQTT-SN gateway transmission method, the picture below is clear at a glance. The transparent gateway will establish a TCP connection channel to the MQTT server for each client. This will consume more gateway network resources, but the model is simple.

The aggregation gateway only establishes one TCP connection channel to the MQTT server, and all clients share one channel, which is very economical.

The gateway needs to decide which messages need to interact with the remote MQTT Server, such as only selecting PUBLISH and SUBSCRIBLE messages sent by the client.

Reprinted from: https://mp.weixin.qq.com/s?__biz=MzI0OTQwNDQxMw==&mid=2247484577&idx=1&sn=6ae197287cd0cbd26c0cc8873e02bd28&chksm=e9934a33dee4c325f9f2b77c9bca87e 7785787d59a4c182ffe48d4e7d2a240130f511c9c6108&scene=27

Quick understanding of MQTT protocol