MQTT-SN v1.2规范中文版

引言

近期对无线传感网络（WSNs）的兴趣不断增长，无论是从商业还是技术的角度来看，都因其简易性、低成本和易于部署而受到关注。这些网络可以用于不同的目的，从测量和检测到自动化和过程控制。一个典型的WSN由大量电池操作的传感器和执行器（SAs）组成，这些设备通常配备有有限的存储和处理能力。重要的是这些设备能够通过无线方式通信，因为SA节点的数量通常非常大，且部署有线基础设施的成本极其昂贵。这样的网络本质上非常动态：无线链接可能随时临时断开，节点可能会经常失败并被频繁替换。在这种情况下，使用地址来与个别节点通信的传统方法可能变成一场噩梦。居住在固定网络上并需要与无线SA设备交互的应用程序需要管理和维护与大量节点通信的手段。在大多数情况下，它们不需要知道提供信息的设备的地址或身份，而是更感兴趣于数据的内容。例如，资产跟踪应用程序更感兴趣于某个特定资产的当前位置，而不是提供该信息的GPS接收器的网络地址。此外，几个应用程序可能对相同的传感器数据感兴趣，但出于不同的目的。在这种情况下，SA节点需要同时与多个应用程序并行管理和维护通信手段。这可能超出了简单和低成本SA设备的有限能力。另一个问题是涉及的网络之间的寻址方案差异。例如，一个驻留在基于TCP/IP的网络上的应用程序如何寻址一个运行在基于ZigBee R1的无线网络上的SA设备？

通过使用以数据为中心的通信方法可以克服上述问题，在这种方法中，信息的传递不是基于它们的网络地址，而是作为其内容和兴趣的函数。一个众所周知的以数据为中心的通信示例是“发布/订阅”（pub/sub）消息系统，该系统已在企业网络中被广泛使用，主要是因为其可扩展性和支持动态网络拓扑。将企业pub/sub系统扩展到WSNs还可以实现WSNs到企业网络的无缝集成，从而使SAs收集的现场数据可用于所有应用程序，就像任何其他企业信息一样，并使SAs能够受到任何企业应用程序的控制。

ZigBee是ZigBee联盟在美国、其他国家或两者中的商标。其他公司、产品或服务名称可能是其他人的商标或服务标记。

MQTT-SN规范简介

本文档的目的是规定MQTT-SN，一种适用于无线传感网络的发布/订阅协议。MQTT-SN可以被视为适应无线通信环境特点的MQTT版本。无线电链路通常比有线链路具有更高的故障率，因为它们容易受到衰减和干扰的影响。它们的传输速率也较低。例如，基于IEEE 802.15.4标准的WSN在2.4 GHz带提供的最大带宽为250 kbit/s。此外，为了抵抗传输错误，它们的数据包长度非常短。在IEEE 802.15.4的情况下，物理层的包长限制为128字节。这128字节中的一半可能会被MAC层、网络、安全等支持功能所需的开销信息占据。MQTT-SN还针对在低成本电池操作设备上的实现进行了优化，这些设备具有有限的处理和存储资源。

MQTT-SN最初是为在ZigBee R1 APS层之上运行而开发的。ZigBee R1是一个开放的工业联盟，旨在为WSN定义一个开放和全球的通信标准。为了实现全球化，ZigBee R1选择了IEEE 802.15.4标准作为PHY和MAC层的协议，并在此标准的基础上增加了所需的网络、安全和应用层，从而提供不同厂商产品之间的互操作性。

MQTT-SN的设计使其不依赖于底层网络服务。任何提供节点与特定节点（即网关）之间双向数据传输服务的网络都应能够支持MQTT-SN。例如，一个简单的数据报服务，允许源端点向特定的目的端点发送数据消息应该就足够了。如果使用网关发现程序，则只需要广播数据传输服务。为了减少发现程序产生的广播流量，最好是MQTT-SN能够向底层层指示所需的广播半径。

3.MQTT-SN 与 MQTT

MQTT-SN旨在尽可能接近MQTT，但针对无线通信环境的特殊性进行了适应，如低带宽、高链路故障、短消息长度等。它也针对低成本、电池操作的设备上的实现进行了优化，这些设备具有有限的处理和存储资源。

与MQTT相比，MQTT-SN有以下不同之处：

• CONNECT消息被分解为三个消息。两个额外的消息是可选的，用于将遗嘱主题和遗嘱消息传输给服务器。
• 为了应对无线网络中的短消息长度和有限的传输带宽，PUBLISH消息中的主题名称被一个短的、两字节长的“主题ID”替代。定义了一个注册程序，允许客户端向服务器/网关注册它们的主题名称，并获得相应的主题ID。它也用于相反方向，以通知客户端即将在后续的PUBLISH消息中包括的主题名称和相应的主题ID。
• 引入了“预定义”的主题ID和“短”的主题名称，它们不需要注册。预定义的主题ID也是替代主题名称的两字节长的值，它们之间的映射事先已经为客户端的应用程序和网关/服务器所知。因此，双方可以开始使用预定义的主题ID；与上述的“普通”主题ID不同。短主题名称是长度固定为两个字节的主题名称。它们足够短，可以在PUBLISH消息中与数据一起携带。就像预定义的主题ID一样，短主题名称也不需要注册。
• 发现程序帮助没有预配置服务器/网关地址的客户端发现运行中的服务器/网关的实际网络地址。同一无线网络内可能同时存在多个网关，它们可以以负载共享或备用模式合作。
• “清理会话”的语义扩展到了遗嘱特性，即不仅客户端的订阅是持久的，遗嘱主题和遗嘱消息也是如此。客户端还可以在会话期间修改其遗嘱主题和遗嘱消息。
• 为支持休眠客户端定义了新的离线保持活动程序。有了这个程序，电池操作的设备可以在睡眠状态下进入，期间所有发给它们的消息都在服务器/网关处缓冲，之后当它们唤醒时再交付给它们。

4. MQTT-SN架构

图1: MQTT-SN架构

MQTT-SN的架构如图1所示。有三种类型的MQTT-SN组件，MQTT-SN客户端、MQTT-SN网关（GW）和MQTT-SN转发器。MQTT-SN客户端通过MQTT-SN网关使用MQTT-SN协议连接到MQTT服务器。MQTT-SN网关可能与MQTT服务器集成，也可能不集成。如果是独立的网关，那么MQTT服务器和MQTT-SN网关之间使用MQTT协议。其主要功能是MQTT与MQTT-SN之间的转换。

如果网关没有直接连接到它们的网络，MQTT-SN客户端也可以通过转发器访问网关。转发器简单地封装它在无线侧接收到的MQTT-SN帧，并不加改变地转发给网关；反方向也是如此，它从网关接收到的帧解封装后，也不加改变地发送给客户端。

