前言
這一段時間在翻看MQTT-SN的協議，對針對不依賴于TCP傳輸的MQTT協議十分感興趣，總是再想著這貨到底是怎么定義的。一系列文章皆有MQTT-SN 1.2協議所拼裝組成，原文檔地址： MQTT-SN_spec_v1.2.pdf
MQTT-SN文檔分為7個部分，我直接按照從前到后的順序，直接組裝成四個小篇。嗯，若放在一篇文章中，文字太長，造成排版難度。
非直譯，完全按照自己理解整理而成，請知曉。
版本變遷歷史
- 2007-11-29 1.0版本
- 2008-6-5 1.1版本，增加休眠設備支持
- 2011-5-20 1.2版本
- 增加消息長度255字節支持
- 增加轉發封裝支持
- 增加返回代碼"0x03 Rejected, not supported"
- ReturnCode 增加到WILLTOPICRESP和WILLMSGRESP消息中
MQTT-SN名稱由來
原名是MQTT-S，但會引起人們的誤解，因此更名成MQTT-SN：
As part of the job of applying the same or similar license terms to the MQTT-S specification as those on the MQTT specification, we are proposing a small name change. The new name would be MQTT-SN, standing for exactly the same long name, MQTT for Sensor Networks. Some people had assumed that the S in MQTT-S stood for secure, so we hope this change will avoid that confusion. -- Ian Craggs
MQTT-SN存在目的
MQTT for Sensor Networks is aimed at embedded devices on non-TCP/IP networks, such as Zigbee. MQTT-SN is a publish/subscribe messaging protocol for wireless sensor networks (WSN), with the aim of extending the MQTT protocol beyond the reach of TCP/IP infrastructure for Sensor and Actuator solutions.
針對適配傳感裝置（縮寫為SA）的特定版MQTT協議，一般運行在嵌入式電池驅動的電子元件中，傳輸通過基于IEEE 802.15.4規范無線低速網絡構成的無線傳感網絡（WSN），同樣具有企業級別特性具有以數據為核心的（data-centric）訂閱/發布特性。
總之，針對低功耗、電池驅動、處理存儲受限的設備、不支持TCP/IP協議棧網絡的電子器件而定制，比如常見的ZigBee（或XBee），對所依賴的底層傳輸網絡不可知，但只要網絡支持雙向數據傳輸和網關，都是可以支持較為上層的MQTT-SN協議傳輸。比如簡單數據報服務，只要支持一個源端點發送數據到一個特定目的地端點，這對支持MQTT-SN協議，就足夠了。廣播數據報傳輸服務也是必須的用于網關和終端的自動發現流程。為了降低廣播風暴，MQTT-SN定義了廣播路徑深度（廣播范圍或廣播半徑）。
一些名詞和術語
- topic id，主題標識符，兩個字節16位表示的自然數（java語言short類型，0-65535范圍），對應于主題topic name
- 網關/服務器（gateway/server），在MQTT-SN中統一稱之為網關，主要處理和MQTT-SN客戶端的交互，縮寫為網關
- MQTT-SN終端和客戶端（client），統一稱之為客戶端，其實也是嵌入式傳感設備，或電子元件，資源受限，在無線區域個人網中運行
- IEEE 802.15.4，完整棧的整個數據上限為128個字節，一般選擇UDP（相比20個字節的TCP協議，UDP報文頭部僅僅需要8個字節）協議傳輸數據
- 低速網絡/當前網絡，指的是LR-WPAN（low-rate wireless personal area network,），低速無線個人區域網絡
MQTT-SN VS MQTT
盡管MQTT-SN被設計成盡可能接近于MQTT，但那些低功耗、電池驅動、資源受限的設備所在網絡場景為低速帶寬、高連接失敗、物理層數據包上線為128字節。文檔提出了以下不同點：
- CONNECT消息被拆分成三個消息（CONNECT，WILLTIPIC，WILLMSG），后兩者用于客戶端傳遞遺囑主題和遺囑消息等
- 在PUBLISH消息中主題（topic name）被替換成兩個字節長度自然數（topic id），這個需要客戶端通過注冊流程進行獲取對應的topic id
- 預定義（提前定義）topic id和topic name，省去中間注冊流程，客戶端和網關要求提前在其固件中指定
- 協議引入的自動發現機制可幫助客戶端發現潛在的網關。若存在多個網關，彼此可協調是為主從互備或者負載均衡
- "clean session"即可作用于訂閱持久化，也被擴展作用于遺囑特性（遺囑主題和遺囑消息）
- 針對休眠設備增加離線保活機制支持，當有消息時代理需要緩存，客戶端被喚醒時再發送
MQTT-SN架構示意
在MQTT-SN架構圖中，存在三種組件：
- MQTT-SN 客戶端
- MQTT-SN 網關，可單獨存在，也可以被集成到MQTT服務器中。需要承擔MQTT-SN和MQTT協議之間的轉換工作
- MQTT-SN 轉發器，負責轉發當前客戶端數據到不可直接訪問的網關上去，針對客戶端而言網關不可直接訪問時，轉發器作用就凸顯。轉發器封裝MQTT-SN消息轉發給網關，解封來自網關的消息發送給客戶端。網關不能夠篡改原始數據。
MQTT-SN傳輸網關
MQTT-SN網關傳輸方式，下面的圖片一目了然。 
- 透明網關，會為每一個客戶端都建立一個TCP連接到MQTT服務器的通道，這樣會較為耗費網關網絡資源，但模型簡單
- 聚合網關，只建立一條TCP連接通道到MQTT服務器上，所有的客戶端共享一個通道，很經濟的說。
網關需要抉擇哪些消息需要和遠程的MQTT Server進行交互，比如只選擇客戶端發送的PUBLISH、SUBSCRIBLE消息等。
小結
上面簡單介紹了MQTT-SN，下面將會介紹MQTT-SN消息頭部和格式。