好文轉載--無線物聯網中CoAP協議的研究與實現

標籤：style   blog   http   color   使用   strong   

無線物聯網中CoAP協議的研究與實現

時間：2013-04-09?來源：電子科技 湯春明，張 熒，吳宇平

關鍵字：CoAP???無線???物聯網???協議??????

摘要：由於物聯網中的很多裝置都是資源受限型的，即只有少量的記憶體空間和有限的計算能力，所以傳統的HTTP協議應用在物聯網上就顯得過於龐大而不適用。IETF的CoRE工作群組提出了一種基於REST架構的CoAP協議。CoAP是6LowPAN協議棧中的應用程式層協議。該文在詳細介紹了CoAP協議的內容、特點和互動模型後，在uIPv6 START KIT無線網路開發套件上，使用Contiki嵌入式作業系統，不僅在瀏覽器端實現了CoAP協議而且用自己編寫的用戶端程式實現了CoAP協議，增加了和資料庫之間的互動功能，從而實現了在Web介面上不僅可以查看即時資料，還可以查看曆史資料的功能。
關鍵詞：物聯網；6LoWPAN；CoAP；Contiki

0 引言
????物聯網是在互連網的基礎上延伸和擴充的一種網路，其使用者端延伸和擴充到了任何物品之間，彼此進行資訊交換和通訊，目的是實現所有物品與網路的串連，從而方便識別、管理和控制。
??? 無線物聯網的特點包括：全面感知、即時準確傳遞物品資訊、利用智能計算技術對海量資料進行分析和處理，以實現智能化控制。
??? 由於無線物聯網中的裝置很多都是資源受限型的，這些裝置只有少量的記憶體空間和有限的計算能力。為此，IETF(Internet Engineering Task Force)的CoRE(Constrained RESTful Environment)工作群組為受限節點制定相關的REST(Representational State Transfer)形式的應用程式層協議。這就是CoRE工作群組正在制訂的CoAP(Constrained Application Protocol)協議。

1 6LoWPAN協議棧
????由於TCP／IP協議棧不適用於資源受限的裝置，因此提出了一種6LoWPAN(IPv6 over Low power Wireless Personal Area Networks)協議棧。CoAP是6LoWPAN協議棧中的應用程式層協議。6LoWPAN使IPv6可用於低功耗的有損網路，它是基於IEEE 802．15．4標準的。6LoWPAN協議棧1所示。

??? 協議棧的下兩層用802．15．4 PHY／MAC，中間加一個IPv6-6LoWPAN適配層，傳輸層使用UDP協議，應用程式層使用CoAP協議。它包括REST的最小子集和到HTTP的無狀態映射。通訊主機使用CoAP協議，能夠支援穩定的通訊架構，以實現感應器節點與互連網的無線串連。

2 CoAP協議
????在2010年3月，CoRE工作群組開始制定CoAP協議，到目前為止，該協議還沒有定稿。CoAP協議是為物聯網中資源受限裝置制定的應用程式層協議。它是一種面向網路的協議，採用了與HTTP類似的特徵，核心內容為資源抽象、REST式互動以及可擴充的頭選項等。應用程式通過URI標識來擷取伺服器上的資源，即可以像HTTP協議對資源進行GET、PUT、POST和DELETE等操作。CoAP協議具有如下特點：
??? (1)前序壓縮：CoAP包含一個緊湊的二進位前序和擴充前序。它只有短短的4 B的基本前序，基本前序後面跟擴充選項。一個典型的請求前序為10～20 B。圖2是CoAP協議的資訊格式。

??? 前序部分各欄位的含義如下：V(Version)表示CoAP協議的版本號碼；T(Type)表示訊息的資訊類型；OC(Option Count)表示頭後面的可選的選項數量；Code表示訊息的類型：請求訊息、響應訊息，或者是空訊息；Message ID表示訊息編號，用於重複訊息檢測、匹配訊息類型等。
??? (2)方法和URIs：為了實現Client Access Server上的資源，CoAP支援GET、PUT、POST和DELETE等方法。CoAP還支援URIs，這是Web架構的主要特點。
??? (3)傳輸層使用UDP協議：CoAP協議是建立在UDP協議之上，以減少開銷和支援組播功能。它也支援一個簡單的停止和等待的可靠性傳輸機制。
??? (4)支援非同步通訊：HTTP對M2M(Machine-to-Machine)通訊不適用，這是由於事務總是由用戶端發起。而CoAP協議支援非同步通訊，這對M2M通訊應用來說是常見的休眠／喚醒機制。
??? (5)支援資摘要搜索：為了自主的發現和使用資源，它支援內建的資摘要搜索格式，用於發現裝置上的資源清單，或者用於裝置向服務類別目錄公告自己的資源。它支援RFC5785中的格式，在CoRE中用／．well—known／core的路徑表示資源描述。
??? (6)支援緩衝：CoAP協議支援資源描述的緩衝以最佳化其效能。
??? (7)訂閱機制：CoAP使用非同步通訊方式，用訂閱機制實現從伺服器到用戶端的訊息推送。實現CoAP的發布，訂閱機制，它是請求成功後自動註冊的一種資源後處理常式。是由預設的EVENT_和PERIODIC_RESOURCEs來進行配置的。它們的事件和輪詢處理常式用EST．notify_subscri bers()函數來發布。
2．1 CoAP協議棧
????圖3是CoAP協議棧。CoAP協議的傳輸層使用UDP協議。由於UDP傳輸的不可靠性，CoAP協議採用了雙層結構，定義了帶有重傳的交易處理機制，並且提供資摘要搜索和資源描述等功能。CoAP採用儘可能小的載荷，從而限制了分區。

