一種快速傳輸?shù)奶掌潫o線個域網(wǎng)MAC協(xié)議

王 磊，周海東，吳佳琪，張 雄

(重慶郵電大學 通信與信息工程學院，重慶 400065)

0 引言

隨著短距離無線通信的快速發(fā)展，在未來幾年，需要數(shù)十Gbps的數(shù)據(jù)速率來滿足人們對高速通信的要求。而傳統(tǒng)的無線通信系統(tǒng)[1-2]都不能滿足如此高的數(shù)據(jù)速率，因此，在這樣的背景下開始探索太赫茲波段。但由于太赫茲波在空氣中的損耗極為嚴重，所以比較適用于無線個域網(wǎng)這樣的短距離通信場景[3]。

太赫茲無線個域網(wǎng)[4](Terahertz Wireless Personal Area Networks，THz-WPANs)是一種采用太赫茲頻段作為載波，且在一個通信范圍較小的網(wǎng)絡(一般在10 m左右)進行高速通信[5-6]的無線個域網(wǎng)。THz-WPANs不僅具有很高的數(shù)據(jù)傳輸速率，而且還具備通信容量較大和抗干擾能力強的特點。太赫茲波有極大的未被分配的頻段，能解決目前頻譜資源[7]稀缺帶來的問題，未來的后5G，6G時代將采用太赫茲進行通信[8]。

目前，關于太赫茲MAC協(xié)議的研究已經(jīng)取得了一定成果。文獻[9]提出了一種太赫茲網(wǎng)絡MAC協(xié)議——PHLAME協(xié)議，此協(xié)議主要針對納米傳感網(wǎng)。PHLAME協(xié)議由控制交互過程和數(shù)據(jù)傳輸過程2個階段組成。在控制交互過程階段，當源節(jié)點有數(shù)據(jù)需要發(fā)送時，則會向目的節(jié)點發(fā)送一個傳輸請求幀，當這個傳輸請求幀被目的節(jié)點成功接收后，目的節(jié)點隨之給源節(jié)點回應一個傳輸確認幀；控制交互過程完成后就進入數(shù)據(jù)傳輸階段，在這個過程中，源節(jié)點和目的節(jié)點根據(jù)在控制交互過程階段中協(xié)商好的參數(shù)(如數(shù)據(jù)傳輸速率、預約信道時間)來進行數(shù)據(jù)幀的交互。該協(xié)議使用低權重編碼和重復編碼的方式減少了數(shù)據(jù)幀發(fā)生碰撞的幾率。Peng等人[10]設計了一種雙信道接入方法，信道的掃描以及交互信息的收發(fā)在低頻段進行，根據(jù)交互信息的參數(shù)來估計節(jié)點的位置信息，緊接著在太赫茲信道運用定向天線精準定位節(jié)點的位置信息，最后源和目的節(jié)點波束對準進行太赫茲通信。Sebastian[11]在上述模型基礎上進行了改進，若數(shù)據(jù)傳輸階段有數(shù)據(jù)幀在太赫茲信道發(fā)生了碰撞，則重傳的數(shù)據(jù)幀在低頻段進行，但是接收端如何對重傳的數(shù)據(jù)幀進行重新組合還有待研究；Temel等人在此基礎上提出了一種飛行自組網(wǎng)中的定位定向MAC(Location Oriented Directional MAC Protocol for Flying Ad Hoc Network,LOD-MAC)協(xié)議[12]，該協(xié)議由2個工作在不同頻段的收發(fā)器組成，其中一臺收發(fā)器工作在探測階段，分為位置信息的估計和控制信息交互；另一臺收發(fā)器主要進行數(shù)據(jù)傳輸，由于在探測階段節(jié)點的位置信息估計和控制信息交互分開進行，所以造成探測階段延時較大。文獻[13]設計了一種適用于太赫茲超高速無線網(wǎng)絡的MAC協(xié)議,提出了一種新型的超幀結構，將CTAP時段放置在CAP時段之前，這樣節(jié)點能夠更快獲得時隙分配信息，從而降低數(shù)據(jù)傳輸時延,該協(xié)議通過把同一對節(jié)點的時隙請求合并在一起，增加了數(shù)據(jù)的發(fā)送量，提升了網(wǎng)絡性能。

文獻[14]對不同模型的用途進行了介紹，提出在設計太赫茲MAC協(xié)議時要考慮所對應的應用場景，并且指明IEEE 802.11ad和IEEE 802.15.3c協(xié)議都是工作在60 GHz頻段，該頻段與太赫茲頻段較為接近，因此在設計太赫茲無線個域網(wǎng)MAC協(xié)議時可以參照以上2種協(xié)議。但是在通信過程中，IEEE 802.15.3c協(xié)議使用了超幀結構，節(jié)點在本超幀結構申請的時隙，只能在下一個超幀結構進行數(shù)據(jù)傳輸，這樣會帶來較大的數(shù)據(jù)傳輸時延。

