無線物聯(lián)網(wǎng)中coap協(xié)議的研究與實現(xiàn)

1、無線物聯(lián)網(wǎng)中 CoAP 協(xié)議的研究與實現(xiàn)，張 熒，作者：引言物聯(lián)網(wǎng)是在互聯(lián)網(wǎng)的基礎(chǔ)上延伸和擴展的一種網(wǎng)絡(luò)，其用戶端延伸和擴展到了任何物品之間，彼此進行信息交換和通信，目的是實現(xiàn)所有物品與網(wǎng)絡(luò)的連接，從而方便識別、管理和控制。無線物聯(lián)網(wǎng)的特點包括：全面感知、實時準確傳遞物品信息、利用智能計算技術(shù)對海量數(shù)據(jù)進行分析和處理，以實現(xiàn)智能化控制。由于無線物聯(lián)網(wǎng)中的設(shè)備很多都是資源受限型的，這些設(shè)備量的內(nèi)存空間和有限的計算能力。為此，IETF(emet Engineering Task Force)的 CoRE(Constrained RESTfulEnvironment)工作組為受限節(jié)點制定相關(guān)的 RE

2、ST(Represenional Se Transfer)形式的應(yīng)用層協(xié)議。這就是 CoRE 工作組正在制訂的 CoAP(Constrained Application Protocol)協(xié)議。1.6LoN 協(xié)議棧由于 TCPIP 協(xié)議棧不適用于資源受限的設(shè)備，因此提出了一種 6LoN(IPv6 overLower Wirelessal Area Networks)協(xié)議棧。CoAP 是 6LoN 協(xié)議棧中的應(yīng)802154 標準用層協(xié)議。6LoN 使 IPv6 可用于低功耗的有損網(wǎng)絡(luò)，它是基于 IEEE的。6LoN 協(xié)議棧如圖 1 所示。CoAP UDPIPv6 層IPv66LoN 適配層 80

3、2.15.4MAC802.15.4PHY圖 1協(xié)議棧的下兩層用 802154 PHYMAC，中間加一個 IPv6-6LoN 適配層，傳輸層使用 UDP 協(xié)議，應(yīng)用層使用 CoAP 協(xié)議。它包括 REST 的最小子集和到 HTTP 的無狀態(tài)映 射。通信主機使用 CoAP 協(xié)議，能夠支持穩(wěn)定的通信架構(gòu)，以實現(xiàn)傳感器節(jié)點與互聯(lián)網(wǎng)的無線連接。2.CoAP 協(xié)議在 2010 年 3 月，CoRE 工作組開始制定 CoAP 協(xié)議，到目前為止，該協(xié)議還沒有定稿。CoAP 協(xié)議是為物聯(lián)網(wǎng)中資源受限設(shè)備制定的應(yīng)用層協(xié)議。它是一種面向網(wǎng)絡(luò)的協(xié)議，采用了與 HTTP 類似的特征，內(nèi)容為資源抽象、REST 式交互以及

4、可擴展的頭選項等。應(yīng)用程序通過 URI 標識來獲取服務(wù)器上的資源，即可以像 HTTP 協(xié)議對資源進行GET、PUT、T 和 DELETE 等操作。CoAP 協(xié)議具有如下特點：(1)報頭壓縮：CoAP 包含一個緊湊的二進制報頭和擴展報頭。它只有短短的 4 B 的基本報頭，基本報頭后面跟擴展選項。一個典型的請求報頭為 1020 B。圖 2 是 CoAP 協(xié)議的信息格式。圖 2 CoAP 協(xié)議的信息格式報頭部分各字段的含義如下：V(Ver)表示 CoAP 協(xié)議的版本號；T(Type)表示消息的信息類型；OC(Option Count)表示頭后面的可選的選項數(shù)量；Code 表示消息的類型：請求消息、響

5、應(yīng)消息，或者是空消息；Message ID 表示消息，用于重復消息檢測、匹配消息類型等。(2)方法和 URIs：為了實現(xiàn)客戶端服務(wù)器上的資源，CoAP 支持 GET、PUT、T和 DELETE 等方法。CoAP 還支持 URIs，這是 Web 架構(gòu)的主要特點。(3)傳輸層使用 UDP 協(xié)議：CoAP 協(xié)議是建立在 UDP 協(xié)議之上，以減少開銷和支持組播功能。它也支持一個簡單的停止和等待的可靠性傳輸機制。(4)支持異步通信：HTTP 對 M2M(Machine-to-Machine)通信不適用，這是由于事務(wù)總是由客戶端發(fā)起。而 CoAP 協(xié)議支持異步通信，這對 M2M 通信應(yīng)用來說是常見的休眠喚

