基于CoAP協(xié)議可靠組通信系統(tǒng)的設(shè)計(jì)及實(shí)現(xiàn)

引言

物聯(lián)網(wǎng)中包括了傳統(tǒng)的互聯(lián)網(wǎng)和主要由傳感器節(jié)點(diǎn)組成的資源受限網(wǎng)絡(luò)，而在互聯(lián)網(wǎng)絡(luò)中普遍使用的應(yīng)用層協(xié)議HTTP不能夠適用于受限網(wǎng)絡(luò)環(huán)境，因此就需要引入一個新的通信協(xié)議針對資源受限網(wǎng)絡(luò)進(jìn)行通信。在這一背景下，互聯(lián)網(wǎng)工程任務(wù)組(InternetEngineeringTaskForce，IETF)成立了CoRE工作組，負(fù)責(zé)定義受限網(wǎng)絡(luò)中的應(yīng)用層通信協(xié)議一一CoAP協(xié)議。

CoAP協(xié)議將實(shí)現(xiàn)資源受限節(jié)點(diǎn)間的有效信息傳輸作為基本目標(biāo)，其定義了在兩個傳感器之間以單播方式傳輸?shù)耐ㄐ趴刂茀f(xié)議，能夠?qū)崿F(xiàn)M2M的可靠消息傳遞。同時，CoAP協(xié)議也定義了針對傳感器節(jié)點(diǎn)之間的組通信協(xié)議。

然而，目前的CoAP組通信是基于IP組播協(xié)議，其僅能實(shí)現(xiàn)不可靠的組通信。具體而言，比照OMA(OPENMOBILEALLIANCE，開放移動聯(lián)盟)提出的輕量級M2M應(yīng)用的需求和架構(gòu)文檔，組通信可靠性沒有保障的CoAP協(xié)議不能夠滿足OMA針對應(yīng)用的需求。在OMA提出的應(yīng)用場景中，如果使用CoAP協(xié)議的不可靠組通信，將會對其定義的應(yīng)用場景帶來極大的隱患。

IETF關(guān)于CoAP及其組通信的介紹

1.1CoAP協(xié)議

CoAP協(xié)議是一種應(yīng)用于受限網(wǎng)絡(luò)和節(jié)點(diǎn)的特殊Web傳輸協(xié)議，在應(yīng)用終端間提供方法/響應(yīng)的交互模式，支持內(nèi)置的資源發(fā)現(xiàn)，包含關(guān)鍵的網(wǎng)絡(luò)概念，比如URIs和Content-type。CoAP協(xié)議類似于HTTP協(xié)議，但不是簡單地對HTTP進(jìn)行壓縮，而是重新實(shí)現(xiàn)了一個類似HTTP的REST子集，以適應(yīng)資源受限環(huán)境叫

CoAP協(xié)議在資源受限網(wǎng)絡(luò)中所起的作用類似于HTTP協(xié)議在互聯(lián)網(wǎng)中所起的作用。其基于UDP傳輸?shù)姆绞?，可明顯降低傳輸開銷，并可滿足CoAP請求的組通信傳遞，而組通信對于M2M應(yīng)用是最重要的需求之一。

1.2CoAP組通信

CoAP協(xié)議構(gòu)建在UDP協(xié)議之上，用以減少開銷且支持組通信叫由于UDP協(xié)議的特性，即不保證數(shù)據(jù)傳輸?shù)目煽啃裕瑢?dǎo)致CoAP協(xié)議雖然支持組通信，但不保證數(shù)據(jù)傳輸?shù)目煽啃院陀行蛐?。這一特性，在某些特定應(yīng)用場景中會為用戶針對設(shè)備的操作帶來隱患和非便利因素，若用戶想同時針對多個接收端進(jìn)行可靠的控制，則其必須使用逐一控制的方式實(shí)現(xiàn)這一功能，否則將有可能導(dǎo)致部分接收端并未按照用戶的意愿執(zhí)行相應(yīng)的操作，這在實(shí)際應(yīng)用中是不能被接受的。

基于以上原因，本文提出了幾種用于CoAP可靠組通信設(shè)計(jì)的方案，針對不同規(guī)模的數(shù)據(jù)集使用不同的方法，解決CoAP協(xié)議的這一缺陷。