Yao等人[15]在以上研究的基礎上，提出了一種雙信道可以輔助太赫茲波波束成形的MAC(Assisted Beamforming MAC Protocol for Terahertz Communication Networks，TAB-MAC)協(xié)議，通過將自身節(jié)點的位置信息放入RTS/CTS交互幀中，在低頻的WiFi(工作在2.4 GHz)信道進行控制交互的過程，然后在高頻的太赫茲信道使用定向天線進行測試幀、確認幀以及數(shù)據(jù)幀的傳輸。TAB-MAC可以很好地解決太赫茲通信距離較短的問題，但深入研究發(fā)現(xiàn)，存在空分復用率低和控制開銷冗余的問題。本文在TAB-MAC協(xié)議的基礎上提出了FTP-MAC協(xié)議。

1 網(wǎng)絡模型

TAB-MAC協(xié)議的網(wǎng)絡模型圖如圖1所示。一個網(wǎng)絡中的節(jié)點包括錨節(jié)點AN(Anchor Node)和常規(guī)節(jié)點RN(Regular Node)。AN主要用來幫助RN獲取自身節(jié)點的位置信息，而RN主要用來傳輸控制消息和數(shù)據(jù)消息。RN能夠在2.4 GHz的WiFi信道進行全向通信，也能在太赫茲信道進行定向通信。AN通過裝備GPS定位模塊來獲取自身節(jié)點的坐標并存入信標(Beacon)幀中，在2.4 GHz的WiFi信道上，AN周期性地廣播信標幀。而RN正是依據(jù)AN傳來的信標幀定位自身節(jié)點的位置信息。一個三維空間的RN至少需要4個不共線的AN來定位自身節(jié)點的坐標。當RN能估算自身節(jié)點的位置信息后，那么太赫茲定向天線的調整工作將變得容易。

圖1 TAB-MAC協(xié)議網(wǎng)絡模型

TAB-MAC協(xié)議的交互流程如圖2所示。TAB-MAC協(xié)議在邏輯上具有WiFi信道RTS/CTS幀交互和太赫茲信道數(shù)據(jù)傳輸2個階段的操作。在WiFi信道時，RN為避免多個節(jié)點同時發(fā)送數(shù)據(jù)而導致碰撞，故采用載波偵聽碰撞避免，即CSMA/CA協(xié)議來接入信道。設源節(jié)點為A，當節(jié)點A有數(shù)據(jù)請求發(fā)送時，則會偵聽信道是否空閑。若不空閑，則執(zhí)行二進制指數(shù)退避的操作等待一段時間重新發(fā)送；若空閑，則使用全向天線向目的節(jié)點(設為B)發(fā)送RTS幀，節(jié)點B收到由節(jié)點A發(fā)來的RTS幀后，等待幀間間隔(SIFS)的時間后，節(jié)點B給節(jié)點A回復CTS幀。應當注意的是，無論是RTS幀還是CTS幀，里面都包含了各自節(jié)點的位置信息和天線信息。當控制消息交互的過程完成后，節(jié)點A，B都有了對方節(jié)點的坐標位置，節(jié)點A根據(jù)這些信息調整太赫茲定向天線對準節(jié)點B，而節(jié)點B也執(zhí)行相同的操作對準源節(jié)點，隨之進入太赫茲信道操作階段。

在太赫茲信道，為確認定向天線是否處于波束對準狀態(tài)，故節(jié)點A會發(fā)送一個測試(Test to Send，TTS)幀給目的節(jié)點，若節(jié)點B能成功接收TTS幀，則回復節(jié)點A一個確認(ACK)幀。節(jié)點A收到節(jié)點B傳來的ACK幀后，即開始傳輸數(shù)據(jù)幀。當節(jié)點A傳輸完所有的數(shù)據(jù)幀后，節(jié)點B回復一個ACK幀確認。

圖2 TAB-MAC協(xié)議消息交互流程

圖3中，Duration為占用信道的持續(xù)時間；針對RTS幀，地址信息分為RA與TA，各占6 Byte，RA為RTS幀接收站點地址，TA為RTS幀發(fā)送站點地址。針對CTS幀，地址信息只有RA，即CTS幀的接收站點地址。針對TTS幀，地址信息包括RA和TA，其含義同RTS幀；在幀主體中，X，Y，Z即為一個節(jié)點X，Y，Z的坐標值，代表了節(jié)點的位置信息。天線信息字段包括了天線的波束寬度以及指向信息。對于TTS幀的幀主體來說，僅有一個4 Byte的無用數(shù)據(jù)字段，主要是為了測試太赫茲信道定向天線是否波束對準。

