多PAN太赫茲無線個域網邊緣節點信息高效報告方法

李 寧, 霍 兵, 宋瑞良, 任 智

(1. 中國電子科技集團公司第五十四研究所, 河北 石家莊 050081;2. 重慶郵電大學移動通信技術重慶市重點實驗室, 重慶 400065)

0 引 言

當前,傳統的無線接入技術難以滿足無線應用的巨大增長及其對高數據速率鏈路的需求,人們逐漸將目光投向了頻率更高的、尚未被完全開發的太赫茲頻段。但是THz無線電信號在傳播過程中容易被空氣中極性分子吸收,傳播越遠,衰減越大,這就決定了THz波只適用于短距離無線通信。通常一個太赫茲無線網絡的通信范圍只有10 m左右。為增大太赫茲無線網絡的通信范圍,IEEE 802.15.3標準允許同時運行多個微微網和父子微微網模型。當多個網絡共存時,若一個網絡在另一個網絡的通信范圍內,則兩個網絡會相互干擾。

為了使多個微微網能夠彼此共享資源并且相互之間不產生干擾,文獻[14]提出一種在802.15無線個域網(wireless personal area network, WPAN)中對齊信標的方法,該方法通過在競爭接入時段(contention access period, CAP)時段由網橋節點轉heartbeat消息,使兩個網絡的微微網控制器(piconet coordinator, PNC)通過動態的信標對齊的方式讓兩個微微網實現協調同步。為了提升帶寬分配效果,文獻[15]設計了一種適用于橋接下行接入時隙分配的自適應帶寬分配算法。文獻[16]介紹了IEEE 802.15.4標準的無線多跳自組網實現方案。文獻[17-18]提出了多跳場景下和多微微網運行時的高效操作機制。

文獻[19]提出一種基于簇的故障申告協議(failure declaring protocol, FDP),即網絡內的中心節點負責本網絡的故障申告管理,并能夠與其他網絡的中心節點直接通信,執行協作式故障管理。簇首節點根據該協議收集簇內節點故障信息,并將該信息報告給中心節點,使每個中心節點掌握本簇內所有節點實時的狀態信息。具體方法為:若節點D發生故障,則節點D生成含有自身故障信息的報文并報告給節點C,在收到節點C發來的確認反饋信息后,停止周期性發送故障信息;簇首節點C收到節點D發來的故障信息后,向節點D發送一個確認消息,表明已收到該故障信息,同時將該故障信息向中心管理節點O報告;然后,將該故障報文加入已發送故障報文隊列;在收到中心節點O的確認反饋消息之前,周期地發送該隊列中的所有消息;中心節點O在收到簇首節點C發來的故障信息后,向簇首節點C回復一個已收到故障信息的反饋消息;簇首節點C收到中心節點O發來的關于節點D的故障信息的確認報文之后,則從故障隊列中刪除該條關于節點D的故障信息,仍然周期性地發送故障隊列中的其他信息。

文獻[20]提出一種報文攜帶故障信息轉發的方法——錯誤信息傳送包(failure carrying packet, FCP)。FCP的基本思路為:報文在轉發過程中如果遇到有故障信息,則將該信息寫入報文;當報文到達某個節點時,該節點先檢測報文的故障信息字段,并根據該字段內容構建新的網絡拓撲;然后根據新的拓撲結構重新計算節點間最短路徑,從而消除報文轉發中的環路。

由上述分析可知,現有的多個域網(personal area network, PAN)的故障信息報告方法的研究雖然取得了一些成果,但仍然存在故障信息報告時控制開銷增大、報告信息時延較大及網間干擾較大等問題。

針對以上問題,本文提出了一種新的太赫茲網絡的高效自適應報告方法(efficient adaptive reporting approach of terahertz network, EARA-T)。通過OPNET軟件進行仿真分析,驗證所提方法對媒體訪問控制(medium access control, MAC)層協議性能的改善。

1 網絡模型與問題描述

1.1 網絡模型

本文所采用的網絡模型和超幀結構都是以IEEE 802.15.3標準為基礎。該標準規定的協調超幀所含時段的具體分布如圖1所示,協調超幀包括4個具有先后順序的時段,即:信標隊列時段(beacon alignment period,BAP)、CAP時段和兩種信道時間分配時段(channel time allocation period, CTAP)——常規CTAP(normal CTAP,N-CTAP)和公共CTAP(public CTAP,P-CTAP)。

