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

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

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

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

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

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

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

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