關(guān)于IoT的協(xié)議選擇

對(duì)于使用傳感器和保持連接性的IoT系統(tǒng)而言，如何使用這些元素和多種互聯(lián)網(wǎng)技術(shù)相結(jié)合呢？

互聯(lián)網(wǎng)協(xié)議并不陌生，但是IoT相關(guān)的互聯(lián)網(wǎng)協(xié)議可能是有不同，有些協(xié)議被用來輔助塑造系統(tǒng)。TCP/IP協(xié)議棧上有多個(gè)應(yīng)用層協(xié)議， 每種協(xié)議都有自己的優(yōu)勢和限制，了解這些可以幫助開發(fā)者為產(chǎn)品做出最好的設(shè)計(jì)選擇。 在選擇物聯(lián)網(wǎng)協(xié)議時(shí)， 帶寬要求、實(shí)時(shí)性能和內(nèi)存占用是主要的約束條件。

鑒于IoT 的多樣性和復(fù)雜性，應(yīng)用場景上有著諸多的類型：

Consumer versus industrial 消費(fèi)者 vs 工業(yè)

Web services 網(wǎng)絡(luò)服務(wù)

IoT services 物聯(lián)網(wǎng)服務(wù)

Publish/subscribe 發(fā)布/訂閱

Request/response 請(qǐng)求/響應(yīng)

。。。。。。

在設(shè)計(jì)IoT系統(tǒng)時(shí)， 必須考慮這些類別， 清晰的需求和邊界確定，幾乎是成敗的關(guān)鍵。一般地，一個(gè)IoT系統(tǒng)大致如此：

圖1 IoT（M2M）的一般系統(tǒng)架構(gòu)

面向接口的設(shè)計(jì)，被業(yè)界廣泛的接受，引申到系統(tǒng)的層面，大約是面向協(xié)議的設(shè)計(jì)， 對(duì)協(xié)議的認(rèn)知是設(shè)計(jì)的基礎(chǔ)。

互聯(lián)網(wǎng)協(xié)議棧

互聯(lián)網(wǎng)是所有網(wǎng)絡(luò)設(shè)備的總和， 用來將 IP 包從源路由到目的地。 相比之下， Web只是一個(gè)在互聯(lián)網(wǎng)上運(yùn)行的應(yīng)用系統(tǒng)。 網(wǎng)絡(luò)是一個(gè)交流信息工具， 在過去的幾十年里， 網(wǎng)絡(luò)得到了普及和發(fā)展， 普通人也能夠輕松有效地使用互聯(lián)網(wǎng)。 例如， 電子郵件，搜索引擎，瀏覽器，移動(dòng)應(yīng)用，以及其他流行的社交媒體。

相對(duì)而言， 物聯(lián)網(wǎng)是讓電子設(shè)備通過互聯(lián)網(wǎng)交換信息。 但是這些設(shè)備還不能像瀏覽器和社交媒體那樣來促進(jìn)交流。 物聯(lián)網(wǎng)也不同于網(wǎng)絡(luò)，因?yàn)槲锫?lián)網(wǎng)設(shè)備為了協(xié)同工作所需要的速度、規(guī)模和功能不同于互聯(lián)網(wǎng)， 需求千姿百態(tài)，這也是物聯(lián)網(wǎng)定義難以明確的原因之一。

協(xié)議棧是互聯(lián)網(wǎng)和網(wǎng)絡(luò)的核心，離不開OSI七層開放系統(tǒng)互連的表示，具體可以參見老曹眼中的網(wǎng)絡(luò)編程基礎(chǔ)。 在這里，上三層被分組在一起以簡化模型。

圖2 OSI 模型簡要

我們需要從IoT的角度來快速理解一下OSI層。

下三層：物理層、數(shù)據(jù)鏈路層 和網(wǎng)絡(luò)層

互聯(lián)網(wǎng)中常用的物理層和數(shù)據(jù)鏈路層協(xié)議有：

Ethernet （10 Mbps， 100 Mbps， 1 Gbps）

Wi-Fi （802.11b/g/n）

點(diǎn)對(duì)點(diǎn)協(xié)議（PPP）

GSM， 3G， 4G， LTE 3G， 4G， LTE

但是對(duì)IoT而言，采用的無線協(xié)議更加豐富，例如 802.15.*等，甚至城域網(wǎng)乃至其他廣域網(wǎng)的相關(guān)協(xié)議也紛紛被引入， 后面單獨(dú)進(jìn)行理解。

網(wǎng)絡(luò)層是互聯(lián)網(wǎng)生存的地方。 互聯(lián)網(wǎng)之所以被命名， 是因?yàn)樗峁┝司W(wǎng)絡(luò)之間、物理層之間的連接。 這就是我們找到無處不在 IP 地址的地方。

傳輸層

