對于使用傳感器和保持連接性的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 請求/響應(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ì),， 對協(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)用, 以及其他流行的社交媒體,。

相對而言, 物聯(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)對點(diǎn)協(xié)議(PPP)

• GSM, 3G, 4G, LTE 3G, 4G, LTE

但是對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ù)包的重傳, 以及流量控制。 但是對于IoT系統(tǒng)而言, TCP 可能有點(diǎn)重。 因此, 盡管 UDP 長期以來一直被降級到DNS和 DHCP等網(wǎng)絡(luò)服務(wù), 現(xiàn)在已經(jīng)在傳感器采集和遠(yuǎn)程控制領(lǐng)域占據(jù)了一席之地,。 如果需要對數(shù)據(jù)進(jìn)行某種類型的管理, 甚至可以在 UDP 之上編寫自己的輕量級協(xié)議, 以避免 TCP的開銷,。

對于語音和視頻等實(shí)時(shí)數(shù)據(jù)應(yīng)用, UDP 比 TCP 可能更適合。 TCP 的數(shù)據(jù)包確認(rèn)和重傳功能對于這些應(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ù), 但是對始終擁有對連接性的需求,，這要求我們不僅對無線方法做出選擇, 還要選擇相應(yīng)的通信協(xié)議,。 因此, 不同的協(xié)議都在試圖建立為從邊緣節(jié)點(diǎn)向云服務(wù)提供數(shù)據(jù)通信的基礎(chǔ)。 每種協(xié)議都希望被看作是對某些類型的數(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 的最大競爭對手, 但是 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ò)相對于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ì)相對簡單, 成本效益較高,。 

由于 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ù)。

對于電信運(yùn)營商而言,，車聯(lián)網(wǎng),、智慧醫(yī)療、智能家居等物聯(lián)網(wǎng)應(yīng)用將產(chǎn)生海量連接,，遠(yuǎn)遠(yuǎn)超過人與人之間的通信需求,。基于蜂窩的窄帶物聯(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)平滑升級,。

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é)議,。對應(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)盟因此受到了批評,。

和 ZigBee 一樣, ZigBee Pro 是一個(gè)相對較新的規(guī)范,。 這種網(wǎng)格網(wǎng)絡(luò)協(xié)議顯然對物聯(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 基金會內(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 基金會內(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ù)器的連接, 但無法接收連接請求時(shí), 它會更安全; 一般不希望外部機(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í)通訊和存儲信息, 并且已經(jīng)擴(kuò)展到語音和視頻通話、協(xié)作,、輕量級中間件,、內(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è)施對物聯(lián)網(wǎng)設(shè)備來說是可用的, 但是對于大多數(shù)物聯(lián)網(wǎng)應(yīng)用來說還是太重了,。 2013年7月, IETF 發(fā)布了 CoAP, 用于低功耗節(jié)點(diǎn)網(wǎng)絡(luò),。 與 HTTP 一樣, CoAP 也具有 RESTful操作資源和資源標(biāo)識符的能力。

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

CoAP 的特點(diǎn):

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

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

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

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

MQTT

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

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 的簡要對比

MQTT 的發(fā)布/訂閱模型很好, 這種體系結(jié)構(gòu)的優(yōu)點(diǎn)已經(jīng)得到證明,。 在 IETF 最新的RFC中, CoAP 引入了對發(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é)議的選擇

連接傳感器和事物對象打開了一個(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ī)療掃描儀,、引擎控制等) , 對產(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é),。

圖6 | 物聯(lián)網(wǎng)的網(wǎng)絡(luò)協(xié)議比較

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

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

物聯(lián)網(wǎng)的高級協(xié)議具有多種特點(diǎn), 提供了不同的功能,。 大多數(shù)協(xié)議是由特定的供應(yīng)商開發(fā)的, 這些供應(yīng)商通常會推廣自己的協(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è)更完整的解決方案, 但是對于較小的傳感器來說, 資源需求是不可接受的,。 此外, 沒有明確說明使用議定書背后的關(guān)鍵假設(shè), 因此難以進(jìn)行比較。

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

• 將使用各種無線連接

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

• 安全是核心要求

• 數(shù)據(jù)將存儲在云中, 并可能在云中處理

• 需要將連接到云存儲

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

其他假設(shè)需要更深入的調(diào)查, 并將對他們的選擇需要深入了解,。 通過查看這些協(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é)議。 對于基本的通信, 這意味著要么 UDP 數(shù)據(jù)包的 TCP 流套接字,。 小型設(shè)備的開發(fā)者聲稱 UDP 在性能和尺寸方面有很大的優(yōu)勢, 這反過來會減少成本,。 雖然這是真的, 但在很多情況下它并不重要。

盡管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)存升級到 TCP 的內(nèi)存成本差異通常很小,。 對于大量的微型應(yīng)用和傳感器來說, 這可能是有意義的, 但通常不會影響 ARM Cortex-M3的設(shè)計(jì), 也不會影響其他架構(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ā)布/訂閱請求 / 響應(yīng)模型具有優(yōu)勢,。 它對隨機(jī)的開/關(guān)操作作出動(dòng)態(tài)響應(yīng), 并能支持多節(jié)點(diǎn),。

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

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

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

可伸縮性

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

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

自修復(fù)性

低功耗和無損網(wǎng)絡(luò)是有節(jié)點(diǎn)層級移動(dòng)的,。 這種動(dòng)態(tài)行為可能會影響網(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)就會變成一個(gè)不連續(xù)的操作, 使得節(jié)點(diǎn)的資源需求更高,。

資源需求

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

互操作性

互操作性對于未來的大多數(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)將會出現(xiàn), 但目前還沒有,。 

安全性

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

· TLS

· IPSec / VPN

· SSH

· SFTP

· Secure bootloader and automatic fallback

· Filtering

· HTTPS

· SNMP v3

· Encryption and decryption

· DTLS (for UDP-only security)

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

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

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

管理平臺一般還包括:

• 系統(tǒng)初始化

• 遠(yuǎn)程字段服務(wù)選項(xiàng)(如字段升級,、重置為默認(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 來存儲和有選擇地更新數(shù)據(jù)到云

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

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

應(yīng)用集成也很重要。 如今, 點(diǎn)系統(tǒng)占據(jù)了主導(dǎo)地位, 但是未來的關(guān)鍵將是使傳感器可以用于用戶選擇的廣泛應(yīng)用,。 準(zhǔn)確性和可靠性可以對結(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ì)算。 由于電力和成本的原因, 存儲限制是存在的,。 如果某些數(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é)議選擇會被那些在他們的產(chǎn)品中有既得利益的供應(yīng)商所掩蓋,。 用戶必須了解他們的具體要求和限制, 并有一個(gè)精確的系統(tǒng)規(guī)范, 以確保為各種管理、應(yīng)用程序和通信功能選擇正確的協(xié)議, 并確保所有的實(shí)現(xiàn)規(guī)范都得到滿足,。