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

摘要：由于物聯(lián)網(wǎng)中的很多設(shè)備都是資源受限型的，即只有少量的內(nèi)存空間和有限的計(jì)算能力，所以傳統(tǒng)的HTTP協(xié)議應(yīng)用在物聯(lián)網(wǎng)上就顯得過(guò)于龐大而不適用。IETF的CoRE工作組提出了一種基于REST架構(gòu)的CoAP協(xié)議。CoAP是6LowPAN協(xié)議棧中的應(yīng)用層協(xié)議。該文在詳細(xì)介紹了CoAP協(xié)議的內(nèi)容、特點(diǎn)和交互模型后，在uIPv6 START KIT無(wú)線網(wǎng)絡(luò)開(kāi)發(fā)套件上，使用Contiki嵌入式操作系統(tǒng)，不僅在瀏覽器端實(shí)現(xiàn)了CoAP協(xié)議而且用自己編寫(xiě)的客戶端程序?qū)崿F(xiàn)了CoAP協(xié)議，增加了和數(shù)據(jù)庫(kù)之間的交互功能，從而實(shí)現(xiàn)了在Web界面上不僅可以查看實(shí)時(shí)數(shù)據(jù)，還可以查看歷史數(shù)據(jù)的功能。
關(guān)鍵詞：物聯(lián)網(wǎng)；6LoWPAN；CoAP；Contiki

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

1 6LoWPAN協(xié)議棧
    由于TCP／IP協(xié)議棧不適用于資源受限的設(shè)備，因此提出了一種6LoWPAN(IPv6 over Low power Wireless Personal Area Networks)協(xié)議棧。CoAP是6LoWPAN協(xié)議棧中的應(yīng)用層協(xié)議。6LoWPAN使IPv6可用于低功耗的有損網(wǎng)絡(luò)，它是基于IEEE 802．15．4標(biāo)準(zhǔn)的。6LoWPAN協(xié)議棧如圖1所示。

    協(xié)議棧的下兩層用802．15．4 PHY／MAC，中間加一個(gè)IPv6-6LoWPAN適配層，傳輸層使用UDP協(xié)議，應(yīng)用層使用CoAP協(xié)議。它包括REST的最小子集和到HTTP的無(wú)狀態(tài)映射。通信主機(jī)使用CoAP協(xié)議，能夠支持穩(wěn)定的通信架構(gòu)，以實(shí)現(xiàn)傳感器節(jié)點(diǎn)與互聯(lián)網(wǎng)的無(wú)線連接。

