李付勇,夏潔,姜勝明
(上海海事大學信息工程學院,上海201306)
MAC[1,2](Medium Access Control)協議是無線多跳網絡[3](Multi-Hop Wireless Network)的基礎,控制著節點對無線媒介的占用,決定了無線信道的使用方式,其性能直接影響了整個網絡的性能。無線自組網中信道共享且受節點發射功率限制,每個通信節點的傳輸范圍是受到限制的。通常需要中間節點作為中繼實現節點間多跳通信,因此數據沖突與節點所在位置相關。此外,無線通信中,受到障礙物和信道衰落的影響節點間通信會出現時延。綜上傳輸范圍、節點位置和時延等因素,無線網絡中隱藏終端和暴露終端[4,5]的問題是無法避免的。終端問題嚴重降低了MAC協議的性能,為了獲得更高的信道利用率、更低的延遲和更加公平的競爭,必須解決終端問題。
隱藏終端是指在接收方通信范圍內且在發送方通信范圍之外的節點,而暴露終端指的是在發送方的通信范圍內且在接收方傳輸范圍之外的節點。
以隱藏終端問題為例:當一個節點發送數據時,在其傳輸范圍之外的節點無法察覺到有其他節點正在發送數據,這可能會導致數據沖突。如圖1所示,當A向B發送數據時,C也向B發送數據,因此,這兩組消息將在B發生沖突,導致傳輸失敗。此時,C被稱為隱藏終端。

圖1 隱藏終端示意圖
針對以上終端問題,已有方法總結如下:1)通過發送忙音信號通知鄰居節點,如BTMA協議系列;2)數據傳輸之前,發送方首先發送請求幀給接收方,接收方收到請求時以確認幀的方式告知其他鄰居節點它即將進行接收,即 RTS/CTS[6]方式,如 CSMA/CA、MACA[7]、MACAW[8]、FAMA[9]。綜上解決方法,解決隱藏終端的關鍵是如何通知鄰居節點了解接收節點的接收狀態。本文提出一種基于節點狀態更新的DBTMA[10,11]改進方法,該方法通過實時監控、更新并收集節點狀態來判斷是否進行數據傳輸。仿真表明該方法準確掌握接收節點的行為,減少請求握手次數和狀態誤判,從而有效避免隱藏終端問題,提高數據傳輸效率、網絡吞吐量和信道利用率。
DBTMA全稱為雙忙音多址接入協議,該協議采用多信道方式——將信道分為兩個彼此獨立的子信道:數據信道和控制信道。在數據信道上發送數據,在控制信道上發送控制幀(RTS和CTS),并且在控制信道上增加忙音信號BT(t發送忙音)——表明數據信道正在傳輸數據和忙音信號BTr(接收忙音)——表明數據信道上正在接收數據。BTt發送忙音信號為RTS幀的傳輸提供保護,并增加接收方的RTS接收成功率;BTr對RTS做出響應并為傳輸的數據提供連續的保護。所有聽到任何忙音的節點都不允許發送RTS請求。當收聽BTr信號建立時,發送RTS幀的節點需要立即放棄傳輸。隱藏終端因為偵聽到BTr忙音信號不會發送數據,避免了數據沖突的發生因而得到解決。
工作于DBTMA協議的節點共有七種狀態,具體如表1:

表1 DBTMA的七種狀態描述
DBTMA協議的工作方式通過圖2隱藏終端示意圖進行解釋。

圖2
根據1.2 DBTMA協議工作方式一節可知,運行DBTMA協議的節點必然處于以下七個狀態之一IDLE,CONTEND,S_RTS,S_DATA,WF_BTR,WF_DATA,WAIT。基于此,設計一個7位二進制節點狀態碼:如表2:

表2 節點狀態碼結構
以1表示在此狀態,0表示不在此狀態,從而每個節點都有一個狀態碼,此狀態碼用來描述節點狀態信息。由此可以得到七個基于二進制的7位二進制狀態碼status_code(如表 2):0000001WAIT,0000010WF_DATA,0000100WF_BTR,0001000S_DATA,0010000S_RTS,0100000CONTEND,1000000 IDLE。
基于節點狀態碼和DBTMA協議忙音策略設計節點狀態碼計劃表,如表3:

表3 節點狀態碼計劃表結構
btt字段為1表示當前節點建立btt信號,btr字段為1表示當前節點建立btr信號,is_busy字段為1代表當前有忙音信號(即節點btt或btr任意字段值為1)。
傳統收集網絡節點信息的方法都是廣播,但是廣播代價是不容忽視的。為此,提出以下優化方法:以集群式網絡為例。根據2.1設計節點狀態碼結構可知,節點處于IDLE(空閑)狀態時狀態碼為1000000,此時節點狀態碼最大負載最小。周圍鄰居節點將各自的狀態碼發送至此節點并將其作為鄰居的負載點,如果有多個最大狀態碼的節點,隨機選擇一個作為負載點。
根據2.3節點狀態信息的收集得到鄰居節點的負載點,該負載點擁有鄰居節點的所有狀態碼(包括自己的狀態碼)。負載點將鄰居節點的所有狀態碼信息封裝在狀態表中,并將表信息發送至周圍鄰居節點,從而各個節點均知道了鄰居節點的狀態碼。網絡中各節點均按此規則收集鄰居節點的狀態碼,從而得到網絡中所有節點的狀態碼。由于無線網絡中所有節點均有可能發生移動且節點狀態隨時變化。因此負載點的選取和狀態表信息均需要及時更新,具體更新策略為:節點狀態碼同步更新到狀態表中;上次確定為負載點的節點主動向周圍鄰居節點發出狀態碼快照并收集到狀態表中,比較個節點的狀態碼大小;將各節點狀態碼發送至周圍鄰居節點并確定狀態碼最大的節點作為負載點而本次作為負載點的節點主動放棄下次負載點的機會。
以圖3集群網絡示意圖為例,具體闡述節點狀態碼數據的收集和共享細節:

圖3 集群網絡示意圖
圖中共有A、B、C、D四個集群以及一個中心節點E。網絡初始化時,假設A3,B3,C3,D3分別為各自集群中狀態碼最大的節點。A集群中A(ii=1,2,4,5)分別將各自的狀態碼發送給A3節點,B集群中B(ii=1,2,4,5)分別將各自的狀態碼發送給B3節點,C集群和D集群以此類推。A3、B3、C3、D3分別拿到各自集群中所有節點的狀態碼,A3、B3、C3、D3再將各自集群中的狀態碼發送給中心節點E,至此E節點拿到網絡中所有節點的狀態碼。E節點將所有節點的狀態碼數據封裝在狀態表中并將此表下發給 A3、B3、C3、D3。A3、B3、C3、D3再將狀態表發給所在集群中的其他節點。至此,網絡中所有節點均擁有了網絡內各個節點的狀態碼。
基于狀態表決策流程圖,如圖4所示。以圖1隱藏終端示意圖為例,其具體決策機制結合狀態表具體闡述如下:
說明:
條件1,4:查看狀態表有btt字段值為1的鄰居節點
條件2,5:查看狀態表無is_busy字段值為1的鄰居節點
條件3:查看狀態表有is_busy字段值為1的鄰居節點
網絡初始化時,各節點均處于IDLE狀態,此時狀態表數據如表4:

圖4 節點決策流程圖

表4
(1)當節點A100000有數據分組需要向B1000000發送,滿足條件2時更新自身狀態碼為,即(2)建立BTt信號進入S_RTS狀態,此時狀態表數據如表5:

表5

表6
B1000000接收到A節點發送的RTS請求幀,BTr字段設為1,之后建立起定時器并進入WF_DATA狀態,即B1000000更新自身狀態碼為,此時狀態表數據如表7:

表7
節點A0000100持續查看狀態表發現建立了BTr信號,確認自己的信道請求成功。(4)等待一段時間進入WAIT狀態,即更新自身狀態碼為A0000001,此時狀態表數據如表8:

表8
A0000001定時器超時后,(5)進入S_DATA狀態即更新自身狀態碼為A0001000,此時狀態表數據如表9:

表9
A0001000傳輸完成,(6)重新進入IDLE狀態,即更新自身狀態碼為A1000000,此時狀態表數據如表10;

表10

表11
同理,當 A100000滿足條件3時,(7)進入CONTEND狀態,即更新自身狀態碼為A0100000并同步到狀態表中;A0100000收到RTS時,(8)滿足條件4時,建立BTr進入WF_DATA狀態,即更新自身狀態碼為并同步更新到狀態表;(9)接收完數據分組或等待數據超時后進入IDLE狀態,即更新自身狀態碼為A1000000。當滿足條件5時進入S_RTS狀態,即更新自身狀態碼為并同步更新到狀態表。
同理,當 A100000滿足條件1時,(10)進入WF_DATA狀態,即更新自身狀態碼為并同步更新到狀態表;(9)接收完數據分組或等待數據超時后進入IDLE狀態,即更新自身狀態碼為A1000000。
如圖1隱藏終端示意圖,A節點向B節點發送數據時,即A節點處于A0001000狀態,B節點處于狀態,此時網絡中節點狀態表數據信息如表12。