圖1 協調超幀結構Fig.1 Coordinated superframe structure

為了更好地減少網絡中節點在N-CTAP時段所受到的干擾,在原有網內節點的基礎上按照是否會偵聽到相鄰網絡節點消息將網內節點類型細分為普通節點以及邊緣節點。節點類型示意圖如圖2所示。

圖2 節點類型示意圖Fig.2 Schematic diagram of node type

多PAN太赫茲無線個域網中的節點類型分為4類,具體如下。

中心節點:即PNC節點,如圖2中的節點PNC1和PNC2,每個PAN只含有1個PNC節點,不同PAN的PNC節點不能直接通信。

網間節點:能夠直接與兩個不同的PAN的PNC節點進行通信的節點,如圖2中的節點a;該類型節點只能在P-CTAP時段中進行數據傳輸。

普通節點:只能與自己所在PAN的節點通信并且自身不屬于PNC和網間節點類型的節點,如圖2中的節點④和節點b;該類型節點只能在N-CTAP時段中進行數據傳輸。

邊緣節點:能夠與另一PAN中的常規節點(非PNC和網間節點)直接通信的常規節點,如圖2中的節點②和節點d;該類型節點在N-CTAP時段中傳輸數據,但在通信時有可能受到相鄰PAN的常規節點的干擾,產生幀碰撞。

一個常規節點可以通過判斷確定自己是邊緣節點,具體判斷方法是:自己是常規節點,且收到了另一PAN的常規節點發出的消息。如果節點判定自己是邊緣節點,則需將自己的節點類型信息報告給PNC。

1.2 問題描述

在深入研究基于IEEE 802.15.3的多PAN太赫茲無線個域網MAC協議后,發現其存在以下問題:

(1) 不同PAN的邊緣節點在通信過程中會相互干擾,產生幀的碰撞,導致幀傳輸失敗,影響邊緣節點間的通信效果。

(2) 一個節點是否為邊緣節點,需要通過相應的幀報告給PNC,使PNC在時隙分配時加以考慮,避免邊緣節點間幀碰撞造成網間干擾問題。

2 自適應節點類型報告新機制

為了解決上述問題,現基于太赫茲網間傳輸協議,提出EARA-T方法將邊緣節點間幀碰撞產生的故障信息通過網絡中的設備(device, DEV)及時高效地報告給PNC。

在常規節點的基礎上定義一種新的節點類型——邊緣節點。邊緣節點是指本網絡中處于對方網絡常規節點通信范圍之內的常規節點。

2.1 DEV向PNC報告節點類型信息

為了報告節點間信道干擾問題,DEV需將邊緣節點類型信息及時高效的報告給PNC,基本機制如下。

2.1.1 節點入網前

節點偵聽到附近網絡PNC發送的Beacon幀時,進行入網準備。在入網過程中,如果節點偵聽到與本PAN的微微網標識(piconet identifier, PNID)不同的PAN節點發送的消息,并且未收到其他PAN的PNC發送的信標幀,則將自身節點類型判定為邊緣節點,并將節點類型信息(使用Command type字段中的0x001F表示)放入關聯請求幀中發送給PNC。

2.1.2 CAP時段

在網絡運行的過程中,節點自身的類型發生變化時通過信道時隙請求幀將自身狀態信息告知PNC。主要操作步驟如下。

如果節點的類型為普通節點,則在為申請時隙而發送時隙申請幀時在該幀的Command type字段填入默認幀類型值0x0012。

如果節點從普通節點類型變成了邊緣節點類型,則在為申請時隙而發送時隙申請幀時在該幀的Command type字段填入新的幀類型值——0x0030,表明該節點已由普通節點變成了邊緣節點。

如果節點的類型從邊緣節點類型變成了普通節點類型,則在為申請時隙而發送時隙申請幀時在該幀的Command type字段填入新的幀類型值——0x0031。

2.1.3 CTAP時段

如果節點需要和其他節點進行數據交互,可以將節點類型信息通過數據幀或立即確認幀攜帶給PNC。