2 CoAP協(xié)議
    在2010年3月，CoRE工作組開(kāi)始制定CoAP協(xié)議，到目前為止，該協(xié)議還沒(méi)有定稿。CoAP協(xié)議是為物聯(lián)網(wǎng)中資源受限設(shè)備制定的應(yīng)用層協(xié)議。它是一種面向網(wǎng)絡(luò)的協(xié)議，采用了與HTTP類似的特征，核心內(nèi)容為資源抽象、REST式交互以及可擴(kuò)展的頭選項(xiàng)等。應(yīng)用程序通過(guò)URI標(biāo)識(shí)來(lái)獲取服務(wù)器上的資源，即可以像HTTP協(xié)議對(duì)資源進(jìn)行GET、PUT、POST和DELETE等操作。CoAP協(xié)議具有如下特點(diǎn)：
    (1)報(bào)頭壓縮：CoAP包含一個(gè)緊湊的二進(jìn)制報(bào)頭和擴(kuò)展報(bào)頭。它只有短短的4 B的基本報(bào)頭，基本報(bào)頭后面跟擴(kuò)展選項(xiàng)。一個(gè)典型的請(qǐng)求報(bào)頭為10～20 B。圖2是CoAP協(xié)議的信息格式。

    報(bào)頭部分各字段的含義如下：V(Version)表示CoAP協(xié)議的版本號(hào)；T(Type)表示消息的信息類型；OC(Option Count)表示頭后面的可選的選項(xiàng)數(shù)量；Code表示消息的類型：請(qǐng)求消息、響應(yīng)消息，或者是空消息；Message ID表示消息編號(hào)，用于重復(fù)消息檢測(cè)、匹配消息類型等。
    (2)方法和URIs：為了實(shí)現(xiàn)客戶端訪問(wèn)服務(wù)器上的資源，CoAP支持GET、PUT、POST和DELETE等方法。CoAP還支持URIs，這是Web架構(gòu)的主要特點(diǎn)。
    (3)傳輸層使用UDP協(xié)議：CoAP協(xié)議是建立在UDP協(xié)議之上，以減少開(kāi)銷和支持組播功能。它也支持一個(gè)簡(jiǎn)單的停止和等待的可靠性傳輸機(jī)制。
    (4)支持異步通信：HTTP對(duì)M2M(Machine-to-Machine)通信不適用，這是由于事務(wù)總是由客戶端發(fā)起。而CoAP協(xié)議支持異步通信，這對(duì)M2M通信應(yīng)用來(lái)說(shuō)是常見(jiàn)的休眠／喚醒機(jī)制。
    (5)支持資源發(fā)現(xiàn)：為了自主的發(fā)現(xiàn)和使用資源，它支持內(nèi)置的資源發(fā)現(xiàn)格式，用于發(fā)現(xiàn)設(shè)備上的資源列表，或者用于設(shè)備向服務(wù)目錄公告自己的資源。它支持RFC5785中的格式，在CoRE中用／．well—known／core的路徑表示資源描述。
    (6)支持緩存：CoAP協(xié)議支持資源描述的緩存以優(yōu)化其性能。
    (7)訂閱機(jī)制：CoAP使用異步通信方式，用訂閱機(jī)制實(shí)現(xiàn)從服務(wù)器到客戶端的消息推送。實(shí)現(xiàn)CoAP的發(fā)布，訂閱機(jī)制，它是請(qǐng)求成功后自動(dòng)注冊(cè)的一種資源后處理程序。是由默認(rèn)的EVENT_和PERIODIC_RESOURCEs來(lái)進(jìn)行配置的。它們的事件和輪詢處理程序用EST．notify_subscri bers()函數(shù)來(lái)發(fā)布。
2．1 CoAP協(xié)議棧
    圖3是CoAP協(xié)議棧。CoAP協(xié)議的傳輸層使用UDP協(xié)議。由于UDP傳輸?shù)牟豢煽啃?，CoAP協(xié)議采用了雙層結(jié)構(gòu)，定義了帶有重傳的事務(wù)處理機(jī)制，并且提供資源發(fā)現(xiàn)和資源描述等功能。CoAP采用盡可能小的載荷，從而限制了分片。

    事務(wù)層(Transaction layer)用于處理節(jié)點(diǎn)之間的信息交換，同時(shí)提供組播和擁塞控制等功能。請(qǐng)求／響應(yīng)層(Request／Responselayer)用于傳輸對(duì)資源進(jìn)行操作的請(qǐng)求和響應(yīng)信息。CoAP協(xié)議的REST構(gòu)架是基于該層的通信。CoAP的雙層處理方式，使得CoAP沒(méi)有采用TCP協(xié)議，也可以提供可靠的傳輸機(jī)制。利用默認(rèn)的定時(shí)器和指數(shù)增長(zhǎng)的重傳間隔時(shí)間實(shí)現(xiàn)CON(Confirmable)消息的重傳，直到接收方發(fā)出確認(rèn)消息。另外，CoAP的雙層處理方式支持異步通信，這是物聯(lián)網(wǎng)和M2M應(yīng)用的關(guān)鍵需求之一。
2．2 CoAP的訂閱機(jī)制
    HTTP的請(qǐng)求／響應(yīng)機(jī)制是假設(shè)事務(wù)都是由客戶端發(fā)起的，通常叫做拉模型。這導(dǎo)致客戶端不能高效的知統(tǒng)中，設(shè)備都是無(wú)線低功耗的，這些設(shè)備大部分時(shí)間是休眠狀態(tài)，因此不能響應(yīng)輪詢請(qǐng)求。而CoRE認(rèn)為支持本地的推送模型是一個(gè)重要的需求，也就是由服務(wù)器初始化事務(wù)到客戶端。推送模型需要一個(gè)訂閱接口，用來(lái)請(qǐng)求響應(yīng)關(guān)于特定資源的改變。而由于UDP的傳輸是異步的，所以不需要特殊的通知消息。訂閱機(jī)制如圖4所示。

