Objective
Immediately after the first introduction, this article is the second, the main carding MQTT-SN 1.2 protocol defined in the message format.
Generic message Format
message Header |
Other variable parts |
2/4 byte representation |
N-Byte composition |
Message header
length |
Message Type |
1 or 3 bytes |
1 bytes |
- The length is either 1 bytes, or 3 bytes, and itself is included. A byte can represent a length of 256, and in general, it is fully sufficient.
- Just determine if the first byte is 0x01, if that length is 3 bytes, the remaining two bytes will represent the true message length, the maximum length is 65535
- Otherwise the length is a byte representation, 256 lengths, most of the message length is one byte unless specifically reminded
Note:
MQTT-SN不支持消息的分片和重组。底层网络所定义数据包长度若小于MQTT-SN消息的最大长度,自身进行的分片和重组,对MQTT-SN协议本身不受影响。
MQTT-SN message Types
MQTT-SN defines a large number of message types, more than 25, feeling some head big.
Message Type value |
Message type name |
Description |
0x00 |
ADVERTISE |
Broadcast messages |
0x01 |
Searchgw |
Find a Gateway |
0x02 |
Gwinfo |
Gateway Information |
0x03 |
Reserved |
Not used to |
0x04 |
CONNECT |
Initiating a connection |
0x05 |
CONNACK |
Connection Confirmation |
0x06 |
Willtopicreq |
Wills Subject Request |
0x07 |
Willtopic |
Probate Subject Confirmation |
0x08 |
Willmsgreq |
Wills Message Request |
0x09 |
Willmsg |
Confirmation of Probate Message |
0x0A |
REGISTER |
Register subject |
0x0B |
Regack |
Registration Confirmation |
0x0C |
PUBLISH |
Publish a message |
0x0D |
Puback |
Release Confirmation |
0x0E |
Pubcomp |
Post link message |
0x0F |
Pubrec |
Post link message |
0x10 |
Pubrel |
Post link message |
0x11 |
Reserved |
Reserved fields |
0x12 |
SUBSCRIBE |
Subscribe to Topics |
0x13 |
SUBACK |
Subscription Confirmation |
0x14 |
Unsubscribe |
Unsubscribe |
0x15 |
Unsuback |
Unsubscribe Confirmation |
0x16 |
PINGREQ |
Ping request |
0x17 |
Pingresp |
Ping response |
0x18 |
DISCONNECT |
Disconnect |
0x19 |
Reserved |
Reserved fields |
0x1A |
Willtopicupd |
Probate Theme Updates |
0x1B |
Willtopicresp |
Confirmation of Probate Subject Renewal |
0x1C |
Willmsgupd |
Renewal of Wills Message |
0x1D |
Willmsgresp |
Confirmation of renewal of probate message |
0x1e-0xfd |
Reserved |
Reserved fields |
0xFE |
Forwarding Encapsulation Flags |
For forwarding |
Message variable part
There are many mutable fields, compared to MQTT:
- Duration Length field (Duration)
- The identifier flags are different, as explained in the table below
- Gateway address (GWADD), variable length, but dependent on the underlying network, 2 byte lengths in the ZigBee network
- One byte Gateway ID (GWID)
- Protocol ID (ProtocolId), one byte, unique value 0x01, unified Representation protocol name and protocol name
- Broadcast path hop count (broadcast path depth/broadcast radiation range), Radius, one byte, 0x00 means broadcast to all nodes in the current network
- Connect/register/subscribe/publish and other messages will contain the return code Recode code, see the table below
return value |
return value meaning |
0x00 |
Accept Request (Accepted) |
0x01 |
Due to congestion rejection (rejected:congestion), it is generally necessary for the receiver to wait t_wait long |
0x02 |
Rejected because of an illegal subject identifier (rejected:invalid topic ID) |
0x03 |
No support denied (Rejected:not supported) |
0x04-0xff |
Reserved, not used to |
Specific Message Format description
The gateway periodically broadcasts all clients and nodes under the current network for the client to discover the available gateways.
byte index |
represents content |
Description |
0 |
Length |
0x05 |
1 |
Msgtype |
0x00 |
2 |
Gwid |
The gateway needs to have its own identifier contained within it |
3-4 |
Duration |
Time of the next broadcast interval for the gateway, in units of seconds |
Searchgw
byte index |
represents content |
Description |
0 |
Length |
0x03 |
1 |
Msgtype |
0x01 |
2 |
Radius |
Broadcast radius depth, but also just to the current network transport layer |
The client actively looks for the gateway to broadcast the message, the broadcast path range is limited by the current network environment of the client deployment density, such as only 1-hop broadcast in a very dense network environment, clients can each other access to each other.
Gwinfo
byte index |
represents content |
Description |
0 |
Length |
Dynamic determination |
1 |
Msgtype |
0x02 |
2 |
Gwid |
Gateway ID |
3-n |
gwadd* |
A gateway address that is present only when a message is issued by the client |
Gwinfo as a response to the SEARCHGW message:
- No Gwadd field if issued by Gateway
- If you are from the client, you need to include the gateway address
CONNECT
The client sends a message to the gateway to establish a connection.
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x04 |
2 |
Flags |
Flag bit |
3 |
ProtocolId |
0X01, which represents the protocol version and Protocol name |
4-5 |
Duration |
Length of survival duration |
6-n |
ClientId |
The client identifier, a 1-23-byte string representation |
The Connect message flag bit is specified as follows:
DUP |
QoS |
Retain |
| would
cleansession |
Topicidtype |
Bit 7 |
6,5 |
4 |
3 |
2 |
1,0 |
X |
X |
X |
0/1 |
0/1 |
X |
- 0/1 indicates a specific value to be determined
- X indicates no use to
Flag bits used in flags:
- Will: If 1, the client may later request a testamentary subject and a testamentary message
- Cleansession: not only for subscription persistence, but also for extension to testamentary subject and probate messages
CONNACK
The gateway responds to the client by sending a connect message.
byte index |
represents content |
Description |
0 |
Length |
0x03 |
1 |
Msgtype |
0x05 |
2 |
ReturnCode |
Accept value 0x00, reject as 0x01-0x03, see Recodecode definition above |
Willtopicreq
Depending on the will field in the client connect flag bit True, the gateway issues a testamentary request to the client in the following format:
byte index |
represents content |
Description |
0 |
Length |
0x02 |
1 |
Msgtype |
0x06 |
Only the head part, very simple.
Willtopic
The client requests a response message as a gateway Willtopicreq. The following is a normal version of the WILLTOPIC message:
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x07 |
2 |
Flags |
Flag bit |
3-n |
Willtopic |
Wills Theme |
The flag at this point is as follows
DUP |
QoS |
Retain |
| would
cleansession |
Topicidtype |
Bit 7 |
6,5 |
4 |
3 |
2 |
1,0 |
X |
0x00-0x02 |
0/1 |
X |
X |
X |
The empty Willtopic is also allowed, on two bytes, for the client to request the deletion of the corresponding testamentary subject and message that already exists on the server side.
byte index |
represents content |
Description |
0 |
Length |
0x02 |
1 |
Msgtype |
0x07 |
Willmsgreq
Depending on the will field in the client connect flag bit, the gateway sends a request for a testamentary message to the client in the following format:
byte index |
represents content |
Description |
0 |
Length |
0x02 |
1 |
Msgtype |
0x08 |
Only the head part, nothing else.
Willmsg
The client responds to the Gateway Willmsgreq request, which passes the testamentary message to the gateway for saving.
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x09 |
2-n |
Willmsg |
Client Wills |
REGISTER
- Client-to-gateway, request subject identifier (topic ID) for subject (topic name)
- Gateway-to-client, Notification topic (topic name) has been assigned to a subject identifier (topic ID)
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x0A |
2-3 |
TopicID |
The client emits a value of 0x0000; the server emits a subject identifier corresponding to the topic name |
4-5 |
MsgId |
The natural number used to identify the corresponding Regack confirmation |
6-n |
Topicname |
Subject name, not too long, try not to use wildcard characters |
Regack
The response of the client or gateway to the register message.
byte index |
represents content |
Description |
0 |
Length |
0x07 |
1 |
Msgtype |
0x0B |
2-3 |
TopicID |
The subject identifier corresponding to topic name, which is used for publish message publishing |
4-5 |
MsgId |
Natural number to identify the corresponding register message |
6 |
ReturnCode |
0x00 is accepted, other values are rejected |
PUBLISH
Publish messages are used for client or gateway publishing messages by:
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x0C |
2 |
Flags |
Flag bit |
3-4 |
TopicID |
Subject identifier |
5-6 |
MsgId |
A natural value needs to be populated when QoS 1-2 is required; QoS 0 o'clock with a value of 0x0000 |
7-n |
Data |
Specific message content for publishing |
The identity bits are as follows:
DUP |
QoS |
Retain |
| would
cleansession |
Topicidtype |
Bit 7 |
6,5 |
4 |
3 |
2 |
1,0 |
0/1 |
0x00-0x02 |
0/1 |
X |
X |
0b00/0b01/0b10 |
Each field in the identity bit is consistent with the MQTT protocol without much explanation.
Puback
The client/gateway responds only to publish messages for QoS 1/2.
byte index |
represents content |
Description |
0 |
Length |
0x07 |
1 |
Msgtype |
0x0D |
2-3 |
TopicID |
Corresponds to the publish message in TopicID |
4-5 |
MsgId |
Natural number to identify the corresponding register message |
6 |
ReturnCode |
0x00 is accepted, other values are rejected, different values indicate different reasons for rejection |
Handling Publish message Exceptions? The ReturnCode field in the Puback message is reflected in the corresponding value, which requires the recipient to handle the reason for the rejection.
Pubrec, Pubrel, Pubcomp
Only in the publish message of QoS 2 o'clock, Pubrec, Pubrel, Pubcomp will come together, otherwise there is no chance of appearances. The message format is uniform:
byte index |
represents content |
Description |
0 |
Length |
0x04 |
1 |
Msgtype |
0x0f/0x10/0x0e |
2-3 |
MsgId |
Corresponds to the MsgId in the publish message |
SUBSCRIBE
Subscribe a message used by a client to subscribe to a topic.
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x12 |
2 |
Flags |
Flag bit |
3-4 |
MsgId |
Used to determine the corresponding subscription acknowledgement Suback message |
5-n |
Topicid/topicname |
Specific needs to be populated according to Topicidtype in the flags flag bit |
The identity bits are as follows:
DUP |
QoS |
Retain |
| would
cleansession |
Topicidtype |
Bit 7 |
6,5 |
4 |
3 |
2 |
1,0 |
0/1 |
0x00-0x02 |
X |
X |
X |
0b00/0b01/0b10 |
Here, the Topicidtype in the flag bit determines the specific padding value of the Topicid/topicname field in the SUBSCRIBE message: A predefined topic ID, or a short two characters for the subject (topic name), or a direct fill in the subject.
SUBACK
Gateway-client, subscription processing acknowledgement receipt, acceptance of subscription, or rejection for other reasons.
byte index |
represents content |
Description |
0 |
Length |
0x08 |
1 |
Msgtype |
0x13 |
2 |
Flags |
Flag bit |
3-4 |
TopicID |
The gateway accepts its registration, which corresponds to the specific assigned TopicID |
5-6 |
MsgId |
corresponding MsgId value in subscribe message |
7 |
ReturnCode |
0x00 is accepted, other values are rejected |
The identity bits are as follows:
DUP |
QoS |
Retain |
| would
cleansession |
Topicidtype |
Bit 7 |
6,5 |
4 |
3 |
2 |
1,0 |
X |
0x00-0x02 |
X |
X |
X |
X |
The QoS specific value of the SUBACK message flag bit in the gateway based on the actual situation, which should also be known to the client and processed.
Unsubscribe
Unsubscribe the message used by the client to unsubscribe from a topic.
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x14 |
2 |
Flags |
Flag bit |
3-4 |
MsgId |
Used to determine the corresponding unsubscribe confirmation Unsuback message |
5-n |
Topicid/topicname |
Specific needs to be populated according to Topicidtype in the flags flag bit |
The identity bits are as follows:
DUP |
QoS |
Retain |
| would
cleansession |
Topicidtype |
Bit 7 |
6,5 |
4 |
3 |
2 |
1,0 |
X |
X |
X |
X |
X |
0b00/0b01/0b10 |
The only available attribute in the Unsubscribe message flag bit Topicidtype determines the Topicid/topicname field fill value in the unsubscribe message.
Unsuback
Gateway-Client, unsubscribe processing acknowledgement receipt, very simple, 4 byte representation.
byte index |
represents content |
Description |
0 |
Length |
0x04 |
1 |
Msgtype |
0x15 |
2-3 |
MsgId |
Corresponding MsgId value in unsubscribe message |
PINGREQ
Consistent with Pingreq in the MQTT protocol, survival detection.
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x16 |
2-n |
ClientId |
Optional, which indicates that the client hibernation state transitions to wake state to check if the gateway is caching messages for it |
Pingresp
The party that accepts the PINGREQ message, such as the gateway response PINGRESP message, indicates that it is now running OK.
Another intention is that if the wake-up state client sends a PINGREQ message, it receives the PINGRESP message directly, indicating that the gateway is not currently cached for its message to be sent.
byte index |
represents content |
Description |
0 |
Length |
0x02 |
1 |
Msgtype |
0x17 |
Very simple, two bytes means enough.
DISCONNECT
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x18 |
2-3 |
Duration |
Optional, indicating the duration value at which the client is about to enter the sleep state |
- Client-side gateway, the client actively shuts down the current connection, and the gateway responds to the acknowledgement message. Only clients that represent themselves into sleep will be appended with the Duration persistent field in the disconnect message.
- Gateway-to-client, the gateway needs to send a connect message to the gateway and retry the connection if the client receives the disconnect due to an exception that proactively notifies the client to close the connection. No duration fields are populated.
When the gateway receives a message that contains the Duration field disconnect sent to the client to enter hibernation, you can return a 2-byte (cannot package containing duration field) disconnect message to confirm.
Willtopicupd
The client sends the request gateway to update its testamentary theme.
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x1A |
2 |
Flags |
Flag bit |
3-n |
Willtopic |
Testamentary Theme for updates |
The identity bits are as follows:
DUP |
QoS |
Retain |
| would
cleansession |
Topicidtype |
Bit 7 |
6,5 |
4 |
3 |
2 |
1,0 |
X |
0x00-0x02 |
0/1 |
X |
X |
X |
The protocol stipulates that only two bytes of empty willtopicupd are allowed, meaning that the client requests the gateway to delete the saved testamentary subject and testamentary message.
byte index |
represents content |
Description |
0 |
Length |
0x02 |
1 |
Msgtype |
0x1A |
Willtopicresp
Willtopicresp the reply message that is made after the gateway receives WILLTOPICUPD.
byte index |
represents content |
Description |
0 |
Length |
0x03 |
1 |
Msgtype |
0x1B |
2 |
ReturnCode |
0x00 is accepted, other values are rejected |
Willmsgupd
byte index |
represents content |
Description |
0 |
Length |
Dynamic Computing |
1 |
Msgtype |
0x1C |
2-n |
Willmsg |
A testamentary message for updates |
Client-side gateway, confirming the updated testamentary message.
Willmsgresp
Willmsgresp the reply message that is made after the gateway receives WILLMSGUPD.
byte index |
represents content |
Description |
0 |
Length |
0x03 |
1 |
Msgtype |
0x1D |
2 |
ReturnCode |
0x00 is accepted, other values are rejected |
Forwarding Encapsulation
In the MQTT-SN architecture diagram, the MQTT-SN forwarder forwarder works when the client cannot directly access the gateway or the gateway does not exist in the current sensor network region:
- Receive MQTT-SN client message encapsulation and forwarded to upstream gateway
- Unpack the message sent by the upstream gateway and send it directly to the corresponding client
Forwarders Act on the encapsulation and forwarding of messages, which are marshaled and not modified for messages.
Forwarder-to-MQTT-SN message encapsulation Format:
byte index |
represents content |
Description |
0 |
Length |
Decimal indicates that the length is n |
1 |
Msgtype |
0xFE |
2 |
Ctrl |
Contains control exchange information between the gateway and the forwarder, mainly the first two bits contain the RADIUS range |
3-n |
Wireless Node Id |
A wireless node that identifies the intended purpose or needs to receive encapsulated messages |
N+1-m |
MQTT-SN message |
A MQTT-SN message message |
Wireless Node ID (Wireless nodes ID):
- Forwarder---Gateway, wireless Node ID is the wireless Node ID of the forwarder, which makes it easy to tell the Gateway forwarder location
- Gateway---Forwarder, wireless Node ID for gateway wireless Node ID
Control Exchange Field CTRL, single byte, bit indicates meaning:
Summary
MQTT-SN 1.2 specification in the definition of the message format is complete, the next one will be MQTT-SN main process work, can be elaborated.
Original http://www.blogjava.net/yongboy/archive/2015/01/08/422142.html
MQTT-SN protocol Scrambled Message format