表12
(1)nRF51822藍牙協議
本文提出的基于節點更新狀態DBTMA改進方法的實際實現平臺是基于nRF51822藍牙協議,該協議的分析模型如圖5:

圖5 nRF51822藍牙協議分層模型
主協議層的 GAP(Generic Access Profile),管理廣播和連接的有關參數且具有以下特征:
①角色
GAP中規定一個設備不是集中器角色就是外圍設備角色,集中器是連接的發起者,外圍設備是被連接者,相當于鏈路層的主機和從機。另外該藍牙協議規范還定義了觀察者角色和廣播者角色,觀察者角色只監聽空中事件,廣播者角色只廣播信息而不接收信息。
②廣播
集中器能夠與外圍設備建立連接,外圍設備必須處于廣播狀態,它每經過一個時間間隔發送一次廣播數據包,這個時間間隔稱為廣播間隔,它的范圍是20ms到10.24s,廣播間隔影響建立連接的時間。
集中器發送一個連接請求來發起連接之前,必須接收到一個廣播數據包,外圍設備發送一個廣播數據包之后一小段時間內只監聽連接請求。
一個廣播數據包最多能攜帶31字節的數據,它通常包含用戶可讀的名字、關于設備發送數據包的有關信息、用于表示此設備是否可被發現的標志等類似的標志。
當集中器接收到廣播數據包后,它可能發送請求更多數據包的請求,稱為掃描回應,如果它被設置成主動掃描,外圍設備將會發送一個掃描回應做為對集中器請求的回應,掃描回應最多可以攜帶31字節的數據。
③掃描
掃描是集中器監聽廣播數據包和發送掃描請求的過程,它有2個定時參數:掃描窗口和掃描間隔。
(2)nRF51822藍牙協議在基于節點更新狀態DBTMA改進方法的應用
基于節點更新狀態DBTMA改進方法的狀態表信息存放于外圍設備的廣播數據包中,當集中器角色發起連接前,首先查看數據包中鄰居節點的狀態碼。根據2.5節基于狀態表的決策策略是否發起連接,當外圍角色監聽到集中器的連接請求時更新自身狀態碼到廣播數據包中的狀態碼中。此時,當別的集中器接收到外圍設備的廣播數據包時,查看其狀態碼信息發現外圍設備正在接收數據。因而,不會發送請求到外圍設備,隱藏終端問題得以在實際平臺中實現。
為了測試和分析基于節點更新狀態DBTMA改進方法的有效性和性能。本節在仿真環境下,通過改變原MAC幀結構,即在原MAC幀中加入本文所提出的7位二進制狀態碼,觀察各個協議之間的性能。每次仿真結果為每10次運行結果的平均值。
仿真環境:首先,研究了不同隱藏終端情況下的各方案的性能。我們在具有N(N=1,2,…,6)個獨立網絡集群和一個公共接收節點Ad Hoc網絡中模擬各個協議。每個集群有5個節點,每個節點通信范圍內互通。以N=4為例,如圖2。RTS數據幀長度為200b,數據包長度為4096b,信道傳輸速率為1M/S。圖6比較了在相同環境下各個協議方案的性能。

圖6 協議性能對比圖
從圖6中我們可以看出基于節點狀態更新的方法相比較于其他任何一種MAC方案有著更高的吞吐量。當N為1時,該方法的網絡利用率低于DBTMA這是由于狀態表的首先收集網絡中各個節點的狀態碼并通知集群中的各個節點,造成初始時效率低于DBTMA協議。但是當N≥2時,該方法相對于DBTMA信道利用率和吞吐量明顯更具有優勢,因為本文提出的基于節點狀態更新的解決方法初始時以很小的代價收集網絡中各個節點狀態信息。狀態表準確實時地更新各節點的接收狀態,減少對接收端握手請求次數和避免對接收端接收計劃的誤判,從而能夠大大提高網絡的吞吐量和信道利用率。
本文在深入學習MAC層隱藏終端和暴露終端問題研究的基礎上,提出了一種基于節點更新狀態的DBTMA改進方法,巧妙利用各個節點狀態設計節點狀態碼結構并封裝狀態碼信息于狀態表,狀態表實時收集并更新節點狀態碼信息。節點基于狀態表信息判斷是否發送數據,該方法相比較于DBTMA協議,通過減少對接收端握手請求次數,提高了網絡吞吐量和信道利用率,避免了對接收端接收計劃的誤判從而數據傳輸更加準確有效。