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

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

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

相對(duì)而言, 物聯(lián)網(wǎng)是讓電子設(shè)備通過(guò)互聯(lián)網(wǎng)交換信息。 但是這些設(shè)備還不能像瀏覽器和社交媒體那樣來(lái)促進(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ǔ)。 在這里，上三層被分組在一起以簡(jiǎn)化模型。

   圖2 OSI 模型簡(jiǎn)要

我們需要從IoT的角度來(lái)快速理解一下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而言，采用的無(wú)線協(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ò)之間、物理層之間的連接。 這就是我們找到無(wú)處不在 IP 地址的地方。

傳輸層

在 IP 之上, 互聯(lián)網(wǎng)有兩個(gè)傳輸協(xié)議——TCP和UDP。 TCP 用于網(wǎng)絡(luò)中的交互(電子郵件、網(wǎng)頁(yè)瀏覽等) , 甚至被認(rèn)為 是傳輸層中唯一的協(xié)議。 TCP 提供了邏輯連接的概念, 傳輸包的確認(rèn), 丟失數(shù)據(jù)包的重傳, 以及流量控制。 但是對(duì)于IoT系統(tǒng)而言, TCP 可能有點(diǎn)重。 因此, 盡管 UDP 長(zhǎng)期以來(lái)一直被降級(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ì)于語(yǔ)音和視頻等實(shí)時(shí)數(shù)據(jù)應(yīng)用, UDP 比 TCP 可能更適合。 TCP 的數(shù)據(jù)包確認(rèn)和重傳功能對(duì)于這些應(yīng)用可能是無(wú)用的開銷。 如果一段數(shù)據(jù)(比如一段口語(yǔ)音頻)沒有及時(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í), 可以通過(guò)網(wǎng)關(guān)將兩個(gè)網(wǎng)絡(luò)連接起來(lái), 或者可以把這個(gè)功能構(gòu)建在"事物"本身上。 許多微控制器(MCUs)現(xiàn)在都有一個(gè)以太網(wǎng)控制器, 這使得這個(gè)任務(wù)更加容易。

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

雖然大部分物聯(lián)網(wǎng)依賴于傳統(tǒng)的嵌入式開發(fā)技術(shù), 但是對(duì)始終擁有對(duì)連接性的需求，這要求我們不僅對(duì)無(wú)線方法做出選擇, 還要選擇相應(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無(wú)線協(xié)議

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

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

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

BLE 可能是Thread Group 的最大競(jìng)爭(zhēng)對(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é)議競(jìng)爭(zhēng)。受益于多年來(lái)不斷增強(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 所使用的低功耗無(wú)線個(gè)人區(qū)域網(wǎng)(6LoWPAN)的是互補(bǔ)的, 因?yàn)楹髢煞N網(wǎng)絡(luò)是明確為處理能力有限、數(shù)據(jù)率低、射頻輸出功率極低、電源或電池耗電量極低的設(shè)備。 這將使設(shè)備和網(wǎng)絡(luò)設(shè)計(jì)相對(duì)簡(jiǎn)單, 成本效益較高。 

由于 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)的增長(zhǎng) , 很多協(xié)議顯然要建立自己的空間, 也許在特定的應(yīng)用程序中找準(zhǔn)自己的位置。

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

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

對(duì)于電信運(yùn)營(yíng)商而言，車聯(lián)網(wǎng)、智慧醫(yī)療、智能家居等物聯(lián)網(wǎng)應(yīng)用將產(chǎn)生海量連接，遠(yuǎn)遠(yuǎn)超過(guò)人與人之間的通信需求?；诜涓C的窄帶物聯(lián)網(wǎng)（Narrow Band Internet of Things, NB-IoT）成為萬(wàn)物互聯(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）市場(chǎng)，是一種可在全球范圍內(nèi)廣泛應(yīng)用的新興技術(shù)。其具有覆蓋廣、連接多、速率低、成本低、功耗低、架構(gòu)優(yōu)等特點(diǎn)。NB-IOT使用授權(quán)頻段，可采取帶內(nèi)、保護(hù)帶或獨(dú)立載波三種部署方式，與現(xiàn)有網(wǎng)絡(luò)共存。

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

圖4 NB-IoT E2E solution　（源自百度百科）

在非授權(quán)頻段，也有應(yīng)用于IoT的相關(guān)無(wú)線協(xié)議。對(duì)應(yīng)于NB-IoT，LP-WAN在非授權(quán)頻譜中的協(xié)議主要有LoRa、SigFox等技術(shù)。網(wǎng)絡(luò)部署拓?fù)洳季挚梢愿鶕?jù)具體應(yīng)用和和場(chǎ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è)最新版本包含了多年來(lái)所有過(guò)往的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 無(wú)需授權(quán)的頻譜中運(yùn)行。 使用擴(kuò)頻調(diào)制方法, 可以超過(guò)16個(gè)通道, 除廣播傳輸選項(xiàng)外, 還支持星狀拓?fù)洹?和大多數(shù)物聯(lián)網(wǎng)節(jié)點(diǎn)應(yīng)用一樣, 節(jié)約能源是首要考慮因素, 因此協(xié)議滿足通過(guò)各種機(jī)電、光或運(yùn)動(dòng)方法獲取能量的無(wú)電池的設(shè)備。

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