在 IP 之上， 互聯(lián)網(wǎng)有兩個(gè)傳輸協(xié)議——TCP和UDP。 TCP 用于網(wǎng)絡(luò)中的交互（電子郵件、網(wǎng)頁瀏覽等） ， 甚至被認(rèn)為 是傳輸層中唯一的協(xié)議。 TCP 提供了邏輯連接的概念， 傳輸包的確認(rèn)， 丟失數(shù)據(jù)包的重傳， 以及流量控制。 但是對(duì)于IoT系統(tǒng)而言， TCP 可能有點(diǎn)重。 因此， 盡管 UDP 長期以來一直被降級(jí)到DNS和 DHCP等網(wǎng)絡(luò)服務(wù)， 現(xiàn)在已經(jīng)在傳感器采集和遠(yuǎn)程控制領(lǐng)域占據(jù)了一席之地。 如果需要對(duì)數(shù)據(jù)進(jìn)行某種類型的管理， 甚至可以在 UDP 之上編寫自己的輕量級(jí)協(xié)議， 以避免 TCP的開銷。

對(duì)于語音和視頻等實(shí)時(shí)數(shù)據(jù)應(yīng)用， UDP 比 TCP 可能更適合。 TCP 的數(shù)據(jù)包確認(rèn)和重傳功能對(duì)于這些應(yīng)用可能是無用的開銷。 如果一段數(shù)據(jù)（比如一段口語音頻）沒有及時(shí)到達(dá)目的地， 那么重新傳輸數(shù)據(jù)包可能意義不大。有時(shí)選擇TCP是因?yàn)樗峁┝艘粋€(gè)持久的連接。 為了實(shí)現(xiàn)類似的功能， 必須在 UDP 上面的協(xié)議層中實(shí)現(xiàn)該特性。

當(dāng)決定如何將數(shù)據(jù)從“事物”本地網(wǎng)絡(luò)轉(zhuǎn)移到一個(gè) IP 網(wǎng)絡(luò)時(shí)， 可以通過網(wǎng)關(guān)將兩個(gè)網(wǎng)絡(luò)連接起來， 或者可以把這個(gè)功能構(gòu)建在“事物”本身上。 許多微控制器（MCUs）現(xiàn)在都有一個(gè)以太網(wǎng)控制器， 這使得這個(gè)任務(wù)更加容易。

用于物聯(lián)網(wǎng)的無線協(xié)議

雖然大部分物聯(lián)網(wǎng)依賴于傳統(tǒng)的嵌入式開發(fā)技術(shù)， 但是對(duì)始終擁有對(duì)連接性的需求，這要求我們不僅對(duì)無線方法做出選擇， 還要選擇相應(yīng)的通信協(xié)議。 因此， 不同的協(xié)議都在試圖建立為從邊緣節(jié)點(diǎn)向云服務(wù)提供數(shù)據(jù)通信的基礎(chǔ)。 每種協(xié)議都希望被看作是對(duì)某些類型的數(shù)據(jù)或數(shù)據(jù)交換方法的最佳選擇。

從計(jì)算機(jī)網(wǎng)絡(luò)演進(jìn)的IoT無線協(xié)議

Nest Labs 在智能恒溫器和煙霧探測器產(chǎn)品中使用了Thread Group 協(xié)議， 在2015年被谷歌收購并獲得了迅速的發(fā)展。 隨著合作伙伴和用戶群體的不斷增長， Thread Group的潛力使其成為 ZigBee、 Z-Wave 和低耗電藍(lán)牙（BLE）等技術(shù)的可行替代品。 其成功的主要原因是谷歌沒有開發(fā)一個(gè)全新的協(xié)議， 而是把它建立在 IEEE 802.15.4無線標(biāo)準(zhǔn)的基礎(chǔ)上。

圖3 Thread 協(xié)議的主要組件

Thread Group的目標(biāo)是家用電器、接入和氣候控制、能源管理、照明、安全等。

BLE 可能是Thread Group 的最大競爭對(duì)手， 但是 BLE 尚不能形成一個(gè)自我修復(fù)的網(wǎng)絡(luò)， 而這個(gè)網(wǎng)絡(luò)正逐漸成為物聯(lián)網(wǎng)應(yīng)用的先決條件。 可靠性是基于傳感器任何形式通信的關(guān)鍵， 如恒溫器、安全警報(bào)器， 當(dāng)然也適用于安全第一的工業(yè)應(yīng)用。盡管如此， BLE 當(dāng)然還沒有退出物聯(lián)網(wǎng)的協(xié)議競爭。受益于多年來不斷增強(qiáng)的功能， 現(xiàn)在一些藍(lán)牙技術(shù)聯(lián)盟（藍(lán)牙 SIG）的參與者， 如 Broadcom、 Qualcomm 和其他行業(yè)領(lǐng)導(dǎo)者， 正在努力提高 BLE 的能力， 使其適用于物聯(lián)網(wǎng)應(yīng)用。

藍(lán)牙 SIG 也為連接互聯(lián)網(wǎng)鋪平了道路，推出了藍(lán)牙智能網(wǎng)絡(luò)工作組（目前已有80多家公司支持該工作組） ， 目標(biāo)是建立標(biāo)準(zhǔn)化藍(lán)牙網(wǎng)絡(luò)網(wǎng)絡(luò)的架構(gòu)。

IPv6， IEEE 802.15.4， 以及一個(gè)叫做 IPv6的個(gè)人區(qū)域網(wǎng)絡(luò)相對(duì)于Thread Group、 ZigBee 和 Z-Wave 所使用的低功耗無線個(gè)人區(qū)域網(wǎng)（6LoWPAN）的是互補(bǔ)的， 因?yàn)楹髢煞N網(wǎng)絡(luò)是明確為處理能力有限、數(shù)據(jù)率低、射頻輸出功率極低、電源或電池耗電量極低的設(shè)備。 這將使設(shè)備和網(wǎng)絡(luò)設(shè)計(jì)相對(duì)簡單， 成本效益較高。

