通过BMW改进减少无线局域网协议MMW的纠错延时问题

所谓无线网络，既包括允许用户建立远距离无线连接的全球语音和数据网络，也包括为近距离无线连接进行优化的红外线技术及射频技术，与有线网络的用途十分类似，最大的不同在于传输媒介的不同，利用无线电技术取代网线，可以和有线网络互为备份。

随着无线网络技术的快速发展和广泛应用，无线移动用户已经不能仅仅满足于简单的数据通信。视频通信，特别是有严格时延、错误率限制的实时多播业务需求正在迅猛增加。大量的实时多播应用充斥于无线网络中，包括：数字视频广播、视频会议、游戏、VoIP、IPTV等。

然而，IEEE802.11对多播数据的MAC层传输不提供纠错，多播数据无法得到可靠性保证。如何在高丢包率的无线网络中完成快速、准确的多播数据传输，这是无线网络下的多播纠错协议所要解决的首要问题。

现有的无线多播纠错协议大多是基于应用层，虽然在可靠性上都较好地达成了期望，但是由于应用层处于物理层、数据链路层、网络层等层次之上，在系统中位置较高，基于应用层的协议往往延时较大，有时候不能满足严格的应用程序延时限制。目前对无线MAC层多播纠错协议的研究主要有BMW（Broadcast Medium Window），BMMM （Batch Mode Multicast MAC）和BLBP（Beacon-driven Leader Based Protocol）等几种方法。BMMM传输一个数据帧要发送大量的控制帧而增加了传输时间。BLBP在可靠性上存在问题。BMW虽然可以确保进行可靠的多播，但是数据帧的纠错时间较长。因此本文在BMW的基础上，提出了BMW的改进协议MMW（Multicast Medium Window），既保持了BMW的可靠性，又克服了BMW延时较大的特点。

1 BMW协议

BMW协议提出了一种可靠的MAC层多播机制，其主要思想是轮流对各个邻居节点进行单播来达到多播的效果。

BMW要求每个节点保存3个列表：成员列表、发送列表和接收列表。成员列表用来记录所有邻居节点的MAC地址；发送列表用来保存已经发送但还没有被所有邻居节点确认收到的多播数据帧，列表大小应不小于邻居节点数量；接收列表用来记录已经收到多播数据帧的序列号。

BMW在RTS帧中新加入LS和RS两个域，分别用来标记发送列表数据帧中的最小序列号和当前序列号。CTS新加入SC域用来标记需要的数据帧序列号。扩展的RTS、CTS报文结构如图1所示。

当一个节点需要发送一个多播帧时，首先将该帧保存到发送列表中，然后在成功执行CSMA/CA后发送RTS。RTS帧包含当前发送列表中数据帧的最小序列号和当前序列号，并选择邻居列表中第一个邻居节点的MAC地址作为目的地址。该邻居成功接收到RTS后，根据最小序列号、当前序列号和接收列表检查是否有丢失数据帧。如果有则将丢失帧的序列号写入CTS并回复，否则回复带有当前序列号的CTS。发送节点收到CTS，从发送列表中找到对应的数据帧进行发送，目的节点成功收到该数据帧后回复ACK，并把数据帧的序列号记录到接收列表中。其他邻居在接收到该数据帧后也将对序列号记录到自己的接收列表中。如果发送节点发送的数据不是当前数据帧，则重复上述与该邻居节点对话过程直到发送当前数据帧并收到ACK确认。如能成功发送当前数据帧且该邻居节点已经确认收到发送列表中的所有帧，则删除发送列表中已被所有邻居确认的数据帧；然后发送节点将选择邻居列表中的下一个邻居重复上述方法发送下一个多播帧。如果没有新的多播帧需要发送，则选择邻居列表中下一个邻居使用上述方法发送当前的多播帧。当发送列表中没有数据帧时停止BMW循环过程，直到有新的多播帧需要发送时，重启BMW。