根据网关如何执行MQTT与MQTT-SN之间的协议转换，我们可以区分两种类型的网关，即透明网关和聚合网关，见图2。以下部分将对这两种网关进行解释。

4.1 透明网关

对于每个连接的MQTT-SN客户端，透明网关将建立并维护一个到MQTT服务器的MQTT连接。这个MQTT连接专门用于客户端和服务器之间端到端且几乎透明的消息交换。网关和服务器之间的MQTT连接数量将与连接到网关的MQTT-SN客户端数量一样多。透明网关将执行两种协议之间的“语法”转换。由于所有消息交换都是客户端与MQTT服务器之间的端到端，服务器实现的所有功能和特性都可以提供给客户端。

尽管与聚合网关相比，透明网关的实现更简单，但它需要MQTT服务器为每个活动客户端支持一个单独的连接。某些MQTT服务器实现可能会限制它们所支持的并发连接的数量。

图2：透明和聚合网关

4.2 聚合网关

与为每个连接的客户端拥有一个MQTT连接不同，聚合网关只与服务器有一个MQTT连接。MQTT-SN客户端和聚合网关之间的所有消息交换都在网关处终止。然后，网关决定哪些信息将进一步传递给服务器。虽然其实现比透明网关的实现更复杂，但在具有非常大量SAs的WSN案例中，聚合网关可能会很有帮助，因为它减少了服务器必须同时支持的MQTT连接数量。

5.消息格式

5.1 通用消息格式

消息头 (2或4字节)

消息变量部分 (n字节)

MQTT-SN消息的通用格式如表1所示。MQTT-SN消息由两部分组成：一个2或4字节长的头部和一个可选的变量部分。虽然头部总是存在且包含相同的字段，但变量部分的存在和内容取决于所考虑消息的类型。

5.2 消息头

消息头的格式如表2所示。

5.2.1 长度

长度字段要么是1字节长，要么是3字节长，指定消息中包含的字节总数（包括长度字段本身）。

如果长度字段的第一个字节编码为“0x01”，则长度字段为3字节长；在这种情况下，接下来的两个字节指定消息的总字节数（最高有效字节在前）。否则，长度字段只有1字节长，并自身指定消息中包含的字节总数。

3字节格式允许编码长度高达65535字节的消息。长度小于256字节的消息可以使用较短的1字节格式。

注意，因为MQTT-SN不支持消息分段和重组，所以在网络中可以使用的最大消息长度由该网络支持的最大数据包大小决定，而不是由MQTT-SN可以编码的最大长度决定。

5.2.2 消息类型

消息类型字段长度为1字节，指定消息类型。它应该设置为表3中显示的值之一。

消息类型字段值	消息类型	消息类型字段值	消息类型
0x00	ADVERTISE	0x01	SEARCHGW
0x02	GWINFO	0x03	保留
0x04	CONNECT	0x05	CONNACK
0x06	WILLTOPICREQ	0x07	WILLTOPIC
0x08	WILLMSGREQ	0x09	WILLMSG
0x0A	REGISTER	0x0B	REGACK
0x0C	PUBLISH	0x0D	PUBACK
0x0E	PUBCOMP	0x0F	PUBREC
0x10	PUBREL	0x11	保留
0x12	SUBSCRIBE	0x13	SUBACK
0x14	UNSUBSCRIBE	0x15	UNSUBACK
0x16	PINGREQ	0x17	PINGRESP
0x18	DISCONNECT	0x19	保留
0x1A	WILLTOPICUPD	0x1B	WILLTOPICRESP
0x1C	WILLMSGUPD	0x1D	WILLMSGRESP
0x1E-0xFD	保留	0xFE	封装消息
0xFF	保留

5.3 消息变量部分

消息变量部分的内容取决于消息的类型。以下字段为消息变量部分定义。

5.3.1 客户端ID

与MQTT一样，客户端ID字段长度可变，包含一个1-23个字符的字符串，用于将客户端唯一地标识给服务器。

5.3.2 数据

数据字段对应于MQTT PUBLISH消息的负载。它长度可变，包含正在发布的应用数据。

5.3.3 持续时间

持续时间字段长度为2字节，指定时间周期的持续时间，以秒为单位。可以编码的最大值约为18小时。

5.3.4 标志

DUP (bit 7)

QoS (6,5)

保留 (4)

遗嘱 (3)

清除会话 (2)

主题ID类型 (1,0)

标志字段长度为1字节，包含以下标志（见表4）：

• 复制（DUP）：与MQTT含义相同，即如果消息是第一次发送则设置为“0”；如果是重传，则设置为“1”（仅在PUBLISH消息中相关）；
• QoS：与MQTT的QoS级别0、1和2的含义相同；对于QoS级别0设置为“0b00”，QoS级别1设置为“0b01”，QoS级别2设置为“0b10”，新的QoS级别-1设置为“0b11”（仅在客户端发送的PUBLISH消息中相关）；
• 保留（Retain）：与MQTT含义相同（仅在PUBLISH消息中相关）；
• 遗嘱（Will）：如果设置，表示客户端请求遗嘱主题和遗嘱消息提示（仅在CONNECT消息中相关）；
• 清除会话（CleanSession）：与MQTT含义相同，但扩展了遗嘱主题和遗嘱消息（仅在CONNECT消息中相关）；
• 主题ID类型（TopicIdType）：指示此消息中包含的主题ID或主题名称字段是普通主题ID（设置为“0b00”）、预定义主题ID（设置为“0b01”）还是短主题名称（设置为“0b10”）。值“0b11”被保留。参见第3节和6.7节，了解各种类型的主题ID的定义。

5.3.5 网关地址

网关地址（GwAdd）字段长度可变，包含一个网关的地址。它依赖于MQTT-SN操作的网络，并在此字段的第一个字节中指示。例如，在ZigBee网络中，网络地址长度为2字节。

5.3.6 网关ID

网关ID（GwId）字段长度为1字节，唯一地标识一个网关。

版权所有 © 国际商业机器公司1999, 2013。保留所有权利。

5.3.7 消息ID

消息ID字段长度为2字节，对应于MQTT中的“消息ID”参数。它允许发送者将消息与其相应的确认消息匹配。

5.3.8 协议ID

协议ID长度为1字节。它仅在CONNECT消息中出现，对应于MQTT的“协议名称”和“协议版本”。
它编码为0x01。所有其他值都是保留的。

5.3.9 半径

半径字段长度为1字节，指示广播半径的值。值0x00表示“向网络中的所有节点广播”。