由于 Thread 的低延遲（通常為100毫秒， 一般比 Wi-Fi 要少得一些）特性 ， 它可以在一個(gè)網(wǎng)絡(luò)上容納300個(gè)設(shè)備， 提供 AES 128位的安全性， 以及一個(gè)網(wǎng)狀網(wǎng)絡(luò)方法將其定位為適合在物聯(lián)網(wǎng)應(yīng)用中使用的協(xié)議。 但是， 沒有證據(jù)表明 Thread 將成為物聯(lián)網(wǎng)連接的主導(dǎo)者。 隨著物聯(lián)網(wǎng)的增長 ， 很多協(xié)議顯然要建立自己的空間， 也許在特定的應(yīng)用程序中找準(zhǔn)自己的位置。

遠(yuǎn)距離的IoT無線協(xié)議

LPWAN技術(shù)是為了滿足物聯(lián)網(wǎng)需求應(yīng)運(yùn)而生的遠(yuǎn)距離無線通信技術(shù)。

對(duì)于電信運(yùn)營商而言，車聯(lián)網(wǎng)、智慧醫(yī)療、智能家居等物聯(lián)網(wǎng)應(yīng)用將產(chǎn)生海量連接，遠(yuǎn)遠(yuǎn)超過人與人之間的通信需求?；诜涓C的窄帶物聯(lián)網(wǎng)（Narrow Band Internet of Things， NB-IoT）成為萬物互聯(lián)網(wǎng)絡(luò)的一個(gè)重要分支。NB-IoT構(gòu)建于蜂窩網(wǎng)絡(luò)，只消耗大約180KHz的帶寬，可直接部署于GSM網(wǎng)絡(luò)、UMTS網(wǎng)絡(luò)或LTE網(wǎng)絡(luò)，以降低部署成本、實(shí)現(xiàn)平滑升級(jí)。

NB-IOT聚焦于低功耗廣覆蓋（LPWA）物聯(lián)網(wǎng)（IOT）市場，是一種可在全球范圍內(nèi)廣泛應(yīng)用的新興技術(shù)。其具有覆蓋廣、連接多、速率低、成本低、功耗低、架構(gòu)優(yōu)等特點(diǎn)。NB-IOT使用授權(quán)頻段，可采取帶內(nèi)、保護(hù)帶或獨(dú)立載波三種部署方式，與現(xiàn)有網(wǎng)絡(luò)共存。

國內(nèi)的華為在NB-IoT上是比較有作為的，該公司給出的端到端解決方案示意如下：

圖4 NB-IoT E2E soluTIon　

在非授權(quán)頻段，也有應(yīng)用于IoT的相關(guān)無線協(xié)議。對(duì)應(yīng)于NB-IoT，LP-WAN在非授權(quán)頻譜中的協(xié)議主要有LoRa、SigFox等技術(shù)。網(wǎng)絡(luò)部署拓?fù)洳季挚梢愿鶕?jù)具體應(yīng)用和和場景設(shè)計(jì)部署方案。 例如，LoRa適合于通信頻次低，數(shù)據(jù)量不大的應(yīng)用。

圖5 LPWAN 的解決方案

其他的那些常見協(xié)議

那么 zigbee / zigbee Pro， Z-Wave， AllJoyn， CSR Mesh， 和 IoTIvity 那些協(xié)議是怎樣的呢？

Zigbee 3.0在2.4 GHz 的頻率運(yùn)行， 最大數(shù)據(jù)速率為250千兆比特， 已經(jīng)獲得了大約400個(gè)供應(yīng)商的廣泛支持， 并且可以使用一個(gè)完善的網(wǎng)絡(luò)協(xié)議支持?jǐn)?shù)以千計(jì)的節(jié)點(diǎn)。 它的鏈接距離約為100英尺， 支持 IPv6， 并提供128位的 AES 加密安全。 這個(gè)最新版本包含了多年來所有過往的ZigBee 應(yīng)用配置， ZigBee 聯(lián)盟因此受到了批評(píng)。

和 ZigBee 一樣， ZigBee Pro 是一個(gè)相對(duì)較新的規(guī)范。 這種網(wǎng)格網(wǎng)絡(luò)協(xié)議顯然對(duì)物聯(lián)網(wǎng)進(jìn)行了優(yōu)化， 它不僅可以在2.4 GHz 頻譜上運(yùn)行， 而且可以在800-900 MHz 無需授權(quán)的頻譜中運(yùn)行。 使用擴(kuò)頻調(diào)制方法， 可以超過16個(gè)通道， 除廣播傳輸選項(xiàng)外， 還支持星狀拓?fù)洹?和大多數(shù)物聯(lián)網(wǎng)節(jié)點(diǎn)應(yīng)用一樣， 節(jié)約能源是首要考慮因素， 因此協(xié)議滿足通過各種機(jī)電、光或運(yùn)動(dòng)方法獲取能量的無電池的設(shè)備。

