Timetravel 2024-08-27 snapshot #49
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Stefan Hagen <[email protected]>
sthagen
added
documentation
|
Diff of google produced markdown (part 1): --- mqtt-sn-v2.0-wd-snapshot-20240814T220000Z.md 2024-08-15 00:14:17
+++ mqtt-sn-v2.0-wd-snapshot-20240827T215900Z.md 2024-08-27 23:59:04
@@ -80,13 +80,13 @@
[1.3 Terminology 10](\#1.3-terminology)
-[1.4 Normative references 14](\#1.4-normative-references)
+[1.4 Normative references 15](\#1.4-normative-references)
[1.5 Informative References 15](\#1.5-informative-references)
[1.6 MQTT For Sensor Networks (MQTT-SN) 15](\#1.6-mqtt-for-sensor-networks-(mqtt-sn))
-[1.6.1 MQTT-SN and MQTT Differences 15](\#1.6.1-mqtt-sn-and-mqtt-differences)
+[1.6.1 MQTT-SN and MQTT Differences 16](\#1.6.1-mqtt-sn-and-mqtt-differences)
[1.7 Data representation 16](\#1.7-data-representation)
\ No newline at end of file
@@ -96,492 +96,496 @@
[1.7.3 Four Byte Integer 16](\#1.7.3-four-byte-integer)
-[1.7.4 UTF-8 Encoded String 16](\#1.7.4-utf-8-encoded-string)
+[1.7.4 UTF-8 Encoded String 17](\#1.7.4-utf-8-encoded-string)
-[2 MQTT-SN Control Packet format 18](\#2-mqtt-sn-control-packet-format)
+[2 MQTT-SN Control Packet format 19](\#2-mqtt-sn-control-packet-format)
-[2.1 Structure of an MQTT-SN Control Packet 18](\#2.1-structure-of-an-mqtt-sn-control-packet)
+[2.1 Structure of an MQTT-SN Control Packet 19](\#2.1-structure-of-an-mqtt-sn-control-packet)
-[2.1.1 Packet Header 18](\#2.1.1-packet-header)
+[2.1.1 Packet Header 19](\#2.1.1-packet-header)
-[2.1.2 Length 18](\#2.1.2-length)
+[2.1.2 Length 20](\#2.1.2-length)
-[2.1.3 MQTT-SN Control Packet Type 19](\#2.1.3-mqtt-sn-control-packet-type)
+[2.1.3 MQTT-SN Control Packet Type 20](\#2.1.3-mqtt-sn-control-packet-type)
-[2.2 Packet Identifier 22](\#2.2-packet-identifier)
+[2.2 Packet Identifier 23](\#2.2-packet-identifier)
-[2.3 MQTT-SN Packet Fields 24](\#2.3-mqtt-sn-packet-fields)
+[2.3 MQTT-SN Packet Fields 25](\#2.3-mqtt-sn-packet-fields)
-[2.3.1 Protocol Id 24](\#2.3.1-protocol-versionid)
+[2.3.1 Protocol Id 25](\#2.3.1-protocol-versionid)
-[2.3.2 Radius 24](\#2.3.2-radius)
+[2.3.2 Radius 25](\#2.3.2-radius)
-[2.3.3 Reason Code 24](\#2.3.3-reason-code)
+[2.3.3 Reason Code 25](\#2.3.3-reason-code)
-[2.3.4 Topic Data 29](\#2.3.4-topic-data)
+[2.3.4 Topic Data 32](\#2.3.4-topic-data)
-[2.3.5 Topic Name 29](\#2.3.5-topic-name)
+[2.3.5 Topic Name 32](\#2.3.5-topic-name)
-[2.4 Topic Types 29](\#2.4-topic-types)
+[2.4 Topic Types 32](\#2.4-topic-types)
-[3 MQTT-SN Control Packets 31](\#3-mqtt-sn-control-packets)
+[3 MQTT-SN Control Packets 33](\#3-mqtt-sn-control-packets)
-[3.1 Format of Individual Packets 31](\#3.1-format-of-individual-packets)
+[3.1 ADVERTISE \- Gateway Advertisement 33](\#3.1-advertise---gateway-advertisement)
-[3.1.1 ADVERTISE \- Gateway Advertisement 31](\#3.1.1-advertise---gateway-advertisement)
+[3.1.1 Length & Packet Type 33](\#3.1.1-length-&-packet-type)
-[3.1.1.1 Length & Packet Type 31](\#3.1.1.1-length-&-packet-type)
+[3.1.2 GwId 33](\#3.1.2-gwid)
-[3.1.1.2 GwId 31](\#3.1.1.2-gwid)
+[3.1.3 Duration 33](\#3.1.3-duration)
-[3.1.1.3 Duration 31](\#3.1.1.3-duration)
+[3.2 SEARCHGW \- Search for A Gateway 34](\#3.2-searchgw---search-for-a-gateway)
-[3.1.2 SEARCHGW \- Search for A Gateway 32](\#3.1.2-searchgw---search-for-a-gateway)
+[3.2.1 Length & Packet Type 34](\#3.2.1-length-&-packet-type)
-[3.1.2.1 Length & Packet Type 32](\#3.1.2.1-length-&-packet-type)
+[3.2.2 Radius 34](\#3.2.2-radius)
-[3.1.2.2 Radius 32](\#3.1.2.2-radius)
+[3.3 GWINFO \- Gateway Information 34](\#3.3-gwinfo---gateway-information)
-[3.1.3 GWINFO \- Gateway Information 32](\#3.1.3-gwinfo---gateway-information)
+[3.3.1 Length & Packet Type 35](\#3.3.1-length-&-packet-type)
-[3.1.3.1 Length & Packet Type 33](\#3.1.3.1-length-&-packet-type)
+[3.3.2 GwId 35](\#3.3.2-gwid)
-[3.1.3.2 GwId 33](\#3.1.3.2-gwid)
+[3.3.3 GwAdd 35](\#3.3.3-gwadd)
-[3.1.3.3 GwAdd 33](\#3.1.3.3-gwadd)
+[3.4 CONNECT \- Connection Request 36](\#3.4-connect---connection-request)
-[3.1.4 CONNECT \- Connection Request 33](\#3.1.4-connect---connection-request)
+[3.4.1 Length & Packet Type 38](\#3.4.1-length-&-packet-type)
-[3.1.4.1 Length & Packet Type 34](\#3.1.4.1-length-&-packet-type)
+[3.4.2 Connect Flags 38](\#3.4.2-connect-flags)
-[3.1.4.2 Connect Flags 34](\#3.1.4.2-connect-flags)
+[3.4.3 Packet Identifier 38](\#3.4.3-packet-identifier)
-[3.1.4.3 Packet Identifier 35](\#3.1.4.3-packet-identifier)
+[3.4.4 Protocol Version 38](\#3.4.4-protocol-version)
-[3.1.4.4 Protocol Version 35](\#3.1.4.4-protocol-version)
+[3.4.5 Keep Alive Timer 39](\#3.4.5-keep-alive-timer)
-[3.1.4.5 Keep Alive Timer 35](\#3.1.4.5-keep-alive-timer)
+[3.4.6 Session Expiry Interval 39](\#3.4.6-session-expiry-interval)
-[3.1.4.6 Session Expiry Interval 36](\#3.1.4.6-session-expiry-interval)
+[3.4.7 Maximum Packet Size 40](\#3.4.7-maximum-packet-size)
-[3.1.4.7 Maximum Packet Size 36](\#3.1.4.7-maximum-packet-size)
+[3.4.8 Client Identifier (ClientID) 40](\#3.4.8-client-identifier-(clientid))
-[3.1.4.8 Client Identifier (ClientID) 36](\#3.1.4.8-client-identifier-(clientid))
+[3.4.9 Connect Will Flags (optional, only with Will flag set) 40](\#3.4.9-connect-will-flags-(optional,-only-with-will-flag-set))
-[3.1.4.9 Connect Will Flags (optional, only with Will flag set) 37](\#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set))
+[3.4.10 Will Topic Short or Will Topic Length (optional, only with Will flag set) 41](\#3.4.10-will-topic-datashort-or-will-topic-length-(optional,-only-with-will-flag-set))
-[3.1.4.10 Will Topic Short or Will Topic Length (optional, only with Will flag set) 37](\#3.1.4.10-will-topic-datashort-or-will-topic-length-(optional,-only-with-will-flag-set))
+[3.4.11 Will Payload Length (optional, only with Will flag set) 41](\#3.4.11-will-payload-length-(optional,-only-with-will-flag-set))
-[3.1.4.11 Will Payload Length (optional, only with Will flag set) 37](\#3.1.4.11-will-payload-length-(optional,-only-with-will-flag-set))
+[3.4.12 Will Payload (optional, only with Will flag set) 41](\#3.4.12-will-payload-(optional,-only-with-will-flag-set))
-[3.1.4.12 Will Payload (optional, only with Will flag set) 37](\#3.1.4.12-will-payload-(optional,-only-with-will-flag-set))
+[3.4.13 Authentication Method Length (optional, only with Auth flag set) 41](\#3.4.13-authentication-method-length-(optional,-only-with-auth-flag-set))
-[3.1.4.13 Authentication Method Length (optional, only with Auth flag set) 38](\#3.1.4.13-authentication-method-length-(optional,-only-with-auth-flag-set))
+[3.4.14 Authentication Method (optional, only with Auth flag set) 41](\#3.4.14-authentication-method-(optional,-only-with-auth-flag-set))
-[3.1.4.14 Authentication Method (optional, only with Auth flag set) 38](\#3.1.4.14-authentication-method-(optional,-only-with-auth-flag-set))
+[3.4.15 Authentication Data Length (optional, only with Auth flag set) 42](\#3.4.15-authentication-data-length-(optional,-only-with-auth-flag-set))
-[3.1.4.15 Authentication Data Length (optional, only with Auth flag set) 38](\#3.1.4.15-authentication-data-length-(optional,-only-with-auth-flag-set))
+[3.4.16 Authentication Data (optional, only with Auth flag set) 42](\#3.4.16-authentication-data-(optional,-only-with-auth-flag-set))
-[3.1.4.16 Authentication Data (optional, only with Auth flag set) 38](\#3.1.4.16-authentication-data-(optional,-only-with-auth-flag-set))
+[3.4.17 CONNECT Actions 42](\#3.4.17-connect-actions)
-[3.1.4.17 CONNECT Actions 38](\#3.1.4.17-connect-actions)
+[3.5 CONNACK \- Connect Acknowledgement 43](\#3.5-connack---connect-acknowledgement)
-[3.1.5 CONNACK \- Connect Acknowledgement 39](\#3.1.5-connack---connect-acknowledgement)
+[3.5.1 Length & Packet Type 44](\#3.5.1-length-&-packet-type)
-[3.1.5.1 Length & Packet Type 40](\#3.1.5.1-length-&-packet-type)
+[3.5.2 Connack Flags 44](\#3.5.2-connack-flags)
-[3.1.5.2 Connack Flags 40](\#3.1.5.2-connack-flags)
+[3.5.3 Packet Identifier 45](\#3.5.3-packet-identifier)
-[3.1.5.3 Packet Identifier 41](\#3.1.5.3-packet-identifier)
+[3.5.4 Reason Code 45](\#3.5.4-reason-code)
-[3.1.5.4 Reason Code 41](\#3.1.5.4-reason-code)
+[3.5.5 Session Expiry Interval 45](\#3.5.5-session-expiry-interval)
-[3.1.5.5 Session Expiry Interval 41](\#3.1.5.5-session-expiry-interval)
+[3.5.6 Authentication Method Length (optional, only with Auth flag set) 45](\#3.5.6-authentication-method-length-(optional,-only-with-auth-flag-set))
-[3.1.5.6 Authentication Method Length (optional, only with Auth flag set) 41](\#3.1.5.6-authentication-method-length-(optional,-only-with-auth-flag-set))
+[3.5.7 Authentication Method (optional, only with Auth flag set) 45](\#3.5.7-authentication-method-(optional,-only-with-auth-flag-set))
-[3.1.5.7 Authentication Method (optional, only with Auth flag set) 41](\#3.1.5.7-authentication-method-(optional,-only-with-auth-flag-set))
+[3.5.8 Authentication Data Length (optional, only with Auth flag set) 45](\#3.5.8-authentication-data-length-(optional,-only-with-auth-flag-set))
-[3.1.5.8 Authentication Data Length (optional, only with Auth flag set) 41](\#3.1.5.8-authentication-data-length-(optional,-only-with-auth-flag-set))
+[3.5.9 Authentication Data (optional, only with Auth flag set) 45](\#3.5.9-authentication-data-(optional,-only-with-auth-flag-set))
-[3.1.5.9 Authentication Data (optional, only with Auth flag set) 41](\#3.1.5.9-authentication-data-(optional,-only-with-auth-flag-set))
+[3.5.10 Assigned Client Identifier 45](\#3.5.10-assigned-client-identifier)
-[3.1.5.10 Assigned Client Identifier 41](\#3.1.5.10-assigned-client-identifier)
+[3.6 AUTH \- Authentication Exchange 46](\#3.6-auth---authentication-exchange)
-[3.1.6 AUTH \- Authentication Exchange 42](\#3.1.6-auth---authentication-exchange)
+[3.6.1 Length & Packet Type 46](\#3.6.1-length-&-packet-type)
-[3.1.6.1 Length & Packet Type 42](\#3.1.6.1-length-&-packet-type)
+[3.7.2 Packet Identifier 47](\#3.7.2-packet-identifier)
-[3.1.7.2 Packet Identifier 42](\#3.1.7.2-packet-identifier)
+[3.6.2 Reason Code 47](\#3.6.2-reason-code)
-[3.1.6.2 Reason Code 42](\#3.1.6.2-reason-code)
+[3.6.3 Auth Method Length 47](\#3.6.3-auth-method-length)
-[3.1.6.3 Auth Method Length 43](\#3.1.6.3-auth-method-length)
+[3.6.4 Auth Method 47](\#3.6.4-auth-method)
-[3.1.6.4 Auth Method 43](\#3.1.6.4-auth-method)
+[3.6.5 Auth Data 47](\#3.6.5-auth-data)
-[3.1.6.5 Auth Data 43](\#3.1.6.5-auth-data)
+[3.6.6 Auth Actions 47](\#3.6.6-auth-actions)
-[3.1.6.6 Auth Actions 43](\#3.1.6.6-auth-actions)
+[3.7 REGISTER \- Register Topic Alias Request 47](\#3.7-register---register-topic-alias-request)
-[3.1.7 REGISTER \- Register Topic Alias Request 43](\#3.1.7-register---register-topic-alias-request)
+[3.7.1 Length & Packet Type 48](\#3.7.1-length-&-packet-type)
-[3.1.7.1 Length & Packet Type 43](\#3.1.7.1-length-&-packet-type)
+[3.7.2 Packet Identifier 48](\#3.7.2-packet-identifier-1)
-[3.1.7.2 Packet Identifier 43](\#3.1.7.2-packet-identifier-1)
+[3.7.3 Topic Alias 48](\#3.7.3-topic-alias)
-[3.1.7.3 Topic Alias 44](\#3.1.7.3-topic-alias)
+[3.7.4 Topic Name 48](\#3.7.4-topic-name)
-[3.1.7.4 Topic Name 44](\#3.1.7.4-topic-name)
+[3.7.5 Register Actions 48](\#3.7.5-register-actions)
-[3.1.7.5 Register Actions 44](\#3.1.7.5-register-actions)
+[3.8 REGACK \- Register Topic Alias Response 49](\#3.8-regack---register-topic-alias-response)
-[3.1.8 REGACK \- Register Topic Alias Response 44](\#3.1.8-regack---register-topic-alias-response)
+[3.8.1 Length & Packet Type 49](\#3.8.1-length-&-packet-type)
-[3.1.8.1 Length & Packet Type 44](\#3.1.8.1-length-&-packet-type)
+[3.8.2 REGACK Flags 49](\#3.8.2-regack-flags)
-[3.1.8.2 REGACK Flags 44](\#3.1.8.2-regack-flags)
+[3.8.3 Packet Identifier 50](\#3.8.3-packet-identifier)
-[3.1.8.3 Packet Identifier 45](\#3.1.8.3-packet-identifier)
+[3.8.4 Topic Alias 50](\#3.8.4-topic-alias)
-[3.1.8.4 Topic Alias 45](\#3.1.8.4-topic-alias)
+[3.8.5 Reason Code 50](\#3.8.5-reason-code)
-[3.1.8.5 Reason Code 45](\#3.1.8.5-reason-code)
+[3.9 Publish Variants 50](\#3.9-publish-variants)
-[3.1.9 Publish Variants 45](\#3.1.9-publish-variants)
+[3.10 PUBWOS \- Publish Without Session 51](\#3.10-pubwos---publish-without-session)
-[3.1.10 PUBWOS \- Publish Without Session 45](\#3.1.10-pubwos---publish-without-session)
+[3.10.1 Length & Packet Type 52](\#3.10.1-length-&-packet-type)
-[3.1.10.1 Length & Packet Type 46](\#3.1.10.1-length-&-packet-type)
+[3.10.2 PUBWOS Flags 52](\#3.10.2-pubwos-flags)
-[3.1.10.2 PUBWOS Flags 46](\#3.1.10.2-pubwos-flags)
+[3.10.3 Topic Data 52](\#3.10.3-topic-data)
-[3.1.10.3 Topic Data 46](\#3.1.10.3-topic-data)
+[3.10.4 Data 52](\#3.10.4-data)
-[3.1.10.4 Data 46](\#3.1.10.4-data)
-
-[3.1.12.7 PUBWOS Actions 46](\#3.1.12.7-pubwos-actions)
+[3.12.7 PUBWOS Actions 52](\#3.10.5-pubwos-actions)
-[3.1.11 PUBLISH \- QoS 0 47](\#3.1.11-publish---qos-0)
+[3.11 PUBLISH \- QoS 0 53](\#3.11-publish---qos-0)
-[3.1.11.1 Length & Packet Type 47](\#3.1.11.1-length-&-packet-type)
+[3.11.1 Length & Packet Type 53](\#3.11.1-length-&-packet-type)
-[3.1.11.2 PUBLISH Flags 47](\#3.1.11.2-publish-flags)
+[3.11.2 PUBLISH Flags 53](\#3.11.2-publish-flags)
-[3.1.11.3 Topic Data 48](\#3.1.11.3-topic-data)
+[3.11.3 Topic Data 54](\#3.11.3-topic-data)
-[3.1.11.4 Data 48](\#3.1.11.4-data)
+[3.11.4 Data 54](\#3.11.4-data)
-[3.1.11.5 PUBLISH \- QoS 0 Actions 48](\#3.1.11.5-publish---qos-0-actions)
+[3.11.5 PUBLISH \- QoS 0 Actions 54](\#3.11.5-publish---qos-0-actions)
-[3.1.12 PUBLISH \- QoS 1 and 2 48](\#3.1.12-publish---qos-1-and-2)
+[3.12 PUBLISH \- QoS 1 and 2 54](\#3.12-publish---qos-1-and-2)
-[3.1.12.1 Length & Packet Type 48](\#3.1.12.1-length-&-packet-type)
+[3.12.1 Length & Packet Type 55](\#3.12.1-length-&-packet-type)
-[3.1.12.2 PUBLISH Flags 49](\#3.1.12.2-publish-flags)
+[3.12.2 PUBLISH Flags 55](\#3.12.2-publish-flags)
-[3.1.12.4 Packet Identifier 49](\#3.1.12.4-packet-identifier)
+[3.12.4 Packet Identifier 56](\#3.12.4-packet-identifier)
-[3.1.12.5 Topic Data 49](\#3.1.12.5-topic-data)
+[3.12.5 Topic Data 56](\#3.12.5-topic-data)
-[3.1.12.6 Data 49](\#3.1.12.6-data)
+[3.12.6 Data 56](\#3.12.6-data)
-[3.1.12.7 PUBLISH Actions 49](\#3.1.12.7-publish-actions)
+[3.12.7 PUBLISH Actions 56](\#3.12.7-publish-actions)
-[3.1.13 PUBACK – Publish Acknowledgement 50](\#3.1.13-puback-–-publish-acknowledgement)
+[3.13 PUBACK – Publish Acknowledgement 57](\#3.13-puback-–-publish-acknowledgement)
-[3.1.13.1 Length & Packet Type 51](\#3.1.13.1-length-&-packet-type)
+[3.13.1 Length & Packet Type 58](\#3.13.1-length-&-packet-type)
-[3.1.13.2 Packet Identifier 51](\#3.1.13.2-packet-identifier)
+[3.13.2 Packet Identifier 58](\#3.13.2-packet-identifier)
-[3.1.13.3 Reason Code 51](\#3.1.13.3-reason-code)
+[3.13.3 Reason Code 58](\#3.13.3-reason-code)
-[3.1.13.4 PUBACK Actions 51](\#3.1.13.4-puback-actions)
+[3.13.4 PUBACK Actions 58](\#3.13.4-puback-actions)
-[3.1.14 PUBREC (QoS 2 delivery part 1\) 51](\#3.1.14-pubrec-(qos-2-delivery-part-1))
+[3.14 PUBREC (QoS 2 delivery part 1\) 58](\#3.14-pubrec-(qos-2-delivery-part-1))
-[3.1.14.1 Length & Packet Type 51](\#3.1.14.1-length-&-packet-type)
+[3.14.1 Length & Packet Type 58](\#3.14.1-length-&-packet-type)
-[3.1.14.2 Packet Identifier 52](\#3.1.14.2-packet-identifier)
+[3.14.2 Packet Identifier 59](\#3.14.2-packet-identifier)
-[3.1.14.3 Reason Code 52](\#3.1.14.3-reason-code)
+[3.14.3 Reason Code 59](\#3.14.3-reason-code)
-[3.1.14.4 PUBREC Actions 52](\#3.1.14.4-pubrec-actions)
+[3.14.4 PUBREC Actions 59](\#3.14.4-pubrec-actions)
-[3.1.15 PUBREL (QoS 2 delivery part 2\) 52](\#3.1.15-pubrel-(qos-2-delivery-part-2))
+[3.15 PUBREL (QoS 2 delivery part 2\) 59](\#3.15-pubrel-(qos-2-delivery-part-2))
-[3.1.15.1 Length & Packet Type 52](\#3.1.15.1-length-&-packet-type)
+[3.15.1 Length & Packet Type 59](\#3.15.1-length-&-packet-type)
-[3.1.15.2 Packet Identifier 52](\#3.1.15.2-packet-identifier)
+[3.15.2 Packet Identifier 59](\#3.15.2-packet-identifier)
-[3.1.15.3 Reason Code 52](\#3.1.15.3-reason-code)
+[3.15.3 Reason Code 60](\#3.15.3-reason-code)
-[3.1.15.4 PUBREL Actions 52](\#3.1.15.4-pubrel-actions)
+[3.15.4 PUBREL Actions 60](\#3.15.4-pubrel-actions)
-[3.1.16 PUBCOMP \- Publish Complete (QoS 2 delivery part 3\) 52](\#3.1.16-pubcomp---publish-complete-(qos-2-delivery-part-3))
+[3.16 PUBCOMP \- Publish Complete (QoS 2 delivery part 3\) 60](\#3.16-pubcomp---publish-complete-(qos-2-delivery-part-3))
-[3.1.16.1 Length & Packet Type 53](\#3.1.16.1-length-&-packet-type)
+[3.16.1 Length & Packet Type 60](\#3.16.1-length-&-packet-type)
-[3.1.16.2 Packet Identifier 53](\#3.1.16.2-packet-identifier)
+[3.16.2 Packet Identifier 60](\#3.16.2-packet-identifier)
-[3.1.16.3 Reason Code 53](\#3.1.16.3-reason-code)
+[3.16.3 Reason Code 60](\#3.16.3-reason-code)
-[3.1.16.4 PUBCOMP Actions 53](\#3.1.16.4-pubcomp-actions)
+[3.16.4 PUBCOMP Actions 60](\#3.16.4-pubcomp-actions)
-[3.1.17 SUBSCRIBE \- Subscribe Request 53](\#3.1.17-subscribe---subscribe-request)
+[3.17 SUBSCRIBE \- Subscribe Request 61](\#3.17-subscribe---subscribe-request)
-[3.1.17.1 Length & Packet Type 54](\#3.1.17.1-length-&-packet-type)
+[3.17.1 Length & Packet Type 61](\#3.17.1-length-&-packet-type)
-[3.1.17.2 SUBSCRIBE Flags 54](\#3.1.17.2-subscribe-flags)
+[3.17.2 SUBSCRIBE Flags 61](\#3.17.2-subscribe-flags)
-[3.1.17.3 Packet Identifier 54](\#3.1.17.3-packet-identifier)
+[3.17.3 Packet Identifier 62](\#3.17.3-packet-identifier)
-[3.1.17.4 Topic Data or Topic Filter 54](\#3.1.17.4-topic-data-or-topic-filter)
+[3.17.4 Topic Data or Topic Filter 62](\#3.17.4-topic-data-or-topic-filter)
-[3.1.17.5 SUBSCRIBE Actions 54](\#3.1.17.5-subscribe-actions)
+[3.17.5 SUBSCRIBE Actions 62](\#3.17.5-subscribe-actions)
-[3.1.18 SUBACK \- Subscribe Acknowledgement 55](\#3.1.18-suback---subscribe-acknowledgement)
+[3.18 SUBACK \- Subscribe Acknowledgement 63](\#3.18-suback---subscribe-acknowledgement)
-[3.1.18.1 Length & Packet Type 56](\#3.1.18.1-length-&-packet-type)
+[3.18.1 Length & Packet Type 64](\#3.18.1-length-&-packet-type)
-[3.1.18.2 Flags 56](\#3.1.18.2-flags)
+[3.18.2 Flags 64](\#3.18.2-flags)
+
+[3.18.3 Topic Data 64](\#3.18.3-topic-data)
-[3.1.18.3 Topic Data 56](\#3.1.18.3-topic-data)
+[3.18.4 Packet Identifier 64](\#3.18.4-packet-identifier)
-[3.1.18.4 Packet Identifier 56](\#3.1.18.4-packet-identifier)
+[3.18.5 Reason Code 64](\#3.18.5-reason-code)
-[3.1.18.5 Reason Code 56](\#3.1.18.5-reason-code)
+[3.19 UNSUBSCRIBE \- Unsubscribe Request 65](\#3.19-unsubscribe---unsubscribe-request)
-[3.1.19 UNSUBSCRIBE \- Unsubscribe Request 56](\#3.1.19-unsubscribe---unsubscribe-request)
+[3.19.1 Length & Packet Type 66](\#3.19.1-length-&-packet-type)
-[3.1.19.1 Length & Packet Type 57](\#3.1.19.1-length-&-packet-type)
+[3.19.2 UNSUBSCRIBE Flags 66](\#3.19.2-unsubscribe-flags)
-[3.1.19.2 UNSUBSCRIBE Flags 57](\#3.1.19.2-unsubscribe-flags)
+[3.19.3 Packet Identifier 66](\#3.19.3-packet-identifier)
-[3.1.19.3 Packet Identifier 57](\#3.1.19.3-packet-identifier)
+[3.19.4 Topic Data or Topic Filter 66](\#3.19.4-topic-data-or-topic-filter)
-[3.1.19.4 Topic Data or Topic Filter 57](\#3.1.19.4-topic-data-or-topic-filter)
+[3.19.4 UNSUBSCRIBE Actions 66](\#3.19.4-unsubscribe-actions)
-[3.1.19.4 UNSUBSCRIBE Actions 57](\#3.1.19.4-unsubscribe-actions)
+[3.20 UNSUBACK \- Unsubscribe Acknowledgement 67](\#3.20-unsuback---unsubscribe-acknowledgement)
-[3.1.20 UNSUBACK \- Unsubscribe Acknowledgement 58](\#3.1.20-unsuback---unsubscribe-acknowledgement)
+[3.20.1 Length & Packet Type 67](\#3.20.1-length-&-packet-type)
-[3.1.20.1 Length & Packet Type 58](\#3.1.20.1-length-&-packet-type)
+[3.20.2 Packet Identifier 67](\#3.20.2-packet-identifier)
-[3.1.20.2 Packet Identifier 58](\#3.1.20.2-packet-identifier)
+[3.20.3 Reason Code 67](\#3.20.3-reason-code)
-[3.1.20.3 Reason Code 58](\#3.1.20.3-reason-code)
+[3.21 PINGREQ \- Ping Request 68](\#3.21-pingreq---ping-request)
-[3.1.21 PINGREQ \- Ping Request 58](\#3.1.21-pingreq---ping-request)
+[3.21.1 Length & Packet Type 68](\#3.21.1-length-&-packet-type)
-[3.1.21.1 Length & Packet Type 59](\#3.1.21.1-length-&-packet-type)
+[3.21.2 Packet Identifier 68](\#3.21.2-packet-identifier)
-[3.1.21.2 Packet Identifier 59](\#3.1.21.2-packet-identifier)
+[3.21.3 Client Identifier (optional) 68](\#3.21.3-client-identifier-(optional))
-[3.1.21.3 Client Identifier (optional) 59](\#3.1.21.3-client-identifier-(optional))
+[3.21.4 PINGREQ Actions 68](\#3.21.4-pingreq-actions)
-[3.1.21.4 PINGREQ Actions 59](\#3.1.21.4-pingreq-actions)
+[3.22 PINGRESP \- Ping Response 69](\#3.22-pingresp---ping-response)
-[3.1.22 PINGRESP \- Ping Response 59](\#3.1.22-pingresp---ping-response)
+[3.22.1 Length & Packet Type 69](\#3.22.1-length-&-packet-type)
-[3.1.22.1 Length & Packet Type 60](\#3.1.22.1-length-&-packet-type)
+[3.22.2 Packet Identifier 69](\#3.22.2-packet-identifier)
-[3.1.22.2 Packet Identifier 60](\#3.1.22.2-packet-identifier)
+[3.22.3 Application Messages Remaining 69](\#3.22.3-application-messages-remaining)
-[3.1.22.3 Application Messages Remaining 60](\#3.1.22.3-application-messages-remaining)
+[3.23 DISCONNECT \- Disconnect Notification 70](\#3.23-disconnect---disconnect-notification)
-[3.1.23 DISCONNECT \- Disconnect Notification 60](\#3.1.23-disconnect---disconnect-notification)
+[3.23.1 Length & Packet Type 71](\#3.23.1-length-&-packet-type)
-[3.1.23.1 Length & Packet Type 61](\#3.1.23.1-length-&-packet-type)
+[3.23.2 Disconnect Flags 71](\#3.23.2-disconnect-flags)
-[3.1.23.2 Disconnect Flags 61](\#3.1.23.2-disconnect-flags)
+[3.23.3 Reason Code 71](\#3.23.3-reason-code)
-[3.1.23.3 Reason Code 61](\#3.1.23.3-reason-code)
+[3.23.4 Session Expiry Interval 72](\#3.23.4-session-expiry-interval)
-[3.1.23.4 Session Expiry Interval 61](\#3.1.23.4-session-expiry-interval)
+[3.23.5 Reason String 72](\#3.23.5-reason-string)
-[3.1.23.5 Reason String 62](\#3.1.23.5-reason-string)
+[3.23.6 DISCONNECT Actions 72](\#3.23.6-disconnect-actions)
-[3.1.23.6 DISCONNECT Actions 62](\#3.1.23.6-disconnect-actions)
+[3.24 WAKEUP \- Wake up request 72](\#3.24-wakeup---wake-up-request)
-[3.1.24 Forwarder Encapsulation 62](\#3.1.25-forwarder-encapsulation)
+[3.24.1 Length & Packet Type 73](\#3.24.1-length-&-packet-type)
-[3.1.24.1 Length 63](\#3.1.25.1-length)
+[3.24.2 WAKEUP Actions 73](\#3.24.2-wakeup-actions)
-[3.1.24.2 Packet Type 63](\#3.1.25.2-packet-type)
+[3.25 Forwarder Encapsulation 73](\#3.25-forwarder-encapsulation)
-[3.1.24.3 Ctrl 63](\#3.1.25.3-ctrl)
+[3.25.1 Length 74](\#3.25.1-length)
-[3.1.24.4 Radius 63](\#3.1.25.4-radius)
+[3.25.2 Packet Type 74](\#3.25.2-packet-type)
-[3.1.24.5 Wireless Node Id 63](\#3.1.25.5-wireless-node-id)
+[3.25.3 Ctrl 74](\#3.25.3-ctrl)
-[3.1.24.6 MQTT SN Packet 63](\#3.1.25.6-mqtt-sn-packet)
+[3.25.4 Radius 74](\#3.25.4-radius)
-[3.1.25 Protection Encapsulation 63](\#3.1.26-protection-encapsulation)
+[3.25.5 Wireless Node Id 74](\#3.25.5-wireless-node-id)
-[3.1.25.1 Length 65](\#3.1.26.1-length)
+[3.25.6 MQTT SN Packet 74](\#3.25.6-mqtt-sn-packet)
-[3.1.25.2 Packet Type 65](\#3.1.26.2-packet-type)
+[3.26 Protection Encapsulation 75](\#3.26-protection-encapsulation)
-[3.1.25.3 Protection Flags 65](\#3.1.26.3-protection-flags)
+[3.26.1 Length 76](\#3.26.1-length)
-[3.1.25.4 Protection Scheme 65](\#3.1.26.4-protection-scheme)
+[3.26.2 Packet Type 76](\#3.26.2-packet-type)
-[3.1.25.5 Sender Identifier 67](\#3.1.26.5-sender-identifier)
+[3.26.3 Protection Flags 77](\#3.26.3-protection-flags)
-[3.1.25.6 Random 67](\#3.1.26.6-random)
+[3.26.4 Protection Scheme 77](\#3.26.4-protection-scheme)
-[3.1.25.7 Crypto Material 68](\#3.1.26.7-crypto-material)
+[3.26.5 Sender Identifier 79](\#3.26.5-sender-identifier)
-[3.1.25.8 Monotonic Counter 68](\#3.1.26.8-monotonic-counter)
+[3.26.6 Random 79](\#3.26.6-random)
-[3.1.25.9 Protected MQTT-SN Packet 68](\#3.1.26.9-protected-mqtt-sn-packet)
+[3.26.7 Crypto Material 80](\#3.26.7-crypto-material)
-[3.1.25.10 Authentication Tag 68](\#3.1.26.10-authentication-tag)
+[3.26.8 Monotonic Counter 80](\#3.26.8-monotonic-counter)
-[4 Operational behavior 69](\#4-operational-behavior)
+[3.26.9 Protected MQTT-SN Packet 80](\#3.26.9-protected-mqtt-sn-packet)
-[4.1 Session state 69](\#4.1-session-state)
+[3.26.10 Authentication Tag 80](\#3.26.10-authentication-tag)
-[4.1.1 Storing Session State 69](\#4.1.1-storing-session-state)
+[4 Operational behavior 81](\#4-operational-behavior)
-[4.1.2 Session Establishment 70](\#4.1.2-session-establishment)
+[4.1 Session state 81](\#4.1-session-state)
-[4.2 Networks and Virtual Connections 71](\#4.2-networks-and-virtual-connections)
+[4.1.1 Storing Session State 81](\#4.1.1-storing-session-state)
-[4.3 Quality of Service levels and protocol flows 72](\#4.3-quality-of-service-levels-and-protocol-flows)
+[4.1.2 Session Establishment 82](\#4.1.2-session-establishment)
-[4.3.1 Publish without session: Any number of deliveries 72](\#4.3.1-publish-without-session:-any-number-of-deliveries)
+[4.2 Networks and Virtual Connections 83](\#4.2-networks-and-virtual-connections)
-[4.3.2 QoS 0: At most once delivery 72](\#4.3.2-qos-0:-at-most-once-delivery)
+[4.3 Quality of Service levels and protocol flows 84](\#4.3-quality-of-service-levels-and-protocol-flows)
-[4.3.3 QoS 1: At least once delivery 73](\#4.3.3-qos-1:-at-least-once-delivery)
+[4.3.1 Publish without session: Any number of deliveries 84](\#4.3.1-publish-without-session:-any-number-of-deliveries)
-[4.3.4 QoS 2: Exactly once delivery 74](\#4.3.4-qos-2:-exactly-once-delivery)
+[4.3.2 QoS 0: At most once delivery 85](\#4.3.2-qos-0:-at-most-once-delivery)
-[4.4 Packet delivery retry 74](\#4.4-packet-delivery-retry)
+[4.3.3 QoS 1: At least once delivery 85](\#4.3.3-qos-1:-at-least-once-delivery)
-[4.4.1 Virtual Connection End 75](\#4.4.1-virtual-connection-end)
+[4.3.4 QoS 2: Exactly once delivery 86](\#4.3.4-qos-2:-exactly-once-delivery)
-[4.4.1 Unacknowledged Packets 76](\#4.4.1-unacknowledged-packets)
+[4.4 Packet delivery retry 87](\#4.4-packet-delivery-retry)
-[4.5 Application Message receipt 76](\#4.5-application-message-receipt)
+[4.4.1 Virtual Connection End 87](\#4.4.1-virtual-connection-end)
-[4.6 Application Message ordering 77](\#4.6-application-message-ordering)
+[4.4.1 Unacknowledged Packets 88](\#4.4.1-unacknowledged-packets)
-[4.7 Topic Names and Topic Filters 77](\#4.7-topic-names-and-topic-filters)
+[4.5 Application Message receipt 89](\#4.5-application-message-receipt)
-[4.7.1 Topic wildcards 77](\#4.7.1-topic-wildcards)
-
-[4.7.1.1 Topic level separator 77](\#4.7.1.1-topic-level-separator)
+[4.6 Application Message ordering 89](\#4.6-application-message-ordering)
-[4.7.1.2 Multi-level wildcard 78](\#4.7.1.2-multi-level-wildcard)
+[4.7 Topic Names and Topic Filters 89](\#4.7-topic-names-and-topic-filters)
-[4.7.1.3 Single-level wildcard 78](\#4.7.1.3-single-level-wildcard)
+[4.7.1 Topic wildcards 89](\#4.7.1-topic-wildcards)
-[4.7.2 Topics beginning with $ 78](\#4.7.2-topics-beginning-with-$)
+[4.7.1.1 Topic level separator 90](\#4.7.1.1-topic-level-separator)
-[4.7.3 Topic semantic and usage 79](\#4.7.3-topic-semantic-and-usage)
+[4.7.1.2 Multi-level wildcard 90](\#4.7.1.2-multi-level-wildcard)
-[4.8 Subscriptions 80](\#4.8-subscriptions)
+[4.7.1.3 Single-level wildcard 90](\#4.7.1.3-single-level-wildcard)
-[4.9 Flow Control 80](\#4.9-flow-control)
+[4.7.2 Topics beginning with $ 91](\#4.7.2-topics-beginning-with-$)
-[4.10 Server redirection 80](\#4.10-server-redirection)
+[4.7.3 Topic semantic and usage 91](\#4.7.3-topic-semantic-and-usage)
-[4.11 Enhanced authentication 80](\#4.11-enhanced-authentication)
+[4.8 Subscriptions 92](\#4.8-subscriptions)
-[4.11.1 Re-authentication 82](\#4.11.1-re-authentication)
+[4.9 Flow Control 92](\#4.9-flow-control)
-[4.12 Handling errors 83](\#4.12-handling-errors)
+[4.10 Server redirection 93](\#4.10-server-redirection)
-[4.12.1 Malformed Packet and Protocol Errors 83](\#4.12.1-malformed-packet-and-protocol-errors)
+[4.11 Enhanced authentication 93](\#4.11-enhanced-authentication)
-[4.12.2 Other errors 83](\#4.12.2-other-errors)
+[4.11.1 Re-authentication 94](\#4.11.1-re-authentication)
-[4.13 Example MQTT-SN Architectures 84](\#4.13-example-mqtt-sn-architectures)
+[4.12 Handling errors 95](\#4.12-handling-errors)
-[4.13.1 Transparent Gateway 85](\#4.13.1-transparent-gateway)
+[4.12.1 Malformed Packet and Protocol Errors 95](\#4.12.1-malformed-packet-and-protocol-errors)
-[4.13.2 Aggregating Gateway 86](\#4.13.2-aggregating-gateway)
+[4.12.2 Other errors 96](\#4.12.2-other-errors)
-[4.14 Gateway Advertisement and Discovery 89](\#4.14-gateway-advertisement-and-discovery)
+[4.13 Example MQTT-SN Architectures 96](\#4.13-example-mqtt-sn-architectures)
-[4.15 Client states 89](\#4.15-client-states)
+[4.13.1 Transparent Gateway 97](\#4.13.1-transparent-gateway)
-[4.15.1 Gateway timers 91](\#4.15.1-gateway-timers)
+[4.13.2 Aggregating Gateway 98](\#4.13.2-aggregating-gateway)
-[4.16 Clean start 92](\#4.16-clean-start)
+[4.14 Gateway Advertisement and Discovery 101](\#4.14-gateway-advertisement-and-discovery)
-[4.17 Topic Registration 92](\#4.17-topic-registration)
+[4.15 Client states 101](\#4.15-client-states)
-[4.18 Topic Mapping and Aliasing 93](\#4.18-topic-mapping-and-aliasing)
+[4.15.1 Gateway timers 103](\#4.15.1-gateway-timers)
-[4.19 Predefined topic aliases and short topic names 93](\#4.19-predefined-topic-aliases-and-short-topic-names)
+[4.16 Clean start 104](\#4.16-clean-start)
-[4.20 Client’s Topic Subscribe/Unsubscribe Procedure 93](\#4.20-client’s-topic-subscribe/unsubscribe-procedure)
+[4.17 Topic Registration 104](\#4.17-topic-registration)
-[4.21 Client’s Publish Procedure 94](\#4.21-client-publish-procedure)
+[4.18 Topic Mapping and Aliasing 105](\#4.18-topic-mapping-and-aliasing)
-[4.22 Gateway’s Publish Procedure 94](\#4.22-gateway-publish-procedure)
+[4.19 Predefined topic aliases and short topic names 105](\#4.19-predefined-topic-aliases-and-short-topic-names)
-[4.23 Keep Alive and PING Procedure 95](\#4.23-keep-alive-and-ping-procedure)
+[4.20 Client’s Topic Subscribe/Unsubscribe Procedure 106](\#4.20-client’s-topic-subscribe/unsubscribe-procedure)
-[4.24 Client’s Disconnect Procedure 95](\#4.24-client’s-disconnect-procedure)
+[4.21 Client Publish Procedure 106](\#4.21-client-publish-procedure)
-[4.25 Sleeping clients 95](\#4.25-sleeping-clients)
+[4.22 Gateway Publish Procedure 106](\#4.22-gateway-publish-procedure)
-[4.26 Retained Messages 97](\#4.26-retained-messages)
+[4.23 Keep Alive and PING Procedure 107](\#4.23-keep-alive-and-ping-procedure)
-[4.27 Optional Features 98](\#4.27-optional-features)
+[4.24 Client’s Disconnect Procedure 107](\#4.24-client’s-disconnect-procedure)
-[**5 Security (Informative) 99**](\#5-security-(informative))
+[4.25 Sleeping clients 107](\#4.25-sleeping-clients)
-[5.1 Introduction 100](\#5.1-introduction)
+[4.26 Retained Messages 110](\#4.26-retained-messages)
-[6 Conformance 101](\#6-conformance)
+[4.27 Optional Features 110](\#4.27-optional-features)
-[**Appendix A. References 102**](\#appendix-a.-references)
+[**5 Security (Informative) 112**](\#5-security-(informative))
-[A.1 Normative References 103](\#a.1-normative-references)
+[5.1 Introduction 113](\#5.1-introduction)
-[A.2 Informative References 103](\#a.2-informative-references)
+[6 Conformance 114](\#6-conformance)
-[**Appendix B. Backwards Compatibility 104**](\#appendix-b.-backwards-compatibility)
+[**Appendix A. References 115**](\#appendix-a.-references)
-[B.1 PUBLISH QoS \-1 (Packet from MQTT-SN 1.2) 104](\#b.1-publish-qos--1-(packet-from-mqtt-sn-1.2))
+[A.1 Normative References 116](\#a.1-normative-references)
-[B.1.1 Length & Packet Type 104](\#b.1.1-length-&-packet-type)
+[A.2 Informative References 116](\#a.2-informative-references)
-[B.1.2 PUBLISH Flags 104](\#b.1.2-publish-flags)
-
-[B.1.3 Topic Id 105](\#b.1.3-topic-id)
+[**Appendix B. Backwards Compatibility 117**](\#appendix-b.-backwards-compatibility)
-[B.1.4 Data 105](\#b.1.4-data)
+[B.1 PUBLISH QoS \-1 (Packet from MQTT-SN 1.2) 117](\#b.1-publish-qos--1-(packet-from-mqtt-sn-1.2))
-[**Appendix C. Security and Privacy Considerations 106**](\#appendix-c.-security-and-privacy-considerations)
+[B.1.1 Length & Packet Type 117](\#b.1.1-length-&-packet-type)
-[**Appendix D. Acknowledgments 107**](\#appendix-d.-acknowledgments)
+[B.1.2 PUBLISH Flags 117](\#b.1.2-publish-flags)
-[D.1 Special Thanks 107](\#d.1-special-thanks)
+[B.1.3 Topic Id 118](\#b.1.3-topic-id)
-[D.2 Participants 107](\#d.2-participants)
+[B.1.4 Data 118](\#b.1.4-data)
-[**Appendix E. Revision History 108**](\#appendix-e.-revision-history)
+[**Appendix C. Security and Privacy Considerations 119**](\#appendix-c.-security-and-privacy-considerations)
-[**Appendix F. Implementation Notes 113**](\#appendix-f.-implementation-notes)
+[**Appendix D. Acknowledgments 120**](\#appendix-d.-acknowledgments)
-[F.1 Support of PUBLISH WITHOUT SESSION 113](\#f.1-support-of-publish-without-session)
+[D.1 Special Thanks 120](\#d.1-special-thanks)
-[F.2 “Best practice” values for timers and counters 113](\#f.2-“best-practice”-values-for-timers-and-counters)
+[D.2 Participants 120](\#d.2-participants)
-[F.3 Mapping of Topic Alias to Topic Names and Topic Filters 113](\#f.3-mapping-of-topic-alias-to-topic-names-and-topic-filters)
+[**Appendix E. Revision History 121**](\#appendix-e.-revision-history)
-[F.4 Exponential Backoff 113](\#f.4-exponential-backoff)
+[**Appendix F. Implementation Notes 126**](\#appendix-f.-implementation-notes)
-[**Appendix G. Notices 115**](\#appendix-g.-notices)
+[F.1 Support of PUBLISH WITHOUT SESSION 126](\#f.1-support-of-publish-without-session)
+
+[F.2 “Best practice” values for timers and counters 126](\#f.2-“best-practice”-values-for-timers-and-counters)
+
+[F.3 Mapping of Topic Alias to Topic Names and Topic Filters 126](\#f.3-mapping-of-topic-alias-to-topic-names-and-topic-filters)
+
+[F.4 Exponential Backoff 126](\#f.4-exponential-backoff)
+[**Appendix G. Notices 128**](\#appendix-g.-notices)
+
# **1 Introduction** {#1-introduction}
\[All text is normative unless otherwise labeled\]
\ No newline at end of file
@@ -654,11 +658,11 @@
An MQTT-SN construct corresponding to the network connection in MQTT. It associates a Network Identity with an MQTT-SN endpoint.
- **Application Message:**
+**Application Message:**
The data carried by the MQTT-SN protocol across the network for the application. When an Application Message is transported by MQTT-SN it contains payload data, a Quality of Service (QoS), and a Topic Name.
- **Client:**
+**Client:**
A program or device that uses MQTT-SN. A Client:
\ No newline at end of file
@@ -733,7 +737,7 @@
A Subscription comprises a Topic Filter and a maximum QoS. A Subscription is associated with a single Session. A Session can contain more than one Subscription. Each Subscription within a Session has a different Topic Filter.
- **Wildcard Subscription:**
+**Wildcard Subscription:**
A Wildcard Subscription is a Subscription with a Topic Filter containing one or more wildcard characters. This allows the subscription to match more than one Topic Name. Refer to [section 4.7.1](\#4.7.1-topic-wildcards) for a description of wildcard characters in a Topic Filter.
\ No newline at end of file
@@ -763,11 +767,11 @@
**Will Message:**
-An Application Message which is published by the Server after the Virtual Connection is deleted in cases where the Virtual Connection is not deleted normally. Refer to [section 3.1.4.9](\#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set)) for information about Will Messages.
+An Application Message which is published by the Server after the Virtual Connection is deleted in cases where the Virtual Connection is not deleted normally. Refer to [section 3.4.9](\#3.4.9-connect-will-flags-(optional,-only-with-will-flag-set)) for information about Will Messages.
**Retained Message:**
-An Application Message which is stored by the Server for a topic on the receipt of a Publish Packet with the retained flag set. When a Client subscribes to a topic with a Retained Message set, the Server sends the Retained Message to the Client, depending on the setting of the Retain Handling Subscribe Flags. Refer to [section 3.1.17.2](\#3.1.17.2-subscribe-flags) and [section 4.26](\#4.26-retained-messages) for more information about Retained Messages.
+An Application Message which is stored by the Server for a topic on the receipt of a Publish Packet with the retained flag set. When a Client subscribes to a topic with a Retained Message set, the Server sends the Retained Message to the Client, depending on the setting of the Retain Handling Subscribe Flags. Refer to [section 3.17.2](\#3.17.2-subscribe-flags) and [section 4.26](\#4.26-retained-messages) for more information about Retained Messages.
**Disallowed Unicode code point:**
\ No newline at end of file
@@ -858,6 +862,8 @@
# - - - 8< - - - rest not fitting in the 64k limit of GitHub comments. |
|
... part 2: # - - - 8< - - - prior diff part not fitting in the 64k limit of GitHub comments.
@@ -858,6 +862,8 @@
Text fields within the MQTT-SN Control Packets are encoded as fixed length UTF-8 strings. UTF-8 [\[RFC3629\]](https://docs.oasis-open.org/mqtt/mqtt/v5.0/cos02/mqtt-v5.0-cos02.html\#RFC3629) is an efficient encoding of Unicode [\[Unicode\]](https://docs.oasis-open.org/mqtt/mqtt/v5.0/cos02/mqtt-v5.0-cos02.html\#Unicode) characters that optimizes the encoding of ASCII characters in support of text-based communications.
Unless stated otherwise all variable length UTF-8 encoded strings can have any length in the range 0 to 65,535 bytes.
+
+![][image1]
| Byte \\ Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -883,6 +889,8 @@
For example, the string A𪛔 which is LATIN CAPITAL Letter A followed by the code point U+2A6D4 (which represents a CJK IDEOGRAPH EXTENSION B character) is encoded as follows:
+![][image2]
+
| Byte \\ BitBit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| byte 1 | ‘A’ (0x41) | | | | | | | |
\ No newline at end of file
@@ -916,6 +924,8 @@
Each MQTT-SN Control Packet contains a Header of format 1 or format 2 as shown below.
+![][image3]
+
| Byte | Use |
| :---: | :---: |
| 1 | Length |
\ No newline at end of file
@@ -923,6 +933,8 @@
Table 4: Packet Header Format 1
+![][image4]
+
| Byte | Use |
| :---: | :---: |
| 1 | Length 0x01 |
\ No newline at end of file
@@ -1065,7 +1077,7 @@
It is possible for a Client to send a PUBLISH packet with Packet Identifier 0x1234 and then receive a different PUBLISH packet with Packet Identifier 0x1234 from its Server before it receives a PUBACK for the PUBLISH packet that it sent.
-![][image1]
+![][image5]
## **2.3 MQTT-SN Packet Fields** {#2.3-mqtt-sn-packet-fields}
\ No newline at end of file
@@ -1177,13 +1189,9 @@
# **3 MQTT-SN Control Packets** {#3-mqtt-sn-control-packets}
-## **3.1 Format of Individual Packets** {#3.1-format-of-individual-packets}
-
-This section specifies the format of the individual MQTT-SN packets.
-
-### **3.1.1 ADVERTISE \- Gateway Advertisement** {#3.1.1-advertise---gateway-advertisement}
+### **3.1 ADVERTISE \- Gateway Advertisement** {#3.1-advertise---gateway-advertisement}
-![][image2]
+![][image6]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1201,11 +1209,11 @@
If the Transport Layer supports multicast, like UDP/IP, the ADVERTISE packet is generally sent using the Multicast Address as destination.
-#### **3.1.1.1 Length & Packet Type** {#3.1.1.1-length-&-packet-type}
+#### **3.1.1 Length & Packet Type** {#3.1.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.1.2 GwId** {#3.1.1.2-gwid}
+#### **3.1.2 GwId** {#3.1.2-gwid}
The *GwId* field is at least 1-byte identifier and uniquely identifies a gateway which is advertising itself in the network.
\ No newline at end of file
@@ -1215,15 +1223,15 @@
If the Gateway has a MAC address, it can be used as *GwId*.
-#### **3.1.1.3 Duration** {#3.1.1.3-duration}
+#### **3.1.3 Duration** {#3.1.3-duration}
The *Duration* field is a 2-byte integer. It specifies the time interval in seconds until the next ADVERTISE packet is transmitted by this gateway period.
The maximum value that can be encoded is approximately 18 hours.
-### **3.1.2 SEARCHGW \- Search for A Gateway** {#3.1.2-searchgw---search-for-a-gateway}
+### **3.2 SEARCHGW \- Search for A Gateway** {#3.2-searchgw---search-for-a-gateway}
-![][image3]
+![][image7]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1239,11 +1247,11 @@
If the Transport Layer supports multicast, like UDP/IP, the SEARCHGW packet is generally sent using the Multicast Address as destination..
-#### **3.1.2.1 Length & Packet Type** {#3.1.2.1-length-&-packet-type}
+#### **3.2.1 Length & Packet Type** {#3.2.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.2.2 Radius** {#3.1.2.2-radius}
+#### **3.2.2 Radius** {#3.2.2-radius}
The transmission radius is also indicated to the underlying network layer when MQTT-SN gives this packet for transmission.
\ No newline at end of file
@@ -1251,9 +1259,9 @@
If a Client or a Gateway forwards the SEARCHGW received, it MUST reduce the Radius value by 1\.
-### **3.1.3 GWINFO \- Gateway Information** {#3.1.3-gwinfo---gateway-information}
+### **3.3 GWINFO \- Gateway Information** {#3.3-gwinfo---gateway-information}
-![][image4]
+![][image8]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1270,21 +1278,21 @@
If the Transport Layer supports multicast, like UDP/IP, the GWINFO packet is generally sent using the Multicast Address as destination.
-#### **3.1.3.1 Length & Packet Type** {#3.1.3.1-length-&-packet-type}
+#### **3.3.1 Length & Packet Type** {#3.3.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.3.2 GwId** {#3.1.3.2-gwid}
+#### **3.3.2 GwId** {#3.3.2-gwid}
The *GwId* field is 1-byte long and uniquely identifies a Gateway in the network.
-#### **3.1.3.3 GwAdd** {#3.1.3.3-gwadd}
+#### **3.3.3 GwAdd** {#3.3.3-gwadd}
The *GwAdd* field has a variable length and contains the address of a Gateway. Its length depends on the type of network over which MQTT-SN operates and is specified by the Length byte. Optional, only included if the packet is sent by a client.
-### **3.1.4 CONNECT \- Connection Request** {#3.1.4-connect---connection-request}
+### **3.4 CONNECT \- Connection Request** {#3.4-connect---connection-request}
-![][image5]
+![][image9]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | 2 | 1 | | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1325,11 +1333,11 @@
The CONNECT packet is sent from the Client to the Gateway to create a Virtual Connection able to create or continue a Session.
-#### **3.1.4.1 Length & Packet Type** {#3.1.4.1-length-&-packet-type}
+#### **3.4.1 Length & Packet Type** {#3.4.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.4.2 Connect Flags** {#3.1.4.2-connect-flags}
+#### **3.4.2 Connect Flags** {#3.4.2-connect-flags}
The Connect Flags is 1 byte field which contains several parameters specifying the behavior of the MQTT-SN Virtual Connection.
\ No newline at end of file
@@ -1342,11 +1350,11 @@
The Gateway MUST validate that the reserved flags in the CONNECT packet are set to 0\. If any of the reserved flags is not 0 it is a Malformed Packet.
-#### **3.1.4.3 Packet Identifier** {#3.1.4.3-packet-identifier}
+#### **3.4.3 Packet Identifier** {#3.4.3-packet-identifier}
Used to identify the corresponding CONNACK packet. It should ideally be populated with a random integer value.
-#### **3.1.4.4 Protocol Version** {#3.1.4.4-protocol-version}
+#### **3.4.4 Protocol Version** {#3.4.4-protocol-version}
The one-byte unsigned value that represents the revision level of the protocol used by the Client.
\ No newline at end of file
@@ -1362,7 +1370,7 @@
A Gateway which supports multiple versions of the MQTT-SN protocol uses the Protocol Version to determine which version of MQTT-SN the Client is using. If the Protocol Version is not 2 and the Gateway does not want to accept the CONNECT packet, the Server MAY send a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version).
-#### **3.1.4.5 Keep Alive Timer** {#3.1.4.5-keep-alive-timer}
+#### **3.4.5 Keep Alive Timer** {#3.4.5-keep-alive-timer}
The Keep Alive is a Two Byte Integer greater than 0 (1 \- 65,535), which is a time interval measured in seconds. It is the maximum time interval that is permitted to elapse between the point at which the Client finishes transmitting one MQTT-SN Control Packet and the point it starts sending the next. It is the responsibility of the Client to ensure that the interval between MQTT-SN Control Packets being sent does not exceed the Keep Alive value. In the absence of sending any other MQTT-SN Control Packets, the Client MUST send a PINGREQ packet.
\ No newline at end of file
@@ -1383,7 +1391,7 @@
The actual value of the Keep Alive is application specific; typically, this is a few minutes. The maximum value of 65,535 is 18 hours 12 minutes and 15 seconds.
-#### **3.1.4.6 Session Expiry Interval** {#3.1.4.6-session-expiry-interval}
+#### **3.4.6 Session Expiry Interval** {#3.4.6-session-expiry-interval}
The Session Expiry Interval is a four-byte integer time interval measured in seconds. If the Session Expiry Interval is set to 0, the Session ends (and state deleted) when a (non SLEEPING) DISCONNECT packet is sent from either the client or gateway.
\ No newline at end of file
@@ -1399,7 +1407,7 @@
The client and gateway between them should negotiate a reasonable and practical session expiry interval according to the network and infrastructure environment in which they are deployed. For example, it would not be practical to set a session expiry interval of many months on a gateway whose hardware is only capable of storing a few client sessions.
-#### **3.1.4.7 Maximum Packet Size** {#3.1.4.7-maximum-packet-size}
+#### **3.4.7 Maximum Packet Size** {#3.4.7-maximum-packet-size}
A Two Byte (16-bit) Integer representing the Maximum Packet Size the Client is willing to accept. If the Maximum Packet Size is set to 0, no limit on the packet size is imposed beyond the limitations in the protocol as a result of the remaining length encoding and the protocol header sizes.
\ No newline at end of file
@@ -1417,7 +1425,7 @@
Where a packet is discarded without being sent, the Gateway could take some diagnostic action including alerting the Server administrator. Such actions are outside the scope of this specification.
-#### **3.1.4.8 Client Identifier (ClientID)** {#3.1.4.8-client-identifier-(clientid)}
+#### **3.4.8 Client Identifier (ClientID)** {#3.4.8-client-identifier-(clientid)}
The Client Identifier (ClientID) identifies the Client to the Gateway. Each Client connecting to the Gateway has a unique ClientID. The ClientID MUST be used by Clients and by Gateway to identify the state that they hold relating to this MQTT-SN Session between the Client and the Gateway.
\ No newline at end of file
@@ -1431,7 +1439,7 @@
The Client Identifier MUST be a UTF-8 Encoded String.
-#### **3.1.4.9 Connect Will Flags (optional, only with *Will* flag set)** {#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set)}
+#### **3.4.9 Connect Will Flags (optional, only with *Will* flag set)** {#3.4.9-connect-will-flags-(optional,-only-with-will-flag-set)}
The Connect optional *Will Flags* is 1 byte field which contains several parameters specifying the handling of the Will Message. It is present only if the Will flag in the Connect *Flags* contains the value 1\.
\ No newline at end of file
@@ -1443,7 +1451,7 @@
* **Will Retain**: Stored in Bit 4, this bit specifies if the Will Message is to be retained when it is published. The Will Message will be retained for a time defined by the server.
-If the Will Flag is set to 1 this indicates that a Will Message MUST be stored on the Server and associated with the Session \[MQTT-SN-3.1.4.9-1\]. The Will Message consists of the Will Topic, and Will Payload fields in the CONNECT Packet. The Will Message MUST be published after the Virtual Connection is deleted or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) \[MQTT-SN--3.1.4.9-2\].
+If the Will Flag is set to 1 this indicates that a Will Message MUST be stored on the Server and associated with the Session \[MQTT-SN-3.4.9-1\]. The Will Message consists of the Will Topic, and Will Payload fields in the CONNECT Packet. The Will Message MUST be published after the Virtual Connection is deleted or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) \[MQTT-SN--3.4.9-2\].
Situations in which the Will Message is published include, but are not limited to:
\ No newline at end of file
@@ -1451,76 +1459,64 @@
* The Client fails to communicate within the Keep Alive time.
* The Server deletes the Virtual Connection because of a protocol error.
-If the Will Flag is set to 1, the Will Topic, and Will Payload fields MUST be present in the Packet \[MQTT-SN-3.1.4.9-3\]. The Will Message MUST be removed from the stored Session State in the Server once it has been published or the Server has received a DISCONNECT packet with a Reason Code of 0x00 (Normal disconnection) from the Client \[MQTT-SN-3.1.4.9-4\].
+If the Will Flag is set to 1, the Will Topic, and Will Payload fields MUST be present in the Packet \[MQTT-SN-3.4.9-3\]. The Will Message MUST be removed from the stored Session State in the Server once it has been published or the Server has received a DISCONNECT packet with a Reason Code of 0x00 (Normal disconnection) from the Client \[MQTT-SN-3.4.9-4\].
The Server SHOULD publish Will Messages promptly after the Virtual Connection is deleted or the Session ends, whichever occurs first. In the case of a Server shutdown or failure, the Server MAY defer publication of Will Messages until a subsequent restart. If this happens, there might be a delay between the time the Server experienced failure and when the Will Message is published.
-#### **3.1.4.10 Will Topic DataShort or Will Topic Length (optional, only with *Will* flag set)** {#3.1.4.10-will-topic-datashort-or-will-topic-length-(optional,-only-with-will-flag-set)}
+#### **3.4.10 Will Topic DataShort or Will Topic Length (optional, only with *Will* flag set)** {#3.4.10-will-topic-datashort-or-will-topic-length-(optional,-only-with-will-flag-set)}
In the case of Will Topic Type being b11 this field will refer to the length of data assigned to the “Will Full Topic Name”, in all other cases, this will be the value used as the Will topic alias or Will short topic name.
-#### **3.1.4.11 Will Payload Length (optional, only with *Will* flag set)** {#3.1.4.11-will-payload-length-(optional,-only-with-will-flag-set)}
+#### **3.4.11 Will Payload Length (optional, only with *Will* flag set)** {#3.4.11-will-payload-length-(optional,-only-with-will-flag-set)}
Contains the length of the Will Payload field.
-#### **3.1.4.12 Will Payload (optional, only with *Will* flag set)** {#3.1.4.12-will-payload-(optional,-only-with-will-flag-set)}
+#### **3.4.12 Will Payload (optional, only with *Will* flag set)** {#3.4.12-will-payload-(optional,-only-with-will-flag-set)}
It contains the content of the Will Message which is published after the Virtual Connection is deleted.
In the case of Topic Type b11 the payload section will be prefixed with a “Will Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Will Payload* field corresponds to the MQTT Will Payload and so it defines the Application Message Payload that is to be published to the Will Topic and this field consists of Binary Data. It has a variable length defined by the Will Payload Length fields.
-#### **3.1.4.13 Authentication Method Length (optional, only with *Auth* flag set)** {#3.1.4.13-authentication-method-length-(optional,-only-with-auth-flag-set)}
+#### **3.4.13 Authentication Method Length (optional, only with *Auth* flag set)** {#3.4.13-authentication-method-length-(optional,-only-with-auth-flag-set)}
-Single byte value (max 0-255 bytes), representing the length of field used to specify the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Single byte value (max 0-255 bytes), representing the length of field used to specify the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.4.14 Authentication Method (optional, only with *Auth* flag set)** {#3.1.4.14-authentication-method-(optional,-only-with-auth-flag-set)}
+#### **3.4.14 Authentication Method (optional, only with *Auth* flag set)** {#3.4.14-authentication-method-(optional,-only-with-auth-flag-set)}
-A UTF-8 Encoded String containing the name of the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+A UTF-8 Encoded String containing the name of the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.4.15 Authentication Data Length (optional, only with *Auth* flag set)** {#3.1.4.15-authentication-data-length-(optional,-only-with-auth-flag-set)}
+#### **3.4.15 Authentication Data Length (optional, only with *Auth* flag set)** {#3.4.15-authentication-data-length-(optional,-only-with-auth-flag-set)}
-Two byte value (max 0-65535 bytes), representing the length of field used to specify the authentication data. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Two byte value (max 0-65535 bytes), representing the length of field used to specify the authentication data. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.4.16 Authentication Data (optional, only with *Auth* flag set)** {#3.1.4.16-authentication-data-(optional,-only-with-auth-flag-set)}
+#### **3.4.16 Authentication Data (optional, only with *Auth* flag set)** {#3.4.16-authentication-data-(optional,-only-with-auth-flag-set)}
-Binary Data containing authentication data. The contents of this data are defined by the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Binary Data containing authentication data. The contents of this data are defined by the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.4.17 CONNECT Actions** {#3.1.4.17-connect-actions}
+#### **3.4.17 CONNECT Actions** {#3.4.17-connect-actions}
Note that a Server MAY support multiple protocols on the same network endpoint. If the Server determines that the protocol is MQTT-SN 2.0 then it validates the connection attempt as follows.
-1. The Server MUST validate that the CONNECT packet matches the format described in [section 3.1.4](\#3.1.4-connect---connection-request) and MUST NOT create a Virtual Connection for this CONNECT if it does not match. \[MQTT-SN-3.1.4.17-1\] The Server MAY send a CONNACK with a Reason Code of 0x80 or greater as described in [section 4.12](\#4.12-handling-errors).
-2. The Server MAY check that the contents of the CONNECT packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail, it MUST NOT create a Virtual Connection for this CONNECT \[MQTT-SN-3.1.4.17-2\]. It MAY send an appropriate CONNACK response with a Reason Code of 0x80 or greater as described in [section 3.1.5](\#3.1.5-connack---connect-acknowledgement) and [section 4.12](\#4.12-handling-errors).
+1. The Server MUST validate that the CONNECT packet matches the format described in [section 3.4](\#3.4-connect---connection-request) and MUST NOT create a Virtual Connection for this CONNECT if it does not match. \[MQTT-SN-3.4.17-1\] The Server MAY send a CONNACK with a Reason Code of 0x80 or greater as described in [section 4.12](\#4.12-handling-errors).
+2. The Server MAY check that the contents of the CONNECT packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail, it MUST NOT create a Virtual Connection for this CONNECT \[MQTT-SN-3.4.17-2\]. It MAY send an appropriate CONNACK response with a Reason Code of 0x80 or greater as described in [section 3.5](\#3.5-connack---connect-acknowledgement) and [section 4.12](\#4.12-handling-errors).
If validation is successful, the Server performs the following steps.
-1. If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) as described in [section 4.12](\#4.12-handling-errors) and MUST delete the Virtual Connection of the existing Client \[MQTT-SN-3.1.4.17-3\]. If the existing Client has a Will Message, that Will Message is published as described in section 3.1.2.5.
-2. The Server MUST perform the processing of Clean Start that is described in [section 4.16](\#4.16-clean-start) \[MQTT-SN-3.1.4.17-4\].
-3. The Server MUST acknowledge the CONNECT packet with a CONNACK packet containing a 0x00 (Success) Reason Code \[MQTT-SN-3.1.4.17-5\].
+1. If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) as described in [section 4.12](\#4.12-handling-errors) and MUST delete the Virtual Connection of the existing Client \[MQTT-SN-3.4.17-3\]. If the existing Client has a Will Message, that Will Message is published as described in [section 3.4.9](\#3.4.9-connect-will-flags-(optional,-only-with-will-flag-set)).
+2. The Server MUST perform the processing of Clean Start that is described in [section 4.16](\#4.16-clean-start) \[MQTT-SN-3.4.17-4\].
+3. The Server MUST acknowledge the CONNECT packet with a CONNACK packet containing a 0x00 (Success) Reason Code \[MQTT-SN-3.4.17-5\].
4. Start Application Message delivery and Keep Alive monitoring.
**Informative comment**
It is recommended that authentication and authorization checks be performed if the Server is being used to process any form of business critical data. If these checks succeed, the Server responds by sending CONNACK with a 0x00 (Success) Reason Code. If they fail, it is suggested that the Server does not send a CONNACK at all, as this could alert a potential attacker to the presence of the MQTT-SN Server and encourage such an attacker to launch a denial of service or password-guessing attack.
-Clients are allowed to send further MQTT Control Packets immediately after sending a CONNECT packet; Clients need not wait for a CONNACK packet to arrive from the Server. If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets \[MQTT-3.1.4-6\].
+Clients must wait for a CONNACK packet with a 0x00 (Success) Reason Code to arrive from the Server before sending any packet that needs a Virtual Connection. The Server MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets \[MQTT-SN-3.4.17-6\].
-**Informative comment**
+### **3.5 CONNACK \- Connect Acknowledgement** {#3.5-connack---connect-acknowledgement}
-Clients typically wait for a CONNACK packet, However, if the Client exploits its freedom to send MQTT-SN Control Packets before it receives a CONNACK, it might simplify the Client implementation as it does not have to police the connected state. The Client accepts that any data that it sends before it receives a CONNACK packet from the Server will not be processed if the Server rejects the connection.
+![][image10]
-**Informative comment**
-
-Clients that send MQTT-SN Control Packets before they receive CONNACK will be unaware of Server information including whether any existing Session is being used.
-
-**Informative comment**
-
-The Server can limit reading from the Network if the Client sends too much data before authentication is complete. This is suggested as a way of avoiding denial of service attacks.
-
-### **3.1.5 CONNACK \- Connect Acknowledgement** {#3.1.5-connack---connect-acknowledgement}
-
-![][image6]
-
| Bit | 7 | 6 | | 5 | | 4 | | 3 | | 2 | | 1 | | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| Byte 1 | Length | | | | | | | | | | | | | |
\ No newline at end of file
@@ -1547,11 +1543,11 @@
The CONNACK packet is sent by the Gateway in response to a CONNECT request from a client.
-#### **3.1.5.1 Length & Packet Type** {#3.1.5.1-length-&-packet-type}
+#### **3.5.1 Length & Packet Type** {#3.5.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.5.2 Connack Flags** {#3.1.5.2-connack-flags}
+#### **3.5.2 Connack Flags** {#3.5.2-connack-flags}
The CONNACK FLAGS is a 1 byte field located at byte 4 which contains flags specifying the behavior of the MQTT-SN Virtual Connection on the gateway. Bits 7-2 of the CONNACK FLAGS are reserved and MUST be set to 0.
\ No newline at end of file
@@ -1575,37 +1571,37 @@
The Client MUST validate that the reserved flags in the CONNACK packet are set to 0\. If any of the reserved flags is not 0 it is a Malformed Packet.
-#### **3.1.5.3 Packet Identifier** {#3.1.5.3-packet-identifier}
+#### **3.5.3 Packet Identifier** {#3.5.3-packet-identifier}
The same value as the Packet Identifier in the CONNECT Packet being acknowledged.
-#### **3.1.5.4 Reason Code** {#3.1.5.4-reason-code}
+#### **3.5.4 Reason Code** {#3.5.4-reason-code}
Byte 5 in the CONNACK header contains the Connect Reason Code. The values for the Connect Reason Code field are shown in Table 9: Reason Code Values. The Server sending the CONNACK packet MUST use one of the Connect Reason Code values.
If a Server sends a CONNACK packet containing a Reason code of 128 or greater it MUST then delete the Virtual Connection.
-#### **3.1.5.5 Session Expiry Interval** {#3.1.5.5-session-expiry-interval}
+#### **3.5.5 Session Expiry Interval** {#3.5.5-session-expiry-interval}
If the Session Expiry Interval is 0, the value of Session Expiry Interval in the CONNECT Packet is used. *The server uses this property to inform the Client that it is using a value other than that sent by the Client in the CONNECT*.
-#### **3.1.5.6 Authentication Method Length (optional, only with *Auth* flag set)** {#3.1.5.6-authentication-method-length-(optional,-only-with-auth-flag-set)}
+#### **3.5.6 Authentication Method Length (optional, only with *Auth* flag set)** {#3.5.6-authentication-method-length-(optional,-only-with-auth-flag-set)}
Single byte value (max 0-255 bytes), representing the length of field used to specify the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.5.7 Authentication Method (optional, only with *Auth* flag set)** {#3.1.5.7-authentication-method-(optional,-only-with-auth-flag-set)}
+#### **3.5.7 Authentication Method (optional, only with *Auth* flag set)** {#3.5.7-authentication-method-(optional,-only-with-auth-flag-set)}
A UTF-8 Encoded String containing the name of the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.5.8 Authentication Data Length (optional, only with *Auth* flag set)** {#3.1.5.8-authentication-data-length-(optional,-only-with-auth-flag-set)}
+#### **3.5.8 Authentication Data Length (optional, only with *Auth* flag set)** {#3.5.8-authentication-data-length-(optional,-only-with-auth-flag-set)}
Two byte value (max 0-65535 bytes), representing the length of field used to specify the authentication data. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.5.9 Authentication Data (optional, only with *Auth* flag set)** {#3.1.5.9-authentication-data-(optional,-only-with-auth-flag-set)}
+#### **3.5.9 Authentication Data (optional, only with *Auth* flag set)** {#3.5.9-authentication-data-(optional,-only-with-auth-flag-set)}
Binary Data containing authentication data. The contents of this data are defined by the authentication method and the state of already exchanged authentication data. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.5.10 Assigned Client Identifier** {#3.1.5.10-assigned-client-identifier}
+#### **3.5.10 Assigned Client Identifier** {#3.5.10-assigned-client-identifier}
The Client Identifier assigned by the gateway when the associated CONNECT packet contained no Client Identifier. If the Client connects using a zero length Client Identifier, the Server MUST respond with a CONNACK containing an Assigned Client Identifier. The Assigned Client Identifier MUST be a new Client Identifier not used by any other Session currently in the Gateway.
\ No newline at end of file
@@ -1619,9 +1615,9 @@
Where a transparent gateway obtains an Assigned Client Identifier which is deemed too large for a device, it should maintain a registry to map shorter gateway generated Client Identifiers with their versions returned from the broker.
-### **3.1.6 AUTH \- Authentication Exchange** {#3.1.6-auth---authentication-exchange}
+### **3.6 AUTH \- Authentication Exchange** {#3.6-auth---authentication-exchange}
-![][image7]
+![][image11]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1638,27 +1634,27 @@
The authentication method and data is first sent by the Client as part of a CONNECT exchange. If the Server requires additional information to complete the authentication, it responds with an AUTH packet to signal that the Client generates and sends another AUTH packet with the required information and so on until the authentication is complete. The server then responds with a CONNACK message.
-#### **3.1.6.1 Length & Packet Type** {#3.1.6.1-length-&-packet-type}
+#### **3.6.1 Length & Packet Type** {#3.6.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.7.2 Packet Identifier** {#3.1.7.2-packet-identifier}
+#### **3.7.2 Packet Identifier** {#3.7.2-packet-identifier}
Used to identify the corresponding CONNECT or, AUTH or CONNACK packet. It should ideally be populated with a random integer value when sent from Client to Server. When sent from Server to Client, it MUST contain the packet identifier of the CONNECT or AUTH packet being responded to.
-#### **3.1.6.2 Reason Code** {#3.1.6.2-reason-code}
+#### **3.6.2 Reason Code** {#3.6.2-reason-code}
Byte 3 in the Auth packet holds the Authentication Reason Code. The values for the Authentication Reason Code field are shown in Table 9: Reason Code Values. The sender of the AUTH Packet MUST use one of the Authenticate Reason Codes.
-#### **3.1.6.3 Auth Method Length** {#3.1.6.3-auth-method-length}
+#### **3.6.3 Auth Method Length** {#3.6.3-auth-method-length}
The length of the auth method string.
-#### **3.1.6.4 Auth Method** {#3.1.6.4-auth-method}
+#### **3.6.4 Auth Method** {#3.6.4-auth-method}
A UTF-8 Encoded String containing the name of the authentication method.
-#### **3.1.6.5 Auth Data** {#3.1.6.5-auth-data}
+#### **3.6.5 Auth Data** {#3.6.5-auth-data}
Binary Data containing authentication data. The contents of this data are defined by the authentication method.
\ No newline at end of file
@@ -1666,13 +1662,13 @@
For a simple cleartext password analogous to MQTT username and password, the SASL PLAIN method can be used.
-#### **3.1.6.6 Auth Actions** {#3.1.6.6-auth-actions}
+#### **3.6.6 Auth Actions** {#3.6.6-auth-actions}
Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-### **3.1.7 REGISTER \- Register Topic Alias Request** {#3.1.7-register---register-topic-alias-request}
+### **3.7 REGISTER \- Register Topic Alias Request** {#3.7-register---register-topic-alias-request}
-![][image8]
+![][image12]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1688,29 +1684,29 @@
The REGISTER packet is sent by a client to a GW for requesting a topic alias value for the included topic name. It is also sent by a GW to inform a client about the topic alias value it has assigned to the included topic name.
-#### **3.1.7.1 Length & Packet Type** {#3.1.7.1-length-&-packet-type}
+#### **3.7.1 Length & Packet Type** {#3.7.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.7.2 Packet Identifier** {#3.1.7.2-packet-identifier-1}
+#### **3.7.2 Packet Identifier** {#3.7.2-packet-identifier-1}
Used to identify the corresponding REGACK packet. It should ideally be populated with a random integer value.
-#### **3.1.7.3 Topic Alias** {#3.1.7.3-topic-alias}
+#### **3.7.3 Topic Alias** {#3.7.3-topic-alias}
If sent by a client, it is coded 0x0000 and is not relevant; if sent by a GW, it contains the topic alias value assigned to the topic name included in the Topic Name field.
-#### **3.1.7.4 Topic Name** {#3.1.7.4-topic-name}
+#### **3.7.4 Topic Name** {#3.7.4-topic-name}
Fixed Length UTF-8 Encoded String Contains the fully qualified topic name.
-#### **3.1.7.5 Register Actions** {#3.1.7.5-register-actions}
+#### **3.7.5 Register Actions** {#3.7.5-register-actions}
As described in [section 4.17](\#4.17-topic-registration).
-### **3.1.8 REGACK \- Register Topic Alias Response** {#3.1.8-regack---register-topic-alias-response}
+### **3.8 REGACK \- Register Topic Alias Response** {#3.8-regack---register-topic-alias-response}
-![][image9]
+![][image13]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | | 1 | | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1729,11 +1725,11 @@
The REGACK packet is sent by a client or by a GW as an acknowledgment to the receipt and processing of a REGISTER packet.
-#### **3.1.8.1 Length & Packet Type** {#3.1.8.1-length-&-packet-type}
+#### **3.8.1 Length & Packet Type** {#3.8.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.8.2 REGACK Flags** {#3.1.8.2-regack-flags}
+#### **3.8.2 REGACK Flags** {#3.8.2-regack-flags}
The REGACK Flags is 1 byte field in Byte position 3 of the REGACK packet.
\ No newline at end of file
@@ -1741,19 +1737,19 @@
* **Topic Type**. This is a 2-bit field in Bit 0 and 1 which determines the format of the topic value. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
-#### **3.1.8.3 Packet Identifier** {#3.1.8.3-packet-identifier}
+#### **3.8.3 Packet Identifier** {#3.8.3-packet-identifier}
The same value as the Packet Identifier in the REGISTER packet being acknowledged.
-#### **3.1.8.4 Topic Alias** {#3.1.8.4-topic-alias}
+#### **3.8.4 Topic Alias** {#3.8.4-topic-alias}
A Topic Alias is an integer value that is used to identify the Topic instead of the Topic Name. This numeric value is used as the Topic Alias.
-#### **3.1.8.5 Reason Code** {#3.1.8.5-reason-code}
+#### **3.8.5 Reason Code** {#3.8.5-reason-code}
Byte 8 in the REGACK packet holds the Register Reason Code. The values for the Register Reason Code field are shown in Table 9: Reason Code Values. The sender of the REGACK Packet MUST use one of the Register Reason Codes.
-### **3.1.9 Publish Variants** {#3.1.9-publish-variants}
+### **3.9 Publish Variants** {#3.9-publish-variants}
MQTT-SN is designed to be optimized for packet size. For this reason, the PUBLISH packet has been split into 3 variants; Variant 1 catering for PUBLISH WITHOUT SESSION where no GW session is required, Variant 2 catering for Quality of Service 0 where no response ACK is required and thus no packet identifier is required and Quality of Service 1 and 2 where a response is expected. The table below breaks down the different versions of the PUBLISH packet and their respective type identifiers.
\ No newline at end of file
@@ -1762,9 +1758,9 @@
| **Publish** | 0x0C | A PUBLISH packet corresponding to Quality of Service (QoS) 0, 1 or 2 |
| **Publish Without Session** | 0x11 | A PUBLISH Packet sent by a Client and does not need not to have an active Session |
-### **3.1.10 PUBWOS \- Publish Without Session** {#3.1.10-pubwos---publish-without-session}
+### **3.10 PUBWOS \- Publish Without Session** {#3.10-pubwos---publish-without-session}
-![][image10]
+![][image14]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | | 2 | | 1 | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | ----- | :---: | :---: | :---: |
\ No newline at end of file
@@ -1781,7 +1777,7 @@
This packet is used by both clients and gateways to publish data for a certain topic.
-The PUBWOS packet does not have a corresponding feature in MQTT. If forwarded to an MQTT connection, PUBWOS packets MUST have their MQTT Quality of Service level set to 0\. \[MQTT-SN-3.1.10-1\]
+The PUBWOS packet does not have a corresponding feature in MQTT. If forwarded to an MQTT connection, PUBWOS packets MUST have their MQTT Quality of Service level set to 0\. \[MQTT-SN-3.10-1\]
**Informative comment**
\ No newline at end of file
@@ -1791,11 +1787,11 @@
PUBWOS packets received by a Gateway are not associated with a MQTT-SN Client Session and can be optionally discarded by the Gateway without being processed for onward delivery.
-#### **3.1.10.1 Length & Packet Type** {#3.1.10.1-length-&-packet-type}
+#### **3.10.1 Length & Packet Type** {#3.10.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.10.2 PUBWOS Flags** {#3.1.10.2-pubwos-flags}
+#### **3.10.2 PUBWOS Flags** {#3.10.2-pubwos-flags}
The PUBWOS Flags field is 1-byte located in the Byte 3 position of the PUBWOS control packet.
\ No newline at end of file
@@ -1804,23 +1800,23 @@
* **Topic Type**. This is a 2-bit field in Bit 0 and 1 which determines the format of the topic data field. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types. **NOTE: only predefined topic alias, short topic or full topic types are allowed in PUBWOS packets.**
* **Retain**: 1 bit field stored in Bit 4 and has the same meaning as with MQTT. The field signifies whether the existing Retained Message for this topic is replaced or kept. For a detailed description of Retained Messages see [section 4.26](\#4.26-retained-messages).
-#### **3.1.10.3 Topic Data** {#3.1.10.3-topic-data}
+#### **3.10.3 Topic Data** {#3.10.3-topic-data}
Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.
-#### **3.1.10.4 Data** {#3.1.10.4-data}
+#### **3.10.4 Data** {#3.10.4-data}
In the case of Topic Alias Type b11 the data section will be prefixed with a “Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
-#### **3.1.12.7 PUBWOS Actions** {#3.1.12.7-pubwos-actions}
+#### **3.10.5 PUBWOS Actions** {#3.10.5-pubwos-actions}
The Client or Server uses a PUBWOS packet to send an Application Message to a Network Address, for possible receipt by a Server or another Client.
-If received by a Client or Server, the PUBWOS packet MUST be treated as if its QoS were 0 \[MQTT-SN-3.1.12.7-1\] as described in [section 3.1.12.7](\#3.1.12.7-publish-actions).
+If received by a Client or Server, the PUBWOS packet MUST be treated as if its QoS were 0 \[MQTT-SN-3.10.5-1\] as described in [section 3.12.7](\#3.12.7-publish-actions).
-### **3.1.11 PUBLISH \- QoS 0** {#3.1.11-publish---qos-0}
+### **3.11 PUBLISH \- QoS 0** {#3.11-publish---qos-0}
-![][image11]
+![][image15]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | | 2 | | 1 | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | ----- | :---: | :---: | :---: |
\ No newline at end of file
@@ -1835,13 +1831,13 @@
Table 29: PUBLISH packet
-This packet is used by both clients and gateways to publish data for a certain topic. PUBLISH QoS 0, 1 & 2 packets received by a Gateway MUST be associated with a valid Client Session \[MQTT-SN-3.1.11-1\].
+This packet is used by both clients and gateways to publish data for a certain topic. PUBLISH QoS 0, 1 & 2 packets received by a Gateway MUST be associated with a valid Client Session \[MQTT-SN-3.11-1\].
-#### **3.1.11.1 Length & Packet Type** {#3.1.11.1-length-&-packet-type}
+#### **3.11.1 Length & Packet Type** {#3.11.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.11.2 PUBLISH Flags** {#3.1.11.2-publish-flags}
+#### **3.11.2 PUBLISH Flags** {#3.11.2-publish-flags}
The PUBLISH Flags field is 1-byte located in Byte 3 position of the PUBLISH control packet.
\ No newline at end of file
@@ -1851,21 +1847,21 @@
* **QoS**: This is a 2-bit field stored in Bit 5 and 6\. QoS has the same meaning as with MQTT indicating the Quality of Service. This field is set to “0b00” for QoS 0\. For a detailed description of the various Quality Of Service levels refer to [section 4.3](\#4.3-quality-of-service-levels-and-protocol-flows).
* **Retain**: 1 bit field stored in Bit 4 and has the same meaning as with MQTT. The field signifies whether the existing Retained Message for this topic is replaced or kept. For a detailed description of Retained Messages see [section 4.26](\#4.26-retained-messages).
-#### **3.1.11.3 Topic Data** {#3.1.11.3-topic-data}
+#### **3.11.3 Topic Data** {#3.11.3-topic-data}
Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.
-#### **3.1.11.4 Data** {#3.1.11.4-data}
+#### **3.11.4 Data** {#3.11.4-data}
In the case of Topic Type b11 the data section will be prefixed with a “Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
-#### **3.1.11.5 PUBLISH \- QoS 0 Actions** {#3.1.11.5-publish---qos-0-actions}
+#### **3.11.5 PUBLISH \- QoS 0 Actions** {#3.11.5-publish---qos-0-actions}
-As described in [section 3.1.12.7](\#3.1.12.7-publish-actions).
+As described in [section 3.12.7](\#3.12.7-publish-actions).
-### **3.1.12 PUBLISH \- QoS 1 and 2** {#3.1.12-publish---qos-1-and-2}
+### **3.12 PUBLISH \- QoS 1 and 2** {#3.12-publish---qos-1-and-2}
-![][image12]
+![][image16]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | | 2 | | 1 | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | ----- | :---: | :---: | :---: |
\ No newline at end of file
@@ -1884,13 +1880,13 @@
This packet is used by both clients and gateways to publish data for a certain topic.
-PUBLISH QoS 0, 1 & 2 packets received by a Gateway MUST be associated with a valid Client Session \[MQTT-SN-3.1.12-1\].
+PUBLISH QoS 0, 1 & 2 packets received by a Gateway MUST be associated with a valid Client Session \[MQTT-SN-3.12-1\].
-#### **3.1.12.1 Length & Packet Type** {#3.1.12.1-length-&-packet-type}
+#### **3.12.1 Length & Packet Type** {#3.12.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.12.2 PUBLISH Flags** {#3.1.12.2-publish-flags}
+#### **3.12.2 PUBLISH Flags** {#3.12.2-publish-flags}
The PUBLISH Flags field is 1-byte located in Byte 3 position of the PUBLISH control packet.
\ No newline at end of file
@@ -1913,23 +1909,23 @@
* **DUP**: 1 bit field stored in Bit 7 and has the same meaning as with MQTT. It notes the duplicate delivery of packets. If the DUP flag is set to “0”, it signifies that the packet is sent for the first time. If the DUP flag is set to “1”, it signifies that the packet was retransmitted or retried.
* **Retain**: 1 bit field stored in Bit 4 and has the same meaning as with MQTT. The field signifies whether an existing Retained Message for this topic is replaced or kept. For a detailed description of Retained Messages see [section 4.26](\#4.26-retained-messages).
-#### **3.1.12.4 Packet Identifier** {#3.1.12.4-packet-identifier}
+#### **3.12.4 Packet Identifier** {#3.12.4-packet-identifier}
Used to identify the corresponding PUBACK packet in the case of QoS 1\. Used to identify the corresponding PUBREC, PUBREL and PUBCOMP packets in the case of QoS 2\. It should ideally be populated with a random integer value.
-#### **3.1.12.5 Topic Data** {#3.1.12.5-topic-data}
+#### **3.12.5 Topic Data** {#3.12.5-topic-data}
Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.
-#### **3.1.12.6 Data** {#3.1.12.6-data}
+#### **3.12.6 Data** {#3.12.6-data}
The *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
In the case of Topic Type b11 the data section will be prefixed with a “Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
-#### **3.1.12.7 PUBLISH Actions** {#3.1.12.7-publish-actions}
+#### **3.12.7 PUBLISH Actions** {#3.12.7-publish-actions}
-The receiver of a PUBLISH pPacket MUST respond with the packet as determined by the QoS in the PUBLISH Packet. \[MQTT-SN-3.1.12.7-1\].
+The receiver of a PUBLISH pPacket MUST respond with the packet as determined by the QoS in the PUBLISH Packet. \[MQTT-SN-3.12.7-1\].
Table 3‑3 Expected PUBLISH packet response
\ No newline at end of file
@@ -1943,7 +1939,7 @@
The Server uses a PUBLISH packet to send an Application Message to each Client which has a matching subscription. The PUBLISH packet includes the Subscription Identifier carried in the SUBSCRIBE packet, if there was one.
-When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published Application Message might match multiple filters. In this case the Server MUST deliver the Application Message to the Client respecting the maximum QoS of all the matching subscriptions \[MQTT-SN-3.1.12.7-2\]. In addition, the Server MAY deliver further copies of the Application Message, one for each additional matching subscription and respecting the subscription’s QoS in each case.
+When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published Application Message might match multiple filters. In this case the Server MUST deliver the Application Message to the Client respecting the maximum QoS of all the matching subscriptions \[MQTT-SN-3.12.7-2\]. In addition, the Server MAY deliver further copies of the Application Message, one for each additional matching subscription and respecting the subscription’s QoS in each case.
The action of the recipient when it receives a PUBLISH packet depends on the QoS level as described in [section 4.3](\#4.3-quality-of-service-levels-and-protocol-flows).
\ No newline at end of file
@@ -1963,9 +1959,9 @@
The Server might choose to suspend the sending of QoS 0 PUBLISH packets when it suspends the sending of QoS 1 and QoS 2 PUBLISH packets.
-### **3.1.13 PUBACK – Publish Acknowledgement** {#3.1.13-puback-–-publish-acknowledgement}
+### **3.13 PUBACK – Publish Acknowledgement** {#3.13-puback-–-publish-acknowledgement}
-![][image13]
+![][image17]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1979,25 +1975,25 @@
A PUBACK packet is the response to a PUBLISH packet with QoS 1\. It can also be sent as response to a PUBLISH packet of any QoS (*with the exception of QoS \-1, or PUBWOS*) in case of an error; the error reason is then indicated in the *Reason Code* field.
-#### **3.1.13.1 Length & Packet Type** {#3.1.13.1-length-&-packet-type}
+#### **3.13.1 Length & Packet Type** {#3.13.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.13.2 Packet Identifier** {#3.1.13.2-packet-identifier}
+#### **3.13.2 Packet Identifier** {#3.13.2-packet-identifier}
The same value as the Packet Identifier in the PUBLISH Packet being acknowledged.
-#### **3.1.13.3 Reason Code** {#3.1.13.3-reason-code}
+#### **3.13.3 Reason Code** {#3.13.3-reason-code}
Byte 5 in the PUBACK packet holds the Reason code in response to the PUBLISH packet. The PUBACK Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the PUBACK packet MUST use one of the PUBACK Reason Codes.
-#### **3.1.13.4 PUBACK Actions** {#3.1.13.4-puback-actions}
+#### **3.13.4 PUBACK Actions** {#3.13.4-puback-actions}
As described in [section 4.3.3](\#4.3.3-qos-1:-at-least-once-delivery).
-### **3.1.14 PUBREC (QoS 2 delivery part 1\)** {#3.1.14-pubrec-(qos-2-delivery-part-1)}
+### **3.14 PUBREC (QoS 2 delivery part 1\)** {#3.14-pubrec-(qos-2-delivery-part-1)}
-![][image14]
+![][image18]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2011,25 +2007,25 @@
A PUBREC packet is the response to a PUBLISH packet with QoS 2\. It is the second packet of the QoS 2 protocol exchange.
-#### **3.1.14.1 Length & Packet Type** {#3.1.14.1-length-&-packet-type}
+#### **3.14.1 Length & Packet Type** {#3.14.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.14.2 Packet Identifier** {#3.1.14.2-packet-identifier}
+#### **3.14.2 Packet Identifier** {#3.14.2-packet-identifier}
The same value as the Packet Identifier in the PUBLISH Packet being acknowledged.
-#### **3.1.14.3 Reason Code** {#3.1.14.3-reason-code}
+#### **3.14.3 Reason Code** {#3.14.3-reason-code}
Byte 5 in the PUBREC packet holds the Reason code in response to the PUBLISH packet. The PUBREC Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the PUBREC packet MUST use one of the PUBREC Reason Codes.
-#### **3.1.14.4 PUBREC Actions** {#3.1.14.4-pubrec-actions}
+#### **3.14.4 PUBREC Actions** {#3.14.4-pubrec-actions}
As described in [section 4.3.4](\#4.3.4-qos-2:-exactly-once-delivery).
-### **3.1.15 PUBREL (QoS 2 delivery part 2\)** {#3.1.15-pubrel-(qos-2-delivery-part-2)}
+### **3.15 PUBREL (QoS 2 delivery part 2\)** {#3.15-pubrel-(qos-2-delivery-part-2)}
-![][image15]
+![][image19]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2043,25 +2039,25 @@
A PUBREL packet is the response to a PUBREC packet. It is the third packet of the QoS 2 protocol exchange.
-#### **3.1.15.1 Length & Packet Type** {#3.1.15.1-length-&-packet-type}
+#### **3.15.1 Length & Packet Type** {#3.15.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.15.2 Packet Identifier** {#3.1.15.2-packet-identifier}
+#### **3.15.2 Packet Identifier** {#3.15.2-packet-identifier}
The same value as the Packet Identifier in the PUBLISH Packet being acknowledged.
-#### **3.1.15.3 Reason Code** {#3.1.15.3-reason-code}
+#### **3.15.3 Reason Code** {#3.15.3-reason-code}
Byte 5 in the PUBREL packet holds the Reason code in response to the PUBREC packet. The PUBREL Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the PUBREL packet MUST use one of the PUBREL Reason Codes.
-#### **3.1.15.4 PUBREL Actions** {#3.1.15.4-pubrel-actions}
+#### **3.15.4 PUBREL Actions** {#3.15.4-pubrel-actions}
As described in [section 4.3.4](\#4.3.4-qos-2:-exactly-once-delivery).
-### **3.1.16 PUBCOMP \- Publish Complete (QoS 2 delivery part 3\)** {#3.1.16-pubcomp---publish-complete-(qos-2-delivery-part-3)}
+### **3.16 PUBCOMP \- Publish Complete (QoS 2 delivery part 3\)** {#3.16-pubcomp---publish-complete-(qos-2-delivery-part-3)}
-![][image16]
+![][image20]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2075,29 +2071,29 @@
The PUBCOMP packet is the response to a PUBREL packet. It is the fourth and final packet of the QoS 2 protocol exchange.
-#### **3.1.16.1 Length & Packet Type** {#3.1.16.1-length-&-packet-type}
+#### **3.16.1 Length & Packet Type** {#3.16.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.16.2 Packet Identifier** {#3.1.16.2-packet-identifier}
+#### **3.16.2 Packet Identifier** {#3.16.2-packet-identifier}
The same value as the Packet Identifier in the PUBLISH Packet being acknowledged.
-#### **3.1.16.3 Reason Code** {#3.1.16.3-reason-code}
+#### **3.16.3 Reason Code** {#3.16.3-reason-code}
Byte 5 in the PUBCOMP packet holds the Reason code in response to the PUBREL packet. The PUBCOMP Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the PUBCOMP packet MUST use one of the PUBCOMP Reason Codes.
-#### **3.1.16.4 PUBCOMP Actions** {#3.1.16.4-pubcomp-actions}
+#### **3.16.4 PUBCOMP Actions** {#3.16.4-pubcomp-actions}
As described in [section 4.3.4](\#4.3.4-qos-2:-exactly-once-delivery).
-### **3.1.17 SUBSCRIBE \- Subscribe Request** {#3.1.17-subscribe---subscribe-request}
+### **3.17 SUBSCRIBE \- Subscribe Request** {#3.17-subscribe---subscribe-request}
-![][image17]
+![][image21]
Or
-![][image18]
+![][image22]
| Bit | 7 | 6 | | 5 | | | 4 | 3 | | 2 | 1 | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | :---: |
\ No newline at end of file
@@ -2115,11 +2111,11 @@
The SUBSCRIBE packet is used by a client to subscribe to a certain topic name.
-#### **3.1.17.1 Length & Packet Type** {#3.1.17.1-length-&-packet-type}
+#### **3.17.1 Length & Packet Type** {#3.17.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.17.2 SUBSCRIBE Flags** {#3.1.17.2-subscribe-flags}
+#### **3.17.2 SUBSCRIBE Flags** {#3.17.2-subscribe-flags}
The SUBSCRIBE Flags field is 1-byte and contains the following flags:
\ No newline at end of file
@@ -2135,25 +2131,25 @@
* **Topic Type**: This is a 2-bit field in Bit 0 and 1 which determines the format of the topic data field. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
-#### **3.1.17.3 Packet Identifier** {#3.1.17.3-packet-identifier}
+#### **3.17.3 Packet Identifier** {#3.17.3-packet-identifier}
Used to identify the corresponding SUBACK packet. It should ideally be populated with a random integer value.
-#### **3.1.17.4 Topic Data or Topic Filter** {#3.1.17.4-topic-data-or-topic-filter}
+#### **3.17.4 Topic Data or Topic Filter** {#3.17.4-topic-data-or-topic-filter}
Contains Fixed Length UTF-8 Encoded String topic filter, topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic names which this subscription is interested in.
-#### **3.1.17.5 SUBSCRIBE Actions** {#3.1.17.5-subscribe-actions}
+#### **3.17.5 SUBSCRIBE Actions** {#3.17.5-subscribe-actions}
-When the Server receives a SUBSCRIBE packet from a Client, the Server MUST respond with a SUBACK packet \[MQTT-SN-3.1.17.5-1\]. The SUBACK packet MUST have the same Packet Identifier as the SUBSCRIBE packet that it is acknowledging \[MQTT-SN-3.1.17.5-2\].
+When the Server receives a SUBSCRIBE packet from a Client, the Server MUST respond with a SUBACK packet \[MQTT-SN-3.17.5-1\]. The SUBACK packet MUST have the same Packet Identifier as the SUBSCRIBE packet that it is acknowledging \[MQTT-SN-3.17.5-2\].
The Server is permitted to start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK packet.
-If a Server receives a SUBSCRIBE packet containing a Topic Filter that is identical to a Subscription’s Topic Filter for the current Session, then it MUST replace that existing Subscription with a new Subscription \[MQTT-SN-3.1.17.5-3\]. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its Subscription Options could be different. If the Retain Handling option is 0, any existing retained messages matching the Topic Filter MUST be re-sent, but Application Messages MUST NOT be lost due to replacing the Subscription \[MQTT-SN-3.1.17.5-4\].
+If a Server receives a SUBSCRIBE packet containing a Topic Filter that is identical to a Subscription’s Topic Filter for the current Session, then it MUST replace that existing Subscription with a new Subscription \[MQTT-SN-3.17.5-3\]. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its Subscription Options could be different. If the Retain Handling option is 0, any existing retained messages matching the Topic Filter MUST be re-sent, but Application Messages MUST NOT be lost due to replacing the Subscription \[MQTT-SN-3.17.5-4\].
If a Server receives a Topic Filter that is not identical to any Topic Filter for the current Session, a new Subscription is created. If the Retain Handling option is not 2, all matching retained messages are sent to the Client.
-The SUBACK packet sent by the Server to the Client MUST contain a Reason Code \[MQTT-SN-3.1.17.5-5\]. This Reason Code MUST either show the maximum QoS that was granted for that Subscription or indicate that the subscription failed \[MQTT-SN-3.1.17.5-6\]. The Server might grant a lower Maximum QoS than the subscriber requested. The QoS of Application Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published Application message and the Maximum QoS granted by the Server \[MQTT-SN-3.1.17.5-7\]. The server is permitted to send duplicate copies of a Application message to a subscriber in the case where the original Application message was published with QoS 1 and the maximum QoS granted was QoS 0\.
+The SUBACK packet sent by the Server to the Client MUST contain a Reason Code \[MQTT-SN-3.17.5-5\]. This Reason Code MUST either show the maximum QoS that was granted for that Subscription or indicate that the subscription failed \[MQTT-SN-3.17.5-6\]. The Server might grant a lower Maximum QoS than the subscriber requested. The QoS of Application Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published Application message and the Maximum QoS granted by the Server \[MQTT-SN-3.17.5-7\]. The server is permitted to send duplicate copies of a Application message to a subscriber in the case where the original Application message was published with QoS 1 and the maximum QoS granted was QoS 0\.
**Informative comment**
If a subscribing Client has been granted maximum QoS 1 for a particular Topic Filter, then a QoS 0 Application Message matching the filter is delivered to the Client at QoS 0\. This means that at most one copy of the Application Message is received by the Client. On the other hand, a QoS 2 Application Message published to the same topic is downgraded by the Server to QoS 1 for delivery to the Client, so that Client might receive duplicate copies of the Application Message.
\ No newline at end of file
@@ -2166,9 +2162,9 @@
Subscribing to a Topic Filter at QoS 2 is equivalent to saying "I would like to receive Application Messages matching this filter at the QoS with which they were published". This means a publisher is responsible for determining the maximum QoS an Application Message can be delivered at, but a subscriber is able to require that the Server downgrades the QoS to one more suitable for its usage.
-### **3.1.18 SUBACK \- Subscribe Acknowledgement** {#3.1.18-suback---subscribe-acknowledgement}
+### **3.18 SUBACK \- Subscribe Acknowledgement** {#3.18-suback---subscribe-acknowledgement}
-![][image19]
+![][image23]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | 2 | 1 | | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2187,35 +2183,35 @@
The SUBACK packet is sent by a gateway to a client as an acknowledgment to the receipt and processing of a SUBSCRIBE packet.
-#### **3.1.18.1 Length & Packet Type** {#3.1.18.1-length-&-packet-type}
+#### **3.18.1 Length & Packet Type** {#3.18.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.18.2 Flags** {#3.1.18.2-flags}
+#### **3.18.2 Flags** {#3.18.2-flags}
The SUBACK Flags field is 1-byte located in Byte 3 position of the SUBACK control packet. The SUBACK Flags includes the following flags:
* **Topic Type**. This is a 2-bit field in Bit 0 and 1 which determines the format of the topic data field. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
-#### **3.1.18.3 Topic Data** {#3.1.18.3-topic-data}
+#### **3.18.3 Topic Data** {#3.18.3-topic-data}
In case of “accepted” the returned Topic Datavalue that will be used as topic alias by the gateway when sending PUBLISH packets to the client (not relevant, 0x0000, in case of subscriptions to a short topic name or to a topic name which contains wildcard characters)
-#### **3.1.18.4 Packet Identifier** {#3.1.18.4-packet-identifier}
+#### **3.18.4 Packet Identifier** {#3.18.4-packet-identifier}
The same value as the Packet Identifier in the SUBSCRIBE Packet being acknowledged.
-#### **3.1.18.5 Reason Code** {#3.1.18.5-reason-code}
+#### **3.18.5 Reason Code** {#3.18.5-reason-code}
Byte 8 in the SUBACK packet holds the Reason code in response to the SUBSCRIBE packet. The SUBACK Reason Codes are shown in Table 9: Reason Code Values.The Server sending the SUBACK packet MUST use one of the SUBACK Reason Codes.
-### **3.1.19 UNSUBSCRIBE \- Unsubscribe Request** {#3.1.19-unsubscribe---unsubscribe-request}
+### **3.19 UNSUBSCRIBE \- Unsubscribe Request** {#3.19-unsubscribe---unsubscribe-request}
-![][image20]
+![][image24]
Or:
-![][image21]
+![][image25]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | | | 2 | 1 | 0 | |
| ----- | ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | :---: |
\ No newline at end of file
@@ -2233,11 +2229,11 @@
An UNSUBSCRIBE packet is sent by the client to the GW to unsubscribe from named topics.
-#### **3.1.19.1 Length & Packet Type** {#3.1.19.1-length-&-packet-type}
+#### **3.19.1 Length & Packet Type** {#3.19.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.19.2 UNSUBSCRIBE Flags** {#3.1.19.2-unsubscribe-flags}
+#### **3.19.2 UNSUBSCRIBE Flags** {#3.19.2-unsubscribe-flags}
For The UNSUBSCRIBE Flags is 1 byte field in Byte position 3 of the UNSUBSCRIBE packet.
\ No newline at end of file
@@ -2245,29 +2241,29 @@
* **Topic Type.** This is a 2-bit field in Bit 0 and 1 which determines the format of the topic dataId value. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
-#### **3.1.19.3 Packet Identifier** {#3.1.19.3-packet-identifier}
+#### **3.19.3 Packet Identifier** {#3.19.3-packet-identifier}
Used to identify the corresponding UNSUBACK packet. It should ideally be populated with a random integer value.
-#### **3.1.19.4 Topic Data or Topic Filter** {#3.1.19.4-topic-data-or-topic-filter}
+#### **3.19.4 Topic Data or Topic Filter** {#3.19.4-topic-data-or-topic-filter}
Contains Fixed Length UTF-8 Encoded String topic filter, topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic names which this subscription is interested in.
-#### **3.1.19.4 UNSUBSCRIBE Actions** {#3.1.19.4-unsubscribe-actions}
+#### **3.19.4 UNSUBSCRIBE Actions** {#3.19.4-unsubscribe-actions}
-The Topic Filter (whether it contains wildcards or not) supplied in an UNSUBSCRIBE packet MUST be compared character-by-character with the current set of Topic Filters held by the Server for the Client. If any filter matches exactly then its owning Subscription MUST be deleted \[MQTT-SN-3.1.19.4-1\], otherwise no additional processing occurs.
+The Topic Filter (whether it contains wildcards or not) supplied in an UNSUBSCRIBE packet MUST be compared character-by-character with the current set of Topic Filters held by the Server for the Client. If any filter matches exactly then its owning Subscription MUST be deleted \[MQTT-SN-3.19.4-1\], otherwise no additional processing occurs.
When a Server receives UNSUBSCRIBE :
-* It MUST stop adding any new Application Messages which match the Topic Filters, for delivery to the Client \[MQTT-SN-3.1.19.4-2\].
-* It MUST complete the delivery of any QoS 1 or QoS 2 Application Messages which match the Topic Filters and it has started to send to the Client \[MQTT-SN-3.1.19.4-3\].
+* It MUST stop adding any new Application Messages which match the Topic Filters, for delivery to the Client \[MQTT-SN-3.19.4-2\].
+* It MUST complete the delivery of any QoS 1 or QoS 2 Application Messages which match the Topic Filters and it has started to send to the Client \[MQTT-SN-3.19.4-3\].
* It MAY continue to deliver any existing Application Messages which match the Topic Filters buffered for delivery to the Client.
-The Server MUST respond to an UNSUBSCRIBE request by sending an UNSUBACK packet \[MQTT-3.1.19.4-4\]. The UNSUBACK packet MUST have the same Packet Identifier as the UNSUBSCRIBE packet. Even where no Topic Subscriptions are deleted, the Server MUST respond with an UNSUBACK \[MQTT-3.1.19.4-5\].
+The Server MUST respond to an UNSUBSCRIBE request by sending an UNSUBACK packet \[MQTT-3.19.4-4\]. The UNSUBACK packet MUST have the same Packet Identifier as the UNSUBSCRIBE packet. Even where no Topic Subscriptions are deleted, the Server MUST respond with an UNSUBACK \[MQTT-3.19.4-5\].
-### **3.1.20 UNSUBACK \- Unsubscribe Acknowledgement** {#3.1.20-unsuback---unsubscribe-acknowledgement}
+### **3.20 UNSUBACK \- Unsubscribe Acknowledgement** {#3.20-unsuback---unsubscribe-acknowledgement}
-![][image22]
+![][image26]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2281,21 +2277,21 @@
An UNSUBACK packet is sent by a GW to acknowledge the receipt and processing of an UNSUBSCRIBE packet.
-#### **3.1.20.1 Length & Packet Type** {#3.1.20.1-length-&-packet-type}
+#### **3.20.1 Length & Packet Type** {#3.20.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.20.2 Packet Identifier** {#3.1.20.2-packet-identifier}
+#### **3.20.2 Packet Identifier** {#3.20.2-packet-identifier}
The same value as the Packet Identifier in the UNSUBSCRIBE packet being acknowledged.
-#### **3.1.20.3 Reason Code** {#3.1.20.3-reason-code}
+#### **3.20.3 Reason Code** {#3.20.3-reason-code}
Byte 5 in the UNSUBACK packet holds the Reason code in response to UNSUBSCRIBE packet. The UNSUBACK Reason Codes are shown in Table 9: Reason Code Values. The server sending the UNSUBACK packet MUST use one of the UNSUBACK Reason Codes.
-### **3.1.21 PINGREQ \- Ping Request** {#3.1.21-pingreq---ping-request}
+### **3.21 PINGREQ \- Ping Request** {#3.21-pingreq---ping-request}
-![][image23]
+![][image27]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2307,29 +2303,29 @@
The PINGREQ packet is an ”are you alive” packet that is sent from or received by a connected client.
-#### **3.1.21.1 Length & Packet Type** {#3.1.21.1-length-&-packet-type}
+#### **3.21.1 Length & Packet Type** {#3.21.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.21.2 Packet Identifier** {#3.1.21.2-packet-identifier}
+#### **3.21.2 Packet Identifier** {#3.21.2-packet-identifier}
Used to identify the corresponding PINGRESP packet. It should ideally be set to a random integer value.
-#### **3.1.21.3 Client Identifier (optional)** {#3.1.21.3-client-identifier-(optional)}
+#### **3.21.3 Client Identifier (optional)** {#3.21.3-client-identifier-(optional)}
Contains the client identifier (ClientID); this field is optional and is included by a “sleeping” client when it goes to the “awake” state and is waiting for packets sent by the server/gateway.
-The Client Identifier MUST be a Fixed Length UTF-8 Encoded String \[MQTT-SN-3.1.21.3-1\].
+The Client Identifier MUST be a Fixed Length UTF-8 Encoded String \[MQTT-SN-3.21.3-1\].
-#### **3.1.21.4 PINGREQ Actions** {#3.1.21.4-pingreq-actions}
+#### **3.21.4 PINGREQ Actions** {#3.21.4-pingreq-actions}
-The Server MUST send a PINGRESP packet in response to a PINGREQ packet \[MQTT-SN-3.1.21.4-1\].
+The Server MUST send a PINGRESP packet in response to a PINGREQ packet \[MQTT-SN-3.21.4-1\].
-The Client MAY send a PINGRESP packet in response to a PINGREQ packet \[MQTT-SN-3.1.21.4-2\].
+The Client MAY send a PINGRESP packet in response to a PINGREQ packet \[MQTT-SN-3.21.4-2\].
-### **3.1.22 PINGRESP \- Ping Response** {#3.1.22-pingresp---ping-response}
+### **3.22 PINGRESP \- Ping Response** {#3.22-pingresp---ping-response}
-![][image24]
+![][image28]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2345,15 +2341,15 @@
A PINGRESP packet is also sent by a Gateway to inform a sleeping ClLient that it has no more buffered packets for that Client.
-#### **3.1.22.1 Length & Packet Type** {#3.1.22.1-length-&-packet-type}
+#### **3.22.1 Length & Packet Type** {#3.22.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.22.2 Packet Identifier** {#3.1.22.2-packet-identifier}
+#### **3.22.2 Packet Identifier** {#3.22.2-packet-identifier}
The same value as the Packet Identifier in the PINGREQ Packet being acknowledged.
-#### **3.1.22.3 Application Messages Remaining** {#3.1.22.3-application-messages-remaining}
+#### **3.22.3 Application Messages Remaining** {#3.22.3-application-messages-remaining}
The number of Application Messages still queued for delivery at the Server when a Client is sent back to sleep. Optional – for use at the end of a client's awake period. Values can be:
\ No newline at end of file
@@ -2365,9 +2361,9 @@
Table 44: Allowed PINGRESP continuation values
-### **3.1.23 DISCONNECT \- Disconnect Notification** {#3.1.23-disconnect---disconnect-notification}
+### **3.23 DISCONNECT \- Disconnect Notification** {#3.23-disconnect---disconnect-notification}
-![][image25]
+![][image29]
| Bit | 7 | 6 | | 5 | | 4 | | 3 | | 2 | | 1 | | 0 | | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2387,15 +2383,15 @@
As with MQTT, the DISCONNECT packet is sent by a client to indicate that it wants to delete the Virtual connection. The gateway will acknowledge the receipt of that packet by returning a DISCONNECT to the client. A server or gateway may also send a DISCONNECT to a client, e.g. in case a gateway, due to an error when for instance it, cannot map a received packet to thea client. Upon receiving such a DISCONNECT packet, a client should try to create another Virtual Connection by sending a CONNECT packet to the gateway or server.
-A Server MUST NOT send a DISCONNECT until after it has sent a CONNACK with Reason Code of less than 0x80 \[MQTT-SN-3.1.23-1\].
+A Server MUST NOT send a DISCONNECT until after it has sent a CONNACK with Reason Code of less than 0x80 \[MQTT-SN-3.23-1\].
A DISCONNECT packet with a *Session Expiry Interval* field is sent by a client when it wants to go to the “asleep” state. The receipt of this packet is also acknowledged by the gateway by means of a DISCONNECT packet.
-#### **3.1.23.1 Length & Packet Type** {#3.1.23.1-length-&-packet-type}
+#### **3.23.1 Length & Packet Type** {#3.23.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.23.2 Disconnect Flags** {#3.1.23.2-disconnect-flags}
+#### **3.23.2 Disconnect Flags** {#3.23.2-disconnect-flags}
The Disconnect Flags is 1 byte field located at byte 3 which contains parameters specifying the behavior of the MQTT-SN sleep on the gateway.
\ No newline at end of file
@@ -2409,31 +2405,31 @@
The Gateway MUST validate that the reserved flags in the DISCONNECT packet are set to 0\. If any of the reserved flags is not 0 it is a Malformed Packet.
-#### **3.1.23.3 Reason Code** {#3.1.23.3-reason-code}
+#### **3.23.3 Reason Code** {#3.23.3-reason-code}
The Reason Code for the DISCONNECT packet is optional. If provided, Byte 3 in the DISCONNECT control packet holds the Reason Code of the disconnection. If not provided, 0x00 (Normal disconnection) is assumed.
-The DISCONNECT Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the DISCONNECT packet MUST use one of the DISCONNECT Reason Code values \[MQTT-SN-3.1.23.3-1\].
+The DISCONNECT Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the DISCONNECT packet MUST use one of the DISCONNECT Reason Code values \[MQTT-SN-3.23.3-1\].
-#### **3.1.23.4 Session Expiry Interval** {#3.1.23.4-session-expiry-interval}
+#### **3.23.4 Session Expiry Interval** {#3.23.4-session-expiry-interval}
The Session Expiry Interval is a four-byte integer time interval measured in seconds. If the Session Expiry Interval is set to 0 or omitted, the Session is transitioned to the “***disconnected***” state. When the value of this field is greater than zero, it is deemed to be sent by a client that wants to transition to the “***asleep***” state, see Section 4.153.19 for further details. At this point the keep alive timer becomes obsolete until the device issues a new CONNECT.
-The Session Expiry Interval MUST NOT be sent on a DISCONNECT by the Server \[MQTT–SN-3.1.23.4-1\].
+The Session Expiry Interval MUST NOT be sent on a DISCONNECT by the Server \[MQTT–SN-3.23.4-1\].
-#### **3.1.23.5 Reason String** {#3.1.23.5-reason-string}
+#### **3.23.5 Reason String** {#3.23.5-reason-string}
Fixed Length UTF-8 Encoded String representing a clear text description of disconnection.
-#### **3.1.23.6 DISCONNECT Actions** {#3.1.23.6-disconnect-actions}
+#### **3.23.6 DISCONNECT Actions** {#3.23.6-disconnect-actions}
After sending a DISCONNECT packet the sender:
-* MUST NOT send any more MQTT-SN Control Packets on that Virtual Connection \[MQTT-SN-3.1.23.6-1\].
+* MUST NOT send any more MQTT-SN Control Packets on that Virtual Connection \[MQTT-SN-3.23.6-1\].
After sending a DISCONNECT packet the Server:
-* MUST delete the Virtual Connection \[MQTT-SN-3.1.23.6-2\].
+* MUST delete the Virtual Connection \[MQTT-SN-3.23.6-2\].
After sending a DISCONNECT packet the Client:
\ No newline at end of file
@@ -2441,16 +2437,16 @@
On receipt of DISCONNECT with a Reason Code of 0x00 (Success) the Server:
-* MUST discard any Will Message associated with the current Connection without publishing it \[MQTT-SN-3.1.23.6-3\], as described in [section 3.1.4.9](\#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set)).
-* MUST send a DISCONNECT packet in response \[MQTT-SN-3.1.23.6-4\], and SHOULD delete the Virtual Connection.
+* MUST discard any Will Message associated with the current Connection without publishing it \[MQTT-SN-3.23.6-3\], as described in [section 3.4.9](\#3.4.9-connect-will-flags-(optional,-only-with-will-flag-set)).
+* MUST send a DISCONNECT packet in response \[MQTT-SN-3.23.6-4\], and SHOULD delete the Virtual Connection.
On receipt of DISCONNECT, the Client:
* SHOULD delete the Virtual Connection.
-### **3.1.24 WAKEUP \- Wake up request**
+### **3.24 WAKEUP \- Wake up request** {#3.24-wakeup---wake-up-request}
-![][image26]
+![][image30]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2461,17 +2457,17 @@
The wakeup packet is a signal sent from the gateway to a client. It is an indication from the gateway that the client should wake up. The client is not obliged to honor this request, nor may it even receive the packet. It can choose to ignore the request, or undertake one of the sequences outlined in the [4.25 Sleeping clients](\#4.25-sleeping-clients) section. The client need not respond to this packet.
-#### **3.1.24.1 Length & Packet Type**
+#### **3.24.1 Length & Packet Type** {#3.24.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](https://docs.google.com/document/d/1Q\_l-TOttOqktQmnupRv7Un1Y8KzULIxc/edit?pli=1\#heading=h.23ckvvd) for a detailed description.
-#### **3.1.24.2 WAKEUP Actions**
+#### **3.24.2 WAKEUP Actions** {#3.24.2-wakeup-actions}
-The Client MAY choose to follow the AWAKE procedure in response to receiving a WAKEUP packet \[MQTT-SN-3.1.21.4-2\].
+The Client MAY choose to follow the AWAKE procedure in response to receiving a WAKEUP packet \[MQTT-SN-3.21.4-2\].
-### **3.1.25 Forwarder Encapsulation** {#3.1.25-forwarder-encapsulation}
+### **3.25 Forwarder Encapsulation** {#3.25-forwarder-encapsulation}
-![][image27]
+![][image31]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2485,15 +2481,15 @@
As detailed in Section 4, MQTT-SN clients can also access a gateway via a forwarder in case the gateway is not directly attached to their WSNs. The forwarder simply encapsulates the MQTT-SN Packets it receives on the wireless side and forwards them unchanged to the gateway; in the opposite direction, it decapsulates the Packets it receives from the gateway and sends them to the clients, unchanged too.
-#### **3.1.25.1 Length** {#3.1.25.1-length}
+#### **3.25.1 Length** {#3.25.1-length}
1-byte long, specifies the number of bytes up to the end of the “Wireless Node Id” field (incl. the Length byte itself)
-#### **3.1.25.2 Packet Type** {#3.1.25.2-packet-type}
+#### **3.25.2 Packet Type** {#3.25.2-packet-type}
Coded “0xFE”, see Table 6
-#### **3.1.25.3 Ctrl** {#3.1.25.3-ctrl}
+#### **3.25.3 Ctrl** {#3.25.3-ctrl}
The Ctrl byte contains control information exchanged between the GW and the forwarder.
\ No newline at end of file
@@ -2504,21 +2500,21 @@
Table 54: Format of the ctrl byte
-#### **3.1.25.4 Radius** {#3.1.25.4-radius}
+#### **3.25.4 Radius** {#3.25.4-radius}
Transmission radius (only relevant in direction gateway to forwarder)
-#### **3.1.25.5 Wireless Node Id** {#3.1.25.5-wireless-node-id}
+#### **3.25.5 Wireless Node Id** {#3.25.5-wireless-node-id}
Identifies the wireless node which has sent or should receive the encapsulated MQTT-SN packet. The mapping between this Id and the address of the wireless node is implemented by the forwarder, if needed.
-#### **3.1.25.6 MQTT SN Packet** {#3.1.25.6-mqtt-sn-packet}
+#### **3.25.6 MQTT SN Packet** {#3.25.6-mqtt-sn-packet}
The MQTT-SN packet, encoded according to the packet type.
-### **3.1.26 Protection Encapsulation** {#3.1.26-protection-encapsulation}
+### **3.26 Protection Encapsulation** {#3.26-protection-encapsulation}
-### **![][image28]**
+### **![][image32]**
| Bit | 7 | 6 | | 5 | | 4 | 3 | | 2 | 1 | | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2555,15 +2551,15 @@
If the GW is not enrolled to the Client (so the Client has no access to a key shared with it on the basis of its GwId) and the Client and GW are not in a private network, it is recommended for the Client to open a DTLS session and process only MQTT-SN packets received over it.
-#### **3.1.26.1 Length** {#3.1.26.1-length}
+#### **3.26.1 Length** {#3.26.1-length}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.26.2 Packet Type** {#3.1.26.2-packet-type}
+#### **3.26.2 Packet Type** {#3.26.2-packet-type}
Coded “0x1E”, see Table 63
-#### **3.1.26.3 Protection Flags** {#3.1.26.3-protection-flags}
+#### **3.26.3 Protection Flags** {#3.26.3-protection-flags}
The PROTECTION Flags is 1 byte field in Byte position 3 of the packet, specifying the properties of the PROTECTION.
\ No newline at end of file
@@ -2593,7 +2589,7 @@
* if 0x1, a monotonic counter field of 16 bits (2 bytes) is present;
* if 0x0, the monotonic counter field is not present.
-#### **3.1.26.4 Protection Scheme** {#3.1.26.4-protection-scheme}
+#### **3.26.4 Protection Scheme** {#3.26.4-protection-scheme}
A (1 byte) field located at byte 4 should contain one of the not Reserved indexes in the following table. In general two types of protection scheme are considered: **Authentication only** (like HMAC or CMAC) and **AEAD** (Authenticated Encryption with Associated Data, like GCM, CCM or ChaCha20/Poly1305).
\ No newline at end of file
@@ -2631,7 +2627,7 @@
8. Reference: https://www.rfc-editor.org/rfc/rfc7539 and security considerations on https://www.rfc-editor.org/rfc/rfc8152\#section-10.3.1
9. ChaCha20/Poly1305 requires a 12 bytes nonce as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.3 obtained by performing SHA256 truncated to 96 bit of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)
-#### **3.1.26.5 Sender Identifier** {#3.1.26.5-sender-identifier}
+#### **3.26.5 Sender Identifier** {#3.26.5-sender-identifier}
TLocated at Bytes 5 \- 12 the Sender Id field (8 bytes) should contain:
\ No newline at end of file
@@ -2656,7 +2652,7 @@
*In order to create a whitelist of authorized senders, the MQTT-SN Gateway should store a map of ClientID and SHA256(ClientID) truncated to the leftmost 64 bits (8 bytes for each registered ClientID) for the clients having an active session and store a list of authorized Sender Ids for the clients not capable to establish sessions.*
-#### **3.1.26.6 Random** {#3.1.26.6-random}
+#### **3.26.6 Random** {#3.26.6-random}
T**Located at Byte 13 \- 16 , t**he “**Random**” field (4 bytes) should contain a random number (not guessable) generated at the PROTECTION packet creation .
\ No newline at end of file
@@ -2664,20 +2660,20 @@
*In case of CCM, in the worst case scenario where the “Crypto Material” and the “Monotonic Counter” optional fields are not present, the recommended nonce on 13 bytes will be calculated as SHA256 truncated to 104 bits of the sequence Byte 1 to Byte 16 (all packet fields until Protected MQTT-SN Packet). So considering the same Sender Id, the same nonce can be generated with a probability of 1/2^32=2.33x10\-10. With a shorter Random field of 2 bytes, the same nonce would be calculated with a probability of only 1/2^16=1.53x10\-5. As CCM is a derivation of CTR (see [https://en.wikipedia.org/wiki/CCM\_mode](https://en.wikipedia.org/wiki/CCM\_mode)), the nonce should never be reused for the same key so the probability to generate two identical nonces should be kept as low as possible. Same for GCM and ChaCha20/Poly1305, the security depends on choosing a unique IV of 12 bytes for every encryption performed with the same key ([https://en.wikipedia.org/wiki/Galois/Counter\_Mode](https://en.wikipedia.org/wiki/Galois/Counter\_Mode)).*
-#### **3.1.26.7 Crypto Material** {#3.1.26.7-crypto-material}
+#### **3.26.7 Crypto Material** {#3.26.7-crypto-material}
TLocated at Byte (17 \- P), the optional field “**Crypto Material**” contains 0, 2, 4 or 12 bytes of crypto material that when defined it can be used to derive, from a shared master secret, the same keys on the two endpoints and/or, when filled partially or totally with a random value, to further reduce the probability of IV/nonce reuse for CCM or GCM or ChaCha20/Poly1305. For instance when the Crypto material length is set to 0x03, the Crypto Material field can be partially filled with a random value of 9 bytes (the remaining 3 bytes can be set to 0 if not used) in order to reach the 13 bytes used only once recommended for the nonce used by CCM or it can be partially filled with a random value of 8 bytes in order to reach the 12 bytes used only once recommended for the IV/nonce used by GCM or ChaCha20/Poly1305 .
-#### **3.1.26.8 Monotonic Counter** {#3.1.26.8-monotonic-counter}
+#### **3.26.8 Monotonic Counter** {#3.26.8-monotonic-counter}
TLocated at Byte Byte (Q \- R), the optional field “**Monotonic Counter**” contains 0, 2 or 4 byte number that when defined, is increased by the Client or GW for every packet sent. The counters should be considered independent of session or destination. E.g. The UE will keep a counter independently from the GW.
-#### **3.1.26.9 Protected MQTT-SN Packet** {#3.1.26.9-protected-mqtt-sn-packet}
+#### **3.26.9 Protected MQTT-SN Packet** {#3.26.9-protected-mqtt-sn-packet}
TLocated at Byte (S \- T), the field “**Protected MQTT-SN Packet**” contains the MQTT-SN packet that is being secured, encoded as per its packet type.
The “Protected MQTT-SN Packet” should not be a “Forwarder-Encapsulation packet” as the shared key used directly or after derivation for the protection must belong to the originator of the content and not to a Forwarder that, in general, is not able to securely identify the originator.
-#### **3.1.26.10 Authentication Tag** {#3.1.26.10-authentication-tag}
+#### **3.26.10 Authentication Tag** {#3.26.10-authentication-tag}
TLocated at Byte (U \- N), the field “**Authentication tag**” field has a length depending on the “Authentication tag length” flag and it is calculated, on the basis of the “Protection scheme” selected in Byte 4, on ALL the preceding fields.
\ No newline at end of file
@@ -2728,11 +2724,11 @@
The CONNECT packet contains flags to communicate to the gateway that Auth interactions, or WILL interactions should take place.
-![][image29]
+![][image33]
Figure 3a: Connect procedure (without Auth flag not Will flag set or no further authentication data required)
-![][image30]
+![][image34]
Figure 3b: Connect procedure (with Auth flag set and additional authentication data required)
\ No newline at end of file
@@ -2963,9 +2959,9 @@
The value of the retry interval Tretry is not specified by the protocol, however, to be useful it ought to be longer than the network round trip time. If it is excessively long, the time taken to detect and retransmit lost Packets will also be excessively long. Implementers need to take care not to use a retry interval that might cause the network to become congested with retried Packets.
-The PINGREQ Packet described in \[[3.1.21 PINGREQ](\#3.1.21-pingreq---ping-request)\] can also be used to determine whether the Virtual Connection is alive.
+The PINGREQ Packet described in \[[3.21 PINGREQ](\#3.21-pingreq---ping-request)\] can also be used to determine whether the Virtual Connection is alive.
-An example of a retry algorithm is described in \[[Appendix F.4Appendix E.F4](\#f.4-exponential-backoff)\]
+An example of a retry algorithm is described in \[[Appendix F.4](\#f.4-exponential-backoff)\]
## **4.5 Application Message receipt** {#4.5-application-message-receipt}
\ No newline at end of file
@@ -2983,7 +2979,7 @@
When a stream of messages is published and subscribed to an Ordered Topic with QoS 1, the final copy of each message received by the subscribers will be in the order that they were published.
-As no more than one message is “in-flight” at any one time, no QoS 1 message will be received after any later one even on re-connection. .For example a subscriber might receive them in the order 1,2,3,3,4 but not 1,2,3,2,3,4.
+As no more than one message is “in-flight” at any one time, no QoS 1 message will be received after any later one even on re-connection. For example a subscriber might receive them in the order 1,2,3,3,4 but not 1,2,3,2,3,4.
## **4.7 Topic Names and Topic Filters** {#4.7-topic-names-and-topic-filters}
\ No newline at end of file
@@ -3064,7 +3060,7 @@
* Topic Names and Topic Filters MUST NOT include the null character (Unicode U+0000) [\[Unicode\]](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#Unicode) \[MQTT-SN-4.7.3-2\]
* Topic Names and Topic Filters are UTF-8 Encoded Strings; they MUST NOT encode to more than 65,535 bytes \[MQTT-SN-4.7.3-4\]. Refer to [section 1.7.4](\#1.7.4-utf-8-encoded-string).
- There is no limit to the number of levels in a Topic Name or Topic Filter, other than that imposed by the overall length of a UTF-8 Encoded String.
+There is no limit to the number of levels in a Topic Name or Topic Filter, other than that imposed by the overall length of a UTF-8 Encoded String.
When it performs subscription matching the Server MUST NOT perform any normalization of Topic Names or Topic Filters, or any modification or substitution of unrecognized characters \[MQTT-SN-4.7.3-4\]. Each non-wildcarded level in the Topic Filter has to match the corresponding level in the Topic Name character for character for the match to succeed.
\ No newline at end of file
@@ -3099,11 +3095,11 @@
If a Client or Server receives an MQTT-SN request and there is already a request outstanding within the same Virtual Connection then it MUST issue a DISCONNECT with Reason Code 147 (Receive Maximum Exceeded) and delete the Virtual Connection \[MQTT-SN-4.9-1\].
-Refer to [section 3.1.12.7](\#3.1.12.7-publish-actions) for a description of how Clients and Servers react if they are sent more than one unacknowledged packet.
+Refer to [section 3.12.7](\#3.12.7-publish-actions) for a description of how Clients and Servers react if they are sent more than one unacknowledged packet.
## **4.10 Server redirection** {#4.10-server-redirection}
-A Server can request that the Client uses another Server by sending a CONNACK or DISCONNECT packet with Reason Codes 0x9C (Use another server), or 0x9D (Server moved) as described in [section 4.13](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#S4\_13\_Errors).
+A Server can request that the Client uses another Server by sending a CONNACK or DISCONNECT packet with Reason Codes 0x9C (Use another server), or 0x9D (Server moved) as described in [section 4.12](\#4.12-handling-errors).
The Reason Code 0x9C (Use another server) specifies that the Client SHOULD temporarily switch to using another Server. The other Server is already known to the Client.
\ No newline at end of file
@@ -3157,11 +3153,11 @@
### **4.11.1 Re-authentication** {#4.11.1-re-authentication}
-If the Client supplied an Authentication Method in the CONNECT packet, it can initiate a re-authentication at any time after receiving a CONNACK. It does this by sending an AUTH packet with a Reason Code of 0x19 (Re-authentication). The Client MUST set the Authentication Method to the same value as the Authentication Method originally used to authenticate the Virtual Connection \[MQTT-SN-4.10.1-1\]. If the authentication method requires Client data first, this AUTH packet contains the first piece of authentication data inas the Authentication Data field.
+If the Client supplied an Authentication Method in the CONNECT packet, it can initiate a re-authentication at any time after receiving a CONNACK. It does this by sending an AUTH packet with a Reason Code of 0x19 (Re-authentication). The Client MUST set the Authentication Method to the same value as the Authentication Method originally used to authenticate the Virtual Connection \[MQTT-SN-4.10.1-1\]. If the authentication method requires Client data first, this AUTH packet contains the first piece of authentication data in the Authentication Data field.
The Server responds to this re-authentication request by sending an AUTH packet to the Client with a Reason Code of 0x00 (Success) to indicate that the re-authentication is complete, or a Reason Code of 0x18 (Continue authentication) to indicate that more authentication data is needed. The Client can respond with additional authentication data by sending an AUTH packet with a Reason Code of 0x18 (Continue authentication). This flow continues as with the original authentication until the re-authentication is complete or the re-authentication fails.
-If the re-authentication fails, the Client or Server MUST send DISCONNECT with an appropriate Reason Code as described in [section 4.13](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#S4\_13\_Errors), and MUST delete the Virtual Connection \[MQTT-SN-4.10.1-2\].
+If the re-authentication fails, the Client or Server MUST send DISCONNECT with an appropriate Reason Code as described in [section 4.12](\#4.12-handling-errors), and MUST delete the Virtual Connection \[MQTT-SN-4.10.1-2\].
During this re-authentication sequence, the flow of other packets between the Client and Server can continue using the previous authentication.
\ No newline at end of file
@@ -3181,10 +3177,8 @@
* The degree to which the receiver trusts the network to deliver Control Packets correctly.
* The consequences of continuing to process a packet that is incorrect.
-If the sender is compliant with this specification it will not send Malformed Packets or cause Protocol Errors. However, if a Client sends Control Packets before it receives CONNACK, it might cause a Protocol Error because it made an incorrect assumption about the Server capabilities. Refer [to section 3.1.4](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#\_CONNECT\_Actions) CONNECT Actions.
+If the sender is compliant with this specification it will not send Malformed Packets or cause Protocol Errors. The Reason Codes used for Malformed Packet and Protocol Errors are:
- The Reason Codes used for Malformed Packet and Protocol Errors are:
-
* 0x81 Malformed Packet
* 0x82 Protocol Error
* 0x93 Receive Maximum exceeded
\ No newline at end of file
@@ -3221,7 +3215,7 @@
The architectures described below are meant as examples and are not exhaustive.
-![][image31]
+![][image35]
Figure 1: MQTT-SN Architecture
\ No newline at end of file
@@ -3231,9 +3225,9 @@
Although the implementation of the transparent Gateway is simpler when compared to the one of an aggregating Gateway, it requires the MQTT server to support a separate connection for each active client. Some MQTT server implementations might impose a limitation on the number of concurrent connections that they support.
- ![A close up of a mapDescription automatically generated][image32]
+ ![A close up of a mapDescription automatically generated][image36]
-![][image33]
+![][image37]
Figure XX2: Transparent and Aggregating Gateway scenarios
\ No newline at end of file
@@ -3241,21 +3235,21 @@
Instead of having a MQTT connection for each connected client, an aggregating Gateway will have only one MQTT connection to the Server. All packet exchanges between a MQTT-SN client and an aggregating Gateway end at the Gateway. The Gateway then decides which information will be given further to the MQTT BrokerServer. Although its implementation is more complex than the one of a transparent Gateway, an aggregating Gateway may be helpful in case of WSNs with a very large number of SAs because it reduces the number of MQTT connections that the Gateway must support concurrently.
-![][image34]
+![][image38]
Figure XX: Aggregating Gateway scenario
### **4.11.3 Forwarder encapsulator**
-![][image35]
+![][image39]
-Figure XX: Forwarder encapsulator with TransparentGateway scenario![][image36]
+Figure XX: Forwarder encapsulator with TransparentGateway scenario![][image40]
Figure XX: Forwarder encapsulator with Aggregating Gateway scenario
### **4.13.4 MQTT-SN broker**
-![][image37]
+![][image41]
Figure XX: MQTT-SN broker scenario
\ No newline at end of file
@@ -3295,7 +3289,7 @@
| **AWAKE** | The client is partially engaged in an ongoing session; it is obliged to not send ANY packets other than those involved in the receipt of PUBLISH packets (PUBACK, PUBREC, PUBCOMP, REGACK) or a DISCONNECT to transition to **DISCONNECTED**. The client transitions back to the **ASLEEP** state on receipt of a PINGRESP packet or **LOST** (by way of supervised gateway timers for the possible PUBACK, PUBREC, PUBCOMP or REGACK packets to be received from the Client). | **ASLEEP DISCONNECTED LOST** |
| **LOST** | The client is considered offline and not able to receive packets until it has re-established a session with the GW by way of a CONNECT. The gateway **must not** attempt to send packets to a client in the **LOST** state**.** Any packets received from a client whose state is **LOST** should not be processed and a DISCONNECT with error should be sent in response, unless the packets received are PUBLISH WITHOUT SESSION or PUBLISH QoS \-1. Session state may exist on the GW for a client in the **LOST** state. | **ACTIVE** |
-![][image38]
+![][image42]
Figure 4: The Server vView of the Client State
\ No newline at end of file
@@ -3452,7 +3446,7 @@
The gateway should attempt to make the best effort to reuse the same topic alias mappings that existed during any initial associated ACTIVE states.
-![][image39]
+![][image43]
Figure 5: Awake ping packet flush
\ No newline at end of file
@@ -3468,11 +3462,11 @@
* If Retain Handling is set to 1 then if the subscription did not already exist, the Server MUST send all retained messages matching the Topic Filter of the subscription to the Client, and if the subscription did exist the Server MUST NOT send the retained messages. \[MQTT-SN-4.26-6\].
* If Retain Handling is set to 2, the Server MUST NOT send the retained messages \[MQTT-SN-4.26-7\].
-Refer to [section 3.1.17.2](\#3.1.17.2-subscribe-flags) for a definition of the Subscription Flags.
+Refer to [section 3.17.2](\#3.17.2-subscribe-flags) for a definition of the Subscription Flags.
If the Server receives a PUBLISH packet with the RETAIN flag set to 1, and QoS 0 it SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time. If this happens there will be no retained message for that topic.
-The setting of the RETAIN flag in an Application Message forwarded by the Server from an established Virtual Connection is controlled by the Retain As Published subscription option. Refer to [section 3.1.17.2](\#3.1.17.2-subscribe-flags) for a definition of the Subscription Flags.
+The setting of the RETAIN flag in an Application Message forwarded by the Server from an established Virtual Connection is controlled by the Retain As Published subscription option. Refer to [section 3.17.2](\#3.17.2-subscribe-flags) for a definition of the Subscription Flags.
* If the value of Retain As Published subscription option is set to 0, the Server MUST set the RETAIN flag to 0 when forwarding an Application Message regardless of how the RETAIN flag was set in the received PUBLISH packet \[MQTT-SN-4.26-8\].
* If the value of Retain As Published subscription option is set to 1, the Server MUST set the RETAIN flag equal to the RETAIN flag in the received PUBLISH packet \[MQTT-SN-4.26-9\].
\ No newline at end of file
@@ -3852,80 +3846,88 @@
The name "OASIS" is a trademark of [OASIS](https://www.oasis-open.org/), the owner and developer of this document, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, documents, while reserving the right to enforce its marks against misleading uses. See [https://www.oasis-open.org/policies-guidelines/trademark/](https://www.oasis-open.org/policies-guidelines/trademark/) for above guidance.
@@ -858,6 +862,8 @@
Text fields within the MQTT-SN Control Packets are encoded as fixed length UTF-8 strings. UTF-8 [\[RFC3629\]](https://docs.oasis-open.org/mqtt/mqtt/v5.0/cos02/mqtt-v5.0-cos02.html\#RFC3629) is an efficient encoding of Unicode [\[Unicode\]](https://docs.oasis-open.org/mqtt/mqtt/v5.0/cos02/mqtt-v5.0-cos02.html\#Unicode) characters that optimizes the encoding of ASCII characters in support of text-based communications.
Unless stated otherwise all variable length UTF-8 encoded strings can have any length in the range 0 to 65,535 bytes.
+
+![][image1]
| Byte \\ Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -883,6 +889,8 @@
For example, the string A𪛔 which is LATIN CAPITAL Letter A followed by the code point U+2A6D4 (which represents a CJK IDEOGRAPH EXTENSION B character) is encoded as follows:
+![][image2]
+
| Byte \\ BitBit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| byte 1 | ‘A’ (0x41) | | | | | | | |
\ No newline at end of file
@@ -916,6 +924,8 @@
Each MQTT-SN Control Packet contains a Header of format 1 or format 2 as shown below.
+![][image3]
+
| Byte | Use |
| :---: | :---: |
| 1 | Length |
\ No newline at end of file
@@ -923,6 +933,8 @@
Table 4: Packet Header Format 1
+![][image4]
+
| Byte | Use |
| :---: | :---: |
| 1 | Length 0x01 |
\ No newline at end of file
@@ -1065,7 +1077,7 @@
It is possible for a Client to send a PUBLISH packet with Packet Identifier 0x1234 and then receive a different PUBLISH packet with Packet Identifier 0x1234 from its Server before it receives a PUBACK for the PUBLISH packet that it sent.
-![][image1]
+![][image5]
## **2.3 MQTT-SN Packet Fields** {#2.3-mqtt-sn-packet-fields}
\ No newline at end of file
@@ -1177,13 +1189,9 @@
# **3 MQTT-SN Control Packets** {#3-mqtt-sn-control-packets}
-## **3.1 Format of Individual Packets** {#3.1-format-of-individual-packets}
-
-This section specifies the format of the individual MQTT-SN packets.
-
-### **3.1.1 ADVERTISE \- Gateway Advertisement** {#3.1.1-advertise---gateway-advertisement}
+### **3.1 ADVERTISE \- Gateway Advertisement** {#3.1-advertise---gateway-advertisement}
-![][image2]
+![][image6]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1201,11 +1209,11 @@
If the Transport Layer supports multicast, like UDP/IP, the ADVERTISE packet is generally sent using the Multicast Address as destination.
-#### **3.1.1.1 Length & Packet Type** {#3.1.1.1-length-&-packet-type}
+#### **3.1.1 Length & Packet Type** {#3.1.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.1.2 GwId** {#3.1.1.2-gwid}
+#### **3.1.2 GwId** {#3.1.2-gwid}
The *GwId* field is at least 1-byte identifier and uniquely identifies a gateway which is advertising itself in the network.
\ No newline at end of file
@@ -1215,15 +1223,15 @@
If the Gateway has a MAC address, it can be used as *GwId*.
-#### **3.1.1.3 Duration** {#3.1.1.3-duration}
+#### **3.1.3 Duration** {#3.1.3-duration}
The *Duration* field is a 2-byte integer. It specifies the time interval in seconds until the next ADVERTISE packet is transmitted by this gateway period.
The maximum value that can be encoded is approximately 18 hours.
-### **3.1.2 SEARCHGW \- Search for A Gateway** {#3.1.2-searchgw---search-for-a-gateway}
+### **3.2 SEARCHGW \- Search for A Gateway** {#3.2-searchgw---search-for-a-gateway}
-![][image3]
+![][image7]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1239,11 +1247,11 @@
If the Transport Layer supports multicast, like UDP/IP, the SEARCHGW packet is generally sent using the Multicast Address as destination..
-#### **3.1.2.1 Length & Packet Type** {#3.1.2.1-length-&-packet-type}
+#### **3.2.1 Length & Packet Type** {#3.2.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.2.2 Radius** {#3.1.2.2-radius}
+#### **3.2.2 Radius** {#3.2.2-radius}
The transmission radius is also indicated to the underlying network layer when MQTT-SN gives this packet for transmission.
\ No newline at end of file
@@ -1251,9 +1259,9 @@
If a Client or a Gateway forwards the SEARCHGW received, it MUST reduce the Radius value by 1\.
-### **3.1.3 GWINFO \- Gateway Information** {#3.1.3-gwinfo---gateway-information}
+### **3.3 GWINFO \- Gateway Information** {#3.3-gwinfo---gateway-information}
-![][image4]
+![][image8]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1270,21 +1278,21 @@
If the Transport Layer supports multicast, like UDP/IP, the GWINFO packet is generally sent using the Multicast Address as destination.
-#### **3.1.3.1 Length & Packet Type** {#3.1.3.1-length-&-packet-type}
+#### **3.3.1 Length & Packet Type** {#3.3.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.3.2 GwId** {#3.1.3.2-gwid}
+#### **3.3.2 GwId** {#3.3.2-gwid}
The *GwId* field is 1-byte long and uniquely identifies a Gateway in the network.
-#### **3.1.3.3 GwAdd** {#3.1.3.3-gwadd}
+#### **3.3.3 GwAdd** {#3.3.3-gwadd}
The *GwAdd* field has a variable length and contains the address of a Gateway. Its length depends on the type of network over which MQTT-SN operates and is specified by the Length byte. Optional, only included if the packet is sent by a client.
-### **3.1.4 CONNECT \- Connection Request** {#3.1.4-connect---connection-request}
+### **3.4 CONNECT \- Connection Request** {#3.4-connect---connection-request}
-![][image5]
+![][image9]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | 2 | 1 | | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1325,11 +1333,11 @@
The CONNECT packet is sent from the Client to the Gateway to create a Virtual Connection able to create or continue a Session.
-#### **3.1.4.1 Length & Packet Type** {#3.1.4.1-length-&-packet-type}
+#### **3.4.1 Length & Packet Type** {#3.4.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.4.2 Connect Flags** {#3.1.4.2-connect-flags}
+#### **3.4.2 Connect Flags** {#3.4.2-connect-flags}
The Connect Flags is 1 byte field which contains several parameters specifying the behavior of the MQTT-SN Virtual Connection.
\ No newline at end of file
@@ -1342,11 +1350,11 @@
The Gateway MUST validate that the reserved flags in the CONNECT packet are set to 0\. If any of the reserved flags is not 0 it is a Malformed Packet.
-#### **3.1.4.3 Packet Identifier** {#3.1.4.3-packet-identifier}
+#### **3.4.3 Packet Identifier** {#3.4.3-packet-identifier}
Used to identify the corresponding CONNACK packet. It should ideally be populated with a random integer value.
-#### **3.1.4.4 Protocol Version** {#3.1.4.4-protocol-version}
+#### **3.4.4 Protocol Version** {#3.4.4-protocol-version}
The one-byte unsigned value that represents the revision level of the protocol used by the Client.
\ No newline at end of file
@@ -1362,7 +1370,7 @@
A Gateway which supports multiple versions of the MQTT-SN protocol uses the Protocol Version to determine which version of MQTT-SN the Client is using. If the Protocol Version is not 2 and the Gateway does not want to accept the CONNECT packet, the Server MAY send a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version).
-#### **3.1.4.5 Keep Alive Timer** {#3.1.4.5-keep-alive-timer}
+#### **3.4.5 Keep Alive Timer** {#3.4.5-keep-alive-timer}
The Keep Alive is a Two Byte Integer greater than 0 (1 \- 65,535), which is a time interval measured in seconds. It is the maximum time interval that is permitted to elapse between the point at which the Client finishes transmitting one MQTT-SN Control Packet and the point it starts sending the next. It is the responsibility of the Client to ensure that the interval between MQTT-SN Control Packets being sent does not exceed the Keep Alive value. In the absence of sending any other MQTT-SN Control Packets, the Client MUST send a PINGREQ packet.
\ No newline at end of file
@@ -1383,7 +1391,7 @@
The actual value of the Keep Alive is application specific; typically, this is a few minutes. The maximum value of 65,535 is 18 hours 12 minutes and 15 seconds.
-#### **3.1.4.6 Session Expiry Interval** {#3.1.4.6-session-expiry-interval}
+#### **3.4.6 Session Expiry Interval** {#3.4.6-session-expiry-interval}
The Session Expiry Interval is a four-byte integer time interval measured in seconds. If the Session Expiry Interval is set to 0, the Session ends (and state deleted) when a (non SLEEPING) DISCONNECT packet is sent from either the client or gateway.
\ No newline at end of file
@@ -1399,7 +1407,7 @@
The client and gateway between them should negotiate a reasonable and practical session expiry interval according to the network and infrastructure environment in which they are deployed. For example, it would not be practical to set a session expiry interval of many months on a gateway whose hardware is only capable of storing a few client sessions.
-#### **3.1.4.7 Maximum Packet Size** {#3.1.4.7-maximum-packet-size}
+#### **3.4.7 Maximum Packet Size** {#3.4.7-maximum-packet-size}
A Two Byte (16-bit) Integer representing the Maximum Packet Size the Client is willing to accept. If the Maximum Packet Size is set to 0, no limit on the packet size is imposed beyond the limitations in the protocol as a result of the remaining length encoding and the protocol header sizes.
\ No newline at end of file
@@ -1417,7 +1425,7 @@
Where a packet is discarded without being sent, the Gateway could take some diagnostic action including alerting the Server administrator. Such actions are outside the scope of this specification.
-#### **3.1.4.8 Client Identifier (ClientID)** {#3.1.4.8-client-identifier-(clientid)}
+#### **3.4.8 Client Identifier (ClientID)** {#3.4.8-client-identifier-(clientid)}
The Client Identifier (ClientID) identifies the Client to the Gateway. Each Client connecting to the Gateway has a unique ClientID. The ClientID MUST be used by Clients and by Gateway to identify the state that they hold relating to this MQTT-SN Session between the Client and the Gateway.
\ No newline at end of file
@@ -1431,7 +1439,7 @@
The Client Identifier MUST be a UTF-8 Encoded String.
-#### **3.1.4.9 Connect Will Flags (optional, only with *Will* flag set)** {#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set)}
+#### **3.4.9 Connect Will Flags (optional, only with *Will* flag set)** {#3.4.9-connect-will-flags-(optional,-only-with-will-flag-set)}
The Connect optional *Will Flags* is 1 byte field which contains several parameters specifying the handling of the Will Message. It is present only if the Will flag in the Connect *Flags* contains the value 1\.
\ No newline at end of file
@@ -1443,7 +1451,7 @@
* **Will Retain**: Stored in Bit 4, this bit specifies if the Will Message is to be retained when it is published. The Will Message will be retained for a time defined by the server.
-If the Will Flag is set to 1 this indicates that a Will Message MUST be stored on the Server and associated with the Session \[MQTT-SN-3.1.4.9-1\]. The Will Message consists of the Will Topic, and Will Payload fields in the CONNECT Packet. The Will Message MUST be published after the Virtual Connection is deleted or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) \[MQTT-SN--3.1.4.9-2\].
+If the Will Flag is set to 1 this indicates that a Will Message MUST be stored on the Server and associated with the Session \[MQTT-SN-3.4.9-1\]. The Will Message consists of the Will Topic, and Will Payload fields in the CONNECT Packet. The Will Message MUST be published after the Virtual Connection is deleted or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) \[MQTT-SN--3.4.9-2\].
Situations in which the Will Message is published include, but are not limited to:
\ No newline at end of file
@@ -1451,76 +1459,64 @@
* The Client fails to communicate within the Keep Alive time.
* The Server deletes the Virtual Connection because of a protocol error.
-If the Will Flag is set to 1, the Will Topic, and Will Payload fields MUST be present in the Packet \[MQTT-SN-3.1.4.9-3\]. The Will Message MUST be removed from the stored Session State in the Server once it has been published or the Server has received a DISCONNECT packet with a Reason Code of 0x00 (Normal disconnection) from the Client \[MQTT-SN-3.1.4.9-4\].
+If the Will Flag is set to 1, the Will Topic, and Will Payload fields MUST be present in the Packet \[MQTT-SN-3.4.9-3\]. The Will Message MUST be removed from the stored Session State in the Server once it has been published or the Server has received a DISCONNECT packet with a Reason Code of 0x00 (Normal disconnection) from the Client \[MQTT-SN-3.4.9-4\].
The Server SHOULD publish Will Messages promptly after the Virtual Connection is deleted or the Session ends, whichever occurs first. In the case of a Server shutdown or failure, the Server MAY defer publication of Will Messages until a subsequent restart. If this happens, there might be a delay between the time the Server experienced failure and when the Will Message is published.
-#### **3.1.4.10 Will Topic DataShort or Will Topic Length (optional, only with *Will* flag set)** {#3.1.4.10-will-topic-datashort-or-will-topic-length-(optional,-only-with-will-flag-set)}
+#### **3.4.10 Will Topic DataShort or Will Topic Length (optional, only with *Will* flag set)** {#3.4.10-will-topic-datashort-or-will-topic-length-(optional,-only-with-will-flag-set)}
In the case of Will Topic Type being b11 this field will refer to the length of data assigned to the “Will Full Topic Name”, in all other cases, this will be the value used as the Will topic alias or Will short topic name.
-#### **3.1.4.11 Will Payload Length (optional, only with *Will* flag set)** {#3.1.4.11-will-payload-length-(optional,-only-with-will-flag-set)}
+#### **3.4.11 Will Payload Length (optional, only with *Will* flag set)** {#3.4.11-will-payload-length-(optional,-only-with-will-flag-set)}
Contains the length of the Will Payload field.
-#### **3.1.4.12 Will Payload (optional, only with *Will* flag set)** {#3.1.4.12-will-payload-(optional,-only-with-will-flag-set)}
+#### **3.4.12 Will Payload (optional, only with *Will* flag set)** {#3.4.12-will-payload-(optional,-only-with-will-flag-set)}
It contains the content of the Will Message which is published after the Virtual Connection is deleted.
In the case of Topic Type b11 the payload section will be prefixed with a “Will Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Will Payload* field corresponds to the MQTT Will Payload and so it defines the Application Message Payload that is to be published to the Will Topic and this field consists of Binary Data. It has a variable length defined by the Will Payload Length fields.
-#### **3.1.4.13 Authentication Method Length (optional, only with *Auth* flag set)** {#3.1.4.13-authentication-method-length-(optional,-only-with-auth-flag-set)}
+#### **3.4.13 Authentication Method Length (optional, only with *Auth* flag set)** {#3.4.13-authentication-method-length-(optional,-only-with-auth-flag-set)}
-Single byte value (max 0-255 bytes), representing the length of field used to specify the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Single byte value (max 0-255 bytes), representing the length of field used to specify the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.4.14 Authentication Method (optional, only with *Auth* flag set)** {#3.1.4.14-authentication-method-(optional,-only-with-auth-flag-set)}
+#### **3.4.14 Authentication Method (optional, only with *Auth* flag set)** {#3.4.14-authentication-method-(optional,-only-with-auth-flag-set)}
-A UTF-8 Encoded String containing the name of the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+A UTF-8 Encoded String containing the name of the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.4.15 Authentication Data Length (optional, only with *Auth* flag set)** {#3.1.4.15-authentication-data-length-(optional,-only-with-auth-flag-set)}
+#### **3.4.15 Authentication Data Length (optional, only with *Auth* flag set)** {#3.4.15-authentication-data-length-(optional,-only-with-auth-flag-set)}
-Two byte value (max 0-65535 bytes), representing the length of field used to specify the authentication data. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Two byte value (max 0-65535 bytes), representing the length of field used to specify the authentication data. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.4.16 Authentication Data (optional, only with *Auth* flag set)** {#3.1.4.16-authentication-data-(optional,-only-with-auth-flag-set)}
+#### **3.4.16 Authentication Data (optional, only with *Auth* flag set)** {#3.4.16-authentication-data-(optional,-only-with-auth-flag-set)}
-Binary Data containing authentication data. The contents of this data are defined by the authentication method. Refer to [section 4.11section 4.10](\#4.11-enhanced-authentication) for more information about extended authentication.
+Binary Data containing authentication data. The contents of this data are defined by the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.4.17 CONNECT Actions** {#3.1.4.17-connect-actions}
+#### **3.4.17 CONNECT Actions** {#3.4.17-connect-actions}
Note that a Server MAY support multiple protocols on the same network endpoint. If the Server determines that the protocol is MQTT-SN 2.0 then it validates the connection attempt as follows.
-1. The Server MUST validate that the CONNECT packet matches the format described in [section 3.1.4](\#3.1.4-connect---connection-request) and MUST NOT create a Virtual Connection for this CONNECT if it does not match. \[MQTT-SN-3.1.4.17-1\] The Server MAY send a CONNACK with a Reason Code of 0x80 or greater as described in [section 4.12](\#4.12-handling-errors).
-2. The Server MAY check that the contents of the CONNECT packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail, it MUST NOT create a Virtual Connection for this CONNECT \[MQTT-SN-3.1.4.17-2\]. It MAY send an appropriate CONNACK response with a Reason Code of 0x80 or greater as described in [section 3.1.5](\#3.1.5-connack---connect-acknowledgement) and [section 4.12](\#4.12-handling-errors).
+1. The Server MUST validate that the CONNECT packet matches the format described in [section 3.4](\#3.4-connect---connection-request) and MUST NOT create a Virtual Connection for this CONNECT if it does not match. \[MQTT-SN-3.4.17-1\] The Server MAY send a CONNACK with a Reason Code of 0x80 or greater as described in [section 4.12](\#4.12-handling-errors).
+2. The Server MAY check that the contents of the CONNECT packet meet any further restrictions and SHOULD perform authentication and authorization checks. If any of these checks fail, it MUST NOT create a Virtual Connection for this CONNECT \[MQTT-SN-3.4.17-2\]. It MAY send an appropriate CONNACK response with a Reason Code of 0x80 or greater as described in [section 3.5](\#3.5-connack---connect-acknowledgement) and [section 4.12](\#4.12-handling-errors).
If validation is successful, the Server performs the following steps.
-1. If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) as described in [section 4.12](\#4.12-handling-errors) and MUST delete the Virtual Connection of the existing Client \[MQTT-SN-3.1.4.17-3\]. If the existing Client has a Will Message, that Will Message is published as described in section 3.1.2.5.
-2. The Server MUST perform the processing of Clean Start that is described in [section 4.16](\#4.16-clean-start) \[MQTT-SN-3.1.4.17-4\].
-3. The Server MUST acknowledge the CONNECT packet with a CONNACK packet containing a 0x00 (Success) Reason Code \[MQTT-SN-3.1.4.17-5\].
+1. If the ClientID represents a Client already connected to the Server, the Server sends a DISCONNECT packet to the existing Client with Reason Code of 0x8E (Session taken over) as described in [section 4.12](\#4.12-handling-errors) and MUST delete the Virtual Connection of the existing Client \[MQTT-SN-3.4.17-3\]. If the existing Client has a Will Message, that Will Message is published as described in [section 3.4.9](\#3.4.9-connect-will-flags-(optional,-only-with-will-flag-set)).
+2. The Server MUST perform the processing of Clean Start that is described in [section 4.16](\#4.16-clean-start) \[MQTT-SN-3.4.17-4\].
+3. The Server MUST acknowledge the CONNECT packet with a CONNACK packet containing a 0x00 (Success) Reason Code \[MQTT-SN-3.4.17-5\].
4. Start Application Message delivery and Keep Alive monitoring.
**Informative comment**
It is recommended that authentication and authorization checks be performed if the Server is being used to process any form of business critical data. If these checks succeed, the Server responds by sending CONNACK with a 0x00 (Success) Reason Code. If they fail, it is suggested that the Server does not send a CONNACK at all, as this could alert a potential attacker to the presence of the MQTT-SN Server and encourage such an attacker to launch a denial of service or password-guessing attack.
-Clients are allowed to send further MQTT Control Packets immediately after sending a CONNECT packet; Clients need not wait for a CONNACK packet to arrive from the Server. If the Server rejects the CONNECT, it MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets \[MQTT-3.1.4-6\].
+Clients must wait for a CONNACK packet with a 0x00 (Success) Reason Code to arrive from the Server before sending any packet that needs a Virtual Connection. The Server MUST NOT process any data sent by the Client after the CONNECT packet except AUTH packets \[MQTT-SN-3.4.17-6\].
-**Informative comment**
+### **3.5 CONNACK \- Connect Acknowledgement** {#3.5-connack---connect-acknowledgement}
-Clients typically wait for a CONNACK packet, However, if the Client exploits its freedom to send MQTT-SN Control Packets before it receives a CONNACK, it might simplify the Client implementation as it does not have to police the connected state. The Client accepts that any data that it sends before it receives a CONNACK packet from the Server will not be processed if the Server rejects the connection.
+![][image10]
-**Informative comment**
-
-Clients that send MQTT-SN Control Packets before they receive CONNACK will be unaware of Server information including whether any existing Session is being used.
-
-**Informative comment**
-
-The Server can limit reading from the Network if the Client sends too much data before authentication is complete. This is suggested as a way of avoiding denial of service attacks.
-
-### **3.1.5 CONNACK \- Connect Acknowledgement** {#3.1.5-connack---connect-acknowledgement}
-
-![][image6]
-
| Bit | 7 | 6 | | 5 | | 4 | | 3 | | 2 | | 1 | | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| Byte 1 | Length | | | | | | | | | | | | | |
\ No newline at end of file
@@ -1547,11 +1543,11 @@
The CONNACK packet is sent by the Gateway in response to a CONNECT request from a client.
-#### **3.1.5.1 Length & Packet Type** {#3.1.5.1-length-&-packet-type}
+#### **3.5.1 Length & Packet Type** {#3.5.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.5.2 Connack Flags** {#3.1.5.2-connack-flags}
+#### **3.5.2 Connack Flags** {#3.5.2-connack-flags}
The CONNACK FLAGS is a 1 byte field located at byte 4 which contains flags specifying the behavior of the MQTT-SN Virtual Connection on the gateway. Bits 7-2 of the CONNACK FLAGS are reserved and MUST be set to 0.
\ No newline at end of file
@@ -1575,37 +1571,37 @@
The Client MUST validate that the reserved flags in the CONNACK packet are set to 0\. If any of the reserved flags is not 0 it is a Malformed Packet.
-#### **3.1.5.3 Packet Identifier** {#3.1.5.3-packet-identifier}
+#### **3.5.3 Packet Identifier** {#3.5.3-packet-identifier}
The same value as the Packet Identifier in the CONNECT Packet being acknowledged.
-#### **3.1.5.4 Reason Code** {#3.1.5.4-reason-code}
+#### **3.5.4 Reason Code** {#3.5.4-reason-code}
Byte 5 in the CONNACK header contains the Connect Reason Code. The values for the Connect Reason Code field are shown in Table 9: Reason Code Values. The Server sending the CONNACK packet MUST use one of the Connect Reason Code values.
If a Server sends a CONNACK packet containing a Reason code of 128 or greater it MUST then delete the Virtual Connection.
-#### **3.1.5.5 Session Expiry Interval** {#3.1.5.5-session-expiry-interval}
+#### **3.5.5 Session Expiry Interval** {#3.5.5-session-expiry-interval}
If the Session Expiry Interval is 0, the value of Session Expiry Interval in the CONNECT Packet is used. *The server uses this property to inform the Client that it is using a value other than that sent by the Client in the CONNECT*.
-#### **3.1.5.6 Authentication Method Length (optional, only with *Auth* flag set)** {#3.1.5.6-authentication-method-length-(optional,-only-with-auth-flag-set)}
+#### **3.5.6 Authentication Method Length (optional, only with *Auth* flag set)** {#3.5.6-authentication-method-length-(optional,-only-with-auth-flag-set)}
Single byte value (max 0-255 bytes), representing the length of field used to specify the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.5.7 Authentication Method (optional, only with *Auth* flag set)** {#3.1.5.7-authentication-method-(optional,-only-with-auth-flag-set)}
+#### **3.5.7 Authentication Method (optional, only with *Auth* flag set)** {#3.5.7-authentication-method-(optional,-only-with-auth-flag-set)}
A UTF-8 Encoded String containing the name of the authentication method. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.5.8 Authentication Data Length (optional, only with *Auth* flag set)** {#3.1.5.8-authentication-data-length-(optional,-only-with-auth-flag-set)}
+#### **3.5.8 Authentication Data Length (optional, only with *Auth* flag set)** {#3.5.8-authentication-data-length-(optional,-only-with-auth-flag-set)}
Two byte value (max 0-65535 bytes), representing the length of field used to specify the authentication data. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.5.9 Authentication Data (optional, only with *Auth* flag set)** {#3.1.5.9-authentication-data-(optional,-only-with-auth-flag-set)}
+#### **3.5.9 Authentication Data (optional, only with *Auth* flag set)** {#3.5.9-authentication-data-(optional,-only-with-auth-flag-set)}
Binary Data containing authentication data. The contents of this data are defined by the authentication method and the state of already exchanged authentication data. Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-#### **3.1.5.10 Assigned Client Identifier** {#3.1.5.10-assigned-client-identifier}
+#### **3.5.10 Assigned Client Identifier** {#3.5.10-assigned-client-identifier}
The Client Identifier assigned by the gateway when the associated CONNECT packet contained no Client Identifier. If the Client connects using a zero length Client Identifier, the Server MUST respond with a CONNACK containing an Assigned Client Identifier. The Assigned Client Identifier MUST be a new Client Identifier not used by any other Session currently in the Gateway.
\ No newline at end of file
@@ -1619,9 +1615,9 @@
Where a transparent gateway obtains an Assigned Client Identifier which is deemed too large for a device, it should maintain a registry to map shorter gateway generated Client Identifiers with their versions returned from the broker.
-### **3.1.6 AUTH \- Authentication Exchange** {#3.1.6-auth---authentication-exchange}
+### **3.6 AUTH \- Authentication Exchange** {#3.6-auth---authentication-exchange}
-![][image7]
+![][image11]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1638,27 +1634,27 @@
The authentication method and data is first sent by the Client as part of a CONNECT exchange. If the Server requires additional information to complete the authentication, it responds with an AUTH packet to signal that the Client generates and sends another AUTH packet with the required information and so on until the authentication is complete. The server then responds with a CONNACK message.
-#### **3.1.6.1 Length & Packet Type** {#3.1.6.1-length-&-packet-type}
+#### **3.6.1 Length & Packet Type** {#3.6.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.7.2 Packet Identifier** {#3.1.7.2-packet-identifier}
+#### **3.7.2 Packet Identifier** {#3.7.2-packet-identifier}
Used to identify the corresponding CONNECT or, AUTH or CONNACK packet. It should ideally be populated with a random integer value when sent from Client to Server. When sent from Server to Client, it MUST contain the packet identifier of the CONNECT or AUTH packet being responded to.
-#### **3.1.6.2 Reason Code** {#3.1.6.2-reason-code}
+#### **3.6.2 Reason Code** {#3.6.2-reason-code}
Byte 3 in the Auth packet holds the Authentication Reason Code. The values for the Authentication Reason Code field are shown in Table 9: Reason Code Values. The sender of the AUTH Packet MUST use one of the Authenticate Reason Codes.
-#### **3.1.6.3 Auth Method Length** {#3.1.6.3-auth-method-length}
+#### **3.6.3 Auth Method Length** {#3.6.3-auth-method-length}
The length of the auth method string.
-#### **3.1.6.4 Auth Method** {#3.1.6.4-auth-method}
+#### **3.6.4 Auth Method** {#3.6.4-auth-method}
A UTF-8 Encoded String containing the name of the authentication method.
-#### **3.1.6.5 Auth Data** {#3.1.6.5-auth-data}
+#### **3.6.5 Auth Data** {#3.6.5-auth-data}
Binary Data containing authentication data. The contents of this data are defined by the authentication method.
\ No newline at end of file
@@ -1666,13 +1662,13 @@
For a simple cleartext password analogous to MQTT username and password, the SASL PLAIN method can be used.
-#### **3.1.6.6 Auth Actions** {#3.1.6.6-auth-actions}
+#### **3.6.6 Auth Actions** {#3.6.6-auth-actions}
Refer to [section 4.11](\#4.11-enhanced-authentication) for more information about extended authentication.
-### **3.1.7 REGISTER \- Register Topic Alias Request** {#3.1.7-register---register-topic-alias-request}
+### **3.7 REGISTER \- Register Topic Alias Request** {#3.7-register---register-topic-alias-request}
-![][image8]
+![][image12]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1688,29 +1684,29 @@
The REGISTER packet is sent by a client to a GW for requesting a topic alias value for the included topic name. It is also sent by a GW to inform a client about the topic alias value it has assigned to the included topic name.
-#### **3.1.7.1 Length & Packet Type** {#3.1.7.1-length-&-packet-type}
+#### **3.7.1 Length & Packet Type** {#3.7.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.7.2 Packet Identifier** {#3.1.7.2-packet-identifier-1}
+#### **3.7.2 Packet Identifier** {#3.7.2-packet-identifier-1}
Used to identify the corresponding REGACK packet. It should ideally be populated with a random integer value.
-#### **3.1.7.3 Topic Alias** {#3.1.7.3-topic-alias}
+#### **3.7.3 Topic Alias** {#3.7.3-topic-alias}
If sent by a client, it is coded 0x0000 and is not relevant; if sent by a GW, it contains the topic alias value assigned to the topic name included in the Topic Name field.
-#### **3.1.7.4 Topic Name** {#3.1.7.4-topic-name}
+#### **3.7.4 Topic Name** {#3.7.4-topic-name}
Fixed Length UTF-8 Encoded String Contains the fully qualified topic name.
-#### **3.1.7.5 Register Actions** {#3.1.7.5-register-actions}
+#### **3.7.5 Register Actions** {#3.7.5-register-actions}
As described in [section 4.17](\#4.17-topic-registration).
-### **3.1.8 REGACK \- Register Topic Alias Response** {#3.1.8-regack---register-topic-alias-response}
+### **3.8 REGACK \- Register Topic Alias Response** {#3.8-regack---register-topic-alias-response}
-![][image9]
+![][image13]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | | 1 | | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1729,11 +1725,11 @@
The REGACK packet is sent by a client or by a GW as an acknowledgment to the receipt and processing of a REGISTER packet.
-#### **3.1.8.1 Length & Packet Type** {#3.1.8.1-length-&-packet-type}
+#### **3.8.1 Length & Packet Type** {#3.8.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.8.2 REGACK Flags** {#3.1.8.2-regack-flags}
+#### **3.8.2 REGACK Flags** {#3.8.2-regack-flags}
The REGACK Flags is 1 byte field in Byte position 3 of the REGACK packet.
\ No newline at end of file
@@ -1741,19 +1737,19 @@
* **Topic Type**. This is a 2-bit field in Bit 0 and 1 which determines the format of the topic value. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
-#### **3.1.8.3 Packet Identifier** {#3.1.8.3-packet-identifier}
+#### **3.8.3 Packet Identifier** {#3.8.3-packet-identifier}
The same value as the Packet Identifier in the REGISTER packet being acknowledged.
-#### **3.1.8.4 Topic Alias** {#3.1.8.4-topic-alias}
+#### **3.8.4 Topic Alias** {#3.8.4-topic-alias}
A Topic Alias is an integer value that is used to identify the Topic instead of the Topic Name. This numeric value is used as the Topic Alias.
-#### **3.1.8.5 Reason Code** {#3.1.8.5-reason-code}
+#### **3.8.5 Reason Code** {#3.8.5-reason-code}
Byte 8 in the REGACK packet holds the Register Reason Code. The values for the Register Reason Code field are shown in Table 9: Reason Code Values. The sender of the REGACK Packet MUST use one of the Register Reason Codes.
-### **3.1.9 Publish Variants** {#3.1.9-publish-variants}
+### **3.9 Publish Variants** {#3.9-publish-variants}
MQTT-SN is designed to be optimized for packet size. For this reason, the PUBLISH packet has been split into 3 variants; Variant 1 catering for PUBLISH WITHOUT SESSION where no GW session is required, Variant 2 catering for Quality of Service 0 where no response ACK is required and thus no packet identifier is required and Quality of Service 1 and 2 where a response is expected. The table below breaks down the different versions of the PUBLISH packet and their respective type identifiers.
\ No newline at end of file
@@ -1762,9 +1758,9 @@
| **Publish** | 0x0C | A PUBLISH packet corresponding to Quality of Service (QoS) 0, 1 or 2 |
| **Publish Without Session** | 0x11 | A PUBLISH Packet sent by a Client and does not need not to have an active Session |
-### **3.1.10 PUBWOS \- Publish Without Session** {#3.1.10-pubwos---publish-without-session}
+### **3.10 PUBWOS \- Publish Without Session** {#3.10-pubwos---publish-without-session}
-![][image10]
+![][image14]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | | 2 | | 1 | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | ----- | :---: | :---: | :---: |
\ No newline at end of file
@@ -1781,7 +1777,7 @@
This packet is used by both clients and gateways to publish data for a certain topic.
-The PUBWOS packet does not have a corresponding feature in MQTT. If forwarded to an MQTT connection, PUBWOS packets MUST have their MQTT Quality of Service level set to 0\. \[MQTT-SN-3.1.10-1\]
+The PUBWOS packet does not have a corresponding feature in MQTT. If forwarded to an MQTT connection, PUBWOS packets MUST have their MQTT Quality of Service level set to 0\. \[MQTT-SN-3.10-1\]
**Informative comment**
\ No newline at end of file
@@ -1791,11 +1787,11 @@
PUBWOS packets received by a Gateway are not associated with a MQTT-SN Client Session and can be optionally discarded by the Gateway without being processed for onward delivery.
-#### **3.1.10.1 Length & Packet Type** {#3.1.10.1-length-&-packet-type}
+#### **3.10.1 Length & Packet Type** {#3.10.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.10.2 PUBWOS Flags** {#3.1.10.2-pubwos-flags}
+#### **3.10.2 PUBWOS Flags** {#3.10.2-pubwos-flags}
The PUBWOS Flags field is 1-byte located in the Byte 3 position of the PUBWOS control packet.
\ No newline at end of file
@@ -1804,23 +1800,23 @@
* **Topic Type**. This is a 2-bit field in Bit 0 and 1 which determines the format of the topic data field. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types. **NOTE: only predefined topic alias, short topic or full topic types are allowed in PUBWOS packets.**
* **Retain**: 1 bit field stored in Bit 4 and has the same meaning as with MQTT. The field signifies whether the existing Retained Message for this topic is replaced or kept. For a detailed description of Retained Messages see [section 4.26](\#4.26-retained-messages).
-#### **3.1.10.3 Topic Data** {#3.1.10.3-topic-data}
+#### **3.10.3 Topic Data** {#3.10.3-topic-data}
Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.
-#### **3.1.10.4 Data** {#3.1.10.4-data}
+#### **3.10.4 Data** {#3.10.4-data}
In the case of Topic Alias Type b11 the data section will be prefixed with a “Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
-#### **3.1.12.7 PUBWOS Actions** {#3.1.12.7-pubwos-actions}
+#### **3.10.5 PUBWOS Actions** {#3.10.5-pubwos-actions}
The Client or Server uses a PUBWOS packet to send an Application Message to a Network Address, for possible receipt by a Server or another Client.
-If received by a Client or Server, the PUBWOS packet MUST be treated as if its QoS were 0 \[MQTT-SN-3.1.12.7-1\] as described in [section 3.1.12.7](\#3.1.12.7-publish-actions).
+If received by a Client or Server, the PUBWOS packet MUST be treated as if its QoS were 0 \[MQTT-SN-3.10.5-1\] as described in [section 3.12.7](\#3.12.7-publish-actions).
-### **3.1.11 PUBLISH \- QoS 0** {#3.1.11-publish---qos-0}
+### **3.11 PUBLISH \- QoS 0** {#3.11-publish---qos-0}
-![][image11]
+![][image15]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | | 2 | | 1 | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | ----- | :---: | :---: | :---: |
\ No newline at end of file
@@ -1835,13 +1831,13 @@
Table 29: PUBLISH packet
-This packet is used by both clients and gateways to publish data for a certain topic. PUBLISH QoS 0, 1 & 2 packets received by a Gateway MUST be associated with a valid Client Session \[MQTT-SN-3.1.11-1\].
+This packet is used by both clients and gateways to publish data for a certain topic. PUBLISH QoS 0, 1 & 2 packets received by a Gateway MUST be associated with a valid Client Session \[MQTT-SN-3.11-1\].
-#### **3.1.11.1 Length & Packet Type** {#3.1.11.1-length-&-packet-type}
+#### **3.11.1 Length & Packet Type** {#3.11.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.11.2 PUBLISH Flags** {#3.1.11.2-publish-flags}
+#### **3.11.2 PUBLISH Flags** {#3.11.2-publish-flags}
The PUBLISH Flags field is 1-byte located in Byte 3 position of the PUBLISH control packet.
\ No newline at end of file
@@ -1851,21 +1847,21 @@
* **QoS**: This is a 2-bit field stored in Bit 5 and 6\. QoS has the same meaning as with MQTT indicating the Quality of Service. This field is set to “0b00” for QoS 0\. For a detailed description of the various Quality Of Service levels refer to [section 4.3](\#4.3-quality-of-service-levels-and-protocol-flows).
* **Retain**: 1 bit field stored in Bit 4 and has the same meaning as with MQTT. The field signifies whether the existing Retained Message for this topic is replaced or kept. For a detailed description of Retained Messages see [section 4.26](\#4.26-retained-messages).
-#### **3.1.11.3 Topic Data** {#3.1.11.3-topic-data}
+#### **3.11.3 Topic Data** {#3.11.3-topic-data}
Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.
-#### **3.1.11.4 Data** {#3.1.11.4-data}
+#### **3.11.4 Data** {#3.11.4-data}
In the case of Topic Type b11 the data section will be prefixed with a “Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
-#### **3.1.11.5 PUBLISH \- QoS 0 Actions** {#3.1.11.5-publish---qos-0-actions}
+#### **3.11.5 PUBLISH \- QoS 0 Actions** {#3.11.5-publish---qos-0-actions}
-As described in [section 3.1.12.7](\#3.1.12.7-publish-actions).
+As described in [section 3.12.7](\#3.12.7-publish-actions).
-### **3.1.12 PUBLISH \- QoS 1 and 2** {#3.1.12-publish---qos-1-and-2}
+### **3.12 PUBLISH \- QoS 1 and 2** {#3.12-publish---qos-1-and-2}
-![][image12]
+![][image16]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | | 2 | | 1 | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | ----- | :---: | :---: | :---: |
\ No newline at end of file
@@ -1884,13 +1880,13 @@
This packet is used by both clients and gateways to publish data for a certain topic.
-PUBLISH QoS 0, 1 & 2 packets received by a Gateway MUST be associated with a valid Client Session \[MQTT-SN-3.1.12-1\].
+PUBLISH QoS 0, 1 & 2 packets received by a Gateway MUST be associated with a valid Client Session \[MQTT-SN-3.12-1\].
-#### **3.1.12.1 Length & Packet Type** {#3.1.12.1-length-&-packet-type}
+#### **3.12.1 Length & Packet Type** {#3.12.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.12.2 PUBLISH Flags** {#3.1.12.2-publish-flags}
+#### **3.12.2 PUBLISH Flags** {#3.12.2-publish-flags}
The PUBLISH Flags field is 1-byte located in Byte 3 position of the PUBLISH control packet.
\ No newline at end of file
@@ -1913,23 +1909,23 @@
* **DUP**: 1 bit field stored in Bit 7 and has the same meaning as with MQTT. It notes the duplicate delivery of packets. If the DUP flag is set to “0”, it signifies that the packet is sent for the first time. If the DUP flag is set to “1”, it signifies that the packet was retransmitted or retried.
* **Retain**: 1 bit field stored in Bit 4 and has the same meaning as with MQTT. The field signifies whether an existing Retained Message for this topic is replaced or kept. For a detailed description of Retained Messages see [section 4.26](\#4.26-retained-messages).
-#### **3.1.12.4 Packet Identifier** {#3.1.12.4-packet-identifier}
+#### **3.12.4 Packet Identifier** {#3.12.4-packet-identifier}
Used to identify the corresponding PUBACK packet in the case of QoS 1\. Used to identify the corresponding PUBREC, PUBREL and PUBCOMP packets in the case of QoS 2\. It should ideally be populated with a random integer value.
-#### **3.1.12.5 Topic Data** {#3.1.12.5-topic-data}
+#### **3.12.5 Topic Data** {#3.12.5-topic-data}
Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.
-#### **3.1.12.6 Data** {#3.1.12.6-data}
+#### **3.12.6 Data** {#3.12.6-data}
The *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
In the case of Topic Type b11 the data section will be prefixed with a “Full Topic Name” encoded with a UTF-8 encoded string value of length determined by the previously defined length field. Thereafter, the *Data* field corresponds to the payload of an MQTT PUBLISH packet. It has a variable length and contains the application data that is being published.
-#### **3.1.12.7 PUBLISH Actions** {#3.1.12.7-publish-actions}
+#### **3.12.7 PUBLISH Actions** {#3.12.7-publish-actions}
-The receiver of a PUBLISH pPacket MUST respond with the packet as determined by the QoS in the PUBLISH Packet. \[MQTT-SN-3.1.12.7-1\].
+The receiver of a PUBLISH pPacket MUST respond with the packet as determined by the QoS in the PUBLISH Packet. \[MQTT-SN-3.12.7-1\].
Table 3‑3 Expected PUBLISH packet response
\ No newline at end of file
@@ -1943,7 +1939,7 @@
The Server uses a PUBLISH packet to send an Application Message to each Client which has a matching subscription. The PUBLISH packet includes the Subscription Identifier carried in the SUBSCRIBE packet, if there was one.
-When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published Application Message might match multiple filters. In this case the Server MUST deliver the Application Message to the Client respecting the maximum QoS of all the matching subscriptions \[MQTT-SN-3.1.12.7-2\]. In addition, the Server MAY deliver further copies of the Application Message, one for each additional matching subscription and respecting the subscription’s QoS in each case.
+When Clients make subscriptions with Topic Filters that include wildcards, it is possible for a Client’s subscriptions to overlap so that a published Application Message might match multiple filters. In this case the Server MUST deliver the Application Message to the Client respecting the maximum QoS of all the matching subscriptions \[MQTT-SN-3.12.7-2\]. In addition, the Server MAY deliver further copies of the Application Message, one for each additional matching subscription and respecting the subscription’s QoS in each case.
The action of the recipient when it receives a PUBLISH packet depends on the QoS level as described in [section 4.3](\#4.3-quality-of-service-levels-and-protocol-flows).
\ No newline at end of file
@@ -1963,9 +1959,9 @@
The Server might choose to suspend the sending of QoS 0 PUBLISH packets when it suspends the sending of QoS 1 and QoS 2 PUBLISH packets.
-### **3.1.13 PUBACK – Publish Acknowledgement** {#3.1.13-puback-–-publish-acknowledgement}
+### **3.13 PUBACK – Publish Acknowledgement** {#3.13-puback-–-publish-acknowledgement}
-![][image13]
+![][image17]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -1979,25 +1975,25 @@
A PUBACK packet is the response to a PUBLISH packet with QoS 1\. It can also be sent as response to a PUBLISH packet of any QoS (*with the exception of QoS \-1, or PUBWOS*) in case of an error; the error reason is then indicated in the *Reason Code* field.
-#### **3.1.13.1 Length & Packet Type** {#3.1.13.1-length-&-packet-type}
+#### **3.13.1 Length & Packet Type** {#3.13.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.13.2 Packet Identifier** {#3.1.13.2-packet-identifier}
+#### **3.13.2 Packet Identifier** {#3.13.2-packet-identifier}
The same value as the Packet Identifier in the PUBLISH Packet being acknowledged.
-#### **3.1.13.3 Reason Code** {#3.1.13.3-reason-code}
+#### **3.13.3 Reason Code** {#3.13.3-reason-code}
Byte 5 in the PUBACK packet holds the Reason code in response to the PUBLISH packet. The PUBACK Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the PUBACK packet MUST use one of the PUBACK Reason Codes.
-#### **3.1.13.4 PUBACK Actions** {#3.1.13.4-puback-actions}
+#### **3.13.4 PUBACK Actions** {#3.13.4-puback-actions}
As described in [section 4.3.3](\#4.3.3-qos-1:-at-least-once-delivery).
-### **3.1.14 PUBREC (QoS 2 delivery part 1\)** {#3.1.14-pubrec-(qos-2-delivery-part-1)}
+### **3.14 PUBREC (QoS 2 delivery part 1\)** {#3.14-pubrec-(qos-2-delivery-part-1)}
-![][image14]
+![][image18]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2011,25 +2007,25 @@
A PUBREC packet is the response to a PUBLISH packet with QoS 2\. It is the second packet of the QoS 2 protocol exchange.
-#### **3.1.14.1 Length & Packet Type** {#3.1.14.1-length-&-packet-type}
+#### **3.14.1 Length & Packet Type** {#3.14.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.14.2 Packet Identifier** {#3.1.14.2-packet-identifier}
+#### **3.14.2 Packet Identifier** {#3.14.2-packet-identifier}
The same value as the Packet Identifier in the PUBLISH Packet being acknowledged.
-#### **3.1.14.3 Reason Code** {#3.1.14.3-reason-code}
+#### **3.14.3 Reason Code** {#3.14.3-reason-code}
Byte 5 in the PUBREC packet holds the Reason code in response to the PUBLISH packet. The PUBREC Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the PUBREC packet MUST use one of the PUBREC Reason Codes.
-#### **3.1.14.4 PUBREC Actions** {#3.1.14.4-pubrec-actions}
+#### **3.14.4 PUBREC Actions** {#3.14.4-pubrec-actions}
As described in [section 4.3.4](\#4.3.4-qos-2:-exactly-once-delivery).
-### **3.1.15 PUBREL (QoS 2 delivery part 2\)** {#3.1.15-pubrel-(qos-2-delivery-part-2)}
+### **3.15 PUBREL (QoS 2 delivery part 2\)** {#3.15-pubrel-(qos-2-delivery-part-2)}
-![][image15]
+![][image19]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2043,25 +2039,25 @@
A PUBREL packet is the response to a PUBREC packet. It is the third packet of the QoS 2 protocol exchange.
-#### **3.1.15.1 Length & Packet Type** {#3.1.15.1-length-&-packet-type}
+#### **3.15.1 Length & Packet Type** {#3.15.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.15.2 Packet Identifier** {#3.1.15.2-packet-identifier}
+#### **3.15.2 Packet Identifier** {#3.15.2-packet-identifier}
The same value as the Packet Identifier in the PUBLISH Packet being acknowledged.
-#### **3.1.15.3 Reason Code** {#3.1.15.3-reason-code}
+#### **3.15.3 Reason Code** {#3.15.3-reason-code}
Byte 5 in the PUBREL packet holds the Reason code in response to the PUBREC packet. The PUBREL Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the PUBREL packet MUST use one of the PUBREL Reason Codes.
-#### **3.1.15.4 PUBREL Actions** {#3.1.15.4-pubrel-actions}
+#### **3.15.4 PUBREL Actions** {#3.15.4-pubrel-actions}
As described in [section 4.3.4](\#4.3.4-qos-2:-exactly-once-delivery).
-### **3.1.16 PUBCOMP \- Publish Complete (QoS 2 delivery part 3\)** {#3.1.16-pubcomp---publish-complete-(qos-2-delivery-part-3)}
+### **3.16 PUBCOMP \- Publish Complete (QoS 2 delivery part 3\)** {#3.16-pubcomp---publish-complete-(qos-2-delivery-part-3)}
-![][image16]
+![][image20]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2075,29 +2071,29 @@
The PUBCOMP packet is the response to a PUBREL packet. It is the fourth and final packet of the QoS 2 protocol exchange.
-#### **3.1.16.1 Length & Packet Type** {#3.1.16.1-length-&-packet-type}
+#### **3.16.1 Length & Packet Type** {#3.16.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.16.2 Packet Identifier** {#3.1.16.2-packet-identifier}
+#### **3.16.2 Packet Identifier** {#3.16.2-packet-identifier}
The same value as the Packet Identifier in the PUBLISH Packet being acknowledged.
-#### **3.1.16.3 Reason Code** {#3.1.16.3-reason-code}
+#### **3.16.3 Reason Code** {#3.16.3-reason-code}
Byte 5 in the PUBCOMP packet holds the Reason code in response to the PUBREL packet. The PUBCOMP Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the PUBCOMP packet MUST use one of the PUBCOMP Reason Codes.
-#### **3.1.16.4 PUBCOMP Actions** {#3.1.16.4-pubcomp-actions}
+#### **3.16.4 PUBCOMP Actions** {#3.16.4-pubcomp-actions}
As described in [section 4.3.4](\#4.3.4-qos-2:-exactly-once-delivery).
-### **3.1.17 SUBSCRIBE \- Subscribe Request** {#3.1.17-subscribe---subscribe-request}
+### **3.17 SUBSCRIBE \- Subscribe Request** {#3.17-subscribe---subscribe-request}
-![][image17]
+![][image21]
Or
-![][image18]
+![][image22]
| Bit | 7 | 6 | | 5 | | | 4 | 3 | | 2 | 1 | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | :---: |
\ No newline at end of file
@@ -2115,11 +2111,11 @@
The SUBSCRIBE packet is used by a client to subscribe to a certain topic name.
-#### **3.1.17.1 Length & Packet Type** {#3.1.17.1-length-&-packet-type}
+#### **3.17.1 Length & Packet Type** {#3.17.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.17.2 SUBSCRIBE Flags** {#3.1.17.2-subscribe-flags}
+#### **3.17.2 SUBSCRIBE Flags** {#3.17.2-subscribe-flags}
The SUBSCRIBE Flags field is 1-byte and contains the following flags:
\ No newline at end of file
@@ -2135,25 +2131,25 @@
* **Topic Type**: This is a 2-bit field in Bit 0 and 1 which determines the format of the topic data field. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
-#### **3.1.17.3 Packet Identifier** {#3.1.17.3-packet-identifier}
+#### **3.17.3 Packet Identifier** {#3.17.3-packet-identifier}
Used to identify the corresponding SUBACK packet. It should ideally be populated with a random integer value.
-#### **3.1.17.4 Topic Data or Topic Filter** {#3.1.17.4-topic-data-or-topic-filter}
+#### **3.17.4 Topic Data or Topic Filter** {#3.17.4-topic-data-or-topic-filter}
Contains Fixed Length UTF-8 Encoded String topic filter, topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic names which this subscription is interested in.
-#### **3.1.17.5 SUBSCRIBE Actions** {#3.1.17.5-subscribe-actions}
+#### **3.17.5 SUBSCRIBE Actions** {#3.17.5-subscribe-actions}
-When the Server receives a SUBSCRIBE packet from a Client, the Server MUST respond with a SUBACK packet \[MQTT-SN-3.1.17.5-1\]. The SUBACK packet MUST have the same Packet Identifier as the SUBSCRIBE packet that it is acknowledging \[MQTT-SN-3.1.17.5-2\].
+When the Server receives a SUBSCRIBE packet from a Client, the Server MUST respond with a SUBACK packet \[MQTT-SN-3.17.5-1\]. The SUBACK packet MUST have the same Packet Identifier as the SUBSCRIBE packet that it is acknowledging \[MQTT-SN-3.17.5-2\].
The Server is permitted to start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK packet.
-If a Server receives a SUBSCRIBE packet containing a Topic Filter that is identical to a Subscription’s Topic Filter for the current Session, then it MUST replace that existing Subscription with a new Subscription \[MQTT-SN-3.1.17.5-3\]. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its Subscription Options could be different. If the Retain Handling option is 0, any existing retained messages matching the Topic Filter MUST be re-sent, but Application Messages MUST NOT be lost due to replacing the Subscription \[MQTT-SN-3.1.17.5-4\].
+If a Server receives a SUBSCRIBE packet containing a Topic Filter that is identical to a Subscription’s Topic Filter for the current Session, then it MUST replace that existing Subscription with a new Subscription \[MQTT-SN-3.17.5-3\]. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its Subscription Options could be different. If the Retain Handling option is 0, any existing retained messages matching the Topic Filter MUST be re-sent, but Application Messages MUST NOT be lost due to replacing the Subscription \[MQTT-SN-3.17.5-4\].
If a Server receives a Topic Filter that is not identical to any Topic Filter for the current Session, a new Subscription is created. If the Retain Handling option is not 2, all matching retained messages are sent to the Client.
-The SUBACK packet sent by the Server to the Client MUST contain a Reason Code \[MQTT-SN-3.1.17.5-5\]. This Reason Code MUST either show the maximum QoS that was granted for that Subscription or indicate that the subscription failed \[MQTT-SN-3.1.17.5-6\]. The Server might grant a lower Maximum QoS than the subscriber requested. The QoS of Application Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published Application message and the Maximum QoS granted by the Server \[MQTT-SN-3.1.17.5-7\]. The server is permitted to send duplicate copies of a Application message to a subscriber in the case where the original Application message was published with QoS 1 and the maximum QoS granted was QoS 0\.
+The SUBACK packet sent by the Server to the Client MUST contain a Reason Code \[MQTT-SN-3.17.5-5\]. This Reason Code MUST either show the maximum QoS that was granted for that Subscription or indicate that the subscription failed \[MQTT-SN-3.17.5-6\]. The Server might grant a lower Maximum QoS than the subscriber requested. The QoS of Application Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published Application message and the Maximum QoS granted by the Server \[MQTT-SN-3.17.5-7\]. The server is permitted to send duplicate copies of a Application message to a subscriber in the case where the original Application message was published with QoS 1 and the maximum QoS granted was QoS 0\.
**Informative comment**
If a subscribing Client has been granted maximum QoS 1 for a particular Topic Filter, then a QoS 0 Application Message matching the filter is delivered to the Client at QoS 0\. This means that at most one copy of the Application Message is received by the Client. On the other hand, a QoS 2 Application Message published to the same topic is downgraded by the Server to QoS 1 for delivery to the Client, so that Client might receive duplicate copies of the Application Message.
\ No newline at end of file
@@ -2166,9 +2162,9 @@
Subscribing to a Topic Filter at QoS 2 is equivalent to saying "I would like to receive Application Messages matching this filter at the QoS with which they were published". This means a publisher is responsible for determining the maximum QoS an Application Message can be delivered at, but a subscriber is able to require that the Server downgrades the QoS to one more suitable for its usage.
-### **3.1.18 SUBACK \- Subscribe Acknowledgement** {#3.1.18-suback---subscribe-acknowledgement}
+### **3.18 SUBACK \- Subscribe Acknowledgement** {#3.18-suback---subscribe-acknowledgement}
-![][image19]
+![][image23]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | 2 | 1 | | 0 | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2187,35 +2183,35 @@
The SUBACK packet is sent by a gateway to a client as an acknowledgment to the receipt and processing of a SUBSCRIBE packet.
-#### **3.1.18.1 Length & Packet Type** {#3.1.18.1-length-&-packet-type}
+#### **3.18.1 Length & Packet Type** {#3.18.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.18.2 Flags** {#3.1.18.2-flags}
+#### **3.18.2 Flags** {#3.18.2-flags}
The SUBACK Flags field is 1-byte located in Byte 3 position of the SUBACK control packet. The SUBACK Flags includes the following flags:
* **Topic Type**. This is a 2-bit field in Bit 0 and 1 which determines the format of the topic data field. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
-#### **3.1.18.3 Topic Data** {#3.1.18.3-topic-data}
+#### **3.18.3 Topic Data** {#3.18.3-topic-data}
In case of “accepted” the returned Topic Datavalue that will be used as topic alias by the gateway when sending PUBLISH packets to the client (not relevant, 0x0000, in case of subscriptions to a short topic name or to a topic name which contains wildcard characters)
-#### **3.1.18.4 Packet Identifier** {#3.1.18.4-packet-identifier}
+#### **3.18.4 Packet Identifier** {#3.18.4-packet-identifier}
The same value as the Packet Identifier in the SUBSCRIBE Packet being acknowledged.
-#### **3.1.18.5 Reason Code** {#3.1.18.5-reason-code}
+#### **3.18.5 Reason Code** {#3.18.5-reason-code}
Byte 8 in the SUBACK packet holds the Reason code in response to the SUBSCRIBE packet. The SUBACK Reason Codes are shown in Table 9: Reason Code Values.The Server sending the SUBACK packet MUST use one of the SUBACK Reason Codes.
-### **3.1.19 UNSUBSCRIBE \- Unsubscribe Request** {#3.1.19-unsubscribe---unsubscribe-request}
+### **3.19 UNSUBSCRIBE \- Unsubscribe Request** {#3.19-unsubscribe---unsubscribe-request}
-![][image20]
+![][image24]
Or:
-![][image21]
+![][image25]
| Bit | 7 | 6 | | 5 | | 4 | 3 | | | | 2 | 1 | 0 | |
| ----- | ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | ----- | :---: | :---: |
\ No newline at end of file
@@ -2233,11 +2229,11 @@
An UNSUBSCRIBE packet is sent by the client to the GW to unsubscribe from named topics.
-#### **3.1.19.1 Length & Packet Type** {#3.1.19.1-length-&-packet-type}
+#### **3.19.1 Length & Packet Type** {#3.19.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.19.2 UNSUBSCRIBE Flags** {#3.1.19.2-unsubscribe-flags}
+#### **3.19.2 UNSUBSCRIBE Flags** {#3.19.2-unsubscribe-flags}
For The UNSUBSCRIBE Flags is 1 byte field in Byte position 3 of the UNSUBSCRIBE packet.
\ No newline at end of file
@@ -2245,29 +2241,29 @@
* **Topic Type.** This is a 2-bit field in Bit 0 and 1 which determines the format of the topic dataId value. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
-#### **3.1.19.3 Packet Identifier** {#3.1.19.3-packet-identifier}
+#### **3.19.3 Packet Identifier** {#3.19.3-packet-identifier}
Used to identify the corresponding UNSUBACK packet. It should ideally be populated with a random integer value.
-#### **3.1.19.4 Topic Data or Topic Filter** {#3.1.19.4-topic-data-or-topic-filter}
+#### **3.19.4 Topic Data or Topic Filter** {#3.19.4-topic-data-or-topic-filter}
Contains Fixed Length UTF-8 Encoded String topic filter, topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic names which this subscription is interested in.
-#### **3.1.19.4 UNSUBSCRIBE Actions** {#3.1.19.4-unsubscribe-actions}
+#### **3.19.4 UNSUBSCRIBE Actions** {#3.19.4-unsubscribe-actions}
-The Topic Filter (whether it contains wildcards or not) supplied in an UNSUBSCRIBE packet MUST be compared character-by-character with the current set of Topic Filters held by the Server for the Client. If any filter matches exactly then its owning Subscription MUST be deleted \[MQTT-SN-3.1.19.4-1\], otherwise no additional processing occurs.
+The Topic Filter (whether it contains wildcards or not) supplied in an UNSUBSCRIBE packet MUST be compared character-by-character with the current set of Topic Filters held by the Server for the Client. If any filter matches exactly then its owning Subscription MUST be deleted \[MQTT-SN-3.19.4-1\], otherwise no additional processing occurs.
When a Server receives UNSUBSCRIBE :
-* It MUST stop adding any new Application Messages which match the Topic Filters, for delivery to the Client \[MQTT-SN-3.1.19.4-2\].
-* It MUST complete the delivery of any QoS 1 or QoS 2 Application Messages which match the Topic Filters and it has started to send to the Client \[MQTT-SN-3.1.19.4-3\].
+* It MUST stop adding any new Application Messages which match the Topic Filters, for delivery to the Client \[MQTT-SN-3.19.4-2\].
+* It MUST complete the delivery of any QoS 1 or QoS 2 Application Messages which match the Topic Filters and it has started to send to the Client \[MQTT-SN-3.19.4-3\].
* It MAY continue to deliver any existing Application Messages which match the Topic Filters buffered for delivery to the Client.
-The Server MUST respond to an UNSUBSCRIBE request by sending an UNSUBACK packet \[MQTT-3.1.19.4-4\]. The UNSUBACK packet MUST have the same Packet Identifier as the UNSUBSCRIBE packet. Even where no Topic Subscriptions are deleted, the Server MUST respond with an UNSUBACK \[MQTT-3.1.19.4-5\].
+The Server MUST respond to an UNSUBSCRIBE request by sending an UNSUBACK packet \[MQTT-3.19.4-4\]. The UNSUBACK packet MUST have the same Packet Identifier as the UNSUBSCRIBE packet. Even where no Topic Subscriptions are deleted, the Server MUST respond with an UNSUBACK \[MQTT-3.19.4-5\].
-### **3.1.20 UNSUBACK \- Unsubscribe Acknowledgement** {#3.1.20-unsuback---unsubscribe-acknowledgement}
+### **3.20 UNSUBACK \- Unsubscribe Acknowledgement** {#3.20-unsuback---unsubscribe-acknowledgement}
-![][image22]
+![][image26]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2281,21 +2277,21 @@
An UNSUBACK packet is sent by a GW to acknowledge the receipt and processing of an UNSUBSCRIBE packet.
-#### **3.1.20.1 Length & Packet Type** {#3.1.20.1-length-&-packet-type}
+#### **3.20.1 Length & Packet Type** {#3.20.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.20.2 Packet Identifier** {#3.1.20.2-packet-identifier}
+#### **3.20.2 Packet Identifier** {#3.20.2-packet-identifier}
The same value as the Packet Identifier in the UNSUBSCRIBE packet being acknowledged.
-#### **3.1.20.3 Reason Code** {#3.1.20.3-reason-code}
+#### **3.20.3 Reason Code** {#3.20.3-reason-code}
Byte 5 in the UNSUBACK packet holds the Reason code in response to UNSUBSCRIBE packet. The UNSUBACK Reason Codes are shown in Table 9: Reason Code Values. The server sending the UNSUBACK packet MUST use one of the UNSUBACK Reason Codes.
-### **3.1.21 PINGREQ \- Ping Request** {#3.1.21-pingreq---ping-request}
+### **3.21 PINGREQ \- Ping Request** {#3.21-pingreq---ping-request}
-![][image23]
+![][image27]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2307,29 +2303,29 @@
The PINGREQ packet is an ”are you alive” packet that is sent from or received by a connected client.
-#### **3.1.21.1 Length & Packet Type** {#3.1.21.1-length-&-packet-type}
+#### **3.21.1 Length & Packet Type** {#3.21.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.21.2 Packet Identifier** {#3.1.21.2-packet-identifier}
+#### **3.21.2 Packet Identifier** {#3.21.2-packet-identifier}
Used to identify the corresponding PINGRESP packet. It should ideally be set to a random integer value.
-#### **3.1.21.3 Client Identifier (optional)** {#3.1.21.3-client-identifier-(optional)}
+#### **3.21.3 Client Identifier (optional)** {#3.21.3-client-identifier-(optional)}
Contains the client identifier (ClientID); this field is optional and is included by a “sleeping” client when it goes to the “awake” state and is waiting for packets sent by the server/gateway.
-The Client Identifier MUST be a Fixed Length UTF-8 Encoded String \[MQTT-SN-3.1.21.3-1\].
+The Client Identifier MUST be a Fixed Length UTF-8 Encoded String \[MQTT-SN-3.21.3-1\].
-#### **3.1.21.4 PINGREQ Actions** {#3.1.21.4-pingreq-actions}
+#### **3.21.4 PINGREQ Actions** {#3.21.4-pingreq-actions}
-The Server MUST send a PINGRESP packet in response to a PINGREQ packet \[MQTT-SN-3.1.21.4-1\].
+The Server MUST send a PINGRESP packet in response to a PINGREQ packet \[MQTT-SN-3.21.4-1\].
-The Client MAY send a PINGRESP packet in response to a PINGREQ packet \[MQTT-SN-3.1.21.4-2\].
+The Client MAY send a PINGRESP packet in response to a PINGREQ packet \[MQTT-SN-3.21.4-2\].
-### **3.1.22 PINGRESP \- Ping Response** {#3.1.22-pingresp---ping-response}
+### **3.22 PINGRESP \- Ping Response** {#3.22-pingresp---ping-response}
-![][image24]
+![][image28]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2345,15 +2341,15 @@
A PINGRESP packet is also sent by a Gateway to inform a sleeping ClLient that it has no more buffered packets for that Client.
-#### **3.1.22.1 Length & Packet Type** {#3.1.22.1-length-&-packet-type}
+#### **3.22.1 Length & Packet Type** {#3.22.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.22.2 Packet Identifier** {#3.1.22.2-packet-identifier}
+#### **3.22.2 Packet Identifier** {#3.22.2-packet-identifier}
The same value as the Packet Identifier in the PINGREQ Packet being acknowledged.
-#### **3.1.22.3 Application Messages Remaining** {#3.1.22.3-application-messages-remaining}
+#### **3.22.3 Application Messages Remaining** {#3.22.3-application-messages-remaining}
The number of Application Messages still queued for delivery at the Server when a Client is sent back to sleep. Optional – for use at the end of a client's awake period. Values can be:
\ No newline at end of file
@@ -2365,9 +2361,9 @@
Table 44: Allowed PINGRESP continuation values
-### **3.1.23 DISCONNECT \- Disconnect Notification** {#3.1.23-disconnect---disconnect-notification}
+### **3.23 DISCONNECT \- Disconnect Notification** {#3.23-disconnect---disconnect-notification}
-![][image25]
+![][image29]
| Bit | 7 | 6 | | 5 | | 4 | | 3 | | 2 | | 1 | | 0 | | |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2387,15 +2383,15 @@
As with MQTT, the DISCONNECT packet is sent by a client to indicate that it wants to delete the Virtual connection. The gateway will acknowledge the receipt of that packet by returning a DISCONNECT to the client. A server or gateway may also send a DISCONNECT to a client, e.g. in case a gateway, due to an error when for instance it, cannot map a received packet to thea client. Upon receiving such a DISCONNECT packet, a client should try to create another Virtual Connection by sending a CONNECT packet to the gateway or server.
-A Server MUST NOT send a DISCONNECT until after it has sent a CONNACK with Reason Code of less than 0x80 \[MQTT-SN-3.1.23-1\].
+A Server MUST NOT send a DISCONNECT until after it has sent a CONNACK with Reason Code of less than 0x80 \[MQTT-SN-3.23-1\].
A DISCONNECT packet with a *Session Expiry Interval* field is sent by a client when it wants to go to the “asleep” state. The receipt of this packet is also acknowledged by the gateway by means of a DISCONNECT packet.
-#### **3.1.23.1 Length & Packet Type** {#3.1.23.1-length-&-packet-type}
+#### **3.23.1 Length & Packet Type** {#3.23.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.23.2 Disconnect Flags** {#3.1.23.2-disconnect-flags}
+#### **3.23.2 Disconnect Flags** {#3.23.2-disconnect-flags}
The Disconnect Flags is 1 byte field located at byte 3 which contains parameters specifying the behavior of the MQTT-SN sleep on the gateway.
\ No newline at end of file
@@ -2409,31 +2405,31 @@
The Gateway MUST validate that the reserved flags in the DISCONNECT packet are set to 0\. If any of the reserved flags is not 0 it is a Malformed Packet.
-#### **3.1.23.3 Reason Code** {#3.1.23.3-reason-code}
+#### **3.23.3 Reason Code** {#3.23.3-reason-code}
The Reason Code for the DISCONNECT packet is optional. If provided, Byte 3 in the DISCONNECT control packet holds the Reason Code of the disconnection. If not provided, 0x00 (Normal disconnection) is assumed.
-The DISCONNECT Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the DISCONNECT packet MUST use one of the DISCONNECT Reason Code values \[MQTT-SN-3.1.23.3-1\].
+The DISCONNECT Reason Codes are shown in Table 9: Reason Code Values. The Client or Server sending the DISCONNECT packet MUST use one of the DISCONNECT Reason Code values \[MQTT-SN-3.23.3-1\].
-#### **3.1.23.4 Session Expiry Interval** {#3.1.23.4-session-expiry-interval}
+#### **3.23.4 Session Expiry Interval** {#3.23.4-session-expiry-interval}
The Session Expiry Interval is a four-byte integer time interval measured in seconds. If the Session Expiry Interval is set to 0 or omitted, the Session is transitioned to the “***disconnected***” state. When the value of this field is greater than zero, it is deemed to be sent by a client that wants to transition to the “***asleep***” state, see Section 4.153.19 for further details. At this point the keep alive timer becomes obsolete until the device issues a new CONNECT.
-The Session Expiry Interval MUST NOT be sent on a DISCONNECT by the Server \[MQTT–SN-3.1.23.4-1\].
+The Session Expiry Interval MUST NOT be sent on a DISCONNECT by the Server \[MQTT–SN-3.23.4-1\].
-#### **3.1.23.5 Reason String** {#3.1.23.5-reason-string}
+#### **3.23.5 Reason String** {#3.23.5-reason-string}
Fixed Length UTF-8 Encoded String representing a clear text description of disconnection.
-#### **3.1.23.6 DISCONNECT Actions** {#3.1.23.6-disconnect-actions}
+#### **3.23.6 DISCONNECT Actions** {#3.23.6-disconnect-actions}
After sending a DISCONNECT packet the sender:
-* MUST NOT send any more MQTT-SN Control Packets on that Virtual Connection \[MQTT-SN-3.1.23.6-1\].
+* MUST NOT send any more MQTT-SN Control Packets on that Virtual Connection \[MQTT-SN-3.23.6-1\].
After sending a DISCONNECT packet the Server:
-* MUST delete the Virtual Connection \[MQTT-SN-3.1.23.6-2\].
+* MUST delete the Virtual Connection \[MQTT-SN-3.23.6-2\].
After sending a DISCONNECT packet the Client:
\ No newline at end of file
@@ -2441,16 +2437,16 @@
On receipt of DISCONNECT with a Reason Code of 0x00 (Success) the Server:
-* MUST discard any Will Message associated with the current Connection without publishing it \[MQTT-SN-3.1.23.6-3\], as described in [section 3.1.4.9](\#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set)).
-* MUST send a DISCONNECT packet in response \[MQTT-SN-3.1.23.6-4\], and SHOULD delete the Virtual Connection.
+* MUST discard any Will Message associated with the current Connection without publishing it \[MQTT-SN-3.23.6-3\], as described in [section 3.4.9](\#3.4.9-connect-will-flags-(optional,-only-with-will-flag-set)).
+* MUST send a DISCONNECT packet in response \[MQTT-SN-3.23.6-4\], and SHOULD delete the Virtual Connection.
On receipt of DISCONNECT, the Client:
* SHOULD delete the Virtual Connection.
-### **3.1.24 WAKEUP \- Wake up request**
+### **3.24 WAKEUP \- Wake up request** {#3.24-wakeup---wake-up-request}
-![][image26]
+![][image30]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2461,17 +2457,17 @@
The wakeup packet is a signal sent from the gateway to a client. It is an indication from the gateway that the client should wake up. The client is not obliged to honor this request, nor may it even receive the packet. It can choose to ignore the request, or undertake one of the sequences outlined in the [4.25 Sleeping clients](\#4.25-sleeping-clients) section. The client need not respond to this packet.
-#### **3.1.24.1 Length & Packet Type**
+#### **3.24.1 Length & Packet Type** {#3.24.1-length-&-packet-type}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](https://docs.google.com/document/d/1Q\_l-TOttOqktQmnupRv7Un1Y8KzULIxc/edit?pli=1\#heading=h.23ckvvd) for a detailed description.
-#### **3.1.24.2 WAKEUP Actions**
+#### **3.24.2 WAKEUP Actions** {#3.24.2-wakeup-actions}
-The Client MAY choose to follow the AWAKE procedure in response to receiving a WAKEUP packet \[MQTT-SN-3.1.21.4-2\].
+The Client MAY choose to follow the AWAKE procedure in response to receiving a WAKEUP packet \[MQTT-SN-3.21.4-2\].
-### **3.1.25 Forwarder Encapsulation** {#3.1.25-forwarder-encapsulation}
+### **3.25 Forwarder Encapsulation** {#3.25-forwarder-encapsulation}
-![][image27]
+![][image31]
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2485,15 +2481,15 @@
As detailed in Section 4, MQTT-SN clients can also access a gateway via a forwarder in case the gateway is not directly attached to their WSNs. The forwarder simply encapsulates the MQTT-SN Packets it receives on the wireless side and forwards them unchanged to the gateway; in the opposite direction, it decapsulates the Packets it receives from the gateway and sends them to the clients, unchanged too.
-#### **3.1.25.1 Length** {#3.1.25.1-length}
+#### **3.25.1 Length** {#3.25.1-length}
1-byte long, specifies the number of bytes up to the end of the “Wireless Node Id” field (incl. the Length byte itself)
-#### **3.1.25.2 Packet Type** {#3.1.25.2-packet-type}
+#### **3.25.2 Packet Type** {#3.25.2-packet-type}
Coded “0xFE”, see Table 6
-#### **3.1.25.3 Ctrl** {#3.1.25.3-ctrl}
+#### **3.25.3 Ctrl** {#3.25.3-ctrl}
The Ctrl byte contains control information exchanged between the GW and the forwarder.
\ No newline at end of file
@@ -2504,21 +2500,21 @@
Table 54: Format of the ctrl byte
-#### **3.1.25.4 Radius** {#3.1.25.4-radius}
+#### **3.25.4 Radius** {#3.25.4-radius}
Transmission radius (only relevant in direction gateway to forwarder)
-#### **3.1.25.5 Wireless Node Id** {#3.1.25.5-wireless-node-id}
+#### **3.25.5 Wireless Node Id** {#3.25.5-wireless-node-id}
Identifies the wireless node which has sent or should receive the encapsulated MQTT-SN packet. The mapping between this Id and the address of the wireless node is implemented by the forwarder, if needed.
-#### **3.1.25.6 MQTT SN Packet** {#3.1.25.6-mqtt-sn-packet}
+#### **3.25.6 MQTT SN Packet** {#3.25.6-mqtt-sn-packet}
The MQTT-SN packet, encoded according to the packet type.
-### **3.1.26 Protection Encapsulation** {#3.1.26-protection-encapsulation}
+### **3.26 Protection Encapsulation** {#3.26-protection-encapsulation}
-### **![][image28]**
+### **![][image32]**
| Bit | 7 | 6 | | 5 | | 4 | 3 | | 2 | 1 | | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
\ No newline at end of file
@@ -2555,15 +2551,15 @@
If the GW is not enrolled to the Client (so the Client has no access to a key shared with it on the basis of its GwId) and the Client and GW are not in a private network, it is recommended for the Client to open a DTLS session and process only MQTT-SN packets received over it.
-#### **3.1.26.1 Length** {#3.1.26.1-length}
+#### **3.26.1 Length** {#3.26.1-length}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.26.2 Packet Type** {#3.1.26.2-packet-type}
+#### **3.26.2 Packet Type** {#3.26.2-packet-type}
Coded “0x1E”, see Table 63
-#### **3.1.26.3 Protection Flags** {#3.1.26.3-protection-flags}
+#### **3.26.3 Protection Flags** {#3.26.3-protection-flags}
The PROTECTION Flags is 1 byte field in Byte position 3 of the packet, specifying the properties of the PROTECTION.
\ No newline at end of file
@@ -2593,7 +2589,7 @@
* if 0x1, a monotonic counter field of 16 bits (2 bytes) is present;
* if 0x0, the monotonic counter field is not present.
-#### **3.1.26.4 Protection Scheme** {#3.1.26.4-protection-scheme}
+#### **3.26.4 Protection Scheme** {#3.26.4-protection-scheme}
A (1 byte) field located at byte 4 should contain one of the not Reserved indexes in the following table. In general two types of protection scheme are considered: **Authentication only** (like HMAC or CMAC) and **AEAD** (Authenticated Encryption with Associated Data, like GCM, CCM or ChaCha20/Poly1305).
\ No newline at end of file
@@ -2631,7 +2627,7 @@
8. Reference: https://www.rfc-editor.org/rfc/rfc7539 and security considerations on https://www.rfc-editor.org/rfc/rfc8152\#section-10.3.1
9. ChaCha20/Poly1305 requires a 12 bytes nonce as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.3 obtained by performing SHA256 truncated to 96 bit of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)
-#### **3.1.26.5 Sender Identifier** {#3.1.26.5-sender-identifier}
+#### **3.26.5 Sender Identifier** {#3.26.5-sender-identifier}
TLocated at Bytes 5 \- 12 the Sender Id field (8 bytes) should contain:
\ No newline at end of file
@@ -2656,7 +2652,7 @@
*In order to create a whitelist of authorized senders, the MQTT-SN Gateway should store a map of ClientID and SHA256(ClientID) truncated to the leftmost 64 bits (8 bytes for each registered ClientID) for the clients having an active session and store a list of authorized Sender Ids for the clients not capable to establish sessions.*
-#### **3.1.26.6 Random** {#3.1.26.6-random}
+#### **3.26.6 Random** {#3.26.6-random}
T**Located at Byte 13 \- 16 , t**he “**Random**” field (4 bytes) should contain a random number (not guessable) generated at the PROTECTION packet creation .
\ No newline at end of file
@@ -2664,20 +2660,20 @@
*In case of CCM, in the worst case scenario where the “Crypto Material” and the “Monotonic Counter” optional fields are not present, the recommended nonce on 13 bytes will be calculated as SHA256 truncated to 104 bits of the sequence Byte 1 to Byte 16 (all packet fields until Protected MQTT-SN Packet). So considering the same Sender Id, the same nonce can be generated with a probability of 1/2^32=2.33x10\-10. With a shorter Random field of 2 bytes, the same nonce would be calculated with a probability of only 1/2^16=1.53x10\-5. As CCM is a derivation of CTR (see [https://en.wikipedia.org/wiki/CCM\_mode](https://en.wikipedia.org/wiki/CCM\_mode)), the nonce should never be reused for the same key so the probability to generate two identical nonces should be kept as low as possible. Same for GCM and ChaCha20/Poly1305, the security depends on choosing a unique IV of 12 bytes for every encryption performed with the same key ([https://en.wikipedia.org/wiki/Galois/Counter\_Mode](https://en.wikipedia.org/wiki/Galois/Counter\_Mode)).*
-#### **3.1.26.7 Crypto Material** {#3.1.26.7-crypto-material}
+#### **3.26.7 Crypto Material** {#3.26.7-crypto-material}
TLocated at Byte (17 \- P), the optional field “**Crypto Material**” contains 0, 2, 4 or 12 bytes of crypto material that when defined it can be used to derive, from a shared master secret, the same keys on the two endpoints and/or, when filled partially or totally with a random value, to further reduce the probability of IV/nonce reuse for CCM or GCM or ChaCha20/Poly1305. For instance when the Crypto material length is set to 0x03, the Crypto Material field can be partially filled with a random value of 9 bytes (the remaining 3 bytes can be set to 0 if not used) in order to reach the 13 bytes used only once recommended for the nonce used by CCM or it can be partially filled with a random value of 8 bytes in order to reach the 12 bytes used only once recommended for the IV/nonce used by GCM or ChaCha20/Poly1305 .
-#### **3.1.26.8 Monotonic Counter** {#3.1.26.8-monotonic-counter}
+#### **3.26.8 Monotonic Counter** {#3.26.8-monotonic-counter}
TLocated at Byte Byte (Q \- R), the optional field “**Monotonic Counter**” contains 0, 2 or 4 byte number that when defined, is increased by the Client or GW for every packet sent. The counters should be considered independent of session or destination. E.g. The UE will keep a counter independently from the GW.
-#### **3.1.26.9 Protected MQTT-SN Packet** {#3.1.26.9-protected-mqtt-sn-packet}
+#### **3.26.9 Protected MQTT-SN Packet** {#3.26.9-protected-mqtt-sn-packet}
TLocated at Byte (S \- T), the field “**Protected MQTT-SN Packet**” contains the MQTT-SN packet that is being secured, encoded as per its packet type.
The “Protected MQTT-SN Packet” should not be a “Forwarder-Encapsulation packet” as the shared key used directly or after derivation for the protection must belong to the originator of the content and not to a Forwarder that, in general, is not able to securely identify the originator.
-#### **3.1.26.10 Authentication Tag** {#3.1.26.10-authentication-tag}
+#### **3.26.10 Authentication Tag** {#3.26.10-authentication-tag}
TLocated at Byte (U \- N), the field “**Authentication tag**” field has a length depending on the “Authentication tag length” flag and it is calculated, on the basis of the “Protection scheme” selected in Byte 4, on ALL the preceding fields.
\ No newline at end of file
@@ -2728,11 +2724,11 @@
The CONNECT packet contains flags to communicate to the gateway that Auth interactions, or WILL interactions should take place.
-![][image29]
+![][image33]
Figure 3a: Connect procedure (without Auth flag not Will flag set or no further authentication data required)
-![][image30]
+![][image34]
Figure 3b: Connect procedure (with Auth flag set and additional authentication data required)
\ No newline at end of file
@@ -2963,9 +2959,9 @@
The value of the retry interval Tretry is not specified by the protocol, however, to be useful it ought to be longer than the network round trip time. If it is excessively long, the time taken to detect and retransmit lost Packets will also be excessively long. Implementers need to take care not to use a retry interval that might cause the network to become congested with retried Packets.
-The PINGREQ Packet described in \[[3.1.21 PINGREQ](\#3.1.21-pingreq---ping-request)\] can also be used to determine whether the Virtual Connection is alive.
+The PINGREQ Packet described in \[[3.21 PINGREQ](\#3.21-pingreq---ping-request)\] can also be used to determine whether the Virtual Connection is alive.
-An example of a retry algorithm is described in \[[Appendix F.4Appendix E.F4](\#f.4-exponential-backoff)\]
+An example of a retry algorithm is described in \[[Appendix F.4](\#f.4-exponential-backoff)\]
## **4.5 Application Message receipt** {#4.5-application-message-receipt}
\ No newline at end of file
@@ -2983,7 +2979,7 @@
When a stream of messages is published and subscribed to an Ordered Topic with QoS 1, the final copy of each message received by the subscribers will be in the order that they were published.
-As no more than one message is “in-flight” at any one time, no QoS 1 message will be received after any later one even on re-connection. .For example a subscriber might receive them in the order 1,2,3,3,4 but not 1,2,3,2,3,4.
+As no more than one message is “in-flight” at any one time, no QoS 1 message will be received after any later one even on re-connection. For example a subscriber might receive them in the order 1,2,3,3,4 but not 1,2,3,2,3,4.
## **4.7 Topic Names and Topic Filters** {#4.7-topic-names-and-topic-filters}
\ No newline at end of file
@@ -3064,7 +3060,7 @@
* Topic Names and Topic Filters MUST NOT include the null character (Unicode U+0000) [\[Unicode\]](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#Unicode) \[MQTT-SN-4.7.3-2\]
* Topic Names and Topic Filters are UTF-8 Encoded Strings; they MUST NOT encode to more than 65,535 bytes \[MQTT-SN-4.7.3-4\]. Refer to [section 1.7.4](\#1.7.4-utf-8-encoded-string).
- There is no limit to the number of levels in a Topic Name or Topic Filter, other than that imposed by the overall length of a UTF-8 Encoded String.
+There is no limit to the number of levels in a Topic Name or Topic Filter, other than that imposed by the overall length of a UTF-8 Encoded String.
When it performs subscription matching the Server MUST NOT perform any normalization of Topic Names or Topic Filters, or any modification or substitution of unrecognized characters \[MQTT-SN-4.7.3-4\]. Each non-wildcarded level in the Topic Filter has to match the corresponding level in the Topic Name character for character for the match to succeed.
\ No newline at end of file
@@ -3099,11 +3095,11 @@
If a Client or Server receives an MQTT-SN request and there is already a request outstanding within the same Virtual Connection then it MUST issue a DISCONNECT with Reason Code 147 (Receive Maximum Exceeded) and delete the Virtual Connection \[MQTT-SN-4.9-1\].
-Refer to [section 3.1.12.7](\#3.1.12.7-publish-actions) for a description of how Clients and Servers react if they are sent more than one unacknowledged packet.
+Refer to [section 3.12.7](\#3.12.7-publish-actions) for a description of how Clients and Servers react if they are sent more than one unacknowledged packet.
## **4.10 Server redirection** {#4.10-server-redirection}
-A Server can request that the Client uses another Server by sending a CONNACK or DISCONNECT packet with Reason Codes 0x9C (Use another server), or 0x9D (Server moved) as described in [section 4.13](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#S4\_13\_Errors).
+A Server can request that the Client uses another Server by sending a CONNACK or DISCONNECT packet with Reason Codes 0x9C (Use another server), or 0x9D (Server moved) as described in [section 4.12](\#4.12-handling-errors).
The Reason Code 0x9C (Use another server) specifies that the Client SHOULD temporarily switch to using another Server. The other Server is already known to the Client.
\ No newline at end of file
@@ -3157,11 +3153,11 @@
### **4.11.1 Re-authentication** {#4.11.1-re-authentication}
-If the Client supplied an Authentication Method in the CONNECT packet, it can initiate a re-authentication at any time after receiving a CONNACK. It does this by sending an AUTH packet with a Reason Code of 0x19 (Re-authentication). The Client MUST set the Authentication Method to the same value as the Authentication Method originally used to authenticate the Virtual Connection \[MQTT-SN-4.10.1-1\]. If the authentication method requires Client data first, this AUTH packet contains the first piece of authentication data inas the Authentication Data field.
+If the Client supplied an Authentication Method in the CONNECT packet, it can initiate a re-authentication at any time after receiving a CONNACK. It does this by sending an AUTH packet with a Reason Code of 0x19 (Re-authentication). The Client MUST set the Authentication Method to the same value as the Authentication Method originally used to authenticate the Virtual Connection \[MQTT-SN-4.10.1-1\]. If the authentication method requires Client data first, this AUTH packet contains the first piece of authentication data in the Authentication Data field.
The Server responds to this re-authentication request by sending an AUTH packet to the Client with a Reason Code of 0x00 (Success) to indicate that the re-authentication is complete, or a Reason Code of 0x18 (Continue authentication) to indicate that more authentication data is needed. The Client can respond with additional authentication data by sending an AUTH packet with a Reason Code of 0x18 (Continue authentication). This flow continues as with the original authentication until the re-authentication is complete or the re-authentication fails.
-If the re-authentication fails, the Client or Server MUST send DISCONNECT with an appropriate Reason Code as described in [section 4.13](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#S4\_13\_Errors), and MUST delete the Virtual Connection \[MQTT-SN-4.10.1-2\].
+If the re-authentication fails, the Client or Server MUST send DISCONNECT with an appropriate Reason Code as described in [section 4.12](\#4.12-handling-errors), and MUST delete the Virtual Connection \[MQTT-SN-4.10.1-2\].
During this re-authentication sequence, the flow of other packets between the Client and Server can continue using the previous authentication.
\ No newline at end of file
@@ -3181,10 +3177,8 @@
* The degree to which the receiver trusts the network to deliver Control Packets correctly.
* The consequences of continuing to process a packet that is incorrect.
-If the sender is compliant with this specification it will not send Malformed Packets or cause Protocol Errors. However, if a Client sends Control Packets before it receives CONNACK, it might cause a Protocol Error because it made an incorrect assumption about the Server capabilities. Refer [to section 3.1.4](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#\_CONNECT\_Actions) CONNECT Actions.
+If the sender is compliant with this specification it will not send Malformed Packets or cause Protocol Errors. The Reason Codes used for Malformed Packet and Protocol Errors are:
- The Reason Codes used for Malformed Packet and Protocol Errors are:
-
* 0x81 Malformed Packet
* 0x82 Protocol Error
* 0x93 Receive Maximum exceeded
\ No newline at end of file
@@ -3221,7 +3215,7 @@
The architectures described below are meant as examples and are not exhaustive.
-![][image31]
+![][image35]
Figure 1: MQTT-SN Architecture
\ No newline at end of file
@@ -3231,9 +3225,9 @@
Although the implementation of the transparent Gateway is simpler when compared to the one of an aggregating Gateway, it requires the MQTT server to support a separate connection for each active client. Some MQTT server implementations might impose a limitation on the number of concurrent connections that they support.
- ![A close up of a mapDescription automatically generated][image32]
+ ![A close up of a mapDescription automatically generated][image36]
-![][image33]
+![][image37]
Figure XX2: Transparent and Aggregating Gateway scenarios
\ No newline at end of file
@@ -3241,21 +3235,21 @@
Instead of having a MQTT connection for each connected client, an aggregating Gateway will have only one MQTT connection to the Server. All packet exchanges between a MQTT-SN client and an aggregating Gateway end at the Gateway. The Gateway then decides which information will be given further to the MQTT BrokerServer. Although its implementation is more complex than the one of a transparent Gateway, an aggregating Gateway may be helpful in case of WSNs with a very large number of SAs because it reduces the number of MQTT connections that the Gateway must support concurrently.
-![][image34]
+![][image38]
Figure XX: Aggregating Gateway scenario
### **4.11.3 Forwarder encapsulator**
-![][image35]
+![][image39]
-Figure XX: Forwarder encapsulator with TransparentGateway scenario![][image36]
+Figure XX: Forwarder encapsulator with TransparentGateway scenario![][image40]
Figure XX: Forwarder encapsulator with Aggregating Gateway scenario
### **4.13.4 MQTT-SN broker**
-![][image37]
+![][image41]
Figure XX: MQTT-SN broker scenario
\ No newline at end of file
@@ -3295,7 +3289,7 @@
| **AWAKE** | The client is partially engaged in an ongoing session; it is obliged to not send ANY packets other than those involved in the receipt of PUBLISH packets (PUBACK, PUBREC, PUBCOMP, REGACK) or a DISCONNECT to transition to **DISCONNECTED**. The client transitions back to the **ASLEEP** state on receipt of a PINGRESP packet or **LOST** (by way of supervised gateway timers for the possible PUBACK, PUBREC, PUBCOMP or REGACK packets to be received from the Client). | **ASLEEP DISCONNECTED LOST** |
| **LOST** | The client is considered offline and not able to receive packets until it has re-established a session with the GW by way of a CONNECT. The gateway **must not** attempt to send packets to a client in the **LOST** state**.** Any packets received from a client whose state is **LOST** should not be processed and a DISCONNECT with error should be sent in response, unless the packets received are PUBLISH WITHOUT SESSION or PUBLISH QoS \-1. Session state may exist on the GW for a client in the **LOST** state. | **ACTIVE** |
-![][image38]
+![][image42]
Figure 4: The Server vView of the Client State
\ No newline at end of file
@@ -3452,7 +3446,7 @@
The gateway should attempt to make the best effort to reuse the same topic alias mappings that existed during any initial associated ACTIVE states.
-![][image39]
+![][image43]
Figure 5: Awake ping packet flush
\ No newline at end of file
@@ -3468,11 +3462,11 @@
* If Retain Handling is set to 1 then if the subscription did not already exist, the Server MUST send all retained messages matching the Topic Filter of the subscription to the Client, and if the subscription did exist the Server MUST NOT send the retained messages. \[MQTT-SN-4.26-6\].
* If Retain Handling is set to 2, the Server MUST NOT send the retained messages \[MQTT-SN-4.26-7\].
-Refer to [section 3.1.17.2](\#3.1.17.2-subscribe-flags) for a definition of the Subscription Flags.
+Refer to [section 3.17.2](\#3.17.2-subscribe-flags) for a definition of the Subscription Flags.
If the Server receives a PUBLISH packet with the RETAIN flag set to 1, and QoS 0 it SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time. If this happens there will be no retained message for that topic.
-The setting of the RETAIN flag in an Application Message forwarded by the Server from an established Virtual Connection is controlled by the Retain As Published subscription option. Refer to [section 3.1.17.2](\#3.1.17.2-subscribe-flags) for a definition of the Subscription Flags.
+The setting of the RETAIN flag in an Application Message forwarded by the Server from an established Virtual Connection is controlled by the Retain As Published subscription option. Refer to [section 3.17.2](\#3.17.2-subscribe-flags) for a definition of the Subscription Flags.
* If the value of Retain As Published subscription option is set to 0, the Server MUST set the RETAIN flag to 0 when forwarding an Application Message regardless of how the RETAIN flag was set in the received PUBLISH packet \[MQTT-SN-4.26-8\].
* If the value of Retain As Published subscription option is set to 1, the Server MUST set the RETAIN flag equal to the RETAIN flag in the received PUBLISH packet \[MQTT-SN-4.26-9\].
\ No newline at end of file
@@ -3852,80 +3846,88 @@
The name "OASIS" is a trademark of [OASIS](https://www.oasis-open.org/), the owner and developer of this document, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, documents, while reserving the right to enforce its marks against misleading uses. See [https://www.oasis-open.org/policies-guidelines/trademark/](https://www.oasis-open.org/policies-guidelines/trademark/) for above guidance.
# - - - 8< - - - rest not fitting in the 64k limit of GitHub comments. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Next warp 2024-08-14 ← 2024-08-27
Not sure if the many section numbering changes are intended ...