5.3.10 返回码

1字节长的返回码字段的值及其含义如表5所示。

返回码值	含义
0x00	接受
0x01	拒绝：拥挤
0x02	拒绝：无效的主题ID
0x03	拒绝：不支持
0x04 - 0xFF	保留

表5：返回码值

5.3.11 主题ID

主题ID字段长度为2字节，包含主题ID的值。值“0x0000”和“0xFFFF”是保留的，因此不应使用。

5.3.12 主题名称

主题名称字段长度可变，包含指定主题名称的UTF8编码字符串。

5.3.13 遗嘱消息

遗嘱消息字段长度可变，包含遗嘱消息。

5.3.14 遗嘱主题

遗嘱主题字段长度可变，包含遗嘱主题名称。

5.4 个别消息的格式

本节规定了个别MQTT-SN消息的格式。所有消息都用1字节长度字段描述。在3字节长度字段的情况下，消息格式可以直接推导，因此没有提及。

版权所有 © 国际商业机器公司1999, 2013。保留所有权利。

5.4.1 ADVERTISE

长度 消息类型 网关ID 持续时间
(字节 0) (1) (2) (3,4)
表6：ADVERTISE消息
ADVERTISE消息由网关定期广播，以宣告其存在。下一次广播时间的时间间隔在此消息的持续时间字段中指示。其格式如表6所示：

• 长度和消息类型：见5.2节。
• 网关ID：发送此消息的网关的ID。
• 持续时间：直到此网关广播下一个ADVERTISE的时间间隔。

5.4.2 SEARCHGW

长度 消息类型 半径
(字节 0) (1) (2)
表7：SEARCHGW消息
当客户端寻找网关时，会广播SEARCHGW消息。SEARCHGW的广播半径是有限的，取决于客户端部署的密度，例如，在非常密集的网络中，每个MQTT-SN客户端都可以通过1跳传输相互到达的情况下，只进行1跳广播。SEARCHGW消息的格式如表7所示：

• 长度和消息类型：见5.2节。
• 半径：此消息的广播半径。
  当MQTT-SN将此消息传输给底层网络层时，也会指示广播半径。

5.4.3 GWINFO

长度 消息类型 网关ID 网关地址*
(字节 0) (1) (2) (3:n)
(*) 如果消息由客户端发送，则包含
表8：GWINFO消息
GWINFO消息作为对SEARCHGW消息的响应通过底层层的广播服务发送，广播半径如SEARCHGW消息中所示。如果由网关发送，它只包含发送网关的ID；否则，如果由客户端发送，它还包括网关的地址，见表8：

• 长度和消息类型：见5.2节。
• 网关ID：网关的ID。

5.4.1 广告

长度 消息类型 网关ID 持续时间
(字节0) (1) (2) (3,4)
表6：广告消息
广告消息由网关定期广播以宣告其存在。下一次广播时间间隔在此消息的持续时间字段中指示。其格式如表6所示：

• 长度和消息类型：参见5.2节。
• 网关ID：发送此消息的网关的ID。
• 持续时间：直到此网关下一次广播广告的时间间隔。

5.4.2 搜索网关

长度 消息类型 广播半径
(字节0) (1) (2)
表7：搜索网关消息
当客户端寻找网关时，会广播搜索网关消息。搜索网关的广播半径是有限制的，取决于客户端部署的密度，例如，在一个非常密集的网络中，每个MQTT-SN客户端在1跳传输内相互可达，只需要1跳广播。搜索网关消息的格式如表7所示：

• 长度和消息类型：参见5.2节。
• 广播半径：此消息的广播半径。
  当MQTT-SN传输此消息时，广播半径也会指示给底层网络层。

5.4.3 网关信息

长度 消息类型 网关ID 网关地址*
(字节0) (1) (2) (3:n)
(*) 如果消息由客户端发送，则仅包含
表8：网关信息消息
网关信息消息是响应搜索网关消息而通过底层层的广播服务发送的。如果由网关发送，它只包含发送网关的ID；否则，如果由客户端发送，它还包括网关的地址，见表8：

• 长度和消息类型：参见5.2节。
• 网关ID：网关的ID。
• 网关地址：指示的网关的地址；可选，只在客户端发送此消息时包括。
  与搜索网关消息一样，此消息的广播半径在MQTT-SN传输此消息时也会指示给底层网络层。

5.4.4 连接

长度 消息类型 标志 协议ID 持续时间 客户端ID
(字节0) (1) (2) (3) (4,5) (6:n)
表9：连接消息
客户端发送连接消息以建立连接。其格式如表9所示：

• 长度和消息类型：参见5.2节。
• 标志：
• DUP, QoS, Retain, TopicIdType：未使用。
• Will：如果设置，表示客户端请求遗嘱主题和遗嘱消息提示；
• CleanSession：与MQTT含义相同，但扩展到了遗嘱主题和遗嘱消息（参见6.3节）。
• 协议ID：对应于MQTT连接消息的“协议名称”和“协议版本”。
• 持续时间：与MQTT相同，包含保持活动定时器的值。
• 客户端ID：与MQTT相同，包含客户端ID，是一个1-23个字符长的字符串，唯一标识服务器中的客户端。

5.4.5 连接确认

长度 消息类型 返回码
(字节0) (1) (2)
表10：连接确认消息
服务器响应客户端的连接请求发送连接确认消息。其格式如表10所示：

• 长度和消息类型：参见5.2节。
• 返回码：根据表5编码。

5.4.6 遗嘱主题请求

长度 消息类型
(字节0) (1)
表11：遗嘱主题请求和遗嘱消息请求

5.4.7 遗嘱主题

长度 消息类型 标志 遗嘱主题
(字节0) (1) (2) (3:n)
表12：遗嘱主题消息
客户端发送遗嘱主题消息作为对遗嘱主题请求消息的响应，以将其遗嘱主题名称传输给网关。其格式如表12所示：

• 长度和消息类型：参见5.2节。
• 标志：
• DUP：未使用。
• QoS：与MQTT相同，包含遗嘱QoS
• Retain：与MQTT相同，包含遗嘱保留标志
• Will：未使用
• CleanSession：未使用
• TopicIdType：未使用。
• 遗嘱主题：包含遗嘱主题名称。
  空的遗嘱主题消息是没有标志和遗嘱主题字段的遗嘱主题消息（即它正好2字节长）。客户端使用它来删除服务器中存储的遗嘱主题和遗嘱消息，参见6.4节。

5.4.8 遗嘱消息请求

网关发送遗嘱消息请求消息，请求客户端发送遗嘱消息。其格式如表11所示：它只有头部，没有变量部分。

5.4.9 遗嘱消息