[!--empirenews.page--]
2．3 CoAP的交互模型
    CoAP使用類似于HTTP的請(qǐng)求／響應(yīng)模型：CoAP終端節(jié)點(diǎn)作為客戶端向服務(wù)器發(fā)送一個(gè)或多個(gè)請(qǐng)求，服務(wù)器端回復(fù)客戶端的CoAP請(qǐng)求。不同于HTTP，CoAP的請(qǐng)求和響應(yīng)在發(fā)送之前不需要事先建立連接，而是通過(guò)CoAP信息來(lái)進(jìn)行異步信息交換。CoAP協(xié)議使用UDP進(jìn)行傳輸。這是通過(guò)信息層選項(xiàng)的可靠性來(lái)實(shí)現(xiàn)的。CoAP定義了四種類型的信息：可證實(shí)的CON(Confirmable)信息，不可證實(shí)的NON(Non-Confirmable)信息，可確認(rèn)的ACK(Acknowledgement)信息和重置信息RST(Reset)。方法代碼和響應(yīng)代碼包含在這些信息中，實(shí)現(xiàn)請(qǐng)求和響應(yīng)功能。這四種類型信息對(duì)于請(qǐng)求／響應(yīng)的交互來(lái)說(shuō)是透明的。
    CoAP的請(qǐng)求／響應(yīng)語(yǔ)義包含在CoAP信息中，其中分別包含方法代碼和響應(yīng)代碼。CoAP選項(xiàng)中包含可選的(或默認(rèn)的)請(qǐng)求和響應(yīng)信息，例如URI和負(fù)載內(nèi)容類型。令牌選項(xiàng)用于獨(dú)立匹配底層的請(qǐng)求到響應(yīng)信息。
    請(qǐng)求／響應(yīng)模型：請(qǐng)求包含在可證實(shí)的或不可證實(shí)的信息中，如果服務(wù)器端是立即可用的，它對(duì)請(qǐng)求的應(yīng)答包含在可證實(shí)的確認(rèn)信息中來(lái)進(jìn)行應(yīng)答。圖5是基本的GET請(qǐng)求和響應(yīng)模式，其中圖5(a)表示成功發(fā)送請(qǐng)求和收到ACK確認(rèn)信息，圖5(b)表示重傳了請(qǐng)求信息，然后才收到ACK確認(rèn)信息。

    雖然CoAP協(xié)議目前還在制定當(dāng)中，但Contiki和TinyOS嵌入式操作系統(tǒng)已經(jīng)支持CoAP協(xié)議。Contiki是一個(gè)多任務(wù)操作系統(tǒng)，并帶有uIPv6協(xié)議棧，適用于嵌入式系統(tǒng)和無(wú)線傳感器網(wǎng)絡(luò)，它占用系統(tǒng)資源小，適用于資源受限的網(wǎng)絡(luò)和設(shè)備。目前，火狐瀏覽器已經(jīng)集成了Copper插件，從而實(shí)現(xiàn)了CoAP協(xié)議。但是這種方式只能讀取傳感器節(jié)點(diǎn)上的實(shí)時(shí)數(shù)據(jù)，而不能查看各種歷史數(shù)據(jù)。為此，在Contiki系統(tǒng)的基礎(chǔ)上，基于uIPv6START KIT無(wú)線網(wǎng)絡(luò)開(kāi)發(fā)套件，用自己編寫(xiě)的客戶端程序?qū)崿F(xiàn)了和數(shù)據(jù)庫(kù)的交互，把歷史數(shù)據(jù)存入數(shù)據(jù)庫(kù)中，從而在Web瀏覽器端不僅可以訪問(wèn)傳感器節(jié)點(diǎn)上的實(shí)時(shí)數(shù)據(jù)，還能查看歷史數(shù)據(jù)，以便于分析問(wèn)題。