可以看出，BMW发送多播数据时，轮流对邻居节点进行单播，并在单播的时候对该邻居节点之前丢失的数据帧进行重传。每个多播帧都能确保被所有节点接收，但是每个节点只有被选择作为目的节点时才能对之前丢失的数据帧就行重传。当接收节点数目较多时，加大了数据传输的延时。

2 BMW的改进协议MMW

英文全称：Multi Media World，中文全称：多媒体世界。多媒体世界其实从字面上可以基本明白它的意思，就是由多种媒体组成，包容了报刊、画册、广播、电影等，并具有自身特有的功能——交互性，只要是能用来传播信息，任何媒体资源都可以把它加入系统中，所以多媒体是汇集了文字、图形、动画、视频、声音、特殊效果的系统。它的重要性不亚于早期的造纸及印刷术，是现代传媒的一场革命，改变了我们学习和理解问题的方式和传播信息的方式。

多媒体设备应从两个层面来谈：一是对普通用户，即多媒体产品的使用者——就象报刊的读者、电视的观众一样，只需要一台多媒体PC电脑，就可感受多媒体的无穷魅力。另一层面则是针对多媒体的设计人员，作为多媒体产品的制作者，除了要有性能较好的多媒体电脑外，还需配置一些输入设备，象扫瞄仪、收录机、麦克风、MIDI、录像机、视频压缩卡等，这样就能处理各种多媒体资料，另外在制作完成后还需要刻录机这类的输出设备。当然，制作多媒体并不是非得将每种设备都配齐，特别是对初学多媒体制作的朋友，有一台性能不错的多媒体PC电脑就行了。

MMW是在BMW的基础上进行改进的，既保持了多播数据可靠传输的特点，又可以使丢失的报文即时得到重传，减小了报文传输的延时。

2.1 改进成员列表

由于BMW对广播数据和多播数据不做区分，将所有各个多播组的多播数据和广播数据共同计算序列号，轮流对各个邻居节点进行单播并进行纠错。实际上把一个多播数据发送给非多播接收节点的邻居节点并进行纠错是没有必要的，而且增加了纠错时间。

MMW中规定每个节点为每一个多播组分别保存成员列表、发送列表和接收列表：成员列表用来记录该多播组所有多播接收节点的MAC地址，该列表在创建多播路由时获得；发送列表用来保存已经发送但还没有被所有多播接收节点确认收到的多播数据帧，列表大小应不小于多播接收节点的数量；接收列表用来记录已经收到多播数据帧的序列号。由于MMW对不同的多播组分开计算序列号，所以需要对RTS帧继续进行改进，具体报文结构如图2所示，加入MA域来记录多播MAC地址。该RTS帧用来表明将要发送的数据属于哪个多播组的以及源节点的该多播组发送列表中的最小序列号和当前序列号。广播被看作一个特殊的多播组，成员列表为邻居列表，RTS中的MA域填入广播MAC地址。

通过对成员列表的改进，每个多播报文只需要对各自多播组的接收节点进行纠错，而不需要对所有邻居节点纠错，减少了纠错延时。

2.2 引入重传请求帧

BMW中假设1个节点有n个邻居节点，当它向第一个邻居发送第一个多播数据时，邻居列表中第n个邻居由于冲突等原因没有成功接收到这个数据，则第n个邻居此时已经发现自己出现丢失了数据包，但必须在等待传输了n-1个数据后，当发送节点选择第n个邻居单播多播数据帧时，才会重传这个数据。可以看出，BMW不能及时进行纠错，加大了丢失帧的纠错延时。