6、醒機制。(5)支持資源發(fā)現(xiàn)：為了的發(fā)現(xiàn)和使用資源，它支持內(nèi)置的資源發(fā)現(xiàn)格式，用于發(fā)現(xiàn)設(shè)備上的資源列表，或者用于設(shè)備向服務(wù)目錄公告自己的資源。它支持 RFC5785 中的格式，在 CoRE 中用wellknowncore 的路徑表示資源描述。(6)支持緩存：CoAP 協(xié)議支持資源描述的緩存以優(yōu)化其性能。(7) 訂閱機制：CoAP 使用異步通信方式，用訂閱機制實現(xiàn)從服務(wù)器到客戶端的消息推送。實現(xiàn) CoAP 的發(fā)布，訂閱機制，它是請求成功后自動的一種資源后處理程序。是由默認的 EVENT_和 PERIODIC_RESOUR來進行配置的。它們的事件和輪詢處理程序用ESTnotify_subscri b

7、ers()函數(shù)來發(fā)布。01234567890123456789012345678901VTOCCodeMessage IDPayload(if any)Options(if any)2.1 CoAP 協(xié)議棧圖 3 是 CoAP 協(xié)議棧。CoAP 協(xié)議的傳輸層使用 UDP 協(xié)議。由于 UDP 傳輸?shù)牟豢煽啃裕?CoAP 協(xié)議采用了雙層結(jié)構(gòu)，定義了帶有重傳的事務(wù)處理機制，并且提供資源發(fā)現(xiàn)和資源描述等功能。CoAP 采用盡可能小的載荷，從而限制了分片。Request/ResponseCoAPTranionUDP6LoN圖 3 CoAP 協(xié)議棧事務(wù)層(Tranion layer)用于處理節(jié)點之間的信息

8、交換，同時提供組播和擁塞控制等功能。請求響應(yīng)層(RequestResponselayer)用于傳輸對資源進行操作的請求和響應(yīng)信息。CoAP 協(xié)議的 REST 構(gòu)架是基于該層的通信。CoAP 的雙層處理方式，使得 CoAP 沒有采用 TCP 協(xié)議，也可以提供可靠的傳輸機制。利用默認的定時器和指數(shù)增長的重傳間隔時間實現(xiàn) CON(Confirmable)消息的重傳，直到接收方發(fā)出確認消息。另外，CoAP 的雙層處理方式支持異步通信，這是物聯(lián)網(wǎng)和 M2M 應(yīng)用的關(guān)鍵需求之一。2.2 CoAP 的訂閱機制HTTP 的請求響應(yīng)機制是假設(shè)事務(wù)都是由客戶端發(fā)起的，通常叫做拉模型。這導致客戶端不能高效的中，設(shè)備

9、都是無線低功耗的，這些設(shè)備大部分時間是休眠狀態(tài)，因此不能響應(yīng)輪詢請求。而 CoRE 認為支持本地的推送模型是一個重要的需求，也就是由服務(wù)器初始化事務(wù)到客戶端。推送模型需要一個訂閱接口，用來請求響應(yīng)關(guān)于特定資源的改變。而由于 UDP 的傳輸是異步的，所以不需要特殊消息。訂閱機制如圖 4 所示。CoAPserverCoAPc ntCON(tid=125)GET/light lifetime=60s/light changesACK(tid=125)200 OK”.”CON(tid=430)GET/light “.”ACK(tid=430)/light changesCON(tid=431)200

10、OK/light”.”ACK(tid=431)圖 4 訂閱機制圖2.3 CoAP 的交互模型CoAP 使用類似于 HTTP 的請求響應(yīng)模型：CoAP 終端節(jié)點作為客戶端向服務(wù)器發(fā)送一個或多個請求，服務(wù)器端回復客戶端的 CoAP 請求。不同于 HTTP，CoAP 的請求和響應(yīng)在發(fā)送之前不需要事先建立連接，而是通過 CoAP 信息來進行異步信息交換。CoAP 協(xié)議使用 UD P 進行傳輸。這是通過信息層選項的可靠性來實現(xiàn)的。CoAP 定義了四種類型的信息：可證實的 CON(Confirmable)信息，不可證實的(-Confirmable)信息，可確認的 ACK(Acknowledgement)信