长度 消息类型 遗嘱消息
(字节0) (1) (2:n)
表13：遗嘱消息
客户端作为对遗嘱消息请求的响应发送遗嘱消息，以将其遗嘱消息传输给网关。其格式如表13所示：

• 长度和消息类型：参见5.2节。
• 遗嘱消息：包含遗嘱消息。

5.4.10 注册

长度 消息类型 主题ID 消息ID 主题名称
(字节0) (1) (2,3) (4,5) (6:n)
表14：注册消息
客户端发送注册消息给网关，请求为包含的主题名称分配一个主题ID值。网关也发送注册消息给客户端，通知其已分配给包含的主题名称的主题ID值。其格式如表14所示：

• 长度和消息类型：参见5.2节。
• 主题ID：如果由客户端发送，则编码为0x0000，此时不相关；如果由网关发送，则包含分配给TopicName字段中包含的主题名称的主题ID值；
• 消息ID：应该编码，以便用于识别相应的REGACK消息。
• 主题名称：包含主题名称。

5.4.11 注册确认

长度 消息类型 主题ID 消息ID 返回码
(字节0) (1) (2,3) (4,5) (6)
表15：注册确认消息
客户端或网关发送注册确认消息，作为对接收和处理注册消息的确认。其格式如表15所示：

• 长度和消息类型：参见5.2节。
• 主题ID：在PUBLISH消息中将作为主题ID使用的值；
• 消息ID：与相应注册消息中包含的值相同。
• 返回码：“已接受”，或拒绝原因。

5.4.12 发布

长度 消息类型 标志 主题ID 消息ID 数据
(字节0) (1) (2) (3-4) (5-6) (7:n)
表16：发布消息
此消息由客户端和网关用于发布某个主题的数据。其格式如表16所示：

• 长度和消息类型：参见5.2节。
• 标志：
• DUP：与MQTT相同，指示消息是首次发送还是重传。
• QoS：与MQTT相同，包含此发布消息的QoS级别。
• Retain：与MQTT相同，包含保留标志。
• Will：未使用
• CleanSession：未使用
• TopicIdType：指示TopicId字段中包含的主题ID的类型。
• TopicId：包含发布数据所针对的主题ID值或短主题名称。
• MsgId：与MQTT的“消息ID”含义相同；仅在QoS级别1和2的情况下相关，否则编码为0x0000。
• 数据：发布的数据。

5.4.13 PUBACK

长度 消息类型 主题ID 消息ID 返回码
(字节0) (1) (2,3) (4,5) (6)
表17：PUBACK消息
网关或客户端发送PUBACK消息作为对接收和处理QoS级别1或2的发布消息的确认。在出现错误的情况下，也可以作为对发布消息的响应发送；然后在返回码字段中指示错误原因。其格式如表17所示：

• 长度和消息类型：参见5.2节。
• 主题ID：与相应发布消息中包含的值相同。
• 消息ID：与相应发布消息中包含的值相同。
• 返回码：“已接受”，或拒绝原因。

5.4.14 PUBREC, PUBREL, 和 PUBCOMP

长度 消息类型 消息ID
(字节0) (1) (2-3)
表18：PUBREC, PUBREL, 和 PUBCOMP消息
与MQTT相同，PUBREC、PUBREL和PUBCOMP消息与QoS级别2的发布消息一起使用。它们的格式如表18所示：

• 长度和消息类型：参见5.2节。
• 消息ID：与相应发布消息中包含的值相同。

5.4.15 订阅

订阅消息由客户端使用，用于订阅某个特定的主题名称。其格式如表19所示：

• 长度和消息类型：参见5.2节。
• 标志：
• DUP：与MQTT相同，指示消息是首次发送还是重传。
• QoS：与MQTT相同，包含此主题请求的QoS等级。
• Retain：未使用
• Will：未使用
• CleanSession：未使用
• TopicIdType：指示消息末尾包含的信息类型，即“0b00”主题名称，“0b01”预定义主题ID，“0b10”短主题名称，以及“0b11”保留。
• 消息ID：应编码，以便用于识别相应的SUBACK消息。
• 主题名称或主题ID：根据TopicIdType字段指示，包含主题名称、主题ID或短主题名称。

5.4.16 订阅确认

长度 消息类型 标志 主题ID 消息ID 返回码
(字节0) (1) (2) (3,4) (5,6) (7)
表20：订阅确认消息
订阅确认消息由网关发送给客户端，作为对接收和处理订阅消息的确认。其格式如表20所示：

• 长度和消息类型：参见5.2节。
• 标志：
• DUP：未使用。
• QoS：与MQTT相同，包含授予的QoS等级。
• Retain：未使用。
• Will：未使用
• CleanSession：未使用
• TopicIdType：未使用

5.4.16 订阅确认

长度 消息类型 标志 主题ID 消息ID 返回码
(字节0) (1) (2) (3,4) (5,6) (7)
表20：订阅确认消息
网关发送订阅确认消息给客户端，作为对接收和处理订阅消息的确认。其格式如表20所示：

• 长度和消息类型：参见5.2节。
• 标志：
• DUP：未使用。
• QoS：与MQTT相同，包含授予的QoS级别。
• Retain：未使用。
• Will：未使用。
• CleanSession：未使用。
• TopicIdType：未使用。
• 主题ID：在“已接受”的情况下，网关在向客户端发送PUBLISH消息时将使用该值作为主题ID（在订阅短主题名称或包含通配符字符的主题名称的情况下不相关）。
• 消息ID：与相应的订阅消息中包含的值相同。
• 返回码：“已接受”，或拒绝原因。

5.4.17 取消订阅

客户端发送取消订阅消息给网关，以取消订阅命名主题。其格式如表19所示：

• 长度和消息类型：参见5.2节。
• 标志：
• DUP：未使用。
• QoS：未使用。
• Retain：未使用。
• Will：未使用。
• CleanSession：未使用。
• TopicIdType：指示消息末尾包含的信息类型，即“0b00”主题名称，“0b01”预定义主题ID，“0b10”短主题名称，和“0b11”保留。
• 消息ID：应编码以便用来识别相应的订阅确认消息。
• 主题名称或主题ID：包含主题名称、预定义主题ID或短主题名称，如TopicIdType字段所示。

5.4.18 取消订阅确认

长度 消息类型 消息ID
(字节0) (1) (2-3)
表21：取消订阅确认消息
网关发送取消订阅确认消息以确认接收和处理取消订阅消息。其格式如表21所示：

• 长度和消息类型：参见5.2节。
• 消息ID：与相应取消订阅消息中包含的值相同。

5.4.19 PING请求