OMA的M2M應(yīng)用需求及分析

2.1基于傳感器網(wǎng)絡(luò)的路燈管理系統(tǒng)應(yīng)用場景

某用戶是一個街區(qū)路燈系統(tǒng)的管理員，負(fù)責(zé)管理其所在街區(qū)的所有路燈狀態(tài)的變更及維護(hù)。為了更好、更快地實(shí)現(xiàn)針對路燈的控制，該用戶將低成本的M2M傳感器嵌入在這些路燈中，并通過一個路燈遠(yuǎn)程控制器針對這些傳感器進(jìn)行操控。

針對這一場景，需要實(shí)現(xiàn)以下幾方面的功能：用戶具備遠(yuǎn)程開、關(guān)特定路燈的能力，包括一次操控一個路燈和一次操控多個路燈；用戶能夠?qū)崟r、準(zhǔn)確地知道每個路燈的現(xiàn)有狀態(tài)；確保這些路燈只接受授權(quán)用戶的指令，杜絕可能存在的安全隱患。

通過以上描述，可以構(gòu)建一個基于物聯(lián)網(wǎng)的路燈控制系統(tǒng)，如圖1所示。

圖1基于傳感器網(wǎng)絡(luò)的路燈管理系統(tǒng)

2.2針對OMA應(yīng)用場景的需求分析

通過針對上述應(yīng)用場景的需求分析，將一次完整的針對M2M傳感器的控制操作流程概括如下：

用戶通過遠(yuǎn)程控制器接入互聯(lián)網(wǎng)，指令通過HTTP協(xié)議得以傳輸。

當(dāng)該指令到達(dá)終端設(shè)備組成的傳感器網(wǎng)絡(luò)時，通過HTTP協(xié)議和CoAP協(xié)議相互轉(zhuǎn)換的功能，實(shí)現(xiàn)針對指令的報文封裝和轉(zhuǎn)換，將互聯(lián)網(wǎng)中的HTTP報文［3］封裝為CoAP報文。

經(jīng)過封裝轉(zhuǎn)換后的信息通過CoAP協(xié)議在傳感器網(wǎng)絡(luò)中進(jìn)行傳輸，最終到達(dá)各個設(shè)備上的M2M傳感器，實(shí)現(xiàn)用戶設(shè)計(jì)的既定操作。

在這一過程中，欲實(shí)現(xiàn)用戶提出的幾項(xiàng)功能，需具備遠(yuǎn)程操控特定設(shè)備的能力，而CoAP協(xié)議目前尚僅能滿足針對單播的可靠傳輸，其針對組通信傳輸尚不能保證可靠性。這一限制條件就導(dǎo)致了當(dāng)用戶想要同時針對多個設(shè)備進(jìn)行控制時，會面臨以下幾點(diǎn)問題：

若想實(shí)現(xiàn)針對多個設(shè)備的可靠控制，則只能采用用戶逐一針對設(shè)備進(jìn)行操控的方式，利用CoAP協(xié)議針對單播可實(shí)現(xiàn)可靠傳輸這一特性實(shí)現(xiàn)該操作。

若想一次性地通過組通信實(shí)現(xiàn)針對設(shè)備的控制，則CoAP協(xié)議目前的傳輸機(jī)制將會為此操作埋下隱患，即部分設(shè)備可能會因CoAP協(xié)議組通信傳輸?shù)牟豢煽啃灾率蛊錄]有按照用戶的要求進(jìn)行相應(yīng)的操作，這在OMA設(shè)定的應(yīng)用場景中是不能為用戶所接受的。

綜上所述，針對不同規(guī)模的用戶數(shù)集群數(shù)量，需實(shí)現(xiàn)的功能中皆包含針對設(shè)備的可靠單播通信和可靠組播通信。而作為傳感器網(wǎng)絡(luò)重要傳輸協(xié)議之一的CoAP協(xié)議，目前尚還只能實(shí)現(xiàn)針對單播的可靠通信，而其針對組通信不可靠傳輸?shù)倪@一問題將會在諸如以上場景的實(shí)際應(yīng)用中產(chǎn)生巨大的隱患。