3 實(shí)驗(yàn)平臺(tái)及CoAP協(xié)議的實(shí)現(xiàn)
3．1 實(shí)驗(yàn)平臺(tái)
    硬件平臺(tái)式是美信凌科公司的IPv6智能網(wǎng)關(guān)(MXG300)、MX231CC節(jié)點(diǎn)、USB無(wú)線網(wǎng)卡(STICK)和JTAG下載器。實(shí)驗(yàn)的硬件平臺(tái)配置和硬件平臺(tái)如圖6，圖7所示。軟件平臺(tái)是WinAVR和AVR studio，用于向節(jié)點(diǎn)和USB網(wǎng)卡中下載程序。

    其中IPv6智能網(wǎng)關(guān)上的主要芯片有：BCM 6358UKFBG支持多用戶以太網(wǎng)功能，具有高度優(yōu)化的32 MIPS CPU和標(biāo)準(zhǔn)的EJTAG調(diào)試器；BCM53 25EKQMG集成了5個(gè)收發(fā)器，具有128 KB的數(shù)據(jù)包緩沖區(qū)，最多可以支持2K的MAC地址，支持地址自動(dòng)學(xué)習(xí)，提供真正的即插即用連接，而且是低功耗的；SIGe2521A60提供2．4～2．5 GHz的無(wú)線工作頻段范圍，應(yīng)用于ISM 2．4．GHz的無(wú)線解決方案。[!--empirenews.page--]
    圖8是IPv6智能無(wú)線網(wǎng)關(guān)的接口布局，它是基于OPENWRT系統(tǒng)定制完成的。具備3個(gè)局域網(wǎng)口，1個(gè)廣域網(wǎng)口，1個(gè)802．11a／b／g WiFi無(wú)線網(wǎng)絡(luò)接口，1個(gè)標(biāo)準(zhǔn)USB口和1個(gè)可選的串口調(diào)試口。該智能無(wú)線網(wǎng)關(guān)除具備通用無(wú)線路由器的功能以外，還可以實(shí)現(xiàn)基于Contiki操作系統(tǒng)的USB UIP網(wǎng)絡(luò)和普通IP網(wǎng)絡(luò)之間的IPv6互連，同時(shí)還支持有能力的系統(tǒng)在OPENWRT的基礎(chǔ)上開(kāi)發(fā)自己的應(yīng)用軟件包，實(shí)現(xiàn)更復(fù)雜的應(yīng)用。

    OPENWRT是一個(gè)開(kāi)源的Linux版本。主要應(yīng)用于嵌入式系統(tǒng)。網(wǎng)關(guān)和節(jié)點(diǎn)上同時(shí)裝有Contiki系統(tǒng)，它提供宏定義和RESTful網(wǎng)絡(luò)服務(wù)實(shí)例。
    MX231CC節(jié)點(diǎn)上的主要芯片是ATmega1284P，它具有128 KB的可編程閃存，4 KB的E2PROM，16 KB的片內(nèi)SRAM，JTAG接口，優(yōu)化的功耗和處理速度。節(jié)點(diǎn)上運(yùn)行Contiki系統(tǒng)。節(jié)點(diǎn)上還有光敏傳感器、室內(nèi)溫度傳感器、三色LED指示燈等。