在 Linux 基金會(huì)內(nèi)部, 有 AllJoyn 框架的 AllSeen 聯(lián)盟。 Alljoyn 是一個(gè)開源、協(xié)作軟件框架, 允許開發(fā)者為物聯(lián)網(wǎng)編寫應(yīng)用程序, 無(wú)論品牌、類別、傳輸媒介和操作系統(tǒng), 都可以為物聯(lián)網(wǎng)編寫應(yīng)用程序, 而無(wú)需使用云計(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 的最安全且簡(jiǎn)單的方法是只包含一個(gè)客戶端, 而不是服務(wù)器。 換句話說(shuō), 當(dāng)物聯(lián)網(wǎng)設(shè)備能夠啟動(dòng)與網(wǎng)絡(luò)服務(wù)器的連接, 但無(wú)法接收連接請(qǐng)求時(shí), 它會(huì)更安全; 一般不希望外部機(jī)器訪問裝有物聯(lián)網(wǎng)設(shè)備的本地網(wǎng)絡(luò)。

WebSocket

Websocket 是一個(gè)協(xié)議, 通過(guò)一個(gè)單一的 TCP 連接提供全雙工通信, 通過(guò)這種連接可以在客戶端和服務(wù)器之間發(fā)送消息。 它是HTML5規(guī)范的一部分。 Websocket 標(biāo)準(zhǔn)簡(jiǎ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ò)展到語(yǔ)音和視頻通話、協(xié)作、輕量級(jí)中間件、內(nèi)容聚合和 XML 數(shù)據(jù)的廣義路由。 它能夠大規(guī)模管理消費(fèi)者產(chǎn)品，如洗衣機(jī)、烘干機(jī)、冰箱等等。

XMPP 的優(yōu)勢(shì)在于地址、安全性和可伸縮性，成為面向消費(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è)備來(lái)說(shuō)是可用的, 但是對(duì)于大多數(shù)物聯(lián)網(wǎng)應(yīng)用來(lái)說(shuō)還是太重了。 2013年7月, IETF 發(fā)布了 CoAP, 用于低功耗節(jié)點(diǎn)網(wǎng)絡(luò)。 與 HTTP 一樣, CoAP 也具有 RESTful操作資源和資源標(biāo)識(shí)符的能力。

CoAP 與 HTTP 語(yǔ)義對(duì)齊, 甚至有一對(duì)一的 HTTP 映射。 網(wǎng)絡(luò)設(shè)備受到較小的MCU約束, 只有少量的閃存和 RAM, 而對(duì)局部網(wǎng)絡(luò)的限制是高數(shù)據(jù)包錯(cuò)誤率和低吞吐量(幾十kb/秒)。 對(duì)于在電池或能量采集元件上運(yùn)行的設(shè)備來(lái)說(shuō), 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é)議分析器來(lái)debug網(wǎng)絡(luò)問題。
• 充分考慮到這是一種極其輕微的協(xié)議, 其行為類似于永久連接。 它對(duì) HTTP 語(yǔ)義很類似, 并且是 RESTful 的。 如果有網(wǎng)絡(luò)編程背景, 使用 CoAP 是相對(duì)容易的。

MQTT

MQTT是針對(duì)受限設(shè)備和低帶寬、高延遲或不可靠網(wǎng)絡(luò)開發(fā)和優(yōu)化的開源協(xié)議。 它是一種發(fā)布/訂閱傳輸模型, 非常輕便, 非常適合將小型設(shè)備與帶寬小的網(wǎng)絡(luò)連接起來(lái)。 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 的簡(jiǎn)要對(duì)比

MQTT 的發(fā)布/訂閱模型很好, 這種體系結(jié)構(gòu)的優(yōu)點(diǎn)已經(jīng)得到證明。 在 IETF 最新的RFC中, CoAP 引入了對(duì)發(fā)布/訂閱的支持。CoAP 的輕型有效負(fù)載非常適合無(wú)線傳感器網(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)用場(chǎng)景將決定何時(shí)為應(yīng)用使用怎樣的協(xié)議。

這些協(xié)議的層位置都是相似的。 除了 HTTP 之外, 所有這些協(xié)議都被定位為實(shí)時(shí)發(fā)布/訂閱的物聯(lián)網(wǎng)協(xié)議, 支持?jǐn)?shù)百萬(wàn)的設(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é)議來(lái)解決問題。 網(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)帶來(lái)的性能效益的另一個(gè)總結(jié)。