CoAP可靠組通信方案設(shè)計(jì)

3.1逐一單播方案

為了解決CoAP協(xié)議組通信不可靠的問題，根據(jù)接收端數(shù)量的多少，可以采用不同的傳輸方式加以解決。當(dāng)控制的接收端數(shù)量小于預(yù)設(shè)值Vs時(兀值由用戶事先根據(jù)實(shí)際情況加以設(shè)定，用以判斷接收端數(shù)量的多少，決定采用何種發(fā)送方式)，考慮到實(shí)際的發(fā)送效率及運(yùn)營成本，可以采用多個單播的形式實(shí)現(xiàn)組通信的功能，具體實(shí)現(xiàn)方式如下：

發(fā)送端以CoAP單播的形式向每個接收端發(fā)送命令。在接收端接收到信息后，會立即發(fā)送一個Request響應(yīng)信息到發(fā)送端。經(jīng)過一個固定延遲△t1后(△t1值根據(jù)接收端反饋信息所需花費(fèi)的平均時間乘以系數(shù)m確定)，未發(fā)送Request響應(yīng)的接收端，即被判定為接收失敗或是Request響應(yīng)在傳輸過程中出現(xiàn)了意外。此時，發(fā)送端針對這些被判定為接收失敗或是Request響應(yīng)在傳輸過程中出現(xiàn)問題的接收節(jié)點(diǎn)再次重復(fù)發(fā)送該信息。重復(fù)以上過程，直到最終所有的接收端都成功返回Request信息為止，此次組通信發(fā)送即宣告完成。

以上這種基于CoAP逐一單播的形式進(jìn)行傳輸?shù)囊笫?接收端數(shù)量小于預(yù)設(shè)值Vs，如圖2所示。

圖2小規(guī)模接收端數(shù)量

3.2基于代理的可靠組通信實(shí)現(xiàn)方式

3.2.1逐一單播方案的局限性

通過逐一單播實(shí)現(xiàn)CoAP可靠組通信的方式，其優(yōu)點(diǎn)是實(shí)現(xiàn)簡便，成本較低；而其缺點(diǎn)則是操作過程繁瑣，且僅適用于接收端數(shù)量較小時使用。

當(dāng)系統(tǒng)中的接收端數(shù)量較多時，若繼續(xù)采用通過多個單播重復(fù)發(fā)送實(shí)現(xiàn)這一功能，則易導(dǎo)致出現(xiàn)以下幾個問題：

接收端接收到信息的時間間隔過大。

易產(chǎn)生發(fā)送端擁塞問題。

操作過程繁瑣。

基于以上三點(diǎn)原因，當(dāng)接收端數(shù)量較大時，需要另一種更為高效可靠的方式解決CoAP組通信不可靠的問題。由此,本文將會介紹一種基于代理(Proxy)的方式實(shí)現(xiàn)CoAP可靠組通信的方案，這一方案可以較好地同時解決上述三個問題。

圖3大規(guī)模接收端數(shù)量

如圖3所示，在這種基于代理的CoAP可靠組通信傳輸系統(tǒng)中，除發(fā)送端和接收端以外，還需要引入一個代理服務(wù)器針對報文進(jìn)行中轉(zhuǎn)、判定和重傳操作，以減輕發(fā)送端的擁塞壓力，同時也能更好、更快地實(shí)現(xiàn)針對報文的重傳操作。

此種基于代理的可靠組通信傳輸方式,具體而言可以分為以下幾個步驟。

3.2.2發(fā)送過程

基于代理的CoAP可靠組通信的發(fā)送過程分為以下幾步:

由發(fā)送端通過CoAP單播的形式，將消息發(fā)送給代理服務(wù)器。

代理服務(wù)器將該消息報文解析后，獲取到本次發(fā)送的實(shí)際接收端的地址。

代理服務(wù)器將此報文進(jìn)行整理封裝，通過CoAP組通信的形式發(fā)送給上述解析出的接收端地址。

同一時間，代理服務(wù)器將這些接收端的地址加以記錄,建立一個布爾數(shù)組，用以記錄后續(xù)的接收狀態(tài)，如圖4所示。

