對于使用傳感器和保持連接性的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é)議棧上有多個應(yīng)用層協(xié)議， 每種協(xié)議都有自己的優(yōu)勢和限制，了解這些可以幫助開發(fā)者為產(chǎn)品做出最好的設(shè)計選擇。 在選擇物聯(lián)網(wǎng)協(xié)議時， 帶寬要求、實時性能和內(nèi)存占用是主要的約束條件。

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

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

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

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

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

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

。。。。。。

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

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

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

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

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

相對而言， 物聯(lián)網(wǎng)是讓電子設(shè)備通過互聯(lián)網(wǎng)交換信息。 但是這些設(shè)備還不能像瀏覽器和社交媒體那樣來促進交流。 物聯(lián)網(wǎng)也不同于網(wǎng)絡(luò)，因為物聯(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）

點對點協(xié)議（PPP）

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

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

網(wǎng)絡(luò)層是互聯(lián)網(wǎng)生存的地方。 互聯(lián)網(wǎng)之所以被命名， 是因為它提供了網(wǎng)絡(luò)之間、物理層之間的連接。 這就是我們找到無處不在 IP 地址的地方。

傳輸層

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NB-IOT聚焦于低功耗廣覆蓋（LPWA）物聯(lián)網(wǎng)（IOT）市場，是一種可在全球范圍內(nèi)廣泛應(yīng)用的新興技術(shù)。其具有覆蓋廣、連接多、速率低、成本低、功耗低、架構(gòu)優(yōu)等特點。NB-IOT使用授權(quán)頻段，可采取帶內(nèi)、保護帶或獨立載波三種部署方式，與現(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ò)部署拓撲布局可以根據(jù)具體應(yīng)用和和場景設(shè)計部署方案。 例如，LoRa適合于通信頻次低，數(shù)據(jù)量不大的應(yīng)用。

圖5 LPWAN 的解決方案

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

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

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

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

與此同時， Z-Wave 只在800-900 MHz 頻帶上運行，仍然得到了超過375個組織的支持。

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

另一個在 Linux 基金會內(nèi)部運行的協(xié)議是 IoTivity， 它專注于提高互操作性和定義物聯(lián)網(wǎng)的連接需求。 它使用一個通用的通信框架， 管理個人計算機和新興物聯(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 是常用的標準， 以及負載中的 XML或 JSON。

HTTP

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

WebSocket

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

XMPP

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

XMPP 的優(yōu)勢在于地址、安全性和可伸縮性，成為面向消費者物聯(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)， 因為物聯(lián)網(wǎng)設(shè)備應(yīng)該盡可能的便宜， 并且運行協(xié)議棧的同時使用最小能力的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é)點網(wǎng)絡(luò)。 與 HTTP 一樣， CoAP 也具有 RESTful操作資源和資源標識符的能力。

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

CoAP 的特點：

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

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

所有的標題、方法和狀態(tài)代碼都是二進制編碼， 可以減少協(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 時具有連續(xù)的會話意圖。 其目的是盡量減少設(shè)備所需資源， 同時努力確保服務(wù)等級的可靠性和某種程度上的保證。

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

MQTT 與 CoAP 的簡要對比

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

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

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

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

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

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

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

協(xié)議選擇問題與協(xié)議的實現(xiàn)密切相關(guān)， 而支持協(xié)議的組件在最終設(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)帶來的性能效益的另一個總結(jié)。

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

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

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

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

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

將使用各種無線連接

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

安全是核心要求

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

需要將連接到云存儲

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

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

協(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ù)據(jù)的有序傳輸。 在167mhz 的 STM32F4上傳輸傳感器數(shù)據(jù)的性能受到影響， 不到16.7% （用2kb 的數(shù)據(jù)包測量）。 通過采用流套接字的方法， 也可以使用標準安全協(xié)議來簡化環(huán)境（盡管如果可用的話， DTLS 可以與 UDP 一起使用）。

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

消息模型

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

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

拓撲架構(gòu)

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

可伸縮性

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

可伸縮性的另一個方面是處理大量不斷變化的節(jié)點， 并將這些節(jié)點與云應(yīng)用程序聯(lián)系起來。 正如所討論的， 發(fā)布/訂閱請求 / 響應(yīng)系統(tǒng)是為了可伸縮性， 因為需要處理出于各種原因離線的節(jié)點， 這些節(jié)點允許應(yīng)用在決定訂閱和請求數(shù)據(jù)時接收特定數(shù)據(jù)， 從而實現(xiàn)精細的數(shù)據(jù)流量控制。 不健壯的方法也不能很好地擴展。

自修復性

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

資源需求

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

互操作性

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

安全性

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

TLS

PSec/VPN

SSH

SFTP

Securebootloaderandautomaticfallback

Filtering

HTTPS

SNMPv3

Encryptionanddecryption

DTLS（forUDP-onlysecurity）

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

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

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

管理平臺一般還包括：

系統(tǒng)初始化

遠程字段服務(wù)選項（如字段升級、重置為默認參數(shù)和遠程測試）

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

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

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

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

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

云計算集成程序

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

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

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

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

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

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

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