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

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

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

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

Web services 網絡服務

IoT services 物聯(lián)網服務

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

Request/response 請求/響應

。。。。。。

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

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

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

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

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

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

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

圖2 OSI 模型簡要

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

下三層：物理層、數據鏈路層 和網絡層

互聯(lián)網中常用的物理層和數據鏈路層協(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.*等，甚至城域網乃至其他廣域網的相關協(xié)議也紛紛被引入， 后面單獨進行理解。

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

傳輸層

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

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

當決定如何將數據從“事物”本地網絡轉移到一個 IP 網絡時， 可以通過網關將兩個網絡連接起來， 或者可以把這個功能構建在“事物”本身上。 許多微控制器（MCUs）現在都有一個以太網控制器， 這使得這個任務更加容易。

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

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

從計算機網絡演進的IoT無線協(xié)議

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

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

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

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

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

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

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

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

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

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

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

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

圖4 NB-IoT E2E solution　

在非授權頻段，也有應用于IoT的相關無線協(xié)議。對應于NB-IoT，LP-WAN在非授權頻譜中的協(xié)議主要有LoRa、SigFox等技術。網絡部署拓撲布局可以根據具體應用和和場景設計部署方案。 例如，LoRa適合于通信頻次低，數據量不大的應用。

圖5 LPWAN 的解決方案

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

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

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

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

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

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

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

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

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

HTTP

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

WebSocket

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

XMPP

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

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

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

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

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

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

CoAP

雖然網絡基礎設施對物聯(lián)網設備來說是可用的， 但是對于大多數物聯(lián)網應用來說還是太重了。 2013年7月， IETF 發(fā)布了 CoAP， 用于低功耗節(jié)點網絡。 與 HTTP 一樣， CoAP 也具有 RESTful操作資源和資源標識符的能力。

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

CoAP 的特點：

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

請求和響應在 CoAP 消息上異步交換（與使用現有 TCP 連接的 HTTP 不同）

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

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

MQTT

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

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

MQTT 與 CoAP 的簡要對比

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

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

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

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

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

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

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

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

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

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

協(xié)議棧的選擇與供應商的關系

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

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

物聯(lián)網應用的基本假設如下：

將使用各種無線連接

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

安全是核心要求

數據將存儲在云中， 并可能在云中處理

需要將連接到云存儲

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

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

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

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

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

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

消息模型

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

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

拓撲架構

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

可伸縮性

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

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

自修復性

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

資源需求

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

互操作性

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

安全性

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

TLS

PSec/VPN

SSH

SFTP

Securebootloaderandautomaticfallback

Filtering

HTTPS

SNMPv3

Encryptionanddecryption

DTLS（forUDP-onlysecurity）

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

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

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

管理平臺一般還包括：

系統(tǒng)初始化

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

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

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

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

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

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

云計算集成程序

運行的 SQLite 來存儲和有選擇地更新數據到云

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

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

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

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

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

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