如果節點在報告自己的狀態變化信息后未收到PNC的回復,則在后續超幀的CAP和CTAP時段繼續報告,直至收到PNC的回復消息為止。

第一種情況,網絡中節點總數大于127時,節點類型信息報告機制如下。

(1) 該節點為數據發送方。節點類型未發生改變時,將所要發送的數據幀幀頭的Frame control字段中的Frame type字段設置為默認幀類型值“100”;節點類型從邊緣節點變為普通節點時,將所要發送的數據幀幀頭的Frame control字段中的Frame type字段設置為“101”,并且將Fragmentation control字段中的Reserved值設置為0;節點類型從普通節點變為邊緣節點時,將所要發送的數據幀幀頭的Frame control字段中的Frame type字段設置為“101”,并且將Fragmentation control字段中的Reserved值設置為1。

(2) 該節點為數據接收方。節點類型未發生改變時,將所要發送的確認幀(acknowledgment, ACK)幀頭的Frame control字段中的Frame type字段設置為默認幀類型值“001”;節點類型從邊緣節點變為普通節點時,將所要發送的ACK幀幀頭的Frame control字段中的Frame type字段設置為“111”;節點類型從普通節點變為邊緣節點時,將所要發送的ACK幀幀頭的Frame control字段中的Frame type字段設置為“111”,并且將Fragmentation control字段中的Reserved設置為1。

此時,PNC進行泛聽偵聽微微網內節點發送的數據幀或立即確認幀。在偵聽到該幀時,首先查看該幀的目標節點地址(destination identifier, DestID)字段,無論字段的地址是否是自身地址都不丟棄。其次,查看該幀的Frame control字段中的Frame type字段值及Fragmentation control字段中的Reserved值,并記錄節點類型值對應的節點類型信息。

第二種情況,網絡中節點數不大于127時,節點類型信息報告機制如下。

(1) 節點類型未發生改變,其數據幀(或ACK幀)中的DestID中的值為目的地址值。

(2) 節點類型發生改變時,其數據幀(或ACK幀)中的DestID中的值為目的地址值加上127。節點類型從邊緣節點變為普通節點時,數據幀(或ACK幀)中的源節點地址(source identifier, SrcID)字段中放置自身節點地址值;節點類型從普通節點變為邊緣節點時,將自身節點的地址值加上127放入數據幀(或ACK幀)中的SrcID字段中。

此時,PNC進行偵聽微微網內節點發送的數據幀或立即確認幀。在偵聽到該幀時,首先查看該幀的DestID。如果DestID字段值大于127則查看該幀的SrcID字段。如果該幀的SrcID字段值不大于127,則將SrcID字段值對應的節點標記為普通節點;反之,將SrcID字段值減去127對應的節點標記為邊緣節點。其他DEV節點在偵聽到該幀時,如果DestID字段值大于127,則將該值減去127與自身地址比較;如果DestID值不大于127則直接將該值與自身地址值比較。如果兩者相同,則接收該幀;否則,丟棄該幀。

2.2 PNC向DEV回復確認信息

為了減少非必要的DEV報告消息,PNC需向DEV回復確認信息,基本機制如下。

2.2.1 節點入網前

PNC在收到節點攜帶自身類型信息的關聯請求幀后,向DEV回復關聯請求確認幀表示已收到節點的類型信息。

2.2.2 CAP時段

PNC收到節點攜帶自身類型信息的時隙請求幀后,如果節點收到時隙請求回復幀,則表明PNC已經收到節點報告的類型信息。

2.2.3 CTAP時段

PNC在回復DEV的消息時使用保留值、保留位與現有值相結合的方式在ACK幀或數據幀中表示所要回復的DEV的序號(8 bit表示,分別為b0～b7)。

具體表示方式如下。

(1) PNC使用ACK幀進行回復,將自己要回復的節點的DEVID用保留位、保留值與現有值相結合的方式來表示。Frame type字段中的保留值“001、101、110、111”分別表示所攜帶的DEVID的b7b6為“00、01、10、11”;使用Frame control字段中的保留值b15-b11分別表示DEVID中的b5-b1;使用Fragmentation control字段中的保留值b23表示DEVID的b0字段。

