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

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

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

Consumer versus industrial 消費者 vs 工業

Web services 網絡服務

IoT services 物聯網服務

Publish/subscribe 發布/訂閱

Request/response 請求/響應

。。。。。。

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

圖1 IoT（M2M）的一般系統架構

面向接口的設計，被業界廣泛的接受，引申到系統的層面，大約是面向協議的設計， 對協議的認知是設計的基礎。

互聯網協議棧

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

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

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

圖2 OSI 模型簡要

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

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

互聯網中常用的物理層和數據鏈路層協議有：

Ethernet （10 Mbps， 100 Mbps， 1 Gbps）

Wi-Fi （802.11b/g/n）

點對點協議（PPP）

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

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

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

傳輸層

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

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

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

用于物聯網的無線協議

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

從計算機網絡演進的IoT無線協議

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

圖3 Thread 協議的主要組件

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

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

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

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

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

遠距離的IoT無線協議

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

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

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

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

圖4 NB-IoT E2E solution　

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

圖5 LPWAN 的解決方案

其他的那些常見協議

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

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

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

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

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

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

可應用在物聯網中的互聯網高層協議

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

HTTP

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

WebSocket

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

XMPP

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

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

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

面向物聯網的高層協議

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

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

CoAP

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

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

CoAP 的特點：

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

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

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

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

MQTT

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

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

MQTT 與 CoAP 的簡要對比

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

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

物聯網協議的選擇

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

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

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

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

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

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

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

協議棧的選擇與供應商的關系

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

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

物聯網應用的基本假設如下：

將使用各種無線連接

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

安全是核心要求

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

需要將連接到云存儲

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

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

協議選擇中的關鍵特性

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

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

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

消息模型

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

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

拓撲架構

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

可伸縮性

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

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

自修復性

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

資源需求

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

互操作性

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

安全性

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

TLS

PSec/VPN

SSH

SFTP

Securebootloaderandautomaticfallback

Filtering

HTTPS

SNMPv3

Encryptionanddecryption

DTLS（forUDP-onlysecurity）

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

協議選擇時的實施考量

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

管理平臺一般還包括：

系統初始化

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

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

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

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

自定義開發的云系統管理應用程序

Snmp 管理的傳感器節點集合

云計算集成程序

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

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

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

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

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

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

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