與此同時(shí)， Z-Wave 只在800-900 MHz 頻帶上運(yùn)行，仍然得到了超過375個(gè)組織的支持。

在 Linux 基金會(huì)內(nèi)部， 有 AllJoyn 框架的 AllSeen 聯(lián)盟。 Alljoyn 是一個(gè)開源、協(xié)作軟件框架， 允許開發(fā)者為物聯(lián)網(wǎng)編寫應(yīng)用程序， 無論品牌、類別、傳輸媒介和操作系統(tǒng)， 都可以為物聯(lián)網(wǎng)編寫應(yīng)用程序， 而無需使用云計(jì)算， 甚至不需要互聯(lián)網(wǎng)（但這兩者都得到了支持）。 它支持 Wi-Fi、以太網(wǎng)、串口乃至電力線傳輸媒體。 支持的操作系統(tǒng)包括 RTOS， Arduino， Linux， Android， iOS， Windows 和 Mac。 該框架同樣使用128位 AES 加密， 目前有120多家公司支持。

另一個(gè)在 Linux 基金會(huì)內(nèi)部運(yùn)行的協(xié)議是 IoTIvity， 它專注于提高互操作性和定義物聯(lián)網(wǎng)的連接需求。 它使用一個(gè)通用的通信框架， 管理個(gè)人計(jì)算機(jī)和新興物聯(lián)網(wǎng)設(shè)備之間的信息流， 而不考慮形式因素、操作系統(tǒng)或服務(wù)提供者。

可應(yīng)用在物聯(lián)網(wǎng)中的互聯(lián)網(wǎng)高層協(xié)議

盡管不像新的協(xié)議那樣有效，但使用web 技術(shù)建立物聯(lián)網(wǎng)系統(tǒng)仍然是可能的。 http/https和 websocket 是常用的標(biāo)準(zhǔn)， 以及負(fù)載中的 XML或 JSON。

HTTP

Http 是 Web 客戶端-服務(wù)器模型的基礎(chǔ)。 在物聯(lián)網(wǎng)設(shè)備中實(shí)現(xiàn) HTTP 的最安全且簡單的方法是只包含一個(gè)客戶端， 而不是服務(wù)器。 換句話說， 當(dāng)物聯(lián)網(wǎng)設(shè)備能夠啟動(dòng)與網(wǎng)絡(luò)服務(wù)器的連接， 但無法接收連接請(qǐng)求時(shí)， 它會(huì)更安全; 一般不希望外部機(jī)器訪問裝有物聯(lián)網(wǎng)設(shè)備的本地網(wǎng)絡(luò)。

WebSocket

Websocket 是一個(gè)協(xié)議， 通過一個(gè)單一的 TCP 連接提供全雙工通信， 通過這種連接可以在客戶端和服務(wù)器之間發(fā)送消息。 它是HTML5規(guī)范的一部分。 Websocket 標(biāo)準(zhǔn)簡化了雙向網(wǎng)絡(luò)通信和連接管理的大部分復(fù)雜性。

XMPP

XMPP 是現(xiàn)有 Web 技術(shù)在物聯(lián)網(wǎng)領(lǐng)域中應(yīng)用的一個(gè)好例子。Xmpp 的根源在于即時(shí)通訊和存儲(chǔ)信息， 并且已經(jīng)擴(kuò)展到語音和視頻通話、協(xié)作、輕量級(jí)中間件、內(nèi)容聚合和 XML 數(shù)據(jù)的廣義路由。 它能夠大規(guī)模管理消費(fèi)者產(chǎn)品，如洗衣機(jī)、烘干機(jī)、冰箱等等。

XMPP 的優(yōu)勢在于地址、安全性和可伸縮性，成為面向消費(fèi)者物聯(lián)網(wǎng)應(yīng)用的良好選擇之一。

HTTP， WebSocket， 和XMPP 只是其中的一些例子，很多組織也在努力尋找解決物聯(lián)網(wǎng)新挑戰(zhàn)的解決方案。

面向物聯(lián)網(wǎng)的高層協(xié)議

許多物聯(lián)網(wǎng)專家把物聯(lián)網(wǎng)設(shè)備稱為受限系統(tǒng)， 因?yàn)槲锫?lián)網(wǎng)設(shè)備應(yīng)該盡可能的便宜， 并且運(yùn)行協(xié)議棧的同時(shí)使用最小能力的MCU。

如果系統(tǒng)不需要 TCP 的特性， 并且可以使用更有限的 UDP 功能， 那么刪除 TCP 模塊將大大減少產(chǎn)品的總代碼量， 這就是 6LoWPAN 和 CoAP 在物聯(lián)網(wǎng)領(lǐng)域的應(yīng)用。

CoAP

雖然網(wǎng)絡(luò)基礎(chǔ)設(shè)施對(duì)物聯(lián)網(wǎng)設(shè)備來說是可用的， 但是對(duì)于大多數(shù)物聯(lián)網(wǎng)應(yīng)用來說還是太重了。 2013年7月， IETF 發(fā)布了 CoAP， 用于低功耗節(jié)點(diǎn)網(wǎng)絡(luò)。 與 HTTP 一樣， CoAP 也具有 RESTful操作資源和資源標(biāo)識(shí)符的能力。