MMW引入了重传请求帧，其报文格式如图３所示，RA域、TA域与RTS帧相同，MA域为多播组MAC地址，SC域为丢失帧的序列号。在每次数据传输完成后，接收节点都会根据最大序列号、当前序列号以及自己的接收列表来检查是否有丢失帧。如果有，则在执行完CSMA/CA后发送重传请求帧通知源节点。源节点接收到重传请求帧后，立刻与该节点进行RTS/CTS交换，完成交换后发送丢失帧。在传输丢失帧时，其他丢失该数据帧的接收节点也接收此帧并更新各自的接收列表。同时可能有不止1个节点发现丢失多播数据帧，都要发送重传请求帧，其他节点也有可能要发送RTS帧。因此，在发送重传请求帧前使用了CSMA/CA避免冲突，一个节点在竞争到信道使用权后，才能发送重传请求帧通知源节点对丢失帧进行重传。

重传请求帧的引入是为了让接收节点在发现自己存在丢失数据帧后，可以主动地请求源节点立即进行重传，而不必等到被选择作为目的节点时才会对丢失的包进行纠错，减少了数据帧的传输延时。

3 仿真实验

通过仿真实验对MAC层纠错协议BMW、BMMM、BLBP和MMW进行比较。发送10 000个大小为1 500 B的多播数据帧，比较不同数量接收节点情况下各个协议所需要的时间以及在一定延时限制内的数据丢包情况。物理层部分参数如表1所示，参数使用801.11a标准。所有的接收节点与发送节点只有一跳的距离。

图4是网络丢包率为0.1时，不同数量的接收节点环境下发送10 000个数据帧所用的总传输时间。每种协议所需要的传输时间都随着接收节点的数量增加而加大，这是由于接收节点数量的增大，造成更多的重传。其中BMMM增加的速度要快于其他协议，因为BMMM每发送1个数据包都要进行更多的控制帧交换，控制帧的数量随着接收节点的增加而增大，因此当接收节点数量加大时，BMMM所用的传输时间要高于其他3种协议。

图5是接收节点为10个时，不同网络丢包率环境下发送10 000个数据帧所用的总时间。由图可以看出，每种协议所需要的传输时间都随着丢包率增加而加大，这也是因为网络丢包率的增加也造成了更多的重传。而且四种协议传输时间增大的速度基本相同，但是由于接收节点为10个时BMMM需要进行大量的控制帧交换，所以BMMM的传输时间要高于其他三种协议。

图6是接收节点数量为10个时，不同网络丢包率环境下发送数据帧的最大延迟时间。可以看出，BMMM、MMW、BLBP最大延迟时间都在10 ms以下，而BMW由于不能即时丢失的数据帧进行重传，增大了数据帧传输的延时。

图7是10个接收节点、网络丢包率为0.1的情况下，每种协议在不同延时限制下的丢失数据帧的数量。BLBP在beach帧的丢失后，非领导节点即使丢失数据帧后也不会回复NACK（Negative Acknowledgements）帧，并且存在隐藏节点问题，造成协议的不可靠，出现丢包。BMMM、BLBP对一个多播数据帧进行纠错结束后才发送下一帧，及时对丢失数据进行重传，因此所有数据帧的延时都小于10 ms。而BMW只有在节点被选择作为目的节点时才能对之前丢失的数据包进行纠错，加大了数据帧延时，在延时限制10 ms时存在约为1.2%的丢包率。MMW加入了重传请求帧，使得丢失数据包可以及时进行纠错，所有数据帧的传输延时保持在10 ms以下。

综上所述，可以发现BMMM在接收节点变大时需要传输大量的控制帧而加大了传输时间；BMW由于不能即时对丢失的数据帧进行重传，增大了数据帧纠错延时；而BLBP的可靠性存在问题。MMW却解决了以上问题，为上层的多播服务提供了更可靠的实时性保障。

本文在BMW的基础上进行改进，提出了无线局域网纠错协议MMW。MMW通过对BMW成员列表的改进和引入了重传请求帧，减少了BMW协议中的纠错延时，保证了无线多播数据在MAC层快速、可靠传输。通过仿真实验表明，在网络丢包率为0.1、存在10个多播接收节点、延时限制为10 ms的情况下，MMW仍能保证所有的数据报正确传输，为上层多播服务提供了很好的保证。