??? 事務層(Transaction layer)用於處理節點之間的資訊交換，同時提供組播和擁塞控制等功能。請求／響應層(Request／Responselayer)用於傳輸對資源進行操作的請求和響應資訊。CoAP協議的REST構架是基於該層的通訊。CoAP的雙層處理方式，使得CoAP沒有採用TCP協議，也可以提供可靠的傳輸機制。利用預設的定時器和指數增長的重傳間隔時間實現CON(Confirmable)訊息的重傳，直到接收方發出確認訊息。另外，CoAP的雙層處理方式支援非同步通訊，這是物聯網和M2M應用的關鍵需求之一。
2．2 CoAP的訂閱機制
????HTTP的請求／響應機制是假設事務都是由用戶端發起的，通常叫做拉模型。這導致用戶端不能高效的知統中，裝置都是無線低功耗的，這些裝置大部分時間是休眠狀態，因此不能響應輪詢請求。而CoRE認為支援本地的推送模型是一個重要的需求，也就是由伺服器初始化事務到用戶端。推送模型需要一個訂閱介面，用來請求響應關於特定資源的改變。而由於UDP的傳輸是非同步，所以不需要特殊的通知訊息。訂閱機制4所示。

?

2．3 CoAP的互動模型
??? CoAP使用類似於HTTP的請求／響應模型：CoAP終端節點作為用戶端向伺服器發送一個或多個請求，伺服器端回複用戶端的CoAP請求。不同於HTTP，CoAP的請求和響應在發送之前不需要事先建立串連，而是通過CoAP資訊來進行非同步資訊交換。CoAP協議使用UDP進行傳輸。這是通過資訊層選項的可靠性來實現的。CoAP定義了四種類型的資訊：可證實的CON(Confirmable)資訊，不可證實的NON(Non-Confirmable)資訊，可確認的ACK(Acknowledgement)資訊和重設資訊RST(Reset)。方法代碼和響應程式碼封裝含在這些資訊中，實現請求和響應功能。這四種類型資訊對於請求／響應的互動來說是透明的。
??? CoAP的請求／響應語義包含在CoAP資訊中，其中分別包含方法代碼和響應代碼。CoAP選項中包含可選的(或預設的)請求和響應資訊，例如URI和負載內容類型。令牌選項用於獨立匹配底層的請求到響應資訊。
??? 請求／響應模型：請求包含在可證實的或不可證實的資訊中，如果伺服器端是立即可用的，它對請求的應答包含在可證實的確認資訊中來進行應答。圖5是基本的GET請求和響應模式，其中圖5(a)表示成功發送請求和收到ACK確認資訊，圖5(b)表示重傳了請求資訊，然後才收到ACK確認資訊。

??? 雖然CoAP協議目前還在制定當中，但Contiki和TinyOS嵌入式作業系統已經支援CoAP協議。Contiki是一個多任務作業系統，並帶有uIPv6協議棧，適用於嵌入式系統和無線感應器網路，它佔用系統資源小，適用於資源受限的網路和裝置。目前，Firefox瀏覽器已經整合了Copper外掛程式，從而實現了CoAP協議。但是這種方式只能讀取感應器節點上的即時資料，而不能查看各種曆史資料。為此，在Contiki系統的基礎上，基於uIPv6START KIT無線網路開發套件，用自己編寫的用戶端程式實現了和資料庫的互動，把曆史資料存入資料庫中，從而在Web瀏覽器端不僅可以訪問感應器節點上的即時資料，還能查看曆史資料，以便於分析問題。

3 實驗平台及CoAP協議的實現
3．1 實驗平台
????硬體平台式是美信淩科公司的IPv6智能網關(MXG300)、MX231CC節點、USB無線網卡(STICK)和JTAG下載器。實驗的硬體平台配置和硬體平台6，圖7所示。軟體平台是WinAVR和AVR studio，用於向節點和USB網卡中下載程式。