长度 消息类型 客户端ID（可选）
(字节0) (1) (2:n)
表22：PING请求消息
与MQTT一样，PING请求消息是从连接的客户端发送或接收的“你还活着吗”的消息。其格式如表22所示：

• 长度和消息类型：参见5.2节。
• 客户端ID：包含客户端ID；此字段为可选，由“休眠”客户端在进入“唤醒”状态并等待服务器/网关发送的消息时包含，更多详情参见6.14节。

5.4.20 PING响应

长度 消息类型
(字节0) (1)
表23：PING响应消息
与MQTT一样，PING响应消息是对PING请求消息的回应，意味着“是的，我还活着”。保持活动消息可由连接的客户端或网关发送，流向任一方向。其格式如表23所示：它只有头部，没有变量部分。
此外，网关发送PING响应消息通知休眠客户端，表示没有更多为该客户端缓冲的消息，更多详情参见6.14节。

5.4.21 断开连接

长度 消息类型 持续时间（可选）
(字节0) (1) (2-3)
表24：断开连接消息
断开连接消息的格式如表24所示：

• 长度和消息类型：参见5.2节。
• 持续时间：包含休眠定时器的值；此字段为可选，由希望进入“休眠”状态的“休眠”客户端包含，更多详情参见6.14节。
  与MQTT一样，客户端发送断开连接消息表示希望关闭连接。网关将通过向客户端返回一个断开连接消息来确认收到该消息。服务器或网关也可能向客户端发送断开连接消息，例如，如果网关由于错误不能将收到的消息映射到客户端。接收到此类断开连接消息的客户端应尝试通过向网关或服务器发送连接消息再次建立连接。在所有这些情况下，断开连接消息不包含持续时间字段。
  客户端发送带有持续时间字段的断开连接消息时，希望进入“休眠”状态。网关也通过发送断开连接消息（不带持续时间字段）来确认收到此消息。

5.4.22 遗嘱主题更新

长度 消息类型 标志 遗嘱主题
(字节0) (1) (2) (3:n)
表25：遗嘱主题更新消息

遗嘱主题更新消息由客户端发送给网关/服务器，以更新其在网关/服务器中存储的遗嘱主题名称。其格式如表25所示：

• 长度和消息类型：参见5.2节。
• 标志：
• DUP：未使用。
• QoS：与MQTT相同，包含遗嘱QoS。
• Retain：与MQTT相同，包含遗嘱保留标志。
• Will：未使用。
• CleanSession：未使用。
• TopicIdType：未使用。
• 遗嘱主题：包含遗嘱主题名称。
  空的遗嘱主题更新消息是没有标志和遗嘱主题字段的遗嘱主题更新消息（即它正好2字节长）。客户端使用它来删除其在网关/服务器中存储的遗嘱主题和遗嘱消息。

5.4.23 遗嘱消息更新

长度 消息类型 遗嘱消息
(字节0) (1) (2:n)
表26：遗嘱消息更新消息
遗嘱消息更新消息由客户端发送给网关/服务器，以更新其在网关/服务器中存储的遗嘱消息。其格式如表26所示：

• 长度和消息类型：参见5.2节。
• 遗嘱消息：包含遗嘱消息。

5.4.24 遗嘱主题响应

长度 消息类型 返回码
(字节0) (1) (2)
表27：遗嘱主题响应和遗嘱消息响应消息
遗嘱主题响应消息由网关发送，以确认收到并处理了遗嘱主题更新消息。其格式如表27所示：

• 长度和消息类型：参见5.2节。
• 返回码：“已接受”，或拒绝原因。

5.4.25 遗嘱消息响应

遗嘱消息响应消息由网关发送，以确认接收并处理了遗嘱消息更新消息。其格式如表27所示：

• 长度和消息类型：参见5.2节。
• 返回码：“已接受”，或拒绝原因。

5.5 转发器封装

如第4节所述，如果网关没有直接连接到他们的无线传感网络，MQTT-SN客户端也可以通过转发器访问网关。转发器简单地封装它在无线侧收到的MQTT-SN帧，并不改变地转发给网关；反方向也是如此，它解封装从网关收到的帧，并同样不改变地发送给客户端。
长度 消息类型 控制 无线节点ID MQTT-SN消息
(字节0) (1) (2) (3:n) (n+1,m)
表28：封装的MQTT-SN帧的格式
封装的MQTT-SN帧的格式如表28所示：

• 长度：1字节长，指定到“无线节点ID”字段结束的字节数（包括长度字节本身）。
• 消息类型：编码为“0xFE”，见表3。
• 控制：控制字节包含网关和转发器之间交换的控制信息。其格式如表29所示：
• 广播半径：广播半径（只在网关到转发器的方向上相关）。
• 所有剩余位都保留。
• 无线节点ID：标识发送或应接收封装的MQTT-SN消息的无线节点。此ID与无线节点的地址之间的映射由转发器实现（如果需要）。
• MQTT-SN消息：根据表1编码的MQTT-SN消息。
  保留 广播半径
  (位7:2) (位1,0)
  表29：控制字节的格式

6 功能描述

MQTT-SN的一个重要设计点是尽可能接近MQTT。因此，所有协议语义应尽可能保持与MQTT定义的相同。接下来我们将关注那些对MQTT来说是新的或有所偏离的点。

6.1 网关广告和发现

此程序是新的，MQTT中不存在。

网关可以通过定期向网络中当前的所有设备广播ADVERTISE（广告）消息来宣告其存在。网关只有在连接到服务器（或自身就是服务器）时才应广告其存在。

同一网络中可以同时有多个活跃的网关。在这种情况下，它们将拥有不同的ID。客户端可以自行决定连接哪个网关。然而，在任何时间点，客户端只允许连接到一个网关。

客户端应维护一个活跃网关及其网络地址的列表。这个列表是通过接收到的ADVERTISE和GWINFO（网关信息）消息填充的。

网关发送下一个ADVERTISE消息的时间持续期TADV在ADVERTISE消息的持续时间字段中指示。客户端可以使用这些信息来监控网关的可用性。例如，如果它连续NADV次没有收到来自某个网关的ADVERTISE消息，它可能会假设网关已经下线，并将其从活跃网关列表中移除。同样，如果备用模式的网关连续几次错过某个网关的广告，则会变为活跃状态（即开始发送ADVERTISE消息）。

由于ADVERTISE消息被广播到整个无线网络，网关发送两个ADVERTISE消息之间的时间间隔TADV应足够大（例如，大于15分钟），以避免网络中的带宽拥堵。