圖4代理服務(wù)器的布爾數(shù)組

3.2.3接收端匹配及反饋過程

在發(fā)送過程結(jié)束后，接收端結(jié)點(diǎn)接收消息報文的過程可分為以下幾步：

接收端接收到由代理服務(wù)器發(fā)出的消息報文后，根據(jù)報文中的目標(biāo)地址進(jìn)行匹配，若匹配成功則加以接收；匹配成功的接收端針對報文中的內(nèi)容進(jìn)行解析，并根據(jù)報文內(nèi)容完成對應(yīng)的操作；由完成以上兩步操作的部分接收端向代理服務(wù)器發(fā)送反饋信息，在這一過程中，為保證傳輸過程的可靠性,這一反饋消息需采用CoAP單播加以實(shí)現(xiàn)。

3.2.4代理服務(wù)器處理反饋并重專信息

完成了接收端匹配及反饋過程后，代理服務(wù)器需針對反饋信息進(jìn)行分析處理，并根據(jù)需求進(jìn)行重傳操作，這一過程可分為以下幾步：

代理服務(wù)器針對收到的眾多接收端發(fā)送來的反饋信息,根據(jù)眾接收端的地址和編號，針對其在發(fā)送步驟時創(chuàng)建的代表接收端狀態(tài)的布爾數(shù)組進(jìn)行狀態(tài)變更。

在經(jīng)過了一個預(yù)設(shè)好的時間△t3后，代理服務(wù)器針對狀態(tài)布爾數(shù)組進(jìn)行遍歷，針對其中尚未變更狀態(tài)的數(shù)組單元即代表該接收端并未成功接收到代理服務(wù)器之前所發(fā)來的信息或是發(fā)送反饋信息失敗。此時，由代理服務(wù)器將之前的信息報文再次重傳給這些被判定為接收失敗的接收端。

重傳時，需要根據(jù)本次重傳中接收端的數(shù)量進(jìn)行判斷,若接收端數(shù)量小于Vs值，則采用逐一單播的形式進(jìn)行發(fā)送；若接收端數(shù)量大于等于Vs值，則繼續(xù)采用組通信的形式進(jìn)行發(fā)送，后續(xù)反饋過程同本次反饋過程。

狀態(tài)變更失敗或反饋信息發(fā)送失敗的接收端，在接收到由代理服務(wù)器發(fā)送來的重傳信息后，按照報文中的內(nèi)容進(jìn)行相應(yīng)的操作，并將成功變更的信息反饋給代理服務(wù)器。

重復(fù)以上步驟，直到代理服務(wù)器中的狀態(tài)布爾數(shù)組全部完成變更，即本次組通信操作成功。

完成以上4步后，代理服務(wù)器需通過CoAP單播反饋給發(fā)送端一個確認(rèn)信息，確認(rèn)本次發(fā)送成功。

3.2.5發(fā)送連貫性

在以上步驟進(jìn)行的過程中，發(fā)送端可以繼續(xù)發(fā)送后續(xù)命令，由于代理服務(wù)器的處理能力相比發(fā)送端較為優(yōu)越，因此處理發(fā)送端重傳的功能由代理服務(wù)器完成，發(fā)送端在這一過程中可進(jìn)行連貫發(fā)送。

3.2.6基于代理的可靠組通信流程圖

基于代理的可靠組通信流程圖如圖5所示。

(本次發(fā)送結(jié)束)

圖5CoAP協(xié)議基于代理的可靠組通信傳輸流程圖

3.3特殊狀況處理

3.3.1結(jié)點(diǎn)睡眠

當(dāng)接收端結(jié)點(diǎn)即將處于睡眠模式時，需要進(jìn)行以下幾個步驟的操作：

接收端向CoAP資源目錄服務(wù)器發(fā)送一個消息，告知其關(guān)于自身狀態(tài)變更的消息；CoAP資源目錄服務(wù)器收到這一信息后，向代理服務(wù)器發(fā)送一個消息，告知后者該結(jié)點(diǎn)處于睡眠狀態(tài)；當(dāng)代理服務(wù)器進(jìn)行消息發(fā)送時，若查閱自身數(shù)據(jù)庫得知某結(jié)點(diǎn)已處于睡眠狀態(tài)，則需先發(fā)送一個睡眠喚醒消息,將這些結(jié)點(diǎn)喚醒，之后再針對該結(jié)點(diǎn)進(jìn)行消息發(fā)送。