??? 其中IPv6智能網關上的主要晶片有：BCM 6358UKFBG支援多使用者乙太網路功能，具有高度最佳化的32 MIPS CPU和標準的EJTAG調試器；BCM53 25EKQMG整合了5個收發器，具有128 KB的資料包緩衝區，最多可以支援2K的MAC地址，支援地址自動學習，提供真正的隨插即用串連，而且是低功耗的；SIGe2521A60提供2．4～2．5 GHz的無線工作頻段範圍，應用於ISM 2．4．GHz的無線解決方案。

?圖8是IPv6智能無線網關的介面布局，它是基於OPENWRT系統定製完成的。具備3個區域網路口，1個廣域網路口，1個802．11a／b／g WiFi無線網路介面，1個標準USB口和1個可選的串口調試口。該智能無線網關除具備通用無線路由器的功能以外，還可以實現基於Contiki作業系統的USB UIP網路和普通IP網路之間的IPv6互連，同時還支援有能力的系統在OPENWRT的基礎上開發自己的應用軟體包，實現更複雜的應用。

??? OPENWRT是一個開源的Linux版本。主要應用於嵌入式系統。網關和節點上同時裝有Contiki系統，它提供宏定義和RESTful網路服務執行個體。
??? MX231CC節點上的主要晶片是ATmega1284P，它具有128 KB的可程式化快閃記憶體，4 KB的E2PROM，16 KB的片內SRAM，JTAG介面，最佳化的功耗和處理速度。節點上運行Contiki系統。節點上還有光敏感應器、室內溫度感應器、三色LED指示燈等。
3．2 CoAP協議的Firefox瀏覽器實現(B／S架構)
????B／S架構的系統結構9所示。

??? 系統由使用者瀏覽器、Web伺服器、IPv6智能網關、MX231CC節點群組成。使用者瀏覽器通過HTTP協議訪問Web伺服器，MX231CC節點通過CoAP協議和IPv6智能網關進行通訊，從而實現使用者瀏覽器訪問節點上資源的功能。圖9中實線表示有線串連，虛線表示無線串連。
??? 在當前的Contiki 2．5中，整合了CoAP 03和CoAP06這兩個版本。這兩個檔案在Contiki 2．5的apps目錄下，關於CoAP的核心內容都在這兩個檔案中。程式的主要部分為：

??? AUTOSTART_PROCESSES(&coap_sample)這個進程需要自啟動，即當節點啟動時啟動本程式；
??? PERIODIC_RESOURCE()為進程的主體部分。
??? 然後進行編譯，編譯成．elf檔案，用JTAG下載器下載到節點上。節點地址設定為：2001：2：：11：22ff：：fe33：4499。這時，用Firefox瀏覽器訪問節點，因為Firefox瀏覽器內建coap外掛程式，如果用其他瀏覽器，那麼需要進行coap的代理設定。以控制節點上的三色LED燈反轉為例，用下面的請求格式：
??? GETcoap：／／[<mote_ip_address>]：<poa_number>／readings
??? 其中mote_ip_address是節點的IPv6地址，port_number是節點的連接埠號碼，readings是用戶端請求的資源(溫度)。
??? 所以在瀏覽器地址欄輸入：coap：／／[2001：2：：11：22ff：fe33：4499]：61616／toggle，作用是讓節點上的三色LED燈進行反轉。伺服器端的響應資訊10所示。

??? 從瀏覽器端可以看出，CoAP協議支援Discover和Observe功能，具有GET、POST、PUT和DELETE等方法。Type表示資訊類型為ACK，Code為200，表示成功完成用戶端的請求。事務ID為38 264，它用於重複資訊檢測，options為1表示有一個可選項，內容類型為text表示文本類型。
??? 由此可以看出，通過Firefox瀏覽器的CoAP協議，可以訪問節點上的感應器資源。
3．3 CoAP協議的用戶端實現(C／S架構)
????上節通過Firefox瀏覽器可以實現COAP協議，但是只能查看即時資料，不能查看曆史資料。為此，這裡搭建了一個C／S架構的環境。11所示。

??? 圖11中用戶端軟體是用基於．NET架構的C#語言編寫的，資料庫使用SQL Server 2008。通過此程式，可以每隔10 s讀取一次資料，存入到資料庫中。並可以通過前台的Web介面查看各種曆史資料，包括溫度、濕度、亮度等。
??? 插入資料庫中的資料12所示，圖中顯示的是室內的亮度值。

??? 在Web瀏覽器端可以查看即時和曆史資料，頁面顯示效果13所示。

??? 由此看出，基於C／S架構的方式，不僅可以顯示即時資料，還可以查看曆史資料，以便及時發現問題，更加具有實用性。

4 結論
????本文詳細介紹了CoAP協議的內容、特點、互動模型以及訂閱機制，還給出了基於uIPv6 START KIT無線網路開發套件的系統配置方式，該網路可以通過Firefox瀏覽器和用戶端軟體兩種方式實現CoAP協議，使用者不僅可以讀取感應器上的即時資料，而且可以查看曆史資料。

SRC=http://www.21ic.com/app/rf/201304/178560_3.htm