MQTT-SN protocol Scrambled Message format

Source: Internet
Author: User

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

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.