999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

一種基于RBAR的協作MAC協議

2017-02-28 10:49:14王艷輝魏振春魏炬熠韓江洪

王艷輝, 魏振春, 魏炬熠, 韓江洪

(合肥工業大學 計算機與信息學院,安徽 合肥 230009)

一種基于RBAR的協作MAC協議

王艷輝, 魏振春, 魏炬熠, 韓江洪

(合肥工業大學 計算機與信息學院,安徽 合肥 230009)

協作通信技術的應用給無線網絡媒體接入控制(media access control,MAC)協議設計帶來新的挑戰。針對該協作通信技術的特點,文章在RBAR速率自適應協議的基礎上,提出一種支持協作通信技術的MAC協議Coop-RBAR。Coop-RBAR協議根據發送端、協作節點和接收端之間的瞬時信道狀態來決定數據傳輸方式和傳輸速率;基于系統能達到的最大吞吐量和邀請幀退避算法,選擇最優的協作節點參與數據傳輸。仿真結果表明,Coop-RBAR協議能夠有效地提高網絡性能,可獲得比RBAR協議更高的吞吐量和更小的傳輸時延。

IEEE 802.11協議;媒體接入控制(MAC)協議;協作通信;RBAR協議;速率自適應

IEEE 802.11[1]物理層支持多種不同的傳輸速率。發送端與接收端可以根據信道狀態選擇合適的數據傳輸速率,當信道狀態較好、信噪比較高時,可選擇較高的傳輸速率;當信道狀態較差、信噪比較低時,可選擇較低的傳輸速率。為了充分利用物理層的多速率特性,研究人員提出不同層次的速率自適應協議。在媒體接入控制(media access control,MAC)層,文獻[2]提出一種基于組播的MAC協議,文獻[3]提出由接收端根據瞬時信道狀態選擇數據傳輸速率的RBAR協議。在這些協議中,當發送端與接收端的信道狀態較差時,兩者只能以較低的速率傳輸數據,這會導致整個網絡性能降低。

為了解決這一問題,研究人員提出協作通信技術[4-5],該協作通信技術顛覆了傳統的無線網絡通信方式。通過協作可以使高速率鏈路取代低速率鏈路,有效地改善無線網絡的性能。然而數據傳輸過程中更多節點的介入使得MAC變得更復雜,需要重新進行MAC協議的設計。

目前,已有研究人員對支持協作通信的MAC協議進行了研究。基于IEEE 802.11 DCF、CoopMAC協議[6]和 Shan-MAC協議[7]相似,通過維護協作表來保存協作節點信息,并根據這些信息選擇數據傳輸方式,但需預先指定數據傳輸速率,不能很好地適應信道瞬時變化,且當同時存在多個協作節點時不能選擇出最優的協作節點。文獻[8]提出一種按需的協作MAC協議,該協議無需維護協作表,協作節點通過設置退避時間T競爭參與協作。節點在競爭過程中發送的邀請幀可能會發生碰撞,從而導致整個握手過程失敗。

針對以上協作MAC協議的不足,本文將協作通信技術引入RBAR協議,提出一種支持協作通信技術的MAC協議Coop-RBAR。Coop-RBAR協議利用發送端、協作節點和接收端之間的信道狀態選擇數據傳輸方式和傳輸速率,能夠較好地適應信道的瞬時變化;基于系統最大吞吐量和邀請幀退避算法選擇協作節點,當同時存在多個協作節點時可選擇出最優的協作節點參與數據傳輸,并減少因協作引起的額外通信開銷。

1 系統模型與網絡拓撲

系統基于頻分雙工(frequency division duplexing,FDD)模式工作,上下鏈路對稱,各站點發送功率固定。無線信道路徑損耗采用距離-對數模型,即

(1)

其中,L(d0)為單位上的路徑損耗;n為路徑損耗指數。

信號是否能被正確接收取決于信號在接收端的信噪比,信號在接收端的信噪比(signal to interference plus noise ration,SINR)定義為:

(2)

其中,Noise-Power為環境噪聲和節點本身產生的噪聲之和;Rx_Power為信號在接收端的接收信號強度。

網絡拓撲如圖1所示。

圖1 網絡拓撲

圖1中,節點S為發送端;節點D為接收端;節點H為協作節點;節點H2~H5為其他可能的協作節點;節點C與節點E為隱藏節點。

2 Coop-RBAR協議