CoAP 與 HTTP 語義對(duì)齊， 甚至有一對(duì)一的 HTTP 映射。 網(wǎng)絡(luò)設(shè)備受到較小的MCU約束， 只有少量的閃存和 RAM， 而對(duì)局部網(wǎng)絡(luò)的限制是高數(shù)據(jù)包錯(cuò)誤率和低吞吐量（幾十kb/秒）。 對(duì)于在電池或能量采集元件上運(yùn)行的設(shè)備來說， CoAP 是一個(gè)很好的協(xié)議。

CoAP 的特點(diǎn)：

由于 CoAP 使用 UDP， 一些 TCP 功能在 CoAP 中被直接復(fù)制。 例如， CoAP 區(qū)分了可確認(rèn)（需要確認(rèn)）和非確認(rèn)消息

請(qǐng)求和響應(yīng)在 CoAP 消息上異步交換（與使用現(xiàn)有 TCP 連接的 HTTP 不同）

所有的標(biāo)題、方法和狀態(tài)代碼都是二進(jìn)制編碼， 可以減少協(xié)定開銷。 然而， 這需要使用協(xié)議分析器來debug網(wǎng)絡(luò)問題。

充分考慮到這是一種極其輕微的協(xié)議， 其行為類似于永久連接。 它對(duì) HTTP 語義很類似， 并且是 RESTful 的。 如果有網(wǎng)絡(luò)編程背景， 使用 CoAP 是相對(duì)容易的。

MQTT

MQTT是針對(duì)受限設(shè)備和低帶寬、高延遲或不可靠網(wǎng)絡(luò)開發(fā)和優(yōu)化的開源協(xié)議。 它是一種發(fā)布/訂閱傳輸模型， 非常輕便， 非常適合將小型設(shè)備與帶寬小的網(wǎng)絡(luò)連接起來。 MQTT 是帶寬效率高、數(shù)據(jù)不可知的， 并且在使用 TCP 時(shí)具有連續(xù)的會(huì)話意圖。 其目的是盡量減少設(shè)備所需資源， 同時(shí)努力確保服務(wù)等級(jí)的可靠性和某種程度上的保證。

MQTT的目標(biāo)是小型設(shè)備的大型網(wǎng)絡(luò)， 這些設(shè)備需要在互聯(lián)網(wǎng)的后端服務(wù)器上進(jìn)行監(jiān)控。 它不是為設(shè)備間傳輸設(shè)計(jì)的， 也不是為許多接收機(jī)“多播”數(shù)據(jù)而設(shè)計(jì)的。 使用MQTT的應(yīng)用程序有時(shí)是緩慢的， 因?yàn)樵谶@種情況下，“實(shí)時(shí)”的定義通常以秒計(jì)量。

MQTT 與 CoAP 的簡要對(duì)比

MQTT 的發(fā)布/訂閱模型很好， 這種體系結(jié)構(gòu)的優(yōu)點(diǎn)已經(jīng)得到證明。 在 IETF 最新的RFC中， CoAP 引入了對(duì)發(fā)布/訂閱的支持。CoAP 的輕型有效負(fù)載非常適合無線傳感器網(wǎng)絡(luò)。傳感器MQTT網(wǎng)絡(luò)已經(jīng)采納并復(fù)制了這個(gè)想法。

兩個(gè)主要的物聯(lián)網(wǎng)專用協(xié)議互相借鑒。 但這兩個(gè)協(xié)議是否是主流？ 尚需時(shí)間檢驗(yàn)。

物聯(lián)網(wǎng)協(xié)議的選擇

連接傳感器和事物對(duì)象打開了一個(gè)全新的世界， 這些應(yīng)用場景將決定何時(shí)為應(yīng)用使用怎樣的協(xié)議。

這些協(xié)議的層位置都是相似的。 除了 HTTP 之外， 所有這些協(xié)議都被定位為實(shí)時(shí)發(fā)布/訂閱的物聯(lián)網(wǎng)協(xié)議， 支持?jǐn)?shù)百萬的設(shè)備。 根據(jù)如何定義“實(shí)時(shí)”（秒、毫秒或微秒）和“事物”（WSN 節(jié)點(diǎn)、多媒體設(shè)備、個(gè)人可穿戴設(shè)備、醫(yī)療掃描儀、引擎控制等） ， 對(duì)產(chǎn)品的協(xié)議選擇至關(guān)重要。 從根本上講， 這些協(xié)議是非常不同的。

在設(shè)計(jì)系統(tǒng)時(shí)， 需要做的是非常精確地定義系統(tǒng)需求， 并選擇正確的協(xié)議來解決問題。 網(wǎng)絡(luò)協(xié)議是一個(gè)載體，可以像Web 一樣封裝物聯(lián)網(wǎng)的許多協(xié)議。

一旦協(xié)議或協(xié)議集被認(rèn)為滿足應(yīng)用的部署、管理和支持， 就應(yīng)該理解每個(gè)協(xié)議的最佳實(shí)現(xiàn)。 鑒于此， 設(shè)計(jì)需要為系統(tǒng)選擇每個(gè)協(xié)議的最佳實(shí)現(xiàn)， 然后從這些協(xié)議中選擇系統(tǒng)的最佳協(xié)議實(shí)現(xiàn)。

