多PAN太赫茲無線個域網(wǎng)邊緣節(jié)點信息高效報告方法

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

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

0 引 言

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

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

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

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

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

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

1 網(wǎng)絡(luò)模型與問題描述

1.1 網(wǎng)絡(luò)模型

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

圖1 協(xié)調(diào)超幀結(jié)構(gòu)Fig.1 Coordinated superframe structure

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

圖2 節(jié)點類型示意圖Fig.2 Schematic diagram of node type

多PAN太赫茲無線個域網(wǎng)中的節(jié)點類型分為4類,具體如下。

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

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

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

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

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

1.2 問題描述

在深入研究基于IEEE 802.15.3的多PAN太赫茲無線個域網(wǎng)MAC協(xié)議后,發(fā)現(xiàn)其存在以下問題:

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

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

2 自適應(yīng)節(jié)點類型報告新機制

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

在常規(guī)節(jié)點的基礎(chǔ)上定義一種新的節(jié)點類型——邊緣節(jié)點。邊緣節(jié)點是指本網(wǎng)絡(luò)中處于對方網(wǎng)絡(luò)常規(guī)節(jié)點通信范圍之內(nèi)的常規(guī)節(jié)點。

2.1 DEV向PNC報告節(jié)點類型信息

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

2.1.1 節(jié)點入網(wǎng)前

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

2.1.2 CAP時段

在網(wǎng)絡(luò)運行的過程中,節(jié)點自身的類型發(fā)生變化時通過信道時隙請求幀將自身狀態(tài)信息告知PNC。主要操作步驟如下。

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

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

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

2.1.3 CTAP時段

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

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

第一種情況,網(wǎng)絡(luò)中節(jié)點總數(shù)大于127時,節(jié)點類型信息報告機制如下。

(1) 該節(jié)點為數(shù)據(jù)發(fā)送方。節(jié)點類型未發(fā)生改變時,將所要發(fā)送的數(shù)據(jù)幀幀頭的Frame control字段中的Frame type字段設(shè)置為默認幀類型值“100”;節(jié)點類型從邊緣節(jié)點變?yōu)槠胀ü?jié)點時,將所要發(fā)送的數(shù)據(jù)幀幀頭的Frame control字段中的Frame type字段設(shè)置為“101”,并且將Fragmentation control字段中的Reserved值設(shè)置為0;節(jié)點類型從普通節(jié)點變?yōu)檫吘壒?jié)點時,將所要發(fā)送的數(shù)據(jù)幀幀頭的Frame control字段中的Frame type字段設(shè)置為“101”,并且將Fragmentation control字段中的Reserved值設(shè)置為1。

(2) 該節(jié)點為數(shù)據(jù)接收方。節(jié)點類型未發(fā)生改變時,將所要發(fā)送的確認幀(acknowledgment, ACK)幀頭的Frame control字段中的Frame type字段設(shè)置為默認幀類型值“001”;節(jié)點類型從邊緣節(jié)點變?yōu)槠胀ü?jié)點時,將所要發(fā)送的ACK幀幀頭的Frame control字段中的Frame type字段設(shè)置為“111”;節(jié)點類型從普通節(jié)點變?yōu)檫吘壒?jié)點時,將所要發(fā)送的ACK幀幀頭的Frame control字段中的Frame type字段設(shè)置為“111”,并且將Fragmentation control字段中的Reserved設(shè)置為1。

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

第二種情況,網(wǎng)絡(luò)中節(jié)點數(shù)不大于127時,節(jié)點類型信息報告機制如下。

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

(2) 節(jié)點類型發(fā)生改變時,其數(shù)據(jù)幀(或ACK幀)中的DestID中的值為目的地址值加上127。節(jié)點類型從邊緣節(jié)點變?yōu)槠胀ü?jié)點時,數(shù)據(jù)幀(或ACK幀)中的源節(jié)點地址(source identifier, SrcID)字段中放置自身節(jié)點地址值;節(jié)點類型從普通節(jié)點變?yōu)檫吘壒?jié)點時,將自身節(jié)點的地址值加上127放入數(shù)據(jù)幀(或ACK幀)中的SrcID字段中。

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

2.2 PNC向DEV回復確認信息

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

2.2.1 節(jié)點入網(wǎng)前

PNC在收到節(jié)點攜帶自身類型信息的關(guān)聯(lián)請求幀后,向DEV回復關(guān)聯(lián)請求確認幀表示已收到節(jié)點的類型信息。

2.2.2 CAP時段

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

2.2.3 CTAP時段

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

具體表示方式如下。

(1) PNC使用ACK幀進行回復,將自己要回復的節(jié)點的DEVID用保留位、保留值與現(xiàn)有值相結(jié)合的方式來表示。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使用數(shù)據(jù)幀進行回復,將自己要回復的節(jié)點的DEVID用保留位與現(xiàn)有值相結(jié)合的方式來表示。Frame type字段的現(xiàn)有值010表示類型為數(shù)據(jù)幀,使用Frame control中Protocol version字段的現(xiàn)有值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放置在回復給其他節(jié)點的ACK幀或數(shù)據(jù)幀中。

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

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

3 性能分析

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

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

FCP協(xié)議總的信息報告控制開銷為

(1)

FDP協(xié)議總的信息報告控制開銷為

(2)

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

(3)

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

證畢

4 仿真實驗

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

4.1 仿真統(tǒng)計量

本文從以下仿真統(tǒng)計量參數(shù)方面進行了仿真性能驗證。

(1) 信息報告控制開銷

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

(4)

式中:表示網(wǎng)絡(luò)中信息報告的次數(shù);表示第次信息報告的控制消息比特數(shù)。

(2) 信息報告時延

信息報告時延指網(wǎng)絡(luò)中故障信息報告幀從發(fā)送端到接收端的平均耗時,單位為ms,計算式為

(5)

式中:表示網(wǎng)絡(luò)中信息報告的次數(shù);表示第幀從發(fā)送端到接收端的時延。

(3) 信息報告成功率

信息報告成功率指網(wǎng)絡(luò)中到達目的節(jié)點的信息報告幀數(shù)據(jù)量與源節(jié)點發(fā)送的信息報告幀數(shù)據(jù)量之比,計算式為

(6)

式中:表示節(jié)點個數(shù);表示第個節(jié)點接收的信息報告幀數(shù)據(jù)量;表示第個節(jié)點發(fā)送的信息報告幀數(shù)據(jù)量。

(4) 吞吐量

吞吐量指網(wǎng)絡(luò)中單位時間內(nèi)到達目的節(jié)點的數(shù)據(jù)量,單位為bps(bit/s),計算式為

(7)

式中:表示網(wǎng)絡(luò)運行時間;表示時間內(nèi)第個節(jié)點所接收的數(shù)據(jù)量。

4.2 仿真參數(shù)設(shè)置

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

表1 主要仿真參數(shù)

4.3 仿真結(jié)果分析

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

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

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

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

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

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

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

圖6 吞吐量Fig.6 Throughput

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

表2 255節(jié)點場景下仿真結(jié)果

5 結(jié)束語

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