(2) PNC使用數據幀進行回復,將自己要回復的節點的DEVID用保留位與現有值相結合的方式來表示。Frame type字段的現有值010表示類型為數據幀,使用Frame control中Protocol version字段的現有值000和保留值001、010、011表示b7～b6位值分別為00、01、10、11;用Frame control字段中的保留值b15-b11分別表示DEVID中的b5-b1;使用Fragmentation control字段中的保留值b23表示DEVID的b0字段。

具體操作機制如下。

(1) PNC將所要回復的DEVID放置在回復給其他節點的ACK幀或數據幀中。

(2) 已發送節點類型信息但未收到PNC確認消息的節點進行泛聽。若偵聽到上述ACK幀或數據幀,則首先查看該幀的DestID值是否為自己,若為自己則直接接收;否則,查看該幀中的SrcID。如果該幀中的SrcID值不為0,則直接丟棄該幀;否則,繼續查看該幀中Frame type字段,根據Frame type字段值進行操作。

(3) 如果該幀中Frame type值為“001、101、110、111”,查看DEVID對應的字段值,如果DEVID與自身節點地址相同則表示PNC已經收到節點發送的類型信息,結束偵聽;否則繼續偵聽。如果該幀中Frame type值為“010”,則查看Protocol version字段、Fragmentation control和Frame control中的保留字段的值,若均為0,則確定該幀為普通的不攜帶PNC回復信息的數據幀,不再做后續操作;若上述字段的值不全為0,則用Protocol version字段的現有值(000)和保留值(001、010、011)(表示b7～b6位的值)、前述6位保留字段的值(表示b5～b0位的值)組成DEVID,然后將DEVID與自身節點地址進行比對,若相等則表示PNC已經接收到本節點報告的類型信息,結束泛聽;若不相等則繼續偵聽。

3 性能分析

與FDP和FCP協議相比,本文提出的EARA-T方法信息報告控制開銷較小。

假設網絡中PAN的個數為2,每個PAN中有一個PNC和個DEV,個DEV中為邊緣節點的概率為,第個邊緣節點信息報告成功的概率為,則第個邊緣節點信息成功報告所需的次數為1。其中表示FCP協議中攜帶故障信息的時隙請求幀的幀長,表示FCP協議中回復幀的幀長;表示FDP協議中時隙請求幀的幀長,表示該協議中回復幀幀長,、分別表示該協議中新增的故障申告幀及申告回復幀的幀長;、分別表示本文提出的EARA-T方法中時隙申請幀及回復幀的幀長。假設兩種對比協議及EARA-T方法中DEV個數,邊緣節點概率,第個邊緣節點信息報告成功率的值都相同。

FCP協議總的信息報告控制開銷為

(1)

FDP協議總的信息報告控制開銷為

(2)

EARA-T方法總的信息報告控制開銷為

(3)

其中,由于FDP協議是將報告信息通過新的故障申告幀報告給PNC,FCP協議將報告信息通過報文攜帶轉發的方式報告給PNC,本文提出的EARA-T方法將報告信息通過原有幀的保留值字段改變報告給PNC。則時隙請求幀=<,回復幀==。可推得+=+<+。由于FDP中新增的信息申告幀開銷+大于FCP協議中的新增信息報告字段開銷-,則可推得(+++)-(+)>0。所以本文提出的EARA-T方法信息報告控制開銷最小,即CEARA-T

證畢

4 仿真實驗

本文采用仿真軟件OPNET14.5進行仿真驗證,將本文提出的EARA-T方法與FDP和FCP協議的性能進行了比較。

4.1 仿真統計量

本文從以下仿真統計量參數方面進行了仿真性能驗證。

(1) 信息報告控制開銷

信息報告控制開銷指為報告邊緣節點信息所導致的控制開銷的比特數,單位為bit,計算式為

(4)

式中:表示網絡中信息報告的次數;表示第次信息報告的控制消息比特數。

(2) 信息報告時延

信息報告時延指網絡中故障信息報告幀從發送端到接收端的平均耗時,單位為ms,計算式為

(5)

式中:表示網絡中信息報告的次數;表示第幀從發送端到接收端的時延。

(3) 信息報告成功率