協(xié)議選擇問題與協(xié)議的實(shí)現(xiàn)密切相關(guān)， 而支持協(xié)議的組件在最終設(shè)計(jì)中往往是必不可少的。 這使得這個(gè)決定非常復(fù)雜。 部署、操作、管理和安全的所有方面都必須被視為包括實(shí)現(xiàn)環(huán)境在內(nèi)的協(xié)議選擇因素。

為了滿足具有少內(nèi)存、低帶寬、高延遲的物聯(lián)網(wǎng)設(shè)備的需求，面向互聯(lián)網(wǎng)的物聯(lián)網(wǎng)協(xié)議已有很多。 圖6 提供了這些協(xié)議給物聯(lián)網(wǎng)帶來的性能效益的另一個(gè)總結(jié)。

此外， 對(duì)于特定的應(yīng)用程序沒有任何統(tǒng)一的標(biāo)準(zhǔn)， 這些標(biāo)準(zhǔn)通常是由市場選擇的。 作為一個(gè)開發(fā)者， 利用環(huán)境的特定特性， 滿足系統(tǒng)的要求， 這反過來又依賴于協(xié)議的細(xì)節(jié)， 應(yīng)對(duì)未來的變化會(huì)變得非常困難。

協(xié)議棧的選擇與供應(yīng)商的關(guān)系

物聯(lián)網(wǎng)的高級(jí)協(xié)議具有多種特點(diǎn)， 提供了不同的功能。 大多數(shù)協(xié)議是由特定的供應(yīng)商開發(fā)的， 這些供應(yīng)商通常會(huì)推廣自己的協(xié)議選擇， 沒有明確地定義他們的假設(shè)， 而且忽略了其他的替代方案。 由于這個(gè)原因， 依靠供應(yīng)商信息來選擇物聯(lián)網(wǎng)協(xié)議是有問題的， 而且大多數(shù)已經(jīng)產(chǎn)生的比較都不足以理解權(quán)衡。

物聯(lián)網(wǎng)協(xié)議常常綁定到業(yè)務(wù)模型。 有時(shí)這些協(xié)議是不完整的和 / 或用于支持現(xiàn)有的業(yè)務(wù)模式和方法。 有些時(shí)候， 它們提供了一個(gè)更完整的解決方案， 但是對(duì)于較小的傳感器來說， 資源需求是不可接受的。 此外， 沒有明確說明使用議定書背后的關(guān)鍵假設(shè)， 因此難以進(jìn)行比較。

物聯(lián)網(wǎng)應(yīng)用的基本假設(shè)如下：

將使用各種無線連接

設(shè)備從微型單片機(jī)到高性能系統(tǒng)都有， 重點(diǎn)是小型的 MCU

安全是核心要求

數(shù)據(jù)將存儲(chǔ)在云中， 并可能在云中處理

需要將連接到云存儲(chǔ)

需要通過無線和有線連接將信息傳送到云存儲(chǔ)中

其他假設(shè)需要更深入的調(diào)查， 并將對(duì)他們的選擇需要深入了解。 通過查看這些協(xié)議的主要特點(diǎn)， 并審視關(guān)鍵的實(shí)現(xiàn)要求， 設(shè)計(jì)者可以更清楚地了解在協(xié)議領(lǐng)域和支持特性領(lǐng)域需要什么， 以改進(jìn)其設(shè)計(jì)。

協(xié)議選擇中的關(guān)鍵特性

物聯(lián)網(wǎng)通信是基于 Internet tcp / udp 協(xié)議和相關(guān)的互聯(lián)網(wǎng)協(xié)議。 對(duì)于基本的通信， 這意味著要么 UDP 數(shù)據(jù)包的 TCP 流套接字。 小型設(shè)備的開發(fā)者聲稱 UDP 在性能和尺寸方面有很大的優(yōu)勢， 這反過來會(huì)減少成本。 雖然這是真的， 但在很多情況下它并不重要。

盡管Stream Socket 受到性能的影響， 但它們確實(shí)保證了所有數(shù)據(jù)的有序傳輸。 在167mhz 的 STM32F4上傳輸傳感器數(shù)據(jù)的性能受到影響， 不到16.7% （用2kb 的數(shù)據(jù)包測量）。 通過采用流套接字的方法， 也可以使用標(biāo)準(zhǔn)安全協(xié)議來簡化環(huán)境（盡管如果可用的話， DTLS 可以與 UDP 一起使用）。

類似地， 增加20 KB 的閃存和8kb 內(nèi)存升級(jí)到 TCP 的內(nèi)存成本差異通常很小。 對(duì)于大量的微型應(yīng)用和傳感器來說， 這可能是有意義的， 但通常不會(huì)影響 ARM Cortex-M3的設(shè)計(jì)， 也不會(huì)影響其他架構(gòu)， 如 RX， PIC32和 ARM Cortex-Ax。

消息模型

信息傳遞通用物聯(lián)網(wǎng)的方法非常重要， 許多協(xié)議已經(jīng)遷移到一個(gè)發(fā)布/訂閱模型。 由于許多節(jié)點(diǎn)連接和斷開， 而且這些節(jié)點(diǎn)需要連接到云中的各種應(yīng)用程序， 因此， 發(fā)布/訂閱請(qǐng)求 / 響應(yīng)模型具有優(yōu)勢。 它對(duì)隨機(jī)的開/關(guān)操作作出動(dòng)態(tài)響應(yīng)， 并能支持多節(jié)點(diǎn)。