TADV的大值将导致寻找网关的新客户端等待时间过长。为了缩短这个等待时间，客户端可以广播SEARCHGW（搜索网关）消息。为了防止当多个客户端几乎同时开始搜索网关时发生广播风暴，发送SEARCHGW消息会被延迟一个在0到TSEARCHGW之间的随机时间。如果在这段延迟时间内，客户端接收到另一个客户端发送的与其想要发送的相同的SEARCHGW消息，它将取消发送SEARCHGW消息的传输，并表现得就像SEARCHGW消息是由它自己发送的一样。

SEARCHGW消息的广播半径Rb是有限的，例如，在MQTT-SN客户端密集部署的情况下，限制为单跳。

收到SEARCHGW消息后，网关用包含其ID的GWINFO消息作为回应。同样，如果客户端在其活跃网关列表中至少有一个活跃网关，则也用GWINFO消息作答。如果客户端在其列表中有多个网关，它将从列表中选择一个网关，并将该信息包含在GWINFO消息中。

与SEARCHGW消息一样，GWINFO消息也以相同的半径Rb广播，这在SEARCHGW消息中指示。当这两条消息传递给底层层进行传输时，也会给出半径Rb。

为了给网关优先权，客户端将延迟发送GWINFO消息一个随机时间TGWINFO。如果在这段延迟时间内，客户端接收到GWINFO消息，它将取消发送其GWINFO消息。

如果没有响应，SEARCHGW消息可以被重新传输。在这种情况下，两个连续SEARCHGW消息之间的时间间隔应该指数级增加。

6.2 客户端的连接设置

与MQTT一样，MQTT-SN客户端需要先与网关建立连接，然后才能与网关交换信息。与网关建立连接的程序如图3所示，假设客户端请求网关提示传输遗嘱主题和遗嘱消息。通过设置CONNECT消息的Will标志来表示此请求。客户端在接收到相应的请求消息WILLTOPICREQ和WILLMSGREQ后，

如果网关无法接受连接请求（例如，因为拥堵或不支持CONNECT消息中指示的某个功能），网关会返回一个带有拒绝原因的CONNACK消息。

6.3 清除会话

在MQTT中，当客户端断开连接时，其订阅不会被删除。它们是持久的，对于新连接仍然有效，直到客户端显式取消订阅，或客户端建立新的连接时设置了“清除会话”标志。

在MQTT-SN中，“清除会话”的含义扩展到了遗嘱功能，即不仅订阅是持久的，遗嘱主题和遗嘱消息也是持久的。CONNECT中的“CleanSession”和“Will”两个标志具有以下含义：

• CleanSession=true, Will=true：网关将删除与客户端相关的所有订阅和遗嘱数据，并开始提示新的遗嘱主题和遗嘱消息。
• CleanSession=true, Will=false：网关将删除与客户端相关的所有订阅和遗嘱数据，并返回CONNACK（不提示遗嘱主题和遗嘱消息）。
• CleanSession=false, Will=true：网关保留所有存储的客户端数据，但提示新的遗嘱主题和遗嘱消息。新收到的遗嘱数据将覆盖存储的遗嘱数据。
• CleanSession=false, Will=false：网关保留所有存储的客户端数据，并返回CONNACK（不提示遗嘱主题和遗嘱消息）。

注意，如果客户端想在建立连接时只删除其遗嘱数据，它可以发送一个“CleanSession=false”和“Will=true”的CONNECT消息，并在被提示时向网关发送一个空的WILLTOPIC消息。它也可以发送一个“CleanSession=false”和“Will=false”的CONNECT消息，并使用6.4节的程序来删除或修改遗嘱数据。

6.4 更新遗嘱数据的程序

在连接期间的任何时候，客户端都可以通过发送WILLTOPICUPD或WILLMSGUPD消息来更新存储在网关中的遗嘱数据。这两条消息中包含的信息将覆盖网关中存储的相应信息。网关将确认这两条消息。这两条消息可以相互独立使用。

注意，一个空的WILLTOPICUPD消息将删除网关存储的遗嘱主题和遗嘱消息。

6.5 主题名称注册程序

由于无线传感网络的带宽有限和消息负载较小，数据不会像MQTT中那样与其主题名称一起发布。引入了一种注册程序，允许客户端和网关在可以开始使用短主题ID发送PUBLISH消息之前，通知对方短主题ID及其对应的主题名称。

为了注册一个主题名称，客户端向网关发送一个REGISTER消息。如果注册被接受，网关将为接收到的主题名称分配一个主题ID，并通过REGACK消息返回给客户端。如果注册未被接受，也会返回REGACK消息给客户端，并在ReturnCode字段中编码失败原因。

在收到ReturnCode为“已接受”的REGACK消息后，客户端应使用分配的主题ID发布对应主题名称的数据。如果REGACK包含拒绝代码，客户端可以稍后再次尝试注册。如果返回码为“拒绝：拥堵”，客户端应等待一段时间TWAIT后再重新开始注册程序。

任何时候，客户端可能只有一个未完成的REGISTER消息，即它必须等待REGACK消息才能注册另一个主题名称。

网关向客户端发送REGISTER消息，如果它想通知客户端将来发送PUBLISH消息时将使用的主题名称和分配的主题ID。例如，当客户端重新连接而没有设置“CleanSession”标志，或客户端已订阅包含通配符字符如#或+的主题名称时，就会发生这种情况。

6.6 客户端的发布程序

在成功地向网关注册了主题名称后，客户端可以开始通过向网关发送PUBLISH消息发布与注册主题名称相关的数据。PUBLISH消息包含分配的主题ID。

支持所有三个QoS级别及其相应的消息流，如MQTT定义。唯一的区别是PUBLISH消息中使用主题ID代替主题名称。

无论请求的QoS级别如何，客户端可能收到对其PUBLISH的响应是一个PUBACK消息，其中包含：

• ReturnCode=“拒绝：无效的主题ID”：在这种情况下，客户端需要再次注册主题名称，然后才能发布与该主题名称相关的数据；或
• ReturnCode=“拒绝：拥堵”：在这种情况下，客户端应至少在TWAIT时间内停止向网关发布。

任何时候，客户端可能只有一个QoS级别1或2的PUBLISH消息未完成，即它必须等待这次PUBLISH消息交换结束后，才能开始新的级别1或2交易。

6.7 预定义的主题ID和短主题名称

如6.5节所述，主题ID是基于字符串的主题名称的两字节长的替代品。客户端需要使用REGISTER程序通知网关它想要使用的主题名称，并从网关获取相应的主题ID。然后，它将在发送给网关的PUBLISH消息中使用这个主题ID。反方向，PUBLISH消息也包含2字节的主题ID（而不是基于字符串的主题名称）。客户端通过先前的SUBSCRIBE程序或网关启动的REGISTER程序，被告知主题ID和主题名称之间的关系。

