MQTT-SN protocol Scrambled Message format

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:

1. Duration Length field (Duration)
2. The identifier flags are different, as explained in the table below
3. Gateway address (GWADD), variable length, but dependent on the underlying network, 2 byte lengths in the ZigBee network
4. One byte Gateway ID (GWID)
5. Protocol ID (ProtocolId), one byte, unique value 0x01, unified Representation protocol name and protocol name
6. Broadcast path hop count (broadcast path depth/broadcast radiation range), Radius, one byte, 0x00 means broadcast to all nodes in the current network
7. 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:

would

DUP	QoS	Retain		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:

1. Will: If 1, the client may later request a testamentary subject and a testamentary message
2. 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

would

DUP	QoS	Retain		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:

would

DUP	QoS	Retain		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:

would

DUP	QoS	Retain		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:

would

DUP	QoS	Retain		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:

would

DUP	QoS	Retain		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:

would

DUP	QoS	Retain		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:

1. Receive MQTT-SN client message encapsulation and forwarded to upstream gateway
2. 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:

bit 7,2	1,0
X	0x00-0x03

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