CoAP 和 HTTP都是基于請(qǐng)求響應(yīng)的，而沒采用發(fā)布/訂閱方法（CoAP在新的RFC中已引入）。 在 CoAP 的情況下， 使用6LoWPAN 和IPv6的自動(dòng)地址被用來唯一地識(shí)別節(jié)點(diǎn)。 在HTTP的例子中， 這種方法是不同的， 因?yàn)檎?qǐng)求可以是任何東西， 包括發(fā)布請(qǐng)求或者訂閱請(qǐng)求， 所以事實(shí)上，這種方式的設(shè)計(jì)是一般情況。 今天， 這些協(xié)議被合并以提供一個(gè)完整的發(fā)布/訂閱請(qǐng)求 / 響應(yīng)模型。

拓?fù)浼軜?gòu)

系統(tǒng)架構(gòu)是多種多樣的， 包括CS、樹或星、總線和 P2P。 大多數(shù)人使用CS， 但也有人使用總線和 P2P 方法。 星狀結(jié)構(gòu)是一種樹的方法。 對(duì)于這些拓?fù)浼軜?gòu)， 性能問題通常存在于 P2P 和總線體系結(jié)構(gòu)中。 模擬或原型方法在設(shè)計(jì)的早期需被采納， 以防止意外發(fā)生。

可伸縮性

可伸縮性取決于在字段中添加多個(gè)節(jié)點(diǎn)， 并增加云資源以服務(wù)這些新的節(jié)點(diǎn)。 不同的架構(gòu)有不同的特性，對(duì)于客戶端服務(wù)器架構(gòu)來說， 增加可用服務(wù)器的池是容易的。 對(duì)于總線和 P2P 架構(gòu)， 規(guī)模在架構(gòu)中是固有的， 但是沒有云服務(wù)。 對(duì)于與樹或星相連接的架構(gòu)來說， 可能存在與在樹上增加額外的葉子有關(guān)的問題， 這會(huì)加重通信節(jié)點(diǎn)的負(fù)擔(dān)。

可伸縮性的另一個(gè)方面是處理大量不斷變化的節(jié)點(diǎn)， 并將這些節(jié)點(diǎn)與云應(yīng)用程序聯(lián)系起來。 正如所討論的， 發(fā)布/訂閱請(qǐng)求 / 響應(yīng)系統(tǒng)是為了可伸縮性， 因?yàn)樾枰幚沓鲇诟鞣N原因離線的節(jié)點(diǎn)， 這些節(jié)點(diǎn)允許應(yīng)用在決定訂閱和請(qǐng)求數(shù)據(jù)時(shí)接收特定數(shù)據(jù)， 從而實(shí)現(xiàn)精細(xì)的數(shù)據(jù)流量控制。 不健壯的方法也不能很好地?cái)U(kuò)展。

自修復(fù)性

低功耗和無損網(wǎng)絡(luò)是有節(jié)點(diǎn)層級(jí)移動(dòng)的。 這種動(dòng)態(tài)行為可能會(huì)影響網(wǎng)絡(luò)的整體， 所以協(xié)議是為多路徑動(dòng)態(tài)重構(gòu)設(shè)計(jì)的。 在 ZigBee、 ZigBee IP （使用6LoWPAN）和 6LoWPAN 中發(fā)現(xiàn)的動(dòng)態(tài)路由協(xié)議確保了網(wǎng)絡(luò)的適應(yīng)性。 如果沒有這些特性， 處理這些節(jié)點(diǎn)就會(huì)變成一個(gè)不連續(xù)的操作， 使得節(jié)點(diǎn)的資源需求更高。

資源需求

隨著應(yīng)用數(shù)量的增加， 資源需求是關(guān)鍵。 微控制器以非常低的成本處理上面列出的問題。 有些協(xié)議過于資源密集， 不適用于小的節(jié)點(diǎn)。 除非包括大量的閃存或其他存儲(chǔ)介質(zhì)， 否則不連續(xù)操作和大數(shù)據(jù)存儲(chǔ)將受到限制。 隨著資源的增加， 為了減少整個(gè)系統(tǒng)的成本， 可能需要添加聚合節(jié)點(diǎn)，來提供額外的共享存儲(chǔ)資源。

互操作性

互操作性對(duì)于未來的大多數(shù)設(shè)備來說是必不可少的。 迄今為止， 已經(jīng)看到了一系列的點(diǎn)解決方案， 但最終用戶希望傳感器和設(shè)備能夠協(xié)同工作。 通過使用一套標(biāo)準(zhǔn)化的協(xié)議和標(biāo)準(zhǔn)化的消息， 設(shè)備可以與支持它們的云服務(wù)分開。 這種方法可以提供完整的設(shè)備互操作性。 此外， 使用智能發(fā)布/訂閱選項(xiàng)， 不同的設(shè)備甚至可以使用相同的云服務(wù)， 并提供不同的功能。 使用開放的方法， 應(yīng)用標(biāo)準(zhǔn)將會(huì)出現(xiàn)， 但目前還沒有。