圖3 交互幀的幀格式圖

2 FTP-MAC協(xié)議

TAB-MAC協(xié)議主要存在的問題：當節(jié)點A，B在太赫茲信道傳輸數(shù)據(jù)時，此時WiFi信道處于空閑，而TAB-MAC協(xié)議為了防止發(fā)生數(shù)據(jù)碰撞，在一對節(jié)點通信過程中，不允許其他節(jié)點進行通信，因此空閑的WiFi信道只能等待太赫茲信道數(shù)據(jù)傳輸完成之后才能使用，這樣造成了信道利用率低，也降低了整個網(wǎng)絡的數(shù)據(jù)傳輸效率和網(wǎng)絡吞吐量。

為了解決上述問題，提出了FTP-MAC協(xié)議。該協(xié)議采用并行傳輸?shù)姆绞?，在同一時刻內(nèi)節(jié)點互不干擾的情況下多對節(jié)點并行傳輸，提高了整個網(wǎng)絡的數(shù)據(jù)傳輸和網(wǎng)絡吞吐量。

2.1 多對節(jié)點并行傳輸機制

2.1.1 基本思想

節(jié)點A向節(jié)點B在WiFi信道發(fā)送RTS幀，除節(jié)點B之外的節(jié)點收到RTS幀后會靜默往返時間(Round Trip Time，RTT)/2時間，(RTT=接收到CTS幀的時刻-發(fā)出RTS幀的時刻)，并根據(jù)RTS幀中的位置信息屏蔽掉與節(jié)點A在太赫茲信道定向天線對準的波束方向，屏蔽時間為節(jié)點A在太赫茲信道發(fā)送數(shù)據(jù)所需時間(可根據(jù)RTS幀中的“持續(xù)時間”值獲得)。

節(jié)點B在WiFi信道收到RTS幀后，向節(jié)點A回送一個CTS幀，周圍的節(jié)點收到CTS幀后不再靜默并屏蔽掉與節(jié)點B在定向天線對準的波束方向。

當節(jié)點A，B在太赫茲信道傳輸數(shù)據(jù)時，若節(jié)點C有數(shù)據(jù)需要發(fā)送給節(jié)點D，那么節(jié)點C首先發(fā)送RTS幀給節(jié)點D，當節(jié)點D收到RTS幀時，會依據(jù)位置信息計算出與節(jié)點C之間的波束方向，若發(fā)現(xiàn)此波束方向未被屏蔽，那么回送CTS幀。若已被屏蔽，則什么也不發(fā)送。

2.1.2 步驟

① 若一個節(jié)點收到了其他節(jié)點發(fā)送來的RTS幀，那么將發(fā)送來的RTS幀中的Duration字段的值和位置信息(X，Y，Z)的值進行提取，并且保持靜默RTT/2的時間。根據(jù)提取到的位置信息，屏蔽掉與發(fā)送RTS幀的節(jié)點在太赫茲信道定向天線的波束方向，Duration字段的值即為此波束方向的屏蔽時間。

② 如果一個節(jié)點收到其他節(jié)點發(fā)來的CTS幀，則提取出CTS幀中位置信息以及Duration字段的值，根據(jù)此節(jié)點位置信息計算出與此節(jié)點在太赫茲信道定向天線對準的波束方向，然后屏蔽掉此波束方向，屏蔽時間為Duration字段的值。

③ 如果一個節(jié)點B收到節(jié)點A發(fā)來的RTS幀，則提取出RTS幀中位置信息的值，根據(jù)位置信息計算出與源RN在太赫茲信道定向天線對準的波束方向，然后判斷該波束方向是否被屏蔽。如果判斷為否，則向源RN發(fā)送CTS幀，并調整太赫茲信道定向天線使波束方向對準源RN，以準備接收即將到來的TTS幀；如果判斷為是，則什么也不發(fā)送。

④ 如果一個節(jié)點A在發(fā)送RTS幀后的一段時間內(nèi)又收到CTS幀，則提取出CTS幀中位置信息的值，根據(jù)此節(jié)點位置信息計算出與此節(jié)點在太赫茲信道定向天線對準的波束方向，然后判斷該波束方向是否被屏蔽。如果判斷為否，調整太赫茲信道定向天線使波束方向對準目的RN，并準備在太赫茲信道上發(fā)送TTS幀；如果判斷為是，則什么也不發(fā)送。

⑤ 如果一個節(jié)點收到節(jié)點A在太赫茲信道上發(fā)來的TTS幀，則在太赫茲信道上向該節(jié)點回復一個ACK幀。

⑥ 如果一個節(jié)點在發(fā)送TTS幀后又收到節(jié)點B在太赫茲信道上發(fā)來的ACK幀，則在太赫茲信道上向該節(jié)點發(fā)送數(shù)據(jù)幀。

2.2 FTP-MAC協(xié)議性能分析

引理 FTP-MAC協(xié)議與TAB-MAC協(xié)議相比能夠提升整個網(wǎng)絡的數(shù)據(jù)傳輸和網(wǎng)絡吞吐量。

證明 文獻[10]中給出了節(jié)點的吞吐量模型，本文采用該文獻中的吞吐量模型推出網(wǎng)絡平均吞吐量分析模型。設N為網(wǎng)絡中節(jié)點的個數(shù)，某個節(jié)點發(fā)送數(shù)據(jù)幀的數(shù)量用K表示，在太赫茲信道成功發(fā)送數(shù)據(jù)幀的概率為Ps，那么，總的收到的數(shù)據(jù)幀的長度應為L×K×Ps，故網(wǎng)絡的平均吞吐量S為：

(1)

3 仿真及分析

本仿真實驗采用OPNET仿真軟件，模擬一個10 m×10 m面積的場景，選取LODMAC協(xié)議和TAB-MAC協(xié)議作為參考協(xié)議，在網(wǎng)絡條件相同的情況下，驗證分析它們在MAC層的信道利用率、吞吐量等性能。

3.1 參數(shù)設置

主要仿真參數(shù)如表1所示。

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

參數(shù)默認值場景大小10 m×10 m節(jié)點數(shù)4,7,10,13,16,19緩存大小10 MB數(shù)據(jù)分組大小8 192 ByteRTS幀長度256 bitCTS幀長度208 bitTTS幀長度208 bitWiFi信息載波頻率2.4 GHzTHz信道載波頻率340 GHz隨機種子64,128,256,512,1 024

3.2 結果分析

3.2.1 MAC層吞吐量

MAC層吞吐量如圖4所示。由圖4可知，網(wǎng)絡吞吐量隨著節(jié)點數(shù)的增多逐漸增大，緊接著趨于穩(wěn)定(此時隨著節(jié)點數(shù)的增多，協(xié)議所支持的業(yè)務量已經(jīng)達到上限)，最后有下降趨勢(這是由于隨著節(jié)點數(shù)的增多，碰撞概率增大)，造成吞吐量下降。在MAC層吞吐量方面，F(xiàn)TP-MAC協(xié)議的性能優(yōu)于TAB-MAC協(xié)議和LODMAC協(xié)議，主要原因在于FTP-MAC協(xié)議采用“多對節(jié)點并行傳輸機制”可以在多對節(jié)點互不干擾的情況下并行傳輸，從而能夠提高MAC層吞吐量。

圖4 MAC層吞吐量

3.2.2 信道利用率

信道利用率如圖5所示。由圖5可知，F(xiàn)TP-MAC協(xié)議的信道利用率高于TAB-MAC協(xié)議和LODMAC協(xié)議，主要原因在于FTP-MAC協(xié)議采用多對節(jié)點并行傳輸機制，可以在多對節(jié)點互不干擾的情況下同時傳輸數(shù)據(jù)，提高了整個網(wǎng)絡的數(shù)據(jù)傳輸和信道利用率。

圖5 信道利用率

4 結束語

針對現(xiàn)有TAB-MAC協(xié)議中為了防止數(shù)據(jù)發(fā)生碰撞，當一對節(jié)點在通信時，其余節(jié)點不允許進行通信，從而只能等待太赫茲信道數(shù)據(jù)傳輸完成之后才能使用，導致信道利用率較低，降低了網(wǎng)絡整體的數(shù)據(jù)傳輸?shù)葐栴}，提出一種FTP-MAC協(xié)議，采用多對節(jié)點并行傳輸機制實現(xiàn)了在太赫茲信道互不干擾進行數(shù)據(jù)傳輸，提高整個網(wǎng)絡的數(shù)據(jù)傳輸和網(wǎng)絡吞吐量，降低了數(shù)據(jù)傳輸時延，提出的快速傳輸具有良好的可實現(xiàn)性。在未來的學術研究中，將繼續(xù)對太赫茲無線個域網(wǎng)MAC協(xié)議進行研究，使其更快地接入信道和網(wǎng)絡中，快速地傳輸數(shù)據(jù)。