3.3.2結(jié)點(diǎn)關(guān)機(jī)或供電不足

當(dāng)接收端結(jié)點(diǎn)即將關(guān)機(jī)（供電不足或人工關(guān)機(jī)）時，需要進(jìn)行以下幾個步驟的操作：

接收端向CoAP資源目錄服務(wù)器發(fā)送一個消息，告知其關(guān)于自身即將關(guān)機(jī)的消息；CoAP資源目錄服務(wù)器收到這一信息后，向代理服務(wù)器發(fā)送一個消息，告知后者該結(jié)點(diǎn)處于關(guān)機(jī)狀態(tài)；當(dāng)代理服務(wù)器進(jìn)行消息發(fā)送時，若查閱自身數(shù)據(jù)庫得知某結(jié)點(diǎn)已處于關(guān)機(jī)狀態(tài)，則暫時保留本要發(fā)送的數(shù)據(jù)。當(dāng)CoAP資源目錄服務(wù)器告知代理服務(wù)器關(guān)于該結(jié)點(diǎn)重新開機(jī)時，代理服務(wù)器再將本要發(fā)送消息發(fā)送給該結(jié)點(diǎn)。

4仿真實(shí)現(xiàn)CoAP可靠組通信

基于上文介紹的CoAP可靠組通信應(yīng)用方案，利用JAVA仿真構(gòu)建了一個基于代理的CoAP可靠組通信模擬系統(tǒng)，該系統(tǒng)可實(shí)現(xiàn)基于代理的模擬CoAP組通信。

圖6仿真實(shí)現(xiàn)CoAP可靠組通信

該通信的規(guī)則為：由發(fā)送端將報文發(fā)送至代理服務(wù)器,代理服務(wù)器根據(jù)其中的接收端數(shù)量判定是何種方式進(jìn)行重傳。經(jīng)大量實(shí)驗(yàn)證明，當(dāng)接收端數(shù)量大于Vs時采用CoAP組通信,當(dāng)接收端數(shù)量小于等于Vs時采用CoAP單播通信如某次組通信發(fā)送后出現(xiàn)了接受失敗的節(jié)點(diǎn)，則會針對其進(jìn)行重傳，重傳的方式同樣由接收端數(shù)量來決定。重復(fù)以上步驟，直至所有接收端節(jié)點(diǎn)都順利接收到該報文，此次發(fā)送結(jié)束。

5結(jié)語

目前互聯(lián)網(wǎng)工程任務(wù)組的Core工作組給出的CoAP協(xié)議草案中尚未提出針對CoAP組通信不可靠性的有效解決辦法。而在OMA等提出的應(yīng)用場景中，CoAP協(xié)議由于其不可靠組通信這一特性將不能勝任此類應(yīng)用場景對傳輸協(xié)議所提出的需求。

基于以上背景，本文利用CoAP協(xié)議的基本特性，構(gòu)建了針對不同規(guī)模接收端數(shù)量的兩類傳輸方式的可靠組通信理論模型，即基于代理服務(wù)器和逐一單播的形式實(shí)現(xiàn)CoAP可靠組通信。在構(gòu)建理論模型的基礎(chǔ)上，本文還進(jìn)一步通過程序搭建了CoAP協(xié)議可靠組通信模擬系統(tǒng)，在該系統(tǒng)中真實(shí)模擬了CoAP組通信的全過程，清晰而直觀地將CoAP可靠組通信的實(shí)現(xiàn)方案呈現(xiàn)于該系統(tǒng)中。通過理論模型的構(gòu)建和模擬系統(tǒng)的架構(gòu)，為后續(xù)研究CoAP協(xié)議可靠組通信奠定了良好的理論基礎(chǔ)。

20211223_61c44a72eaefe__基于CoAP協(xié)議可靠組通信系統(tǒng)的設(shè)計(jì)及實(shí)現(xiàn)