安全性

使用標(biāo)準(zhǔn)信息安全解決方案是大多數(shù)提供安全性的協(xié)議核心安全機(jī)制。 這些安全辦法的基礎(chǔ)是：

TLS

PSec/VPN

SSH

SFTP

SecurebootloaderandautomaTIcfallback

Filtering

HTTPS

SNMPv3

Encryptionanddecryption

DTLS（forUDP-onlysecurity）

由于這些技術(shù)已使用多年， 因此將安全作為一攬子計(jì)劃的一部分至關(guān)重要。

協(xié)議選擇時(shí)的實(shí)施考量

隱私是一個(gè)必不可少的實(shí)現(xiàn)要求，幾乎所有系統(tǒng)都需要對(duì)云進(jìn)行安全通信， 以確保個(gè)人數(shù)據(jù)無法被訪問或修改。 此外， 云中顯示的設(shè)備和數(shù)據(jù)的管理需要單獨(dú)管理。 如果沒有這個(gè)功能， 用戶的關(guān)鍵個(gè)人信息就不能得到適當(dāng)?shù)谋Ｗo(hù)， 任何有管理權(quán)限的人都可以獲得。

管理平臺(tái)一般還包括：

系統(tǒng)初始化

遠(yuǎn)程字段服務(wù)選項(xiàng)（如字段升級(jí)、重置為默認(rèn)參數(shù)和遠(yuǎn)程測試）

控制帳戶用途（例如帳戶禁用、帳戶啟用及帳單功能）

為防盜目的而進(jìn)行控制（相當(dāng)于把設(shè)備弄壞）

考慮到這種類型的體系結(jié)構(gòu)， 還有一些附加的協(xié)議和程序需要考慮：

自定義開發(fā)的云系統(tǒng)管理應(yīng)用程序

Snmp 管理的傳感器節(jié)點(diǎn)集合

云計(jì)算集成程序

運(yùn)行的 SQLite 來存儲(chǔ)和有選擇地更新數(shù)據(jù)到云

計(jì)費(fèi)是商業(yè)系統(tǒng)的一個(gè)重要方面。 電信運(yùn)營商已經(jīng)證明， 包月模式是最佳的收入選擇。 此外， 自動(dòng)化服務(wù)的選擇和集成對(duì)于無縫計(jì)費(fèi)也很重要。 此外， 信用卡依賴性也會(huì)產(chǎn)生問題， 包括超過限額的問題， 過期的信用卡和被刪除的賬戶。

用戶自服務(wù)也是實(shí)現(xiàn)成功的關(guān)鍵。 這包括遠(yuǎn)程現(xiàn)場服務(wù)， 這樣設(shè)備就不會(huì)返回工廠， 智能或自動(dòng)配置， 在線幫助， 社區(qū)幫助和非常直觀的產(chǎn)品都是關(guān)鍵。

應(yīng)用集成也很重要。 如今， 點(diǎn)系統(tǒng)占據(jù)了主導(dǎo)地位， 但是未來的關(guān)鍵將是使傳感器可以用于用戶選擇的廣泛應(yīng)用。 準(zhǔn)確性和可靠性可以對(duì)結(jié)果應(yīng)用結(jié)果產(chǎn)生重大影響， 一旦出現(xiàn)標(biāo)準(zhǔn)接口， 預(yù)計(jì)將在這一領(lǐng)域開展競爭。 通過服務(wù)器的間接訪問可以確保安全性、沒有應(yīng)用程序更改的進(jìn)化和計(jì)費(fèi)控制。

不連續(xù)的操作和大數(shù)據(jù)是緊密相連的。 隨著設(shè)備的隨機(jī)連接和斷開， 需要為傳感器保存數(shù)據(jù)并在稍后更新云計(jì)算。 由于電力和成本的原因， 存儲(chǔ)限制是存在的。 如果某些數(shù)據(jù)是關(guān)鍵的， 它可以在其他數(shù)據(jù)被丟棄的時(shí)候被保存。 所有的數(shù)據(jù)都可以保存下來， 并選擇性地更新以后執(zhí)行的云。 處理數(shù)據(jù)的算法可以運(yùn)行在云或傳感器或任何中間節(jié)點(diǎn)。 所有這些選項(xiàng)都給傳感器、云、通信和外部應(yīng)用帶來了特殊的挑戰(zhàn)。

多連接傳感器訪問也是一個(gè)需求， 使傳感器真正可用于一系列廣泛的應(yīng)用程序。 這種連接最有可能通過服務(wù)器進(jìn)行， 以簡化傳感器并消除重復(fù)消息的功率需求。

綜上所述，許多協(xié)議都被吹捧為物聯(lián)網(wǎng)（IoT）的理想解決方案。 通常正確的協(xié)議選擇會(huì)被那些在他們的產(chǎn)品中有既得利益的供應(yīng)商所掩蓋。 用戶必須了解他們的具體要求和限制， 并有一個(gè)精確的系統(tǒng)規(guī)范， 以確保為各種管理、應(yīng)用程序和通信功能選擇正確的協(xié)議， 并確保所有的實(shí)現(xiàn)規(guī)范都得到滿足。