天天干天天做天天操-天天干天天做天天射-天天干网-天天干网站-天天干网址

引言

物聯網中包括了傳統的互聯網和主要由傳感器節點組成的資源受限網絡，而在互聯網絡中普遍使用的應用層協議HTTP不能夠適用于受限網絡環境，因此就需要引入一個新的通信協議針對資源受限網絡進行通信。在這一背景下，互聯網工程任務組(InternetEngineeringTaskForce，IETF)成立了CoRE工作組，負責定義受限網絡中的應用層通信協議一一CoAP協議。

CoAP協議將實現資源受限節點間的有效信息傳輸作為基本目標，其定義了在兩個傳感器之間以單播方式傳輸的通信控制協議，能夠實現M2M的可靠消息傳遞。同時，CoAP協議也定義了針對傳感器節點之間的組通信協議。

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

IETF關于CoAP及其組通信的介紹

1.1CoAP協議

CoAP協議是一種應用于受限網絡和節點的特殊Web傳輸協議，在應用終端間提供方法/響應的交互模式，支持內置的資源發現，包含關鍵的網絡概念，比如URIs和Content-type。CoAP協議類似于HTTP協議，但不是簡單地對HTTP進行壓縮，而是重新實現了一個類似HTTP的REST子集，以適應資源受限環境叫

CoAP協議在資源受限網絡中所起的作用類似于HTTP協議在互聯網中所起的作用。其基于UDP傳輸的方式，可明顯降低傳輸開銷，并可滿足CoAP請求的組通信傳遞，而組通信對于M2M應用是最重要的需求之一。

1.2CoAP組通信

CoAP協議構建在UDP協議之上，用以減少開銷且支持組通信叫由于UDP協議的特性，即不保證數據傳輸的可靠性，導致CoAP協議雖然支持組通信，但不保證數據傳輸的可靠性和有序性。這一特性，在某些特定應用場景中會為用戶針對設備的操作帶來隱患和非便利因素，若用戶想同時針對多個接收端進行可靠的控制，則其必須使用逐一控制的方式實現這一功能，否則將有可能導致部分接收端并未按照用戶的意愿執行相應的操作，這在實際應用中是不能被接受的。

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

OMA的M2M應用需求及分析

2.1基于傳感器網絡的路燈管理系統應用場景

某用戶是一個街區路燈系統的管理員，負責管理其所在街區的所有路燈狀態的變更及維護。為了更好、更快地實現針對路燈的控制，該用戶將低成本的M2M傳感器嵌入在這些路燈中，并通過一個路燈遠程控制器針對這些傳感器進行操控。

針對這一場景，需要實現以下幾方面的功能：用戶具備遠程開、關特定路燈的能力，包括一次操控一個路燈和一次操控多個路燈；用戶能夠實時、準確地知道每個路燈的現有狀態；確保這些路燈只接受授權用戶的指令，杜絕可能存在的安全隱患。

通過以上描述，可以構建一個基于物聯網的路燈控制系統，如圖1所示。

圖1基于傳感器網絡的路燈管理系統

2.2針對OMA應用場景的需求分析

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

用戶通過遠程控制器接入互聯網，指令通過HTTP協議得以傳輸。

當該指令到達終端設備組成的傳感器網絡時，通過HTTP協議和CoAP協議相互轉換的功能，實現針對指令的報文封裝和轉換，將互聯網中的HTTP報文［3］封裝為CoAP報文。

經過封裝轉換后的信息通過CoAP協議在傳感器網絡中進行傳輸，最終到達各個設備上的M2M傳感器，實現用戶設計的既定操作。

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

若想實現針對多個設備的可靠控制，則只能采用用戶逐一針對設備進行操控的方式，利用CoAP協議針對單播可實現可靠傳輸這一特性實現該操作。

若想一次性地通過組通信實現針對設備的控制，則CoAP協議目前的傳輸機制將會為此操作埋下隱患，即部分設備可能會因CoAP協議組通信傳輸的不可靠性致使其沒有按照用戶的要求進行相應的操作，這在OMA設定的應用場景中是不能為用戶所接受的。

