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

(合肥工業(yè)大學(xué) 計(jì)算機(jī)與信息學(xué)院,安徽 合肥 230009)

一種基于RBAR的協(xié)作MAC協(xié)議

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

(合肥工業(yè)大學(xué) 計(jì)算機(jī)與信息學(xué)院,安徽 合肥 230009)

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

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

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

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

目前,已有研究人員對支持協(xié)作通信的MAC協(xié)議進(jìn)行了研究?；贗EEE 802.11 DCF、CoopMAC協(xié)議[6]和 Shan-MAC協(xié)議[7]相似,通過維護(hù)協(xié)作表來保存協(xié)作節(jié)點(diǎn)信息，并根據(jù)這些信息選擇數(shù)據(jù)傳輸方式,但需預(yù)先指定數(shù)據(jù)傳輸速率,不能很好地適應(yīng)信道瞬時(shí)變化,且當(dāng)同時(shí)存在多個(gè)協(xié)作節(jié)點(diǎn)時(shí)不能選擇出最優(yōu)的協(xié)作節(jié)點(diǎn)。文獻(xiàn)[8]提出一種按需的協(xié)作MAC協(xié)議,該協(xié)議無需維護(hù)協(xié)作表,協(xié)作節(jié)點(diǎn)通過設(shè)置退避時(shí)間T競爭參與協(xié)作。節(jié)點(diǎn)在競爭過程中發(fā)送的邀請幀可能會(huì)發(fā)生碰撞,從而導(dǎo)致整個(gè)握手過程失敗。

針對以上協(xié)作MAC協(xié)議的不足,本文將協(xié)作通信技術(shù)引入RBAR協(xié)議,提出一種支持協(xié)作通信技術(shù)的MAC協(xié)議Coop-RBAR。Coop-RBAR協(xié)議利用發(fā)送端、協(xié)作節(jié)點(diǎn)和接收端之間的信道狀態(tài)選擇數(shù)據(jù)傳輸方式和傳輸速率,能夠較好地適應(yīng)信道的瞬時(shí)變化;基于系統(tǒng)最大吞吐量和邀請幀退避算法選擇協(xié)作節(jié)點(diǎn),當(dāng)同時(shí)存在多個(gè)協(xié)作節(jié)點(diǎn)時(shí)可選擇出最優(yōu)的協(xié)作節(jié)點(diǎn)參與數(shù)據(jù)傳輸，并減少因協(xié)作引起的額外通信開銷。

1 系統(tǒng)模型與網(wǎng)絡(luò)拓?fù)?/h2>

系統(tǒng)基于頻分雙工(frequency division duplexing，F(xiàn)DD)模式工作,上下鏈路對稱,各站點(diǎn)發(fā)送功率固定。無線信道路徑損耗采用距離-對數(shù)模型,即

(1)

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

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

(2)

其中，Noise-Power為環(huán)境噪聲和節(jié)點(diǎn)本身產(chǎn)生的噪聲之和;Rx_Power為信號(hào)在接收端的接收信號(hào)強(qiáng)度。

網(wǎng)絡(luò)拓?fù)淙鐖D1所示。

圖1 網(wǎng)絡(luò)拓?fù)?/p>

圖1中，節(jié)點(diǎn)S為發(fā)送端；節(jié)點(diǎn)D為接收端；節(jié)點(diǎn)H為協(xié)作節(jié)點(diǎn)；節(jié)點(diǎn)H2～H5為其他可能的協(xié)作節(jié)點(diǎn)；節(jié)點(diǎn)C與節(jié)點(diǎn)E為隱藏節(jié)點(diǎn)。

2 Coop-RBAR協(xié)議

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

協(xié)作表格式見表1所列。其中，Dst字段為D的地址；RelayNode字段為H的地址；Time字段為創(chuàng)建此條記錄的時(shí)間；State字段表示此條記錄是否有效，為1時(shí)有效,為0時(shí)無效。

表1 協(xié)作表格式

2.1 數(shù)據(jù)傳輸過程

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

圖2 控制幀格式

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

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

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

圖3 協(xié)作方式下數(shù)據(jù)傳輸過程

數(shù)據(jù)傳輸?shù)木唧w步驟如下。

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

(3)

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

圖4 協(xié)作方式下數(shù)據(jù)傳輸時(shí)序圖

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

(4)

其中,Rsh為H和S的數(shù)據(jù)傳輸速率。H可根據(jù)收到的RTS控制幀的信號(hào)強(qiáng)度得出Rsh。

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

(5)

其中,TACK為ACK幀的傳輸時(shí)延。

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

(6)

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

(7)

2.2 協(xié)作表建立過程

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

Coop-RBAR采用邀請幀退避算法選擇最優(yōu)協(xié)作節(jié)點(diǎn)和減少額外通信開銷。為實(shí)現(xiàn)邀請幀退避算法,每個(gè)節(jié)點(diǎn)維護(hù)一張服務(wù)表,服務(wù)表格式見表2所列。

表2 服務(wù)表格式

表2中，〈Src, Dst〉字段表示節(jié)點(diǎn)想要為其提供幫助的節(jié)點(diǎn)對〈S, D〉的地址;T1字段表示此條記錄的生成時(shí)間;T2字段表示最近一次發(fā)送邀請幀或?yàn)楣?jié)點(diǎn)對〈S, D〉提供幫助的時(shí)間;BI字段表示一個(gè)退避時(shí)間;State字段表示此條記錄是否有效,為1時(shí)有效,為0時(shí)無效。

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

2.3 協(xié)作條件判定算法

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

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

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

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

3 仿真結(jié)果與分析

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

表5 接收信號(hào)強(qiáng)度與數(shù)據(jù)傳輸速率關(guān)系

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

動(dòng)態(tài)場景下UDP、TCP的吞吐量與傳輸時(shí)延比較如圖6所示。

圖5 靜態(tài)場景下吞吐量和傳輸時(shí)延比較

圖6 動(dòng)態(tài)場景下吞吐量與傳輸時(shí)延比較

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

4 結(jié) 論

本文在RBAR協(xié)議的基礎(chǔ)上提出了一種支持協(xié)作通信的MAC協(xié)議Coop-RBAR,實(shí)現(xiàn)了高速率鏈路取代低速率鏈路,有效地提高了網(wǎng)絡(luò)性能。仿真結(jié)果表明,Coop-RBAR可獲得比RBAR協(xié)議更高的吞吐量和更小的傳輸時(shí)延。目前Coop-RBAR只支持單個(gè)協(xié)作節(jié)點(diǎn),支持多個(gè)協(xié)作節(jié)點(diǎn)的協(xié)議有待進(jìn)一步研究。

[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.

(責(zé)任編輯 閆杏麗)

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

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

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

10.3969/j.issn.1003-5060.2017.01.007

TP393.01

A

1003-5060(2017)01-0037-06