何榮毅,王小群,陳楷豐
(山東大學(xué)(威海)網(wǎng)絡(luò)與信息管理中心,山東 威海 264209)
近年來,無線通信技術(shù)和消費電子的發(fā)展,使得在消費電子中的建設(shè)網(wǎng)絡(luò)成為可能,并加速了物聯(lián)網(wǎng)(Internet of Things,IoT)的快速增長[1-2]。IoT的主要目標(biāo)是將現(xiàn)實世界中的現(xiàn)有對象或事物與因特網(wǎng)集成,以創(chuàng)建所有對象和機器自動交互的新方法。為向物聯(lián)網(wǎng)提供更多不同的應(yīng)用,無線設(shè)備須支持比傳統(tǒng)無線技術(shù)更高的傳輸速率。超寬帶(Ultra Wide Band,UWB)技術(shù)是一種應(yīng)用于高速無線數(shù)據(jù)傳輸和長距離定位的無線技術(shù),由于其吞吐量優(yōu)于Wi-Fi,因此適合于多媒體應(yīng)用,UWB是市場上出現(xiàn)的較新的無線網(wǎng)絡(luò)技術(shù),具有高數(shù)據(jù)速率和低功耗的客觀要求,其效率比Wi-Fi高80%~90%[3]。
WiMedia聯(lián)盟已經(jīng)為高速WPAN指定了基于UWB的PHY/MAC標(biāo)準(zhǔn)。WPAN的傳統(tǒng)標(biāo)準(zhǔn)支持集中式MAC方法并形成微網(wǎng)。在物聯(lián)網(wǎng)應(yīng)用中可同時操作微網(wǎng)(SOP),而移動性支持和為同步流提供服務(wù)質(zhì)量(QoS)是核心需求[4-5]。例如,文獻[6]為提高WiMedia網(wǎng)絡(luò)資源的利用率,滿足服務(wù)速率和服務(wù)間隔的要求,提出一種資源分配算法,文獻[7]考慮了WiMedia標(biāo)準(zhǔn)中視頻流的流量規(guī)格和QoS要求,在對最大比特率進行預(yù)測的基礎(chǔ)上,提出一種估計CBR流和VBR流傳輸所需資源量的算法,并據(jù)此分配資源,文獻[8]提出一種考慮信道估計環(huán)境的資源預(yù)留方案,通過預(yù)留大量資源來提高網(wǎng)絡(luò)性能,文獻[9]使用包丟失、吞吐量、平均端到端延遲、平均抖動和路由開銷等各種性能指標(biāo)來評估WiMedia網(wǎng)絡(luò)路由協(xié)議性能。上述算法都是集中式體系結(jié)構(gòu)路由算法,但存在以下問題,首先協(xié)調(diào)器管理整個微微網(wǎng),若協(xié)調(diào)器消失,網(wǎng)絡(luò)中的設(shè)備重新選擇新的PNC,浪費了大量的時間和精力,且在協(xié)調(diào)器的重新選擇過程中不能保證QoS,其次當(dāng)2個或更多微微網(wǎng)彼此重疊時,IEEE 802.15.3協(xié)議的效率顯著降低(即SOP問題),最后是移動性支持不佳以及擴展WPAN覆蓋范圍的困難。為解決上述問題,WiMedia MAC協(xié)議支持分布式MAC方法,使所有設(shè)備具有相同的功能,并提供分布式時間同步方案。此外,WiMedia MAC協(xié)議采用分布式體系結(jié)構(gòu),可消除SOP問題。
近年來,人們針對應(yīng)用于WiMedia標(biāo)準(zhǔn)的路由協(xié)議進行了大量的研究。然而,由于較少考慮信道條件,因此不能為實時應(yīng)用程序提供完整的QoS。本文設(shè)計鏈接反饋信息元素(IE)結(jié)構(gòu)形式,利用媒體接入時隙的數(shù)量和跳數(shù)來決定源設(shè)備和目的地設(shè)備之間的最佳路由。
WiMedia標(biāo)準(zhǔn)使得所有設(shè)備具有相同的功能,并以分布式方式向設(shè)備提供諸如信道分配、數(shù)據(jù)傳輸和時間同步等功能[10]。WiMedia標(biāo)準(zhǔn)的超幀由信標(biāo)周期(BP)和數(shù)據(jù)傳輸周期(DTP)組成,圖1為WiMedia標(biāo)準(zhǔn)的超幀結(jié)構(gòu)。
圖1 WiMedia超幀結(jié)構(gòu)
超幀具有固定的時間長度,并且被分成多個時間窗口,稱為媒體接入時隙(MAS)。超幀中的MAS數(shù)量為256,超幀的長度為65.536 ms。在BP算法中,每個設(shè)備選擇不與其他設(shè)備重疊的信標(biāo)時隙,并在所選擇的信標(biāo)時隙中廣播其信標(biāo)。因此,為了在沒有沖突的情況下廣播其信標(biāo),所有設(shè)備都應(yīng)該搜索沒有被其他設(shè)備占用的免費信標(biāo)時隙。根據(jù)多個信息元素,設(shè)備可以共享用于網(wǎng)絡(luò)管理、移動性支持等的各種信息。超幀的起點是信標(biāo)周期的開始時間,稱為信標(biāo)周期開始時間(BPST)。超幀的其余部分用于傳輸數(shù)據(jù),并且被分成2種類型的MAS塊。基于競爭的協(xié)議在一個MAS塊期間工作,而基于預(yù)留的協(xié)議在另一個MAS塊期間工作?;诟偁幍膮f(xié)議稱為PCA,對于多個優(yōu)先級排序的類類似于IEEE 802.11e標(biāo)準(zhǔn)。PCA是基于CSMA/CA的媒體接入,分為4個接入類別(AC),具有不同的優(yōu)先級,用于異步業(yè)務(wù)傳輸。在PCA塊中,設(shè)備發(fā)送屬于相應(yīng)AC的數(shù)據(jù)幀。
圖2給出AODV路由協(xié)議的路由選擇示例。在圖2中,設(shè)備A和F超出了通信范圍,因此設(shè)備A不能直接向設(shè)備F發(fā)送數(shù)據(jù)包。然而,由于設(shè)備A使用路由協(xié)議發(fā)現(xiàn)從設(shè)備A到設(shè)備F的路由路徑,因此它可以通過設(shè)備B和E向設(shè)備F發(fā)送數(shù)據(jù)分組。
圖2 AODV協(xié)議的路由發(fā)現(xiàn)示例
傳統(tǒng)AODV路由協(xié)議通常能夠發(fā)現(xiàn)具有最小跳數(shù)的路由。因此,它可以選擇在源設(shè)備和目的地設(shè)備之間具有最短路徑的路由[11-12]。然而,傳統(tǒng)的AODV路由協(xié)議不適合基于預(yù)約的信道接入方案,并且不考慮用于通信的可用資源和每個鏈路支持的數(shù)據(jù)速率。因此,如果所選路由上的中間節(jié)點中有低效的可用資源,則整個網(wǎng)絡(luò)的性能降低。文獻[13]為WiMedia標(biāo)準(zhǔn)的DRP提出了新的路由協(xié)議,由于它們不考慮鏈路支持的數(shù)據(jù)速率,低數(shù)據(jù)速率的鏈路會降低網(wǎng)絡(luò)性能,因此傳統(tǒng)的路由協(xié)議不能充分利用較高速率的優(yōu)點。為此,本文提出一個增強的路由協(xié)議,通過考慮WiMedia網(wǎng)絡(luò)中的信道條件來建立有效的路由。
本文路由協(xié)議可以找到數(shù)據(jù)速率最高的路由路徑,并提出了新的路由發(fā)現(xiàn)請求(R-REQ)IE和路由發(fā)現(xiàn)響應(yīng)(R-REP)IE。R-REQ IE包括中間設(shè)備的地址、RREQ IE已經(jīng)通過的鏈路的成本等。本節(jié)在設(shè)計鏈接反饋結(jié)構(gòu)路由協(xié)議過程中采用預(yù)約機制,提出鏈接反饋IE結(jié)構(gòu)形式,所有設(shè)備都可以獲得關(guān)于相鄰設(shè)備使用的鏈路數(shù)據(jù)速率的信息,利用源和目的地之間的中間設(shè)備計算路由成本以確定最佳路由,并利用媒體接入時隙的數(shù)量和跳數(shù)來決定源設(shè)備和目的地設(shè)備之間的最佳路由。
本文路由協(xié)議能夠找到由從源到目的地的中間鏈路支持的具有最高數(shù)據(jù)速率的路由。源和目的地之間的中間設(shè)備通過計算路由成本以確定最佳路由,并且目的地設(shè)備選擇具有最小鏈路成本的路由[14-15]。當(dāng)路由上的設(shè)備數(shù)量為n時,所選擇的路由P表示為P(D1,D2,…,Dn),其中,Dk是路由上的節(jié)點。WiMedia標(biāo)準(zhǔn)提供鏈路反饋IE,其通告關(guān)于相鄰節(jié)點的數(shù)據(jù)速率和傳輸功率水平的信息。圖3所示為鏈接反饋IE結(jié)構(gòu)形式。
圖3 鏈接反饋IE結(jié)構(gòu)形式
在圖3中,DevAddr字段表示提供反饋的設(shè)備的地址。發(fā)送功率電平改變字段指示接收方向源設(shè)備推薦的發(fā)送功率電平的改變,而數(shù)據(jù)速率字段指示接收方設(shè)備向源設(shè)備推薦的數(shù)據(jù)速率。本文提出的路由協(xié)議通過考慮鏈路成本和傳輸數(shù)據(jù)包所需的資源來確定路由。設(shè)TDRP是發(fā)送數(shù)據(jù)包所需的DRP預(yù)留的持續(xù)時間,因此得到[16-17]:
(1)
其中,η是鏈路Li,j的MAC效率,即有效載荷傳輸?shù)臅r間比例,PPERij是鏈路Li,j的相應(yīng)分組錯誤率。根據(jù)式(2),通過鏈路Li,j傳輸數(shù)據(jù)包所需的MAS數(shù)量為[18-19]:
(2)
其中,TMAS是MAS的長度,為256 μs。根據(jù)式(3),端到端路由上的所有設(shè)備都可以計算所需的端到端數(shù)據(jù)流時隙數(shù),則MAC效率η可計算如下[20]:
(3)
通過考慮確認(ACK)策略來估計MAC效率η。WiMedia標(biāo)準(zhǔn)提供了無確認(NoACK)、立即確認(Imm-ACK)和塊確認(B-ACK)3種ACK策略。No-ACK方案容易受到分組丟失的影響,在Imm-ACK中,每幀在短幀間空間(SIFS)持續(xù)時間之后被確認為一個ACK幀,可以提供可靠性。然而,Imm-ACK機制導(dǎo)致確認諸如多媒體流之類的接收業(yè)務(wù)突發(fā)的開銷量,在WiMedia標(biāo)準(zhǔn)和IEEE 802.11e標(biāo)準(zhǔn)中已經(jīng)提出了B-ACK方案,以減輕這種開銷。
B-ACK機制允許源設(shè)備發(fā)送多個幀,并從接收方接收單個確認幀,該確認幀指示接收了哪些幀以及哪些幀需要重傳。由于在預(yù)留的傳輸持續(xù)時間中僅對所有幀使用一個ACK,因此開銷大大降低。因此,可將B-ACK策略應(yīng)用于本文協(xié)議。圖4所示為DRP預(yù)約塊中B-ACK方案的幀事務(wù)。
圖4 B-ACK策略幀事務(wù)示例
總傳輸時間受鏈路支持的數(shù)據(jù)速率的影響,其計算公式如下:
(Nframe-1)×TMISF+2TSIFS+TB-ACK
(4)
其中,Nframe為數(shù)據(jù)幀號,WHeader和WPSDU分別為WiMedia標(biāo)準(zhǔn)的MAC報頭和有效負載的大小,Rmin為WiMedia標(biāo)準(zhǔn)支持的最小數(shù)據(jù)速率,WPre_S為標(biāo)準(zhǔn)前導(dǎo)碼的大小,WPre_B是突發(fā)前導(dǎo)碼的大小,TMISF和TSIFS是幀間間隔的持續(xù)時間,TB-ACK是B-ACK幀的傳輸時間。TB-ACK可計算為:
TB-ACK=TPre-S+THeader+
(5)
WiMedia標(biāo)準(zhǔn)的數(shù)據(jù)幀由前導(dǎo)、報頭和物理層服務(wù)數(shù)據(jù)單元(PSDU)組成?;谑?4)、式(5),TOverhead和TPSDU可計算為:
TMISF+2TsIFS+TB-ACK
(6)
(7)
鏈路Li,j的平均PER可計算為:
PPER=1-(1-BBER)8WPSDU
(8)
上述等式意味著路由上的中間設(shè)備可以計算傳輸數(shù)據(jù)分組所需的MAS數(shù)量,計算鏈路成本以確定最佳路線。總鏈路成本C是針對路由中的鏈路計算的數(shù)據(jù)速率的倒數(shù)和,計算公式為:
(9)
其中,n是路徑上的鏈接總數(shù)。路由上的所有設(shè)備計算鏈路成本,并在BP中廣播包括計算鏈路成本的RREQ IE。
源設(shè)備廣播包括BP中的RREQ IE的信標(biāo)幀,以將數(shù)據(jù)幀發(fā)送到超出范圍的另一設(shè)備。圖5給出建議的RREQ IE的格式。在圖5中,用戶DevAddr字段表示發(fā)送RREQ IE的設(shè)備的ID。
圖5 RREQ IE格式
如果源設(shè)備首先廣播包括所提RREQ IE的信標(biāo)幀,則所有者DevAddr字段被設(shè)置為源DevAddr字段的值;源DevAddr字段指示首先廣播所提RREQ IE設(shè)備的地址,Dest DevAddr字段指示目的地設(shè)備的地址。服務(wù)數(shù)據(jù)長度字段指示提供服務(wù)所需的數(shù)據(jù)幀長度。
Hop Count字段指示源設(shè)備和目的地設(shè)備之間的跳數(shù),并且當(dāng)RREQ IE通過中間節(jié)點時,Hop Count字段的值增加1。鏈接成本文件包含使用式(9)計算的鏈接成本,DRP分配字段包含關(guān)于為多跳通信保留的資源的信息、區(qū)域位圖和MAS位圖的信息。為了便于資源分配,WiMedia標(biāo)準(zhǔn)提出二維超幀結(jié)構(gòu),將超幀劃分為16個區(qū)域。每個區(qū)域由16個MAS組成,并且對應(yīng)于16×16超幀矩陣的每個列。圖6所示為接收RREQ IE的設(shè)備流程。
圖6 接收RREQ IE的設(shè)備流程
在圖6中,首先接收設(shè)備接收源設(shè)備廣播的包括RREQ IE的信標(biāo)幀,基于接收到的RREQ IE信標(biāo)幀確定路由目標(biāo)的DevAddr字段。然后對當(dāng)前字段的地址與目標(biāo)DevAddr字段的地址進行對比,如果字段地址不符合,則丟棄該字段RREQ IE信標(biāo)幀。如果滿足字段要求,再判斷是否在可用MASs范圍內(nèi),如果不在范圍內(nèi)則丟棄該字段RREQ IE信標(biāo)幀。如果滿足可用范圍條件,則繼續(xù)執(zhí)行算法,更新鏈路消耗,如果目的地設(shè)備接收到RREQ IE,則它廣播包括所提RREP IE的信標(biāo)幀。
圖7給出所提RREP IE的設(shè)備流程。在圖7中,源DevAddr字段指示源設(shè)備的地址,目標(biāo)DevAddr字段包含目標(biāo)設(shè)備的地址。用戶DevAddr字段指示廣播RREP IE的設(shè)備地址,而Target DevAddr字段指示已被選擇為中繼設(shè)備的地址。鏈路Cost字段指示由目的地設(shè)備計算的端到端路徑的總鏈路成本。Hop Count字段指示源設(shè)備和目標(biāo)設(shè)備之間的跳數(shù)。DRP可用位圖字段指示關(guān)于可用資源的信息,如果相應(yīng)的MAS可用,則字段中的每個位設(shè)置為“1”。如果請求預(yù)約的MAS已經(jīng)被其他設(shè)備預(yù)約,則字段中的對應(yīng)位被設(shè)置為“0”。如果沒有預(yù)約沖突,則設(shè)備不會更改DRP可用性位圖字段的值。
圖7 接收RREP IE的設(shè)備流程
在圖7中,接收RREP IE的設(shè)備首先確定目標(biāo)DevAddr字段。如果目標(biāo)DevAddr字段的值等于設(shè)備的地址,則檢查DRP可用位圖字段。如果請求資源與設(shè)備資源重疊,則創(chuàng)建DRP可用位圖字段,否則,設(shè)備將用戶 DevAddr字段設(shè)置為其地址,并選擇具有最小鏈接成本的目標(biāo)設(shè)備,將目標(biāo)DevAddr字段設(shè)置為要向其發(fā)送RREP IE的設(shè)備的地址。然后,設(shè)備廣播包括RREP IE的信標(biāo)幀。如果目標(biāo)DevAddr字段不等于其地址,則丟棄RREP IE。如果源設(shè)備接收到RREP IE,則構(gòu)建Rconf IE。圖8給出了本文Rconf IE格式。
圖8 Rconf IE格式
接收RREP IE的源設(shè)備將關(guān)于保留資源的信息存儲到DRP Allocation字段。此外,在將Target DevAddr字段設(shè)置為位于路由路徑上的下一個設(shè)備的地址之后,它將Route Sequence字段設(shè)置為1,并廣播包括Rconf IE的信標(biāo)幀,接收Rconf IE的設(shè)備確定目標(biāo)DevAddr字段。如果目標(biāo)DevAddr字段等于其地址,則將用戶DevAddr字段設(shè)置為其地址,并將目標(biāo)DevAddr字段設(shè)置為沿路由路徑的下一個設(shè)備的地址。此外,將DRP分配字段設(shè)置為保留資源的信息,并廣播包括Rconf IE的信標(biāo)幀。如果目標(biāo)DevAddr字段不等于設(shè)備的地址,則丟棄接收到的Rconf IE。在廣播Rconf IE之后,設(shè)備在保留的資源中發(fā)送數(shù)據(jù)幀。
圖9為本文路由協(xié)議的示例。為簡單起見,本文不考慮鏈路的分組錯誤率和MAC效率。此外,假設(shè)提供服務(wù)所需的數(shù)據(jù)長度是27 KB。
圖9 路由協(xié)議示例
在圖9中,圖9(a)顯示每個鏈接支持的數(shù)據(jù)速率和可用MAS的數(shù)量,在圖9(b)中,源設(shè)備A將包括RREQ IE的信標(biāo)幀廣播到相鄰設(shè)備B和C,相鄰設(shè)備B和C在接收到RREQ IE時計算鏈路成本,設(shè)備B計算的鏈路成本是1/160,設(shè)備C計算的鏈路成本是1/200。圖9(c)為設(shè)備B和C廣播包括新鏈路成本的RREQ IE(參),設(shè)備B接收設(shè)備C發(fā)送的RREQ IE,并重新計算所接收的RREQ IE的鏈路成本,即(1/200+1/106.7),由設(shè)備B計算的新鏈路成本大于先前計算的鏈路成本(1/160)。因此,設(shè)備B丟棄從設(shè)備C接收的RREQ IE。設(shè)備C接收設(shè)備B發(fā)送的RREQ IE,并重新計算接收的RREQ IE的鏈路成本,即(1/160+1/106.7),由設(shè)備B計算的新鏈路成本大于先前計算的鏈路成本(1/200)。因此,設(shè)備C也丟棄從設(shè)備B接收的RREQ IE。設(shè)備E從設(shè)備B接收RREQ IE,而設(shè)備D從設(shè)備B和C接收RREQ IE。設(shè)備E在從設(shè)備B接收到RREQ IE時計算的鏈路成本是(1/160+1/106.7),并且由設(shè)備D在從設(shè)備B接收到RREQ IE時計算的鏈路成本是(1/160+1/53.3)。
由于設(shè)備C的鏈路成本小于設(shè)備B,因此設(shè)備D選擇設(shè)備C作為候選中繼設(shè)備。在圖9(d)中,設(shè)備D和E廣播RREQ IE。設(shè)備E從設(shè)備D接收RREQ IE并重新計算鏈路成本,即(1/200+1/480+1/320)。因為新鏈路成本小于先前計算的鏈路成本,所以設(shè)備E重新廣播包括新鏈路成本的RREQ IE(見圖9(e))。在圖9(d)中,設(shè)備G從設(shè)備E接收RREQ IE,但是它幾乎沒有足夠的資源來傳輸數(shù)據(jù)幀,因此,丟棄從設(shè)備E接收的RREQ IE。目的地設(shè)備F接收具有路由(A、B、E、F)和鏈路成本(1/160+1/106.7+1/400)、路由的RREQ IE(A、C、D、F)和鏈路成本(1/200+1/480+1/106.7)、具有路由的RREQ IE(A、C、D、E、F)和鏈路成本(1/200+1/480+1/320+1/400)。目的地設(shè)備F比較所有鏈路成本并選擇具有最小路由的路由,即路由(A、C、D、E、F)。隨后,目的地設(shè)備F將RREP IE與選擇的路由一起發(fā)送回源設(shè)備A(見圖9(f))。源設(shè)備A更新其路由表,因此建立從設(shè)備A到F的路由(見圖9(g))。源設(shè)備A廣播Rconf IE,包括已建立的路由的信息,當(dāng)選擇的中間設(shè)備接收到Rconf IE時,為路由建立預(yù)留的資源信息(見圖9(h))。之后,路由上的所有設(shè)備在保留的MAS中發(fā)送數(shù)據(jù)幀。本文方案發(fā)現(xiàn)的路由可以提供比現(xiàn)有路由協(xié)議更好的吞吐量。
使用openWNS模擬器[15]來評估本文方案的性能。openWNS是一個動態(tài)事件驅(qū)動的仿真平臺,包括WiMedia標(biāo)準(zhǔn)的實現(xiàn)。在仿真中,源設(shè)備總是向目標(biāo)設(shè)備發(fā)送數(shù)據(jù)幀。WiMedia設(shè)備發(fā)送的分組有效負載大小為1 024 Byte,源對和目標(biāo)對之間的業(yè)務(wù)負載是通過改變每秒的分組數(shù)量來生成的。此外,隨機地選擇源-目的地對作為網(wǎng)絡(luò)中業(yè)務(wù)負載,信標(biāo)幀和ACK幀以53.3 Mb/s的強制速率傳輸。模擬中使用的參數(shù)如表1所示。
表1 仿真參數(shù)
此外,考慮具有無線IPTV和個人錄像機(PVR)記錄相同節(jié)目的多媒體應(yīng)用。在某個時候,用戶使用遙控器,命令機頂盒(STB)啟動IPTV節(jié)目。機頂盒中的PVR同時開始在位于客廳旁邊壁櫥的無線連接的外部硬盤驅(qū)動器上記錄相同的程序。設(shè)服務(wù)提供者的視頻源使用實時傳輸協(xié)議(RTP)作為傳輸生成MPEG-4流,表2顯示了業(yè)務(wù)流的令牌桶TSPEC。
表2 業(yè)務(wù)流的令牌桶TSPEC特性
在該模擬中,假設(shè)所有設(shè)備隨機分布在100 m×100 m的正方形區(qū)域。給定網(wǎng)絡(luò)拓撲,隨機選擇源-目標(biāo)對。將節(jié)點的通信半徑設(shè)為10 m,在仿真中評估了不同信道編碼參數(shù)對算法性能的影響,包括業(yè)務(wù)負載、節(jié)點數(shù)目和信噪比。在本文仿真中,將本文方案與WiMedia標(biāo)準(zhǔn)以及WiMedia網(wǎng)絡(luò)中的QoS路由協(xié)議進行了比較。
在不同業(yè)務(wù)負載下,每50 s添加新的業(yè)務(wù)流,并且業(yè)務(wù)流的數(shù)量隨時間單調(diào)地增加。經(jīng)過一定時間后,計算在整個網(wǎng)絡(luò)中傳輸?shù)臉I(yè)務(wù)流的數(shù)量,并將其總和除以整個網(wǎng)絡(luò)飽和的業(yè)務(wù)流的數(shù)量,得到的數(shù)字被當(dāng)作網(wǎng)絡(luò)的平均負載,設(shè)備的數(shù)量固定在40個。圖10為WiMedia標(biāo)準(zhǔn)、QoS路由和本文方案的吞吐量仿真結(jié)果。
圖10 3種協(xié)議的吞吐量仿真結(jié)果比較
在輕量業(yè)務(wù)下(發(fā)送的分組數(shù)較小情況下),本文算法的端到端吞吐量實驗結(jié)果非常接近選取的WiMedia標(biāo)準(zhǔn)和QoS路由2種協(xié)議。當(dāng)流量增加時,WiMedia標(biāo)準(zhǔn)的DRP協(xié)議的缺點較為明顯,其端到端的吞吐量指標(biāo)下降較多,主要原因是算法的效率低,導(dǎo)致數(shù)據(jù)傳輸過程中存在較為嚴(yán)重的數(shù)據(jù)擁堵問題。而QoS路由協(xié)議因為將數(shù)據(jù)傳輸服務(wù)質(zhì)量(QoS)作為主要的評價指標(biāo),端到端的吞吐量作為QoS路由協(xié)議的主要考量指標(biāo),其具有相對較優(yōu)的性能表現(xiàn)。本文協(xié)議相對于QoS路由協(xié)議的優(yōu)勢在于,本文協(xié)議采用了預(yù)約機制的鏈接反饋IE結(jié)構(gòu)形式,這種協(xié)議結(jié)構(gòu)的優(yōu)點在于其可有效避免無效數(shù)據(jù)的處理,從而節(jié)省了網(wǎng)絡(luò)資源和帶寬資源,具有相對較好的數(shù)據(jù)傳輸性能表現(xiàn)。因此,所提出的路由協(xié)議優(yōu)于2個傳統(tǒng)協(xié)議。
圖11通過比較WiMedia標(biāo)準(zhǔn)、QoS路由和在各種業(yè)務(wù)負載下提出的路由協(xié)議,顯示了平均端到端延遲的仿真結(jié)果。在輕流量下,文獻[15]提出的QoS路由協(xié)議所經(jīng)歷的分組端到端延遲結(jié)果與WiMedia標(biāo)準(zhǔn)的結(jié)果類似。隨著網(wǎng)絡(luò)流量的增加,本文路由協(xié)議逐漸優(yōu)于WiMedia標(biāo)準(zhǔn),因為網(wǎng)絡(luò)中的每個鏈路變得負載過重,所以WiMedia標(biāo)準(zhǔn)會出現(xiàn)網(wǎng)絡(luò)擁堵的情形,導(dǎo)致分組延遲情形的增加。而QoS路由協(xié)議是一種帶寬感知路由,它能夠確保在該路徑上保留足夠的帶寬。另外,由于QoS路由協(xié)議允許路由路徑上的所有設(shè)備使用預(yù)留的資源無爭用地發(fā)送數(shù)據(jù)幀,因此QoS路由協(xié)議可以減少擁塞。然而,QoS路由協(xié)議只考慮可用資源,選擇最短路徑,因此它不能獲得速率自適應(yīng)調(diào)整,反映在實驗結(jié)果中就是本文算法在端到端延遲指標(biāo)上的性能表現(xiàn)要顯著優(yōu)于QoS路由協(xié)議。由于本文路由協(xié)議考慮了鏈路質(zhì)量和每個鏈路支持的數(shù)據(jù)速率,因此可以選擇數(shù)據(jù)速率最高的路由路徑。因此,本文提出的路由協(xié)議優(yōu)于2個傳統(tǒng)協(xié)議的端到端延遲性能。
圖11 3種協(xié)議的端到端延遲仿真結(jié)果比較
圖12為每個協(xié)議中最小剩余能量的比較。本文協(xié)議和QoS路由的生命期比WiMedia標(biāo)準(zhǔn)要長,因為它們可以無競爭地發(fā)送數(shù)據(jù)幀。使用WiMedia標(biāo)準(zhǔn)的設(shè)備必須與相鄰設(shè)備進行數(shù)據(jù)傳輸。隨著網(wǎng)絡(luò)流量的增加,傳輸數(shù)據(jù)幀的爭用變得更加激烈,并且增加了沖突造成的數(shù)據(jù)丟失。因此,在WiMedia標(biāo)準(zhǔn)中,通過爭用和沖突進行重傳會增加能耗。然而,由于所提出的路由協(xié)議和QoS路由協(xié)議可以無競爭地發(fā)送數(shù)據(jù)幀,因此它們的性能優(yōu)于WiMedia標(biāo)準(zhǔn)。然而,QoS路由協(xié)議只考慮可用資源,只選擇最短路徑,無法選擇最優(yōu)的路由路徑。本文提出的路由協(xié)議考慮了每個鏈路所支持的數(shù)據(jù)速率,從而可以選擇數(shù)據(jù)速率最高的路由路徑。因此,本文路由協(xié)議比傳統(tǒng)的2種協(xié)議具有更好的節(jié)能性能。
圖12 最小剩余能量比較
本文提出一種考慮WiMedia網(wǎng)絡(luò)信道條件的多跳路由協(xié)議。該協(xié)議通過可用資源與每個鏈路的數(shù)據(jù)速率配置多跳通信的最佳路由路徑,是一種完全分布式的協(xié)議,其不依賴于網(wǎng)絡(luò)中設(shè)備之間的全局時間同步。在網(wǎng)絡(luò)棧的操作中,MAC層由路由層決定,不需要額外的控制分組建立路由,并提供路由協(xié)議來保證實時業(yè)務(wù)的QoS。仿真結(jié)果表明,與傳統(tǒng)WiMedia協(xié)議相比,本文路由協(xié)議可提高分組的傳輸率,明顯改善平均的端到端分組延遲。