一种基于RBAR的协作MAC协议

王艳辉, 魏振春, 魏炬熠, 韩江洪

(合肥工业大学 计算机与信息学院,安徽 合肥 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