此外, 對(duì)于特定的應(yīng)用程序沒有任何統(tǒng)一的標(biāo)準(zhǔn), 這些標(biāo)準(zhǔn)通常是由市場(chǎng)選擇的。 作為一個(gè)開發(fā)者, 利用環(huán)境的特定特性, 滿足系統(tǒng)的要求, 這反過(guò)來(lái)又依賴于協(xié)議的細(xì)節(jié), 應(yīng)對(duì)未來(lái)的變化會(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)商信息來(lái)選擇物聯(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ì)于較小的傳感器來(lái)說(shuō), 資源需求是不可接受的。 此外, 沒有明確說(shuō)明使用議定書背后的關(guān)鍵假設(shè), 因此難以進(jìn)行比較。

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

• 將使用各種無(wú)線連接
• 設(shè)備從微型單片機(jī)到高性能系統(tǒng)都有, 重點(diǎn)是小型的 MCU
• 安全是核心要求
• 數(shù)據(jù)將存儲(chǔ)在云中, 并可能在云中處理
• 需要將連接到云存儲(chǔ)
• 需要通過(guò)無(wú)線和有線連接將信息傳送到云存儲(chǔ)中

其他假設(shè)需要更深入的調(diào)查, 并將對(duì)他們的選擇需要深入了解。 通過(guò)查看這些協(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)勢(shì), 這反過(guò)來(lái)會(huì)減少成本。 雖然這是真的, 但在很多情況下它并不重要。

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

類似地, 增加20 KB 的閃存和8kb 內(nèi)存升級(jí)到 TCP 的內(nèi)存成本差異通常很小。 對(duì)于大量的微型應(yīng)用和傳感器來(lái)說(shuō), 這可能是有意義的, 但通常不會(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)勢(shì)。 它對(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)地址被用來(lái)唯一地識(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)來(lái)說(shuō), 增加可用服務(wù)器的池是容易的。 對(duì)于總線和 P2P 架構(gòu), 規(guī)模在架構(gòu)中是固有的, 但是沒有云服務(wù)。 對(duì)于與樹或星相連接的架構(gòu)來(lái)說(shuō), 可能存在與在樹上增加額外的葉子有關(guān)的問題, 這會(huì)加重通信節(jié)點(diǎn)的負(fù)擔(dān)。

可伸縮性的另一個(gè)方面是處理大量不斷變化的節(jié)點(diǎn), 并將這些節(jié)點(diǎn)與云應(yīng)用程序聯(lián)系起來(lái)。 正如所討論的, 發(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ú)損網(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é)議過(guò)于資源密集, 不適用于小的節(jié)點(diǎn)。 除非包括大量的閃存或其他存儲(chǔ)介質(zhì), 否則不連續(xù)操作和大數(shù)據(jù)存儲(chǔ)將受到限制。 隨著資源的增加, 為了減少整個(gè)系統(tǒng)的成本, 可能需要添加聚合節(jié)點(diǎn)，來(lái)提供額外的共享存儲(chǔ)資源。

互操作性

互操作性對(duì)于未來(lái)的大多數(shù)設(shè)備來(lái)說(shuō)是必不可少的。 迄今為止, 已經(jīng)看到了一系列的點(diǎn)解決方案, 但最終用戶希望傳感器和設(shè)備能夠協(xié)同工作。 通過(guò)使用一套標(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ù)無(wú)法被訪問或修改。 此外, 云中顯示的設(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)程測(cè)試)
• 控制帳戶用途(例如帳戶禁用、帳戶啟用及帳單功能)
• 為防盜目的而進(jìn)行控制(相當(dāng)于把設(shè)備弄壞)

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

• 自定義開發(fā)的云系統(tǒng)管理應(yīng)用程序
• Snmp 管理的傳感器節(jié)點(diǎn)集合
• 云計(jì)算集成程序
• 運(yùn)行的 SQLite 來(lái)存儲(chǔ)和有選擇地更新數(shù)據(jù)到云

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

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

應(yīng)用集成也很重要。 如今, 點(diǎn)系統(tǒng)占據(jù)了主導(dǎo)地位, 但是未來(lái)的關(guān)鍵將是使傳感器可以用于用戶選擇的廣泛應(yīng)用。 準(zhǔn)確性和可靠性可以對(duì)結(jié)果應(yīng)用結(jié)果產(chǎn)生重大影響, 一旦出現(xiàn)標(biāo)準(zhǔn)接口, 預(yù)計(jì)將在這一領(lǐng)域開展競(jìng)爭(zhēng)。 通過(guò)服務(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ù)都可以保存下來(lái), 并選擇性地更新以后執(zhí)行的云。 處理數(shù)據(jù)的算法可以運(yùn)行在云或傳感器或任何中間節(jié)點(diǎn)。 所有這些選項(xiàng)都給傳感器、云、通信和外部應(yīng)用帶來(lái)了特殊的挑戰(zhàn)。

多連接傳感器訪問也是一個(gè)需求, 使傳感器真正可用于一系列廣泛的應(yīng)用程序。 這種連接最有可能通過(guò)服務(wù)器進(jìn)行, 以簡(jiǎ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ī)范都得到滿足。

【本文來(lái)自51CTO專欄作者“老曹”的原創(chuàng)文章，作者微信公眾號(hào)：喔家ArchiSelf,id:wrieless-com】

戳這里，看該作者更多好文