Ad Hoc网络中, 通过将协作通信中无线信道的广播特性所产生的空间分集增益和网络编码技术相融合, 能够有效地提高网络性能和链路的可靠性[1]。协作通信[2]是指在某个区域内, 多个具备单天线的通信节点通过彼此相互协作的方式接收或转发数据, 构成一种虚拟的多输入多输出(Multiple Input Multiple Output, MIMO)无线系统, 从而实现在不具备多天线的情况下得到分集增益; 而网络编码技术[3]是指网络中的某些中间节点对接收到的数据先进行编码操作, 然后再将编码后的数据转发给下一跳或者目的节点, 其能够有效地减少网络带宽的使用, 从而节省网络资源。因此, 将两种技术有效地融合应用一直是近年来研究的热点。
目前, 协作通信已在媒体访问控制(Medium Access Control, MAC)协议中得到广泛的研究[4-6], 然而, 在许多协作MAC协议[7-8]中, 当数据直传没有被目的节点正确接收时, 需要协作中继节点协助源节点转发该数据分组, 此时协作中继节点需要竞争信道, 贡献部分带宽, 协助源节点转发数据分组, 却不能处理自身需要发送的数据, 则称此操作是中继低效率问题[8]。因此, 设计一种既能协助源节点转发数据分组又能发送自身数据的高效协作MAC协议显得尤为重要。为了解决上述问题, 协作中继节点需要将数据包融合且使目的节点能够解码该数据包, 而网络编码技术恰好能够有效地实现该目的。
将网络编码技术应用在协作通信中, 能够增强数据传输的可靠性和有效性。为了保证目的节点能够有效解码, 选择合适的协作中继节点是实现上述目的的重要条件。文献[8]针对Ad Hoc网络提出了一种基于数据速率传输的中继选择算法, 该算法的核心思想为:当数据传输速率较大时采用编码传输方式; 反之, 则采用数据直传方式。在数据传输的过程中, 首先选出数据传输速率相对较大所对应的候选协作中继节点, 然后根据其传输方式相对应的数据传输速率, 通过利用退避方式竞争成为最佳协作中继节点, 从而提高网络的性能。
文献[9]针对协作中继节点低效率问题提出了一种Phoenix协议。该协议将网络编码技术与协作通信相结合, 通过随机退避方式选出协作中继节点, 且协作中继节点将自身需要发送的数据帧与已缓存源节点发送的数据帧进行编码, 然后该协作中继节点与其目的节点之间通过CTS/RTS(Clear To Send/Request To Send)握手机制判断自身的目的节点能否解码出该编码的数据帧。若能成功解码, 则协作中继节点将编码包发送至其目的节点以及源节点的目的节点; 若不能成功解码, 则单一地采用协作重传方式传输源节点的数据分组。
文献[10]针对无线Ad Hoc网络提出了一种基于网络编码的协同MAC协议(Cooperative MAC with Network Coding for Ad hoc networks, NCCMAC), 该协议将网络编码与协同机制进行融合。该机制主要考虑了协作中继节点何时进行数据编码传输, 何时进行单一的协作重传, 且同样通过CTS/RTS握手机制判断协作中继节点是否能进行数据的编码传输。另外, 该文献分三种情况讨论了协作中继节点的目的节点的所处情况, 并且在二维马尔可夫(Markov)退避模型基础上, 对多跳网络中的吞吐量进行了分析。
文献[11]针对文献[9]中的Phoenix协议无法确定所选择的协作中继节点是否具有编码机会和无法准确获知协作中继节点缓存区缓存的数据帧数量以及通过CTS/RTS握手机制判别是否进行数据编码并非最优的问题, 提出了一种基于编码感知的协作MAC协议(Network Coding Aware Cooperative MAC protocol for wireless Ad Hoc networks, NCAC-MAC)。该协议在选择最佳协作中继节点时综合考虑了候选中继的预估吞吐量、缓存区缓存数据帧的数量以及候选协作中继节点的目的节点成功解码的概率等多种度量, 同时取消了CTS/RTS握手机制, 采用连接表机制评估协作中继节点的目的节点是否已经接收到或者已拥有源节点发送的数据帧, 从而判断是否能够成功解码; 但是该协议忽略了节点的能耗, 不能有效延长网络寿命。
文献[12]在文献[11]基础上对编码感知MAC协议中选择协作中继节点的具体操作过程进行了深入的研究, 提出了两种选择协作中继节点的算法(基于中继选择的分区算法和基于组间竞争思想的中继选择算法),从而在选择协作中继节点的过程中能够降低数据帧碰撞的概率, 但是在基于组间竞争思想的中继选择算法中, 由于存在不在彼此通信范围内的节点导致协作中继节点选择效率较低。
文献[11-12]在选择协作中继节点的过程中考虑了网络吞吐量、端到端时延和数据帧的投递率相关性能指标, 然而该NCAC-MAC协议未能将能耗[13]同时综合考虑。因此, 本文针对协作中继节点的选择问题, 提出了一种基于协作网络编码的高效MAC协议(High Efficiency MAC protocol based on Cooperative Network Coding, HECNC-MAC)。
1 网络模型和问题描述 1.1 网络模型为了便于阐述HECNC-MAC协议, 给出如下定义:
定义1 候选协作中继节点。表示既接收了源节点发送的数据帧, 又接收了目的节点广播的NACK(Negative Acknowledgment)控制消息的那些节点。
定义2 连接表。表示一个节点与其所有邻居及其邻居的邻居节点的链路质量、距离和信道容量信息的表, 且该连接表于网络初始化时所构建。
定义3 伪广播。将最佳协作中继节点的地址添加在控制帧的确认消息(Feed Back, FB)头部中, 然后以广播的方式发送。该确认消息FB有三种FB0、FB1、FB2,且每种确认帧中有一个标志位,其值为0或者为1(0表示确认失败,1表示确认成功)。
定义4 缓存概率ρb。指候选协作中继节点的目的节点已缓存源节点发送的数据帧的概率。
在协作MAC机制中采用网络编码技术, 协作中继节点能够完成协助转发源节点数据的同时发送自己的数据的功能。其网络模型如图 1所示。
若源节点S给其目的节点D发送数据包a, 假设候选协作中继节点A、B、C、F都能侦听到该数据包, 且所有候选协作中继都能正确接收目的节点发送的数据。若目的节点D由于信道衰落或者噪声等影响接收到一个损坏的数据a′, 当该数据帧的信噪比大于设定的阈值时, 此时目的节点D将会反馈一个标志位flag为1的控制消息, 协作中继节点A(此处假设A已通过竞争且被选为协作中继节点)就会将自己待发送的数据b与侦听的数据a进行网络编码得到组合包F(a, b), 然后发送该组合包。目的节点D接收到该组合包以后, 使用一种网络编码MIMO_NC[14]进行解码, 即使存在一个损坏的数据a′, MIMO_NC依然可以根据编码包F(a, b)和损坏数据a′进行解码; 而协作中继节点的目的节点B, 收到组合包F(a, b)后根据已得到的数据a使用常规网络编码的解码方案即可解码。
1.2 问题描述NCAC-MAC协议提出的无碰撞中继选择机制的核心思想是候选协作中继节点首先计算各自的效用值, 然后根据其效用值计算出退避时间, 经过三次退避两次竞选从而得到协作中继节点。具体实现主要有以下两个部分:
1) 产生一个效用值整数位对应索引值取整的退避时间, 从而抑制整数位较大的候选协作中继节点, 紧接着继续产生一个效用值的小数位对应索引值取整的退避时间, 从而抑制小数位较大的候选协作中继节点;
2) 若前两次仍没竞选成功, 则第三次产生一个随机退避时间, 从而最终竞选出协作中继节点, 然后选择对应的数据传输方式协助源节点发送数据。
经过深入研究发现, 发现该算法存在以下三个问题:
1) 假设候选协作中继节点的目的节点与源节点S之间链路质量较差, 该候选节点却依然参与竞争, 增加碰撞的概率, 导致竞选成功的效率降低。在图 1中, 假设节点A的目的节点为E, 而节点E缓存源节点数据的概率较低, 此时节点A却依然参与竞争; 另外, 即使A竞选成功, 节点E收到编码包后亦不能解码出数据, 从而影响整个网络的吞吐量, 降低了中继效率。
2) 在每次退避过程中, 候选协作中继节点会广播发送抑制帧; 且竞选协作中继节点成功后, 会广播发送ETH(Eager To Help)控制消息进行通告。然而存在不在彼此通信范围内的候选节点, 则使得原本应该停止退避的候选节点没有停止退避, 最后导致竞选协作中继节点失败。如图 1中, 若节点A与C、F不在彼此通信范围内, 假设A先退避至0, 目的节点确认后, 其会发送ETH帧时, 节点C、F都不能接收, 当节点C或者F退避至0时, 目的节点也会发送确认消息, 则节点C和F也会发送ETH控制消息, 从而导致竞选失败, 最后只能由源节点超时重传。
3) 在计算映射为退避时间的效用值时仅考虑了缓存数据帧个数、数据帧的估计吞吐量以及协作中继节点目的节点的解码成功率,由于没有考虑候选协作中继节点发送编码帧给目的节点所需要的传输的能耗, 会导致选择的协作中继节点由于生存时间过短而重新竞争, 降低了网络整体的性能。
2 HECNC-MAC协议提出的优化策略针对NCAC-MAC协议中存在的三个问题, 本文提出了HECNC-MAC协议。该协议中提出了三种优化策略:首先,候选协作中继节点利用缓存概率进行解码预判, 同时限制参与竞争节点的个数, 从而保证协作中继节点的目的节点能成功解码; 其次,在计算映射为退避时间的效用值时, 同时综合考虑节点传输所需能耗以及自身的剩余能量; 最后,取消ETH控制消息, 且目的节点使用伪广播的方式进行协作中继节点通告, 减少信令开销的同时解决了因存在不在彼此通信范围内的候选协作中继节点导致竞选失败的问题。
2.1 协作中继节点的解码预判由于协作中继节点的目的节点是否缓存了源节点S发送的数据帧直接影响到协作中继节点的目的节点能否解码, 因此缓存概率ρb的取值显得尤为重要。为了避免选择的协作中继节点的缓存概率较低或者缓存概率较低的节点却仍然参与竞争而占用信道、浪费带宽的问题, 缓存概率ρb其具体的取值如式(1) 所示:
$ {\rho _b} = \left\{ \begin{array}{l} 1, \;\;\;\;\;\;D\left( b \right) = D\left( a \right)\\ 0.9\;\;\;\;LQ\left( {S, D\left( b \right)} \right) \ge LQ\left( {S, relay} \right)\\ 0, \;\;\;\;\;其他 \end{array} \right. $ | (1) |
其中:D(x)表示数据帧x对应的目的节点; LQ(S, D(x))表示源节点S与数据帧x对应的目的之间的链路质量; LQ(S, relay)表示源节点S与候选协作中继节点之间的链路质量; b表示协作中继节点的数据帧;a表示源节点S的数据帧, 且链路质量的值通过连接表可得, 其具体值由下层计算可得。当候选协作中继节点的目的节点同时也是源节点的目的节点时,ρb取值为1;当候选协作中继节点的目的节点与源节点之间链路质量比源节点与其自身的链路质量更好时,其取值为0.9;反之, 当候选协作中继节点的目的节点与源节点之间链路质量比源节点与其自身的链路质量较差时,则其取值为0。候选协作中继节点根据其缓存概率的取值对其目的能否解码进行解码预判, 当其缓存概率为0时认定其目的不能解码, 则该候选协作中继节点直接放弃竞争; 反之则继续进行效用值的计算, 参与竞争。
2.2 效用值的计算效用值表示映射为退避时间一个度量值, 该值越大说明对应的协作中继节点越能使得吞吐量更大、能耗更小, 且效用值越大的候选协作中继节点越能最先退避至0, 能更快地成为协作中继节点。首先候选协作中继节点i计算其缓存中每个待发送数据帧的效用值, 然后在每个数据帧对应效用值中选择一个最大的值作为其效用值。具体计算过程如下所示。
步骤1 计算候选协作中继节点发送数据帧给目的节点的预估能耗Ecost[15], 其计算公式如式(2) 所示:
$ {E_{{{\rm{cost}}}}} = \left( {{P_b} \times {l_b}} \right)/\left( {{R_b}} \right) $ | (2) |
其中: lb、Pb、Rb分别表示候选协作中继节点发送数据帧b的长度、发送功率和发送速率。
步骤2 将式(1)~(2) 中得到的结果代入到式(3) 中计算其效用值:
$ {U_i} = \mathop {\max }\limits_{b = 1, 2, \cdots, {L_i}} \left( {\frac{{{\rho _b}{E_{^{{\rm{remain}}}}}}}{{{E_{{\rm{cost}}}}}}\left( {\frac{{{S_{i, b}}}}{{{S^{\max }}}} + \beta \frac{{{L_i}}}{{{L^{\max }}}}} \right)} \right) $ | (3) |
其中: ρb分别表示数据帧b的目的节点缓存源节点发送数据帧a的概率;Si, b表示数据帧b在链路中的预估吞吐量; Li表示候选协作中继节点已经缓存数据帧的个数; Smax和Lmax表示候选协作中继节点缓存数据帧在链路中的预估吞吐量的最大值和缓存空间能够缓存的最大值的个数; β表示权重值;Eremain表示候选协作中继节点当前的剩余能量。
2.3 最佳协作中继节点选择策略源节点发送数据给目的节点, 当目的节点没有正确接收, 且接收的数据帧信噪比大于给定的阈值时, 目的节点会广播发送一个标志位flag为1的NACK的控制帧, 接收了源节点数据和该NACK的节点首先成为候选协作中继节点, 此时候选协作中继节点根据其缓存概率的值决定是否放弃竞争。而最佳协作节点的选择策略其具体步骤如下所示:
步骤1 未放弃竞争的候选协作中继节点首先根据式(4) 计算出其索引值g(g∈[0, G-1]), 然后根据式(5) 计算出第一次退避时间, 从而进入第一次的First退避阶段。
$ g = \left\lfloor {\frac{{G({U_{\max }}-{U_i})}}{{{U_{\max }}-{U_{\min }}}}} \right\rfloor $ | (4) |
其中:Umax、Umin分别表示网络中效用值的上界和下界; Ui是节点i的效用值;G是常数; ⌊x⌋表示向下取整。
$ {T_1}(g) = g \times {t_{fb}} $ | (5) |
其中:tfb表示退避的时隙, 表示T1(g)候选节点需要退避的时间。
步骤2 最先退避至0的所有候选协作中继节点广播发送(Group Indicator, GI)抑制帧, 其他侦听到该抑制帧的节点则放弃竞争。此时目的节点接收端可能存在两种情况:若目的节点仅仅接收一个GI抑制帧, 则目的节点以伪广播方式回复标志位为1的FB0确认帧, 所有候选协作中继节点(包括发送了GI帧和由于不在彼此通信范围内未侦听到GI帧仍在退避的其他节点)收到该确认帧后, 查看帧头部中的地址, 若与自身地址相同, 则说明被选为协作中继节点, 此时协作中继节点竞选成功; 否则说明其未被选为协作中继节点, 同时放弃竞争。若目的节点同时接收到多个GI帧, 产生碰撞, 则执行步骤3。
步骤3 此时目的节点以伪广播方式发送标志位为0的确认帧FB0, 收到该确认帧且在步骤2中由于不在彼此通信范围内仍在退避的其他节点则停止退避, 放弃竞争; 而收到该确认帧且发送了GI帧的所有候选协作中继节点则开始进入下一个Second退避阶段。此时所有发送了GI帧的候选协作中继节点根据式(6) 计算出其索引值m(m∈[0, M-1]), 然后根据式(7) 计算出第二次退避时间:
$ m = \left\lfloor {\frac{{GM({U_{\max }}-{U_i})}}{{{U_{\max }}-{U_{\min }}}}-gM} \right\rfloor $ | (6) |
$ {T_2}(g, m) = m \times {t_{fb}} $ | (7) |
步骤4 发送了GI帧且最先退避至0的候选协作中继节点广播发送(Member Indicator, MI)抑制帧, 其他接收到该抑制帧的候选节点则放弃竞争。而目的节点接收端也存在两种情况:若目的节点仅仅接收了一个MI抑制帧, 则目的节点以伪广播方式发送确认帧其标志位是1的FB1, 通告协作中继节点, 此时协作中继节点竞选成功, 而其他候选节点则放弃竞争; 若此时目的节点仍同时接收了多个MI抑制帧, 则执行步骤5。
步骤5 此时说明节点的效用值非常接近, 且候选协作节点相对较少, 只需从中任选一个作为协作中继节点即可。目的节点以伪广播方式发送标志位为0的确认帧FB1, 收到该确认帧且在步骤4中仍在退避的其他节点则停止退避, 放弃竞争。而收到该确认帧且发送了MI帧的所有候选协作中继节点, 根据式(8) 计算一个退避时间T3(k), 然后发送控制帧R, 目的节点接收到控制消息R后, 单播回复标志位为1的FB2确认消息, 此时协作中继节点竞选成功; 反之,若目的节点处产生R帧碰撞, 则以概率P坚持的方式进行竞争, 直至成功竞选协作中继节点为止。
$ {T_3}(k) = k \times {t_{fb}} $ | (8) |
其中k是随机产生的数。
通过以上步骤, 可成功选出协作中继节点, 此时则由协作中继节点将数据包编码发送。其具体的数据帧交换如图 2所示。
为确定HECNC-MAC协议的正确性和有效性, 本文对其作了详细的理论分析, 具体如下。
引理1 HECNC-MAC协议中选出协作中继节点的时间开销低于NCAC-MAC协议中选出协作中继节点的时间开销。
证明 本文选择协作中继节点时考虑目的节点接收的损坏数据包SINR(Signal to Interference plus Noise Ratio)大于阈值时协作编码重传的情况。为方便分析, 先作出如下假设:数据帧在节点的处理时延不作考虑, 且数据帧GI、MI、FB在信道上传输的时间都是tframe, 且假设First退避所需要的时间都是为tG, Second退避所需要的时间都是tM, 随机退避所需要的时间都是tR, 帧间最小时隙是tf。
在HECNC-MAC机制中, 根据图 2中数据帧交换传输过程, 可得节点从接收NACK消息开始到成功竞选为协作中继所需要的时间开销为:
若第一次First退避就竞选成功, 则其所需要的时间为:
$ {t_1} = {t_G} + {t_{frame}} + {t_f} + {t_{_{frame}}} $ | (9) |
若第二次Second退避中才竞选成功, 则其所需要的时间为:
$ {t_2} = {t_1} + {t_M} + {t_{frame}} + {t_f} + {t_{frame}} $ | (10) |
若第三次随机退避中才竞选成功, 则其所需要的时间为:
$ {t_3} = {t_2} + {t_R} + {t_{frame}} + {t_f} + {t_{frame}} $ | (11) |
综上所诉, 候选协作中继节点确认自己为协作中继节点的平均时间开销为:
$ t = \frac{1}{3}{\rm{ }}({t_1} + {t_2} + {t_3}) = {t_G} + \frac{2}{3}{t_M} + \frac{1}{3}{t_R} + 2{t_f} + 4{t_{frame}} $ | (12) |
而原协议NCAC-MAC中候选协作中继成功竞选为协作中继节点所需要的时间为:
若在Second退避后就竞选成功, 则需要时间为:
$ {t_1}^{\prime} = {t_G} + {t_{frame}} + {t_M} + {t_{frame}} + {t_f} + {t_{frame}} + {t_f} + {t_{frame}} $ | (13) |
若在随机退避才竞选成功, 则需要时间为:
$ \begin{array}{l} {t_1}^{\prime} = {\rm{ }}{t_G} + {t_{frame}} + {t_M} + {t_{frame}} + {t_f} + {t_{frame}} + {t_R} + {t_{frame}} + \\ \;\;\;\;\;\;\;{t_f} + {t_{frame}} + {t_f} + {t_{frame}} \end{array} $ | (14) |
综上, 候选协作中继节点确认自己为协作中继节点的平均时间开销为:
$ t^{\prime} = \frac{1}{2}(t{^{\prime} _1} + t{^{\prime} _2}) = {t_G} + {t_M} + \frac{1}{2}{t_R} + \frac{5}{2}{t_f} + 5{t_{frame}} $ | (15) |
从式(12) 和(15) 可以得出, 改进协议中无需发送ETH的控制时间开销, 且NCAC-MAC协议中未考虑存在候选协作中节点不在彼此通信范围内导致竞选失败,进一步增大时延开销的情况,因此可得前者时间开销t明显小于后者时间开销t′。 证毕。
引理2 HECNC-MAC协议中网络平均吞吐量高于NCAC-MAC协议中网络平均吞吐量。
证明 假设网络中有N个源节点且发送的数据帧的大小都为M, 定义网络中的平均吞吐量可以看成在直传失败的情况下目的节点接收总的数据帧与节点之间平均端到端时延之比。而在协作中继节点经过网络编码操作后, 目的节点收到的数据帧大小为2M。故网络的平均吞吐量S如式(16) 所示:
$ S = \sum\limits_{i = 1}^N {\frac{{2M}}{T}} $ | (16) |
其中:T表示候选协作中继节点从开始参与竞争到成功竞选为协作中继节点的时间t或t′与协作中继节点将编码数据帧发送给目的节点所需要传输时延的时间之和。由引理1可得, 改进方案中竞选时延t小于原方案所需时延t′, 两方案中数据的传输时延相等, 因此可得改进方案中所需总的时间开销T相对更小, 所以可以得出优化方案的吞吐量高于原算法的吞吐量。 证毕。
4 仿真实验及结果分析使用OPNET 14.5软件对网络建模并搭建仿真平台, 在相同的仿真场景下、相同的时间内分别对网络平均端到端时延、网络平均吞吐量和节点的能耗等方面对提出的HECNC-MAC协议与CSMA、Phoenix和NCAC-MAC协议进行性能对比和分析。
4.1 仿真环境及参数设置在300 m×300 m的正方形区域构建由35个节点组成的单跳无线网络场景, 其网络节点移动性较小即处于相对静止, 且节点以泊松分布发送数据帧。仿真实验中使用的主要参数如表 1所示。
1) 端到端平均时延。
如图 3所示, 端到端平均时延随着每秒发送数据包的增加而增加, 最后趋于稳定。但是, HECNC-MAC协议的端到端平均时延明显低于CSMA、Phoenix和NCAC-MAC协议的平均时延。主要原因在于CSMA协议在选择协作中继节点时, 由于随机接入导致的碰撞; Phoenix协议选择协作中继节点存在碰撞的概率相对较大, 且其通过CTS/RTS握手机制判断协作中继节点是否能进行编码操作, 带来了一定的时间开销; 而NCAC-MAC协议中, 由于存在候选节点不在彼此通信范围内导致的竞选失败而重新竞争的问题, 且即使竞选成功, 协作中继节点需要广播ETH控制消息, 需要额外的时间开销; 而HECNC-MAC协议中取消了ETH控制消息, 减少了参与竞选的候选节点, 且使目的节点以伪广播的方式避免了不在彼此通信范围内导致的竞选失败的问题, 从而减少了时间开销。
2) 网络平均吞吐量。
图 4为网络的平均吞吐量随负载的变化的曲线。从图 4可以发现, 随着负载的增加, 网络的平均吞吐量随着增加, 最后趋于稳定; 且HECNC-MAC协议的网络平均吞吐量明显高于CSMA、Phoenix和NCAC-MAC协议的平均吞吐量。主要原因在于CSMA协议中在选择协作中继节点时, 未使用网络编码技术; 而Phoenix协议中使用CTS/RTS握手机制导致了额外的时间开销; NCAC-MAC协议中在选择协作中继节点时考虑了吞吐量以及缓存区队列长度的影响, 且解决了是否编码的问题, 故其吞吐量相对前两者较高; 而HECNC-MAC协议在选择协作中继节点时, 先利用缓存概率的值进行解码预判, 不仅保证了目的节点能成功解码, 而且提高了成功竞选协作中继节点的效率, 同时无需发送冗余信令ETH, 从而大大的提升了网络的吞吐量。
3) 网络平均传输能耗。
图 5为网络中单位比特能量消耗随发包速率的变化的曲线。由图 5可知, 当节点发包速率不断增加, 其能耗也不断增加, 最后趋于稳定。而CSMA协议中存在拐点的主要原因是由于竞争过程中不公平所导致, 其他三种协议存在拐点主要是因为有大量数据帧的编码重传。另外, 从图 5可以发现, HECNC-MAC协议的网络平均能耗明显低于CSMA、Phoenix和NCAC-MAC协议的能耗。其主要原因在于HECNC-MAC协议在计算效用值时综合考虑了节点传输数据所需的能耗, 使得在协作中继节点协作编码传输时, 优先考虑传输能耗较小的候选协作中继节点, 从而相对另外三种机制减少了数据单位比特流所需要的能耗。
本文针对NCAC-MAC协议中的组间竞争机制不能有效避免由于候选协作中继节点不在彼此通信范围内导致数据帧产生碰撞和选择最佳协作中继节点时未考虑节点传输所需能耗以及参与竞选协作中继节点的候选节点过多导致数据传输效率较低等问题, 提出了一种基于协作网络编码的高效MAC协议(HECNC-MAC)。该协议在中继选择的过程中将节点传输能耗、预估吞吐量、节点缓存占用率等多种度量有效地结合, 选出了编码协作重传的最佳协作中继节点。理论分析和实验仿真结果表明, 与CSMA、Phoenix和NCAC-MAC协议相比, HECNC-MAC协议能够有效地增大网络吞吐量、减小时延并最大化地降低网络传输平均能耗, 但是该协议只是针对单跳网络进行了分析与验证, 未来将考虑在多跳网络中进行进一步的研究。
[1] | LANEMAN J N, TSE D N C, WORNELL G W. Cooperative diversity in wireless networks: efficient protocols and outage behavior[J]. IEEE Transactions on Information Theory, 2004, 50(12): 3062-3080. DOI:10.1109/TIT.2004.838089 |
[2] | NOSRATINIA A, HUNTER T E, HEDAYAT A. Cooperative communication in wireless networks[J]. IEEE Communications Magazine, 2004, 42(10): 74-80. DOI:10.1109/MCOM.2004.1341264 |
[3] | AHLSWEDE R, CAI N, LI S Y R, et al. Network information flow[J]. IEEE Transaction on Information Theory, 2000, 46(4): 1204-1216. DOI:10.1109/18.850663 |
[4] | ZHANG J, ZHANG Q, JIA W. VC-MAC: a cooperative MAC protocol in vehicular networks[J]. IEEE Transactions on Vehicular Technology, 2009, 58(3): 1561-1571. DOI:10.1109/TVT.2008.929219 |
[5] | ARGYRIOU A. MAC protocol for wireless cooperative physical layer network coding[C]//Proceedings of the 2012 IEEE Wireless Communications and Networking Conference. Piscataway, NJ: IEEE, 2012: 1596-1601. http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=6214037 |
[6] | YANG D, FANG X, XUE G. HERA: an optimal relay assignment scheme for cooperative networks[J]. IEEE Journal on Selected Areas in Communications, 2012, 30(2): 245-253. DOI:10.1109/JSAC.2012.120202 |
[7] | SHARMA S, SHI Y, LIU J, et al. Network coding in cooperative communications: friend or foe?[J]. IEEE Transactions on Mobile Computing, 2012, 11(7): 1073-1085. DOI:10.1109/TMC.2011.130 |
[8] | MUNARI A, ROSSETTO F, ZORZI M. On the viability of a cooperative network coding protocol in clustered networks[C]//MILCOM 2008: Proceedings of the 2008 IEEE Military Communications Conference. Piscataway, NJ: IEEE, 2008: 1-8. http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=4753086 |
[9] | MUNARI A, ROSSETTO F, ZORZI M. Phoenix: making cooperation more efficient through network coding in wireless network[J]. IEEE Transactions on Wireless Communications, 2009, 8(10): 5248-5258. DOI:10.1109/TWC.2009.081478 |
[10] | 李楠, 戚进勇, 蔡跃明, 等. 无线Ad Hoc网络中一种基于网络编码的协同MAC协议[J]. 电子与信息学报, 2011, 33(12): 2971-2977. (LI N, QI J Y, CAI Y M, et al. A cooperative MAC with network coding for Ad Hoc networks[J]. Journal of Electronics & Information Technology, 2011, 33(12): 2971-2977.) |
[11] | WANG X, LI J, GUIZANI M. NCAC-MAC: network coding aware cooperative medium access control for wireless networks[C]//Proceedings of the 2012 IEEE Wireless Communications and Networking Conference. Piscataway, NJ: IEEE, 2012: 1636-1641. http://ieeexplore.ieee.org/xpls/icp.jsp?arnumber=6214044 |
[12] | WANG X, LI J, TANG F L. Network coding aware cooperative MAC protocol for Ad Hoc wireless networks[J]. IEEE Transaction on Parallel and Distributed System, 2014, 25(1): 167-179. DOI:10.1109/TPDS.2013.22 |
[13] | SAMI M, NOORDIN N K, HASHIM F, et al. An energy-aware cross-layer cooperative MAC protocol for wireless Ad Hoc networks[J]. Journal of Network & Computer Applications, 2015, 58: 227-240. |
[14] | FASOLO E, ROSSETTO F, ZORZI M. Network coding meets MIMO[C]//NetCod 2008: Proceedings of the Fourth Workshop on Network Coding, Theory and Applications. Piscataway, NJ: IEEE, 2008:1-6. |
[15] | 周亚星. 基于网络编码的协作中继节点选择策略研究[D]. 湖南: 中南大学, 2014: 47-49. (ZHOU Y X, Research of relay selection based on network coding [D]. Hunan: Central South University, 2014: 47-49.) http://cdmd.cnki.com.cn/Article/CDMD-10533-1014408262.htm |