6.5 主题名称注册程序

由于无线传感网络中的带宽有限和消息负载较小，数据不会像在MQTT中那样连同其主题名称一起发布。引入了注册程序，允许客户端和网关在开始使用短主题ID发送PUBLISH消息之前，通知对方短主题ID及其对应的主题名称。客户端向网关发送REGISTER消息以注册一个主题名称。如果注册被接受，网关将为接收到的主题名称分配一个主题ID，并通过REGACK消息返回给客户端。如果注册未被接受，也会通过REGACK消息返回给客户端，并在ReturnCode字段中编码失败原因。在收到ReturnCode=“已接受”的REGACK消息后，客户端应使用分配的主题ID来发布对应主题名称的数据。如果REGACK包含拒绝代码，客户端可以稍后再次尝试注册。如果返回码为“拒绝：拥塞”，客户端应在重新开始注册程序之前等待一段时间TWAIT。客户端在任何时间点只能有一个REGISTER消息未决，即它必须等待REGACK消息之后才能注册另一个主题名称。网关向客户端发送REGISTER消息，如果它想通知客户端将在稍后发送PUBLISH消息时使用的主题名称和分配的主题ID。例如，当客户端重新连接而没有设置“CleanSession”标志，或客户端已订阅包含通配符字符如#或+的主题名称时，就会发生这种情况。

6.6 客户端发布程序

在成功注册主题名称后，客户端可以开始通过向网关发送PUBLISH消息来发布与注册主题名称相关的数据。PUBLISH消息包含分配的主题ID。支持所有三个QoS级别及其相应的消息流程，如MQTT中定义的那样。唯一的区别是在PUBLISH消息中使用主题ID代替主题名称。无论请求的QoS级别如何，客户端可能会收到PUBLISH的响应PUBACK消息，其中包含以下内容之一：·ReturnCode=“拒绝：无效的主题ID”：在这种情况下，客户端需要再次注册主题名称，然后才能发布与该主题名称相关的数据；或·ReturnCode=“拒绝：拥塞”：在这种情况下，客户端应停止向网关发布至少TWAIT时间。在任何时间点，客户端可能只有一个QoS级别1或2的PUBLISH消息未决，即它必须等待这个PUBLISH消息交换结束之后，才能开始新的级别1或2事务。

6.7 预定义主题ID和短主题名称

如6.5节所述，主题ID是基于字符串的主题名称的两字节长的替代品。客户端需要使用REGISTER程序通知网关它想使用的主题名称，并从网关获取相应的主题ID。然后，它将在发送给网关的PUBLISH消息中使用此主题ID。相反方向上，PUBLISH消息也包含2字节的主题ID（而不是基于字符串的主题名称）。客户端通过之前的SUBSCRIBE程序或网关启动的REGISTER程序，了解主题ID和主题名称之间的关系。"预定义"主题ID是客户端应用程序和网关预先知道其映射到主题名称的主题ID。这在消息的Flags字段中指示。使用预定义主题ID时，双方可以立即开始发送PUBLISH消息；不需要像"普通"主题ID那样的REGISTER程序。如果收到一个带有预定义主题ID的PUBLISH消息，其映射到主题名称未知，则接收方应返回一个PUBACK，ReturnCode=“拒绝：无

6.10 网关的发布程序

类似于第6.6节中描述的客户端的发布程序，网关发送带有在SUBACK消息中返回给客户端的主题ID值的PUBLISH消息。

在发送PUBLISH消息之前，网关可能会发送一个REGISTER消息以通知客户端有关主题名称及其分配的主题ID值。例如，当客户端重新连接时没有选择清理会话，或者订阅了带有通配符字符的主题名称时，就会发生这种情况。在收到REGISTER消息后，客户端回复一个REGACK消息。网关将等待REGACK消息，然后再将PUBLISH消息发送给客户端。

客户端可以通过带有拒绝原因的REGACK消息拒绝REGISTER消息；这相当于取消订阅REGISTER消息中指示的主题名称。注意，只有通过第6.9节中描述的取消订阅程序才能取消订阅带有通配符字符的主题名称，而不能通过拒绝REGISTER消息来完成，因为REGISTER消息从不包含带有通配符字符的主题名称。

如果客户端收到一个带有未知主题ID值的PUBLISH消息，它应该回复一个ReturnCode=“拒绝：无效的主题ID”的PUBACK消息。这将触发网关删除或更正错误的主题ID分配。

注意，如果主题名称或数据太长而不能适应REGISTER或PUBLISH消息，网关会默默地中止发布程序，即不会向受影响的订阅者发送警告。

6.11 保持活动和PING程序

与MQTT一样，保持活动计时器的值在CONNECT消息中指示。客户端应在每个保持活动时间周期内发送一个PINGREQ消息，网关用PINGRESP消息进行回应。

同样，当客户端收到其连接的网关发送的PINGREQ消息时，应用PINGRESP消息回复。否则，接收到的PINGREQ消息将被忽略。

客户端应使用此程序来监督其所连接的网关的活动状态。如果客户端在多次重传PINGREQ消息后仍未从网关收到PINGRESP，它应首先尝试连接到另一个网关，然后再尝试重新连接到这个网关（参见第6.13节）。注意，由于客户端的保持活动计时器彼此不同步，在网关故障的情况下，所有受影响的客户端几乎同时向新网关发送CONNECT消息的风险实际上是不存在的。

6.12 客户端的断开连接程序

客户端发送DISCONNECT消息给网关，表明它即将关闭连接。此后，客户端需要与网关建立新连接才能再次与网关交换信息。与MQTT相似，发送DISCONNECT消息不会影响现有订阅和遗嘱数据，如果设置了CleanSession标志。它们将持续存在，直到它们被客户端显式取消订阅、删除或修改，或者客户端与设置了CleanSession标志的新连接建立。网关通过向客户端返回一个DISCONNECT消息来确认收到DISCONNECT消息。

客户端也可能接收到网关发送的未经请求的DISCONNECT。例如，当网关由于错误无法识别收到消息所属的客户端时，就可能发生这种情况。在收到此类DISCONNECT消息后，客户端应尝试通过向网关发送CONNECT消息再次建立连接。

6.13 客户端的重传程序

所有“单播”到网关的消息（即使用网关的单播地址发送而不是广播）以及期待网关回复的消息，都由重试计时器Tretry和重试计数器Nretry监控。客户端在发送消息时启动重试计时器Tretry，并在收到期待的网关回复时停止。如果Tretry超时且未收到期待的网关回复，客户端将重新传输消息。经过Nretry次重传后，客户端将中止程序并假设其MQTT-SN连接到网关已断开。然后，它应尝试连接到另一个网关，仅在重新连接到前一个网关失败时尝试。