綜上所述，針對不同規模的用戶數集群數量，需實現的功能中皆包含針對設備的可靠單播通信和可靠組播通信。而作為傳感器網絡重要傳輸協議之一的CoAP協議，目前尚還只能實現針對單播的可靠通信，而其針對組通信不可靠傳輸的這一問題將會在諸如以上場景的實際應用中產生巨大的隱患。

CoAP可靠組通信方案設計

3.1逐一單播方案

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

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

以上這種基于CoAP逐一單播的形式進行傳輸的要求是,接收端數量小于預設值Vs，如圖2所示。

圖2小規模接收端數量

3.2基于代理的可靠組通信實現方式

3.2.1逐一單播方案的局限性

通過逐一單播實現CoAP可靠組通信的方式，其優點是實現簡便，成本較低；而其缺點則是操作過程繁瑣，且僅適用于接收端數量較小時使用。

當系統中的接收端數量較多時，若繼續采用通過多個單播重復發送實現這一功能，則易導致出現以下幾個問題：

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

易產生發送端擁塞問題。

操作過程繁瑣。

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

圖3大規模接收端數量

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

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

3.2.2發送過程

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

由發送端通過CoAP單播的形式，將消息發送給代理服務器。

代理服務器將該消息報文解析后，獲取到本次發送的實際接收端的地址。

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

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

圖4代理服務器的布爾數組

3.2.3接收端匹配及反饋過程

在發送過程結束后，接收端結點接收消息報文的過程可分為以下幾步：

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

3.2.4代理服務器處理反饋并重專信息

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

代理服務器針對收到的眾多接收端發送來的反饋信息,根據眾接收端的地址和編號，針對其在發送步驟時創建的代表接收端狀態的布爾數組進行狀態變更。

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

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

狀態變更失敗或反饋信息發送失敗的接收端，在接收到由代理服務器發送來的重傳信息后，按照報文中的內容進行相應的操作，并將成功變更的信息反饋給代理服務器。

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

完成以上4步后，代理服務器需通過CoAP單播反饋給發送端一個確認信息，確認本次發送成功。

3.2.5發送連貫性

在以上步驟進行的過程中，發送端可以繼續發送后續命令，由于代理服務器的處理能力相比發送端較為優越，因此處理發送端重傳的功能由代理服務器完成，發送端在這一過程中可進行連貫發送。

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

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

(本次發送結束)

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

3.3特殊狀況處理

3.3.1結點睡眠

當接收端結點即將處于睡眠模式時，需要進行以下幾個步驟的操作：

接收端向CoAP資源目錄服務器發送一個消息，告知其關于自身狀態變更的消息；CoAP資源目錄服務器收到這一信息后，向代理服務器發送一個消息，告知后者該結點處于睡眠狀態；當代理服務器進行消息發送時，若查閱自身數據庫得知某結點已處于睡眠狀態，則需先發送一個睡眠喚醒消息,將這些結點喚醒，之后再針對該結點進行消息發送。

3.3.2結點關機或供電不足

當接收端結點即將關機（供電不足或人工關機）時，需要進行以下幾個步驟的操作：

接收端向CoAP資源目錄服務器發送一個消息，告知其關于自身即將關機的消息；CoAP資源目錄服務器收到這一信息后，向代理服務器發送一個消息，告知后者該結點處于關機狀態；當代理服務器進行消息發送時，若查閱自身數據庫得知某結點已處于關機狀態，則暫時保留本要發送的數據。當CoAP資源目錄服務器告知代理服務器關于該結點重新開機時，代理服務器再將本要發送消息發送給該結點。

4仿真實現CoAP可靠組通信

基于上文介紹的CoAP可靠組通信應用方案，利用JAVA仿真構建了一個基于代理的CoAP可靠組通信模擬系統，該系統可實現基于代理的模擬CoAP組通信。

圖6仿真實現CoAP可靠組通信

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

5結語

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

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

20211223_61c44a72eaefe__基于CoAP協議可靠組通信系統的設計及實現