11、息和重置信息 RST(Reset)。方法代碼和響應(yīng)代碼包含在這些信息中，實現(xiàn)請求和響應(yīng)功能。這四種類型信息對于請求響應(yīng)的交互來說是透明的。CoAP 的請求響應(yīng)語義包含在 CoAP 信息中，其中分別包含方法代碼和響應(yīng)代碼。CoA P 選項中包含可選的(或默認的)請求和響應(yīng)信息，例如 URI 和負載內(nèi)容類型。令牌選項用于獨立匹配底層的請求到響應(yīng)信息。請求響應(yīng)模型：請求包含在可證實的或不可證實的信息中，如果服務(wù)器端是立即可用的，它對請求的應(yīng)答包含在可證實的確認信息中來進行應(yīng)答。圖 5 是基本的 GET 請求和響應(yīng)模式，其中圖 5(a)表示成功發(fā)送請求和收到 ACK 確認信息，圖 5(b)表示重傳了請

12、求信息，然后才收到 ACK 確認信息。CoAPclCoAPserverCON(tid=123)GET/lightACK(tid=123)200 OK”(a)成功發(fā)送請求和收到 ACK 確認信息CoAPclCoAPclCON(tid=124)GET/humidit yCON(tid=124)GET/humidityTimeoutCON(tid=124)OK”.”(b)重傳了請求信息才收到 ACK 確認信息圖 5 典型CoAP 信息交換雖然 CoAP 協(xié)議目前還在制定當中，但 Contiki 和 TinyOS操作系統(tǒng)已經(jīng)支持CoAP 協(xié)議。Contiki 是一個多任務(wù)操作系統(tǒng)，并帶有 uIPv6

13、協(xié)議棧，適用于系統(tǒng)和無線傳感器網(wǎng)絡(luò)，它占用系統(tǒng)資源小，適用于資源受限的網(wǎng)絡(luò)和設(shè)備。目前，火狐瀏覽器已經(jīng)集成了 Copper 插件，從而實現(xiàn)了 CoAP 協(xié)議。但是這種方式只能傳感器節(jié)點上的實時數(shù)據(jù)，而不能查看各種歷史數(shù)據(jù)。為此，在 Contiki 系統(tǒng)的基礎(chǔ)上，基于 uIPv6START KIT 無線網(wǎng)絡(luò)開發(fā)套件，用自己編寫的客戶端程序?qū)崿F(xiàn)了和數(shù)據(jù)庫的交互，把歷史數(shù)據(jù)存入數(shù)據(jù)庫中，從而在 Web 瀏覽器端不僅可以還能查看歷史數(shù)據(jù)，以便于分析問題。傳感器節(jié)點上的實時數(shù)據(jù)，3. 實臺及 CoAP 協(xié)議3.1 實驗硬件式是美信公司的 IPv6 智能網(wǎng)關(guān)(MXG300)、MX231CC 節(jié)點、USB

14、無線網(wǎng)卡(STICK)和 JTAG器。實驗的硬件配置和硬件如圖 6，圖 7 所示。程序。是WinAVR 和 AVRstudio，用于向節(jié)點和 USB 網(wǎng)卡中MXG300STICK服務(wù)器圖 6 實驗的硬件配置圖 7 硬件其中 IPv6 智能網(wǎng)關(guān)上的主要有：BCM 6358UKFBG 支持多用戶以太網(wǎng)功能，具有高度優(yōu)化的 32 MIPS CPU 和標準的 EJTAG 調(diào)試器；BCM53 25EKQMG 集成了 5 個收發(fā)器，具有 128 KB 的數(shù)據(jù)包緩沖區(qū)，最多可以支持 2K 的 MAC 地址，支持地址自動學習，提供真正的即插即用連接，而且是低功耗的；SIGe2521A60 提供 2425 GH

15、z 的無線工作頻段范圍，應(yīng)用于 ISM 24GHz 的無線解決方案。圖 8 是 IPv6 智能無線網(wǎng)關(guān)的接口布局，它是基于 OPENWRT 系統(tǒng)定制完成的。具備 3 個局域網(wǎng)口，1 個廣域網(wǎng)口，1 個 80211abg WiFi 無線網(wǎng)絡(luò)接口，1 個標準 USB 口和 1 個可選的串口調(diào)試口。該智能無線網(wǎng)關(guān)除具備通用無線路由器的功能以外，還可以實現(xiàn)基于 Contiki 操作系統(tǒng)的 USB UIP 網(wǎng)絡(luò)和普通 IP 網(wǎng)絡(luò)之間的 IPv6 互連，同時還支持有能力的系統(tǒng)在 OPENWRT 的基礎(chǔ)上開發(fā)自己的應(yīng)用包，實現(xiàn)更復雜的應(yīng)用。MX231CCMX231CC802.15.4MX231CCPCB 正