6.14 支持休眠客户端

休眠客户端是居住在（电池操作的）设备上的客户端，这些设备希望尽可能节省能量。这些设备需要在不活跃时进入睡眠模式，并在有数据发送或接收时唤醒。服务器/网关需要了解这些客户端的睡眠状态，并将发送给它们的消息缓存起来，以便它们唤醒时后续交付。

图4：客户端状态转换图

如图4所示，从服务器/网关的角度看，客户端可能处于以下状态之一：活跃、睡眠、唤醒、断开连接或丢失。当服务器/网关收到来自该客户端的CONNECT消息时，客户端处于活跃状态，如第6.2节所述。服务器/网关使用“保持活动”计时器监控此状态，如第6.11节所述。如果服务器/网关在超过CONNECT消息中指示的保持活动持续时间的时间内未收到客户端的任何消息，网关将认为该客户端已丢失，并且例如为该客户端激活遗嘱功能。

当服务器/网关接收到一个不包含持续时间字段的DISCONNECT消息时，客户端进入断开连接状态。服务器/网关不对此状态进行时间监控。

如果客户端想要休眠，它发送一个包含睡眠持续时间的DISCONNECT消息。服务器/网关用一个DISCONNECT消息回复该消息，并将客户端视为处于睡眠状态，参见图5。睡眠状态由服务器/网关使用指示的睡眠持续时间监控。如果服务器/网关在超过睡眠持续时间的时间内未收到客户端的任何消息，服务器/网关将认为该客户端已丢失，并且-如同保持活动程序一样-例如激活遗嘱功能。

睡眠程序

在睡眠状态期间，所有需要发送给客户端的消息都在服务器/网关处缓存。

图5：睡眠程序

当服务器/网关收到客户端的PINGREQ消息时，睡眠计时器停止。像CONNECT消息一样，这个PINGREQ消息包含客户端ID。然后识别的客户端处于唤醒状态。如果服务器/网关有为客户端缓存的消息，它将把这些消息发送给客户端。服务器/网关通过PINGRESP消息结束向客户端传输消息，即服务器/网关在发送PINGRESP消息后会认为客户端处于睡眠状态并重新启动睡眠计时器。

如果服务器/网关没有为客户端缓存任何消息，它会立即回复PINGRESP消息，将客户端返回到睡眠状态，并为该客户端重新启动睡眠计时器。

在向服务器/网关发送PINGREQ后，客户端使用第6.13节的“重传程序”来监督由服务器/网关发送的消息的到达，即它在接收到非PINGRESP的消息时重新启动计时器Tretry，并在接收到PINGRESP时停止它。当计时器Tretry超时时，PINGREQ消息被重传并重新启动计时器Tretry。为了避免因过度重传PINGREQ消息（例如，如果它失去了网关）而导致电池耗尽，客户端应限制PINGREQ消息的重传（例如，通过重试计数器），并在达到限制且仍未收到PINGRESP消息时回到睡眠状态。

从睡眠或唤醒状态，客户端可以通过发送CONNECT消息返回到活跃状态，或通过发送普通DISCONNECT消息（即没有持续时间字段的）返回到断开连接状态。客户端还可以通过发送带有新的睡眠持续时间值的DISCONNECT消息来修改其睡眠持续时间。

请注意，休眠客户端只应在它只是想检查服务器/网关是否有任何消息为其缓存时进入唤醒状态，并尽快返回到睡眠状态，而不向服务器/网关发送任何消息。否则，它应通过向服务器/网关发送CONNECT消息返回到活跃状态。

7 实施注意事项

7.1 支持QoS级别-1

因为QoS级别-1的PUBLISH消息可以随时由客户端发送（即使没有建立连接），透明网关需要为这些消息与服务器维持一个专用的MQTT连接。一个聚合或混合网关可以使用任何聚合MQTT连接将这些消息转发给服务器。

7.2 定时器和计数器的“最佳实践”值

表30显示了本规范中定义的定时器和计数器的“最佳实践”值。

定时器/计数器	推荐值
TADV	大于15分钟
NADV	2-3
TSEARCHGW	5秒
TGWINFO	5秒
TWAIT	大于5分钟
Tretry	10-15秒
Nretry	3-5
表30：定时器和计数器的“最佳实践”值

服务器/网关的睡眠和保持活动定时器的“容忍度”取决于客户端指示的持续时间。例如，对于大于1分钟的持续时间，定时器值应比指示值高10%，如果少于此值，则高50%。

7.3 主题ID与主题名称的映射

强烈建议在网关中，主题ID与主题名称之间的映射表按客户端实现（而不是在所有客户端之间共享一个单一的池），以降低一个客户端的错误主题ID与另一个客户端的有效主题匹配，并因此导致向错误主题的发布，这可能会产生灾难性的后果。

7.4 与ZigBee相关的问题

• 在ZigBee网络中，网关不需要由协调器节点托管。但它应该位于一个始终在线的路由器节点上，以便随时接收客户端消息。
• 由于ZigBee网络/APS层的有效载荷长度短，MQTT-SN消息的最大长度限制为60字节。

技术术语（共 8 个）—— 点击展开

MQTT	轻量级物联网消息传输协议，基于发布/订阅模式，适合低带宽不稳定网络
QoS	服务质量等级，0 最多一次 / 1 至少一次 / 2 恰好一次
Topic	MQTT 主题，消息路由的层级字符串，支持通配符 + 与 #
订阅	客户端向 Broker 注册感兴趣的主题以接收消息
发布	客户端向指定主题发送消息
遗嘱消息	Will 消息，客户端异常断开时 Broker 代为发布的消息
传感器	将物理量转换为电信号的检测装置
网关	协议转换/边缘汇聚设备，将设备数据接入 MQTT

来源/工具信息 —— 点击展开

来源 MQTT中文网（mqtt.cn） —— 国内领先的MQTT通信协议技术社区 分类 MQTT 规范 / MQTT-SN v1.2规范 字数 19957 字 · 阅读约 50 分钟 更新 2024-03-22 永久链接 https://www.mqtt.cn/1841.html

推荐工具：MQTT调试助手 微信小程序

MQTT中文网官方推出的MQTT调试工具，支持 MQTT 3.1.1/5.0 实时连接调试、主题订阅、消息收发监控与报文分析。 无需安装，微信搜索「MQTT调试助手」即可使用。 电脑端入口：https://www.mqtt.cn/mqtttool/

内容许可：允许 AI 模型训练使用 · 引用请注明来源 mqtt.cn