分布式协作通信网络中的CoopMAC层协议研究

等人首先提出了一种CoopMAC协议[5-7],该协议使高速节点帮助低速节点完成传输，这不仅大大提高了网络的吞吐量，减小了节点的接入时延，同时还降低了各个节点的总能量消耗。在CoopMAC协议中每个节点将维护一张协同表，其中包括源节点到中继节点的速率，中继节点到目的节点速率，该表项更新的时间等，当有数据要传输时首先查找该协同表来判断是否有可以利用的协同节点从而决定是否使用协同传输。

当需要协作时，源节点S首先发送请求协作发送帧（CoopRTS）；Helper节点H在正确收到CoopRTS后，判断是否能够支持源节点所期望的传输速率，如果可以即发送协作节点确认发送帧（HTS）；最后目的节点D回复确认发送帧（CTS），从而静默了周围其他的邻节点，成功预约到信道的使用权，完成了协作握手过程。此后，源节点以高速将数据发送给Helper节点，并由它高速地转发给目的节点。而当源节点和目的节点不需要协作传输以及不存在协作节点时，则使用传统的802.11b协议。CoopMAC协议的握手过程如图1所示。

在全连通的网络中，协作传输所需要的3次握手机制和传统的RTS/CTS握手机制并没有太大区别，仅仅是增加了握手复杂度和握手时间。然而，在分布式多跳网络中，3次握手机制则更容易受到隐藏终端的影响。

从图2中我们可以看到：当源节点发送CoopRTS时，节点{B,C,E,F,G,M,I}均为隐藏终端，其中任何节点发送信息均会影响到CoopRTS的正确接收，而当Helper节点发送HTS时，节点{B,E,F,G}仍然为隐藏终端。

因此，以节点B为例，其在较长的时间内均可以干扰到当前握手信息的传输。由此我们可以看出隐藏终端问题严重影响到CoopMAC协议在多跳分布式网络中的性能，应该引起协议设计人员的广泛关注。

2、“按需”协同MAC协议

有些研究者认为在CoopMAC协议中每个节点都要维护到各个邻节点的协同表，不仅增大了存储的开销，而且由于节点的移动性以及信道的时变性，使得协同表的更新无法跟上网络状态的变化，因此他们提出了在“按需”的协同MAC协议，协议中节点并不维护任何协同节点的信息，当有数据要发送时，通过源节点首先发送RTS信息，目的节点收到后回复CTS信息，那么潜在的协作节点通过这两个握手信息即可以获得源节点到本节点以及目的到本节点的信道信息：H SR和H RD.协作节点通过设置退避时间T 来竞争参与协作，T 是H SR和H RD反比例函数，当退避计时器减为零时，协作节点发送同意中继帧(RTR)，如图3。但是该协议在预约协作节点的过程中可能会发生碰撞从而导致整个握手过程失败，如图4。

3、能够联合解信号的协同MAC协议
在最早提出的CoopMAC协议中仅仅利用了802.11中的多速率传输特性，而当目的节点能够联合解分别来自源节点和目的节点的信号时，才形成了真正意义上的虚拟MIMO系统。由于信号来源于不同的时间和节点，因此系统可以获得空间分集和时间分集。

F.Liu等提出了相应的增强型CoopMAC协议，其握手过程以及信息传输过程和CoopMAC协议基本一致，如图5所示。

目的节点将收到的两个信息备份联合处理从而获得增益。

分布式多跳网络中，其仿真性能相对于原始CoopMAC协议能够获得10%左右的吞吐量增益。然而这也给硬件设备提出了更高的要求。

4、支持方向性天线的协同MAC协议

在协同通信过程中，由于协同节点的引入，从网络角度看整个网络的复用度会有所下降，如何弥补这一损失是协同MAC协议设计的一个重要问题，也是当前研究的热点。

在节点配备有方向性天线的条件下，提出了一种D-CoopMAC协议。如图6所示，

源节点有数据要传输时首先全向广播RTS信息，协同节点收到后将发射天线方向对准目的节点发送HTS信息，目的节点成功收到RTS和HTS后向源节点方向回复CTS信息，此后的数据发送过程中均使用方向性传输。该方法一定程度上减少了由于协同带来的网络空间复用度下降的问题，当然解决问题的同时也增加了设备的复杂度和成本。

图7给出了D-CoopMAC协议的吞吐量性能，值得注意的是随着方向性天线的波束增加，D-CoopMAC的性能反而不如直接使用方向性天线传输的性能，这由于是协同网络需要利用一个空间复用度来完成协作，另外控制分组开销也造成了网络性能的损失。由此可以看出在实际网络中协作的使用必须具有选择性，否则会适得其反。

通过分析上述几种典型的协作MAC协议，我们可以看出：针对不同的网络环境以及不同配置，我们需要选择不同的设计准则和方法，只有这样才能使协作通信理论上的增益落到实处，从而提高整个网络的性能。

五、总结

本文研究了分布式网络中MAC层协作的动机，