16、面RXTXGNDVCCRESET開關(guān)電源LAN1LAN2LAN3WANUSBNCNCNCVLAN1.0(LAN1-LAN3) VLAN1.1圖 8 網(wǎng)關(guān)接口布局OPENWRT 是一個開源的 Linux 版本。主要應(yīng)用于 Contiki 系統(tǒng)，它提供宏定義和 RESTful 網(wǎng)絡(luò)服務(wù)實例。系統(tǒng)。網(wǎng)關(guān)和節(jié)點上同時裝有MX231CC 節(jié)點上的主要是 ATmega1284P，它具有 128 KB 的可編程閃存，4 KB 的E2PROM，16 KB 的片內(nèi) SRAM，JTAG 接口，優(yōu)化的功耗和處理速度。節(jié)點上運行 Contiki系統(tǒng)。節(jié)點上還有光敏傳感器、室內(nèi)溫度傳感器、三色 LED 指示燈等。3.2

17、 CoAP 協(xié)議的火狐瀏覽器實現(xiàn)(BS 架構(gòu))BS 架構(gòu)的系統(tǒng)結(jié)構(gòu)如圖 9 所示。用戶瀏覽器用戶瀏覽器HTTPCoAPIPv6智能網(wǎng)關(guān)Web服務(wù)器用戶瀏覽器用戶瀏覽器用戶瀏覽器用戶瀏覽器圖 9 B/S 架構(gòu)系統(tǒng)結(jié)構(gòu)圖系統(tǒng)由用戶瀏覽器、Web 服務(wù)器、IPv6 智能網(wǎng)關(guān)、MX231CC 節(jié)點組成。用戶瀏覽器通過 HTTP 協(xié)議Web 服務(wù)器，MX231CC 節(jié)點通過 CoAP 協(xié)議和 IPv6 智能網(wǎng)關(guān)進行通信，從而實現(xiàn)用戶瀏覽器節(jié)點上資源的功能。圖 9 中實線表示有線連接，虛線表示無線連接。在當前的 Contiki 25 中，集成了 CoAP 03 和 CoAP06 這兩個版本。這兩個文件在C

18、ontiki 25 的 apps 目錄下，關(guān)于 CoAP 的分為：內(nèi)容都在這兩個文件中。程序的主要部RJ11#if WITH_COAP = = 3#include “coap-0.3.h” #elif WITH_COAP = = 6#include “coap-0.6.h”進行 CoAP 的版本選擇；/*/PROS(coap_sle,”CoAP Sle”);AUTOSTART_PRO/*SES(&coap_sle);*/Char temp100; PERIODIC_RESOURCE(light,METHOD_GET,”light”,”title=”Periodiclight);rt=”O(jiān)bse

19、rvable”;l*CLOCK_SECOND);PROS(coap_sle,”CoAP_Sle”);一個名為 coap_sle 的進程；AUTOSTART_PRO程序；SES(&coap_sle)這個進程需要自啟動，即當節(jié)點啟動時啟動本PERIODIC_RESOURCE()為進程的主體部分。然后進行編譯，編譯成elf 文件，用 JTAG器到節(jié)點上。節(jié)點地址設(shè)置為：2001：2：11：22ff：fe33：4499。這時，用火狐瀏覽器自帶 coap 插件，如果用其他瀏覽器，那么需要進行 coap 的節(jié)點，因為火狐瀏覽器設(shè)置。以控制節(jié)點上的三色 LED 燈反轉(zhuǎn)為例，用下面的請求格式：GETcoap：/：/readings其中 mote_ip_address 是節(jié)點的 IPv6 地址，port_number 是節(jié)點的端，readings是客戶端請求的資源(溫度)。所以在瀏覽器地址欄輸入：coap：/2001：2：11：22e33：4499：61616/toggle，作用是讓節(jié)點上的三色 LED 燈進行反轉(zhuǎn)。服務(wù)器端的響應(yīng)信息如圖 10 所示。圖 10 服務(wù)器的響應(yīng)信息從瀏覽器端可以看出，CoAP 協(xié)議支持 Discover 和 Observe 功能，具有 GET、T、PUT 和 DELETE 等方法。Type 表示信息類型為 ACK，Code 為 200，表示成功完