前言
本篇是MQTT-SN 1.2协议最后一篇翻译了，主要涉及实现要点，很简短。
需要支持QoS 值为 -1
QoS虽默认设置有0,1,2三个值，但还有一种情况其值为-1。来自客户端的PUBLISH消息中若QoS为-1的情况下，此刻客户端不会关心和网关有没有建立连接，也不在乎时间点，有消息就需要发出去。透明的网关需要维护此类消息并与远程的MQTT Server建立一个专用TCP连接。聚合网关或hybird混杂网关可使用已有的MQTT Server连接转发此类消息。
定时器和计时器实践建议
| 定时器/计数器 | 说明 | 推荐值 |
|---|---|---|
| T_ADV | 广播频率 | 大于15分钟 |
| N_ADV | 没有接收到ADVERSE广播次数 | 2-3次 |
| T_SEARCHGW | 发送SEARCHGW延迟 | 5秒 |
| T_GWINFO | 等待网关响应GWINFO广播延迟时长 | 5秒 |
| T_WAIT | 等待时长 | 大于5分钟 |
| T_RETRY | 重试时长 | 10s - 15s |
| N_RETRY | 重试次数 | 3-5次 |
网关处理客户端的休眠和存活定时器，需要根据客户端在所发送消息中延续时间的定义值。例如，定时器值应该高出10%大于指定值持续时间1分钟，如果不高出50%。
网关持有的Topic Id和Topic Name的映射维护
协议严重建议所有客户端的Topic Id和Topic Name之间对应关系不应该使用一个共享池对象，因为这样可以避免不同客户端Topic Id和Topic Name匹配错误，将PUBLISH消息发错地方（客户端接收者），可能会导致引发潜在的不可恢复的灾难性后果。
正确做法是按照客户端的维度为维护Topic Id和Topic Name的对应关系。任何两个客户端之间可能会存在同样的Topic Name，但对应的Topic Id不一样。可能Topic Id一致，但Topic Name不一样。
ZigBee 相关问题
- 在ZigBee规范中，网关需要被托管在一个协调器节点内，MQTT-SN协议建议网关更应该而驻留在一个不间断运行的的ZigBee路由器节点上，能够随时接收来自客户端消息。
- 受限于ZigBee网络支持层有限的数据负载容量，MQTT-SN消息最大负载被限制为60字节。