信息報告成功率指網絡中到達目的節點的信息報告幀數據量與源節點發送的信息報告幀數據量之比,計算式為

(6)

式中:表示節點個數;表示第個節點接收的信息報告幀數據量;表示第個節點發送的信息報告幀數據量。

(4) 吞吐量

吞吐量指網絡中單位時間內到達目的節點的數據量,單位為bps(bit/s),計算式為

(7)

式中:表示網絡運行時間;表示時間內第個節點所接收的數據量。

4.2 仿真參數設置

本文采用仿真軟件OPNET14.5進行仿真驗證,根據太赫茲無線通信的特點并結合典型的相關文獻,設置主要仿真參數如表1所示。

表1 主要仿真參數

4.3 仿真結果分析

3種協議的信息報告控制開銷如圖3所示。從圖3可以看出,EARA-T的信息報告控制開銷是3種協議中最小的,相較于FDP和FCP協議,本文提出的方法分別降低了23.9%和14.1%。這是由于FCP協議將故障信息通過原有幀攜帶轉發的方式報告,EARA-T通過原有幀類型中的字段保留位值的改變報告故障信息。FDP協議增加新的幀類型申告故障信息,極大地增加了協議的信息報告控制開銷。

圖3 信息報告控制開銷Fig.3 Information reporting controls overhead

3種協議的信息報告時延如圖4所示。從圖4中可以看出,隨著節點數的增多,信息報告時延逐漸增大。相較于FDP和FCP協議,EARA-T的信息報告時延最小,分別降低了11.2%和3.7%。這是因為FCP協議攜帶的故障信息使得信息報告數據包增大,傳輸時延隨之增大。由于FDP協議增加了新的故障申告幀去報告故障信息,而本文提出的新方法沒有增加新的幀類型去報告故障信息,隨著節點數的增多EARA-T的信息報告時延始終低于FDP協議的信息報告時延。

圖4 信息報告時延Fig.4 Information reporting delay

3種協議的信息報告成功率如圖5所示。隨著節點數的增多,3種協議的信息報告成功率都有所下降。但EARA-T的信息報告成功率始終是3種協議中最高的,相較于FDP和FCP協議,本文提出的方法分別提高了1.2%和0.4%。這是由于EARA-T通過原有幀類型中字段保留值報告故障信息,而FCP增加新的報告故障信息的字段,FDP協議通過新的幀申告故障信息。EARA-T報告故障信息時,發送的數據包最小,產生碰撞的幾率更小,發送的成功率更高。

圖5 信息報告成功率Fig.5 Success rate of information report

本文提出的方法與其他兩種協議的吞吐量對比如圖6所示。隨著節點數的增加,整個網絡的吞吐量逐漸增加至最大后,呈下降趨勢。這是由于節點密度的增加,節點申請通信時隙的幀碰撞機率更大,申請時隙成功的幾率逐漸減少。由于其他PAN邊緣節點通信的影響,導致數據幀碰撞幾率增大,數據幀發送成功幾率減少。但是,本文提出的方法與其他兩種方法相比,整個網絡的吞吐量基本相近,并沒有導致吞吐量性能的下降。

圖6 吞吐量Fig.6 Throughput

當網絡中總節點數大于127時,255節點場景下的仿真數據如表2所示。從表2可以看出,節點數增加時整個網絡中的信息報告時延、信息報告控制開銷較節點數小于127的仿真場景都有所增加,信息報告成功率及網絡的吞吐量進一步下降。但節點數大于127時統計結果的變化范圍都較為合理。

表2 255節點場景下仿真結果

5 結束語

本文針對太赫茲無線個域網絡跨PAN通信所存在的N-CTAP時段邊緣節點數據傳輸受干擾問題,提出了一種新的多PAN太赫茲無線個域網邊緣節點信息高效自適應報告方法——EARA-T,并將該方法與FDP和FCP協議的性能進行了比較。通過OPNET軟件的仿真驗證,可以得出EARA-T方法相較于其他兩種協議在性能上有不小于0.4%的改善。在下一步工作中,將考慮讓PNC根據節點通信類型的不同有規律地為節點分配時隙并且跨PAN傳送時隙分配比例信息,從而有效地解決邊緣節點間幀碰撞帶來的網間節點的干擾問題。