3．2 CoAP協(xié)議的火狐瀏覽器實(shí)現(xiàn)(B／S架構(gòu))
    B／S架構(gòu)的系統(tǒng)結(jié)構(gòu)如圖9所示。

    系統(tǒng)由用戶瀏覽器、Web服務(wù)器、IPv6智能網(wǎng)關(guān)、MX231CC節(jié)點(diǎn)組成。用戶瀏覽器通過(guò)HTTP協(xié)議訪問(wèn)Web服務(wù)器，MX231CC節(jié)點(diǎn)通過(guò)CoAP協(xié)議和IPv6智能網(wǎng)關(guān)進(jìn)行通信，從而實(shí)現(xiàn)用戶瀏覽器訪問(wèn)節(jié)點(diǎn)上資源的功能。圖9中實(shí)線表示有線連接，虛線表示無(wú)線連接。
    在當(dāng)前的Contiki 2．5中，集成了CoAP 03和CoAP06這兩個(gè)版本。這兩個(gè)文件在Contiki 2．5的apps目錄下，關(guān)于CoAP的核心內(nèi)容都在這兩個(gè)文件中。程序的主要部分為：

    AUTOSTART_PROCESSES(&coap_sample)這個(gè)進(jìn)程需要自啟動(dòng)，即當(dāng)節(jié)點(diǎn)啟動(dòng)時(shí)啟動(dòng)本程序；
    PERIODIC_RESOURCE()為進(jìn)程的主體部分。
    然后進(jìn)行編譯，編譯成．elf文件，用JTAG下載器下載到節(jié)點(diǎn)上。節(jié)點(diǎn)地址設(shè)置為：2001：2：：11：22ff：：fe33：4499。這時(shí)，用火狐瀏覽器訪問(wèn)節(jié)點(diǎn)，因?yàn)榛鸷鼮g覽器自帶coap插件，如果用其他瀏覽器，那么需要進(jìn)行coap的代理設(shè)置。以控制節(jié)點(diǎn)上的三色LED燈反轉(zhuǎn)為例，用下面的請(qǐng)求格式：
    GETcoap：／／[<mote_ip_address>]：<poa_number>／readings
    其中mote_ip_address是節(jié)點(diǎn)的IPv6地址，port_number是節(jié)點(diǎn)的端口號(hào)，readings是客戶端請(qǐng)求的資源(溫度)。
    所以在瀏覽器地址欄輸入：coap：／／[2001：2：：11：22ff：fe33：4499]：61616／toggle，作用是讓節(jié)點(diǎn)上的三色LED燈進(jìn)行反轉(zhuǎn)。服務(wù)器端的響應(yīng)信息如圖10所示。

    從瀏覽器端可以看出，CoAP協(xié)議支持Discover和Observe功能，具有GET、POST、PUT和DELETE等方法。Type表示信息類型為ACK，Code為200，表示成功完成客戶端的請(qǐng)求。事務(wù)ID為38 264，它用于重復(fù)信息檢測(cè)，options為1表示有一個(gè)可選項(xiàng)，內(nèi)容類型為text表示文本類型。
    由此可以看出，通過(guò)火狐瀏覽器的CoAP協(xié)議，可以訪問(wèn)節(jié)點(diǎn)上的傳感器資源。
3．3 CoAP協(xié)議的客戶端實(shí)現(xiàn)(C／S架構(gòu))
    上節(jié)通過(guò)火狐瀏覽器可以實(shí)現(xiàn)COAP協(xié)議，但是只能查看實(shí)時(shí)數(shù)據(jù)，不能查看歷史數(shù)據(jù)。為此，這里搭建了一個(gè)C／S架構(gòu)的環(huán)境。如圖11所示。

    圖11中客戶端軟件是用基于．NET架構(gòu)的C#語(yǔ)言編寫(xiě)的，數(shù)據(jù)庫(kù)使用SQL Server 2008。通過(guò)此程序，可以每隔10 s讀取一次數(shù)據(jù)，存入到數(shù)據(jù)庫(kù)中。并可以通過(guò)前臺(tái)的Web界面查看各種歷史數(shù)據(jù)，包括溫度、濕度、亮度等。
    插入數(shù)據(jù)庫(kù)中的數(shù)據(jù)如圖12所示，圖中顯示的是室內(nèi)的亮度值。

    在Web瀏覽器端可以查看實(shí)時(shí)和歷史數(shù)據(jù)，頁(yè)面顯示效果如圖13所示。

    由此看出，基于C／S架構(gòu)的方式，不僅可以顯示實(shí)時(shí)數(shù)據(jù)，還可以查看歷史數(shù)據(jù)，以便及時(shí)發(fā)現(xiàn)問(wèn)題，更加具有實(shí)用性。

4 結(jié)論
    本文詳細(xì)介紹了CoAP協(xié)議的內(nèi)容、特點(diǎn)、交互模型以及訂閱機(jī)制，還給出了基于uIPv6 START KIT無(wú)線網(wǎng)絡(luò)開(kāi)發(fā)套件的系統(tǒng)配置方式，該網(wǎng)絡(luò)可以通過(guò)火狐瀏覽器和客戶端軟件兩種方式實(shí)現(xiàn)CoAP協(xié)議，用戶不僅可以讀取傳感器上的實(shí)時(shí)數(shù)據(jù)，而且可以查看歷史數(shù)據(jù)。