Coop-RBAR協議工作過程如下:H通過監聽S與D之間的數據傳輸,判斷是否能以其為協作節點提高S與D的傳輸效率。若能,則H發送一條邀請幀通知S。網絡中的每個節點維護一張協作表,用來保存可為其數據傳輸提供幫助的協作節點的信息。當收到來自H的邀請幀后,S在其協作表中添加一條新的記錄。下次S向D傳輸數據時,S根據協作表中的記錄,先將數據發送至H,再由H發送至D。

協作表格式見表1所列。其中,Dst字段為D的地址;RelayNode字段為H的地址;Time字段為創建此條記錄的時間;State字段表示此條記錄是否有效,為1時有效,為0時無效。

表1 協作表格式

2.1 數據傳輸過程

為了實現協作通信,Coop-RBAR協議在RBAR協議原有控制幀上進行了修改,并添加控制幀HTS(helper to send)和邀請幀,新的控制幀格式如圖2所示。

圖2 控制幀格式

新的RTS控制幀在RBAR協議RTS控制幀上增加HelpAddr字段,表示S選擇的協作節點的地址。新的CTS控制幀中除HelpAddr字段外還增加了RTS-SNR字段和HTS-SNR字段,分別表示D收到的RTS控制幀和HTS控制幀的接收信號強度,其他字段與RBAR協議控制幀對應字段作用相同。HTS控制幀的RTS-SNR字段表示H收到的RTS控制幀的信號強度。邀請幀的RA字段為廣播地址,TA字段為H的地址,Src和Dst字段分別為S和D的地址。

S向D傳輸數據既可以采用協作方式,也可以采用直接傳輸方式。所采用的方式取決于要傳輸的數據幀的長度L以及S的協作表中的記錄。當L小于RTS門限值時,數據傳輸采用DATA/ACK的直接傳輸方式;當L大于RTS門限值但在協作表中找不到可提供幫助的協作節點時,數據傳輸采用RTS/CTS/DATA/ACK的直接傳輸方式;當L大于RTS門限值且可在協作表中找到協作節點時,數據傳輸采用RTS/HTS/CTS/DATA(S→H)/DATA(H→D)/ACK的協作方式。

一次完整的數據傳輸分為握手過程和數據幀傳輸過程2個階段。直接傳輸方式下的數據傳輸過程和時序圖與RBAR協議相同。協作方式下的數據傳輸過程和時序圖分別如圖3、圖4所示。

圖3 協作方式下數據傳輸過程

數據傳輸的具體步驟如下。

步驟1 當S有數據要發送到D時,S首先檢測信道,在檢測到信道空閑時間超過分布式幀間間隙(distributed inter-frame spacing,DIFS)時間間隔后執行隨機退避算法,若退避結束后信道仍為空閑狀態,則S獲得信道控制權。S檢索協作表,尋找協作節點。若找到協作節點,則將RTS幀中的HelpAddr字段填充為協作節點的地址;若沒有找到,則將HelpAddr字段置0。之后S廣播RTS幀并等待。RTS的Duration字段設置為即將傳輸的數據幀長度L。收到RTS的節點將其網絡分配矢量(network allocation vector,NAV)設置為:

(3)

其中,THTS為HTS幀的傳輸時延;TCTS為CTS幀的傳輸時延;σ為最大長度數據幀傳播時延;SIFS為短幀間間隔(short inter frame space)。

圖4 協作方式下數據傳輸時序圖

步驟2 H收到來自S的RTS幀后,將RTS幀的HelpAddr字段與自身地址進行對比,若兩者相等,且H當前處于空閑狀態,則H廣播HTS幀并等待;否則H直接丟棄RTS幀。HTS幀的Duration字段設置為:

(4)

其中,Rsh為H和S的數據傳輸速率。H可根據收到的RTS控制幀的信號強度得出Rsh。

步驟3 D收到來自S的RTS幀后,等待來自H的HTS幀。若超過THTS+SIFS+σ時間間隔后仍未收到HTS幀,則D認為H忙,將CTS幀的HelpAddr字段置0。若D收到HTS幀,則根據收到的RTS幀的信號強度得出S與D所能達到的最大數據傳輸速率Rsd,根據HTS幀的RTS-SNR字段得出S與H所能達到的最大數據傳輸速率Rsh,再根據收到的HTS幀的信號強度得出H與D所能達到的最大數據傳輸速率Rhd。D根據Rsd、Rsh、Rhd執行協作條件判定算法,判斷此時由H轉發數據能否提高傳輸效率,若不能,則將CTS幀的HelpAddr字段置0。之后D廣播CTS幀,并等待數據幀的到來。CTS幀的Duration字段設置為:

(5)

其中,TACK為ACK幀的傳輸時延。

步驟4 S在等待THTS+TCTS+2SIFS+2σ時間間隔后若沒有收到HTS幀或CTS幀,則認為發生了分組碰撞,并執行二進制指數退避算法。若S收到了CTS幀但沒有收到HTS幀,則根據CTS幀的接收信號強度得出Rsd,將數據幀直接發送給D,并將協作表中相應記錄的State字段置0。若S同時收到了HTS幀和CTS幀,則判斷CTS幀中的HelpAddr字段是否為0,若為0則說明D判定此時H無法提高傳輸效率,S可將數據幀直接發送給D;否則,S根據收到的HTS幀的信號強度得出Rsh,將數據幀發送給H。由S發送給H的數據幀的Duration字段設置為:

(6)

步驟5 H收到來自S的數據幀后,以Rhd的數據傳輸速率將數據幀發送給D。D收到數據幀后發送ACK給S。由H發送給D的數據幀的Duration字段設置為:

(7)

2.2 協作表建立過程

H通過監聽S與D的數據傳輸過程來判斷以其為協作節點是否能提高傳輸效率。H根據接收到的RTS幀的信號強度得出Rsh,并判斷接收到的CTS幀的HelpAddr字段是否為0。若HelpAddr字段為0,則當前S與D的數據傳輸沒有采用協作方式。H再根據接收到的CTS幀的信號強度得出Rhd,根據CTS幀的RTS-SNR字段得出Rsd,并執行協作條件判定算法,若H滿足成為協作節點的條件,則執行邀請幀退避算法。若CTS幀的HelpAddr字段不為0,則說明當前數據傳輸采用協作方式。H根據CTS幀的HTS-SNR字段和HTS幀的RTS-SNR字段分別得出當前協作節點與D的數據傳輸速率Rhd′以及與S的數據傳輸速率Rsh′,若滿足min(Rsh,Rhd)> min(Rhd′,Rsh′)或max(Rsh,Rhd)>max(Rhd′,Rsh′),則H執行邀請幀退避算法。S收到邀請幀后,在其協作表中添加一條新的記錄,并刪除表中Dest與邀請幀中DstToRelay字段相同的記錄。

Coop-RBAR采用邀請幀退避算法選擇最優協作節點和減少額外通信開銷。為實現邀請幀退避算法,每個節點維護一張服務表,服務表格式見表2所列。

表2 服務表格式

表2中,〈Src, Dst〉字段表示節點想要為其提供幫助的節點對〈S, D〉的地址;T1字段表示此條記錄的生成時間;T2字段表示最近一次發送邀請幀或為節點對〈S, D〉提供幫助的時間;BI字段表示一個退避時間;State字段表示此條記錄是否有效,為1時有效,為0時無效。

邀請幀退避算法描述如下:若某一時刻H執行協作條件判定算法后發現其滿足作為〈S,D〉的協作節點的條件,則檢索服務表,查看是否有〈S,D〉的記錄。若沒有,則在服務表中創建一條新紀錄,并置T1、T2為t,BI為初始值,State置1并生成1條邀請幀到發送隊列中。t表示當前時間。若已存在〈S,D〉的記錄,則判斷條件T2+BI>t且State=1是否滿足,若滿足,則置BI=2BI,再判斷BI是否大于最大值。若BI大于最大值,則置State為0且不生成邀請幀。若BI小于最大值,則置T1、T2為當前時間,并生成1條邀請幀到其發送隊列。若在邀請幀發送之前H收到了來自其他節點的為〈S, D〉提供協作的邀請幀,則根據該邀請幀的RTS-SNR字段和CTS-SNR字段分別得出發送該邀請幀的節點與S和D的數據傳輸速率Rsh″和Rhd″,若滿足min(Rsh″,Rhd″)>min(Rsh,Rhd)或max(Rsh″,Rhd″)>max(Rsh,Rhd),則H將未發送的邀請幀從發送隊列中刪除。節點在每次成功為〈S, D〉轉發數據后將對應記錄的BI設置為初始值。

2.3 協作條件判定算法

通過測量不同傳輸速率的單跳鏈路和雙跳鏈路的實際吞吐量來判斷節點H是否滿足作為〈S, D〉的協作節點的條件。以IEEE802.11 b[9]為例說明協作條件判定算法,通過NS2網絡模擬器進行仿真,結果見表3、表4所列。

表3 單跳鏈路下的吞吐量 Mb/s

從表3、表4可看出,單跳鏈路下Rsd為5.5 Mb/s時的吞吐量高于雙跳鏈路下Rsh和Rhd都為11 Mb/s時的吞吐量,因此,當Rsd≥5.5 Mb/s時不需要采用協作方式。單跳鏈路下Rsd為2 Mb/s時的吞吐量高于雙跳鏈路下Rsh和Rhd分別為11 Mb/s和2 Mb/s時的吞吐量。因此若Rsd<5.5 Mb/s且min(Rsh,Rhd)≥5.5 Mb/s,節點H滿足成為協作節點的條件。否則,節點H不滿足成為協作節點的條件。

表4 雙跳鏈路下的吞吐量 Mb/s

3 仿真結果與分析

采用NS2網絡模擬器比較Coop-RBAR與RBAR協議的性能,在IEEE 802.11 b環境下進行仿真,所有節點隨機分布在250 m×250 m的圓形區域內。在靜態場景下,分別取節點數為20、30、40、50、60,數據流取10條,其中5條數據流符合協作判定條件。在動態場景下,取節點數為40,數據流為20條,分別取節點移動速度為2、4、6、8、10 m/s,數據流和節點的移動方式分別由NS2的Cbrgen和Setdest工具生成。每個場景下的仿真文件運行時間設置為50 s,運行10次,仿真結果取10次運行結果的平均值。設置服務表BI初始值和最大值分別為2 s和128 s。根據Lucent Orinoco PC Card[9],接收信號強度、數據傳輸速率與信號傳輸范圍的關系見表5所列。

表5 接收信號強度與數據傳輸速率關系

靜態場景下用戶數據協議(user datagram protocol,UDP)、傳輸控制協議(transmission control protocol,TCP)的吞吐量與傳輸時延比較如圖5所示。從圖5可以看出,Coop-RBAR協議無論是吞吐量還是傳輸時延都比RBAR協議有所提高,且吞吐量和傳輸時延的提高程度不隨節點數的變化而產生較大浮動。這說明隨著節點分布密度逐漸稠密,潛在的協作節點增多時,邀請幀退避算法可較好地減小因發送邀請幀而引起的額外開銷。由于TCP存在數據傳輸控制,因此TCP的吞吐量比UDP的吞吐量低,但TCP的傳輸時延比UDP的傳輸時延小。

動態場景下UDP、TCP的吞吐量與傳輸時延比較如圖6所示。

圖5 靜態場景下吞吐量和傳輸時延比較

圖6 動態場景下吞吐量與傳輸時延比較

從圖6可知,動態場景下Coop-RBAR協議比RBAR協議性能更好,但動態場景下性能提高的程度比靜態場景下略小。由于節點的隨機移動可能導致S與D相互靠近,Rsd相對較大,無需采用協作方式;也可能導致協作表的表項失效,使得表中節點不再滿足協作節點的條件。

4 結 論

本文在RBAR協議的基礎上提出了一種支持協作通信的MAC協議Coop-RBAR,實現了高速率鏈路取代低速率鏈路,有效地提高了網絡性能。仿真結果表明,Coop-RBAR可獲得比RBAR協議更高的吞吐量和更小的傳輸時延。目前Coop-RBAR只支持單個協作節點,支持多個協作節點的協議有待進一步研究。

[1] HIERTZ G R,DENTENEER D,STIBOR L,et al.The IEEE 802.11 universe[J].IEEE Communications Magazine,2010,48(1):62-70.

[2] KIM S W,KIM B S.Rate-adaptive MAC protocol for eireless multicast over OFDMA-based MANETs[J].Wireless Personal Communications:An International Journal,2011,56(4):675-692.

[3] HOLLAND G,VAIDYA N,BAHL P.A rate-adaptive MAC protocol for multi-Hop wireless networks[C]//Proceedings of the 7th Annual International Conference on Mobile Computing and Networking.[S.l.:s.n.],2001:236-251.

[4] JU P J,SONG W,ZHOU D Z.Survey on cooperative medium access control protocols[J].IET Communications,2013,7(9):893-902.

[5] KHAN R A M,KARL H.MAC protocols for cooperative diversity in wireless LANs and wireless sensor networks[J].IEEE Communications Surveys & Tutorials,2014,16(1):46-63.

[6] LIU P,TAO Z F,NARAYANAN S,et al.CoopMAC: a cooperative MAC for wireless LANs[J].IEEE Journal on Selected Areas in Communications,2007,25(2):340-354.

[7] SHAN H G,CHENG H T,ZHUANG W H.Cross-layer cooperative MAC protocol in distributed wireless networks[J].IEEE Transactions on Wireless Communications,2011,10(8):2603-2615.

[8] OH C Y,LEE T J.Cooperative MAC protocol using active relays for multi-rate WLANs[J].Journal of Communications and Networks,2011,13(5):463-471.

[9] CARVALHO J A R P D,VEIGA H,MARQUES N,et al.Wi-Fi IEEE 802.11 B,G WEP links[M].New York: Electrical Engineering and Intelligent Systems,2013:183-193.

(責任編輯 閆杏麗)

A RBAR based cooperative MAC protocol

WANG Yanhui, WEI Zhenchun, WEI Juyi, HAN Jianghong

(School of Computer and Information, Hefei University of Technology, Hefei 230009, China)

The application of cooperative communication technology introduces new challenges to media access control(MAC) protocol design. According to the characteristics of cooperative communication, a cooperative MAC protocol is proposed on the basis of RBAR, called Coop-RBAR. Coop-RBAR uses joint feedback of instantaneous channel state information from both the sender and the receiver as well as the relay node to select data transfer mode and data rate; the most capable relay node is chosen depending on the max throughput and the invitation frame backoff algorithm. The simulation results show that Coop-RBAR can effectively enhance the network performance, it outperforms RBAR in terms of throughput and end-to-end delay.

IEEE 802.11 protocol; media access control(MAC) protocol; cooperative communication; RBAR protocol; rate-adaptive

2015-12-18;

2016-02-22

國家自然科學基金資助項目(61370088;61502142);國家國際科技合作專項資助項目(2014DFB10060)

王艷輝(1991-),男,安徽利辛人,合肥工業大學碩士生; 韓江洪(1954-),男,安徽涇縣人,合肥工業大學教授,博士生導師.

10.3969/j.issn.1003-5060.2017.01.007

TP393.01

A

1003-5060(2017)01-0037-06

主站蜘蛛池模板: 国产精品久久精品| 亚洲欧美极品| 亚洲国语自产一区第二页| v天堂中文在线| 国产a在视频线精品视频下载| 亚洲第一香蕉视频| 2020久久国产综合精品swag| 国产精品美乳| 国产网友愉拍精品| 免费高清毛片| 精品无码国产一区二区三区AV| 国产精品自在在线午夜区app| 高清视频一区| 99re在线免费视频| 日韩黄色大片免费看| 欧美成人手机在线视频| 久久久久青草线综合超碰| 香蕉视频在线观看www| 伊人狠狠丁香婷婷综合色| 蜜桃视频一区二区| 亚洲综合久久一本伊一区| 丝袜高跟美脚国产1区| 91福利国产成人精品导航| 亚洲—日韩aV在线| 国内精品视频在线| 91精品国产自产91精品资源| 青青草原国产av福利网站| 午夜啪啪福利| 国产精品区视频中文字幕| 午夜a视频| 青青操国产视频| 四虎影视无码永久免费观看| 91香蕉视频下载网站| 亚洲Va中文字幕久久一区 | 污视频日本| 在线色综合| 毛片国产精品完整版| 国产成人综合久久| 少妇露出福利视频| 亚洲侵犯无码网址在线观看| 免费 国产 无码久久久| 国产视频只有无码精品| 婷婷六月色| 国产精品手机在线播放| 久久毛片网| 人妻无码AⅤ中文字| 欧美成人在线免费| 久久一本精品久久久ー99| 日韩高清成人| 91最新精品视频发布页| 日韩国产无码一区| 国产日韩精品欧美一区灰| 成人小视频网| www.精品国产| 国产成人1024精品下载| 久久99国产视频| 国产免费一级精品视频 | 亚洲精品少妇熟女| 亚洲人成日本在线观看| 国产成人精品高清不卡在线| 亚洲AV无码不卡无码| 久久精品亚洲中文字幕乱码| 亚洲国产清纯| 欧美劲爆第一页| 国产一级二级三级毛片| 人妻91无码色偷偷色噜噜噜| 99这里精品| 经典三级久久| 69视频国产| 国产高清国内精品福利| 中文字幕色站| 日韩东京热无码人妻| 国产精品一区二区无码免费看片| 亚洲天堂网站在线| 91在线免费公开视频| 国产在线视频欧美亚综合| 国产在线视频自拍| 亚洲综合经典在线一区二区| 国产国语一级毛片| 8090成人午夜精品| 亚洲区欧美区| 国产区在线观看视频|