CN101521586A - 在无线局域网中的多播方法 - Google Patents

Abstract

一种在无线网络中的媒体接入控制(MAC)层中执行多播传输的方法，包括步骤：发送方根据多播组成员的信道条件将多播组成员分成小组，并指示每个小组的代表节点；向多播组成员多播包含指示是否有要发送到多播组的数据包的MRTS，并等待来自每个小组代表节点的MCTS；接收到来自每个小组的代表节点的MCTS后，向多播组成员多播数据包，并记录当前发送的数据包的序号；代表节点在接收到多播的数据包之后，在各自的MCTS的位映射字段中记录指示是否正确接收到此次发送的相应数据包的值，并在预定时间周期后向发送方发送MCTS。发送方从来自代表节点的MCTS的位映射字段中记录的值来判断是否出现数据包丢失，并在出现数据包丢失的情况下，在下次发送数据包时重发丢失的数据包。

Description

在无线局域网中的多播方法

技术领域

本发明涉及一种无线网络中的多播方法，特别是，涉及在无线局域网中可靠地执行多播传输的方法，该方法通过对接收成员进行分组，只由每个分组中的代表向发送方反馈信息，从而减小时延，提高多播协议的效率，并减少控制包的开销。

背景技术

在无线宽带接入技术中，IEEE 802.11已经正成为一种非常普遍的选择。目前，在无线局域网(WLAN)上的很多重要应用都是基于多播传输的。这些应用包括，但不限于多媒体会议，共享白板，远程教育，多方游戏和分布式计算等等。

多播(也称为组播)，是指将数据包从一个源端传送到多个目的端，将信息的拷贝发送到一组地址，到达所有想要接收它的接收者。与单播相比，组播的效率非常高。这是因为任何给定的链路至多用一次，因而可以节省网络的带宽和资源。由于多播传输在资源利用率上的优势，目前，它受到了相当多的关注。

在无线宽带接入上，无线局域网(WLAN)已经正成为一种非常流行的选择。不论是在家庭还是在公司，WLAN都得到广泛的应用。从这点考虑，因特网上多播包的最后一跳很可能就是无线局域网。

然而，在目前的因特网的多播设计中，通常都在骨干网上研究，集中在组播路由设计和组成员管理上。在WLAN当中，并不支持MAC层的多播传输。当接入点(AP)发现需要发送多播包时，就只把它当作广播包处理。在媒体接入控制(MAC)层，通常不考虑是否是多播包。因此，在MAC层中不提供多播设计，而只把数据包当作广播包处理。这样情况下，当IP层的多播包在WLAN上传输时，会出现如下问题。一方面，增加额外的IP处理开销。这是因为目前的MAC层不支持多播包，因此WLAN中的节点(station)在MAC层并不区分收到的是多播包还是广播包，也不能将不支持的多播包屏蔽掉，而是将该包一律转发到IP层之后，才由接收端根据多播地址来判断是否接收此包。这样必然会增加IP层不必要的处理开销。另一方面，多播包在WLAN中传输时，没有RTS(请求发送分组)/CTS(清除发送分组)握手交互机制来预留信道，也没有重传机制来纠正差错，因此导致传输的可靠性较低。这样，就会导致多播包因链路错误或者冲突而丢失。

为了支持MAC层的多播传输，需要解决以下三个问题：

1.如何避免信息冲突。为了支持重传，需要组成员(group receivers)发送反馈信息给发送节点(通常是接入点(AP))来通知信息包是否被正确接收。如果多个节点同时发送反馈信息，则很容易在AP处产生冲突。

2.如何降低大的控制包开销。为了支持可靠传输，多播协议可能需要用到RTS(请求发送分组)，CTS(清除发送分组)，ACK(肯定确认)等控制包。虽然在单播情况下控制包的开销并不太高，可是在多播情况下，如果组成员都发送RTS，CTS和ACK，那么控制包的开销会非常大。

3.如何调整发送速率。WLAN中的单播传输支持发送方的自适应速率调整。当信道条件好的时候，发送方会增加发送速率；反之，则降低发送速率。在多播传输中，因为有多个接收节点，他们的信道条件变化可能完全不同，在进行自适应速率调整时，需要综合考虑AP和多个接收节点之间的信道条件。

另外，WLAN中存在着多种终端，例如，便携式计算机，移动电话，个人数字助理(PDA)。这些终端之间存在异构性。此外，不同终端针对不同的应用而对QoS(业务质量)有不同的要求。因此，目前在IP层的多播包直接在WLAN中传输会遇到上述问题。由于这些问题，设计MAC层的可靠多播协议是非常必要的。

现有技术中已经提出了多种方法来实现可靠的多播传输。例如，J.Kuri和S.K.Kasera发表的题为“Reliable multicast in Multi-Access WirelessLANs”的文章(参见ACM/Kluwer Wireless Networks Journal，vol.7，no.4，pp.359-369，August 2001)；S.K.S.Gupta，V.Shankar发表的题为“Reliablemulticast MAC Protocol for Wireless LANs”的文章(参见ICC 2003，pp93-pp97，2003)；K.Tang和M.Gerla发表的题为“MAC Reliable Broadcastin AdHoc Networks”的文章(参见Proc.IEEE MILCOM 2001，pp.1008-1013，Oct.2001)；M.T.Sum，L.Huang发表的题为“Reliable MAC layer multicast inIEEE 802.11 wireless networks”的文章(参见Proc.of ICPP，pp.527-536，Aug.2002)；以及Hrishikesh Gossain，Nagesh Nandiraju发表的题为“SupportingMAC layer Multicast in IEEE 802.11Based MANETs：Issues and Solutions”的文章(参见LCN’04，2004)。

上述现有技术中提出的方法可以分为两类：第一类是基于否定反馈的(NCTS/NACK)机制，另一类是基于肯定反馈的(CTS/ACK)机制。通常，基于否定反馈的多播协议的效率更高，但其可靠性较差。通常采用的方法包括基于负反馈的多播协议，例如：LBP(基于代表的协议)，DBP(基于随机时延的协议)和PBP(基于概率的协议)，以及基于正反馈的多播协议，例如：BMW(广播媒体窗协议和BMMM)，和批处理多播协议。

LBP(基于代表的协议：leader based protocol)在IEEE 802.11的基础上，扩展了RTS/CTS的握手机制和响应ACK的纠错机制，从而能够可靠地支持多播传输。在这种方法中，需要事先从一组接收者中指定一个代表(leader)。源端(发送方)在发送多播数据包之前，首先发送一个多播RTS包(MRTS)给所有的组员。对于接收组中的代表，如果它已准备好接收数据，就响应MCTS(多播清除发送分组)，反之，则不做出响应。对于接收组中的其他组员，如果没有准备好接收数据，就响应NCTS(negaive CTS)，反之，则不做出响应。在这个握手过程中，如果接收组中的代表已准备好接收并响应了CTS包，而某一组员没有准备好，而响应了NCTS包，那么，这个NCTS包就会和接收组中的代表发送的CTS包冲突。而源端一旦监听到CTS包，就认为已经成功获取了信道，并开始发送多播数据。收到数据包之后，对于接收组中的代表，如果数据包接收正确，则响应ACK，反之，则发送NACK；对于接收组中的其他组员，如果成功接收，则不响应，否则，响应NACK。

因此，在把LBP方法应用到IEEE802.11的情况下，存在着接收方难以判断应该如何反馈的问题。这个问题存在于所有基于负反馈的协议中。在IEEE 802.11中，如果发生冲突或者链路错误，接收方将不能正确接收包，当然也就不能提取包中携带的诸如包类型，包的源地址、目标地址等之类的包头信息。因此，当接收方不能正确接收数据包时，它很难决定是否需要给出负反馈，以及给出何种负反馈。例如，难以决定是反馈NACK还是反馈NCTS。为了要解决这个问题，需要再做额外的工作来修改IEEE802.11协议。

另外，在把LBP方法应用到IEEE 802.11的情况下，在源端发出多播数据之后，如果作为非接收组中的代表的组员接收到错误包之后，它将发送NACK分组，而与接收组中的代表发出的ACK分组碰撞。这个碰撞将导致源端无法听到接收组中的代表反馈回来的ACK分组，从而重传该数据包。因此，导致发送方进行不必要的重传。当数据包的传输在某个组员处发生错误时，该组员因为无法得到数据包的序列号，而不能判断这个数据包是否是重传的数据包。因此，该组员不管之前是否已经成功接收了该数据包，一律向源端反馈NACK分组。这样，就会导致源端进行不必要的重传。

此外，在把LBP方法应用到IEEE 802.11的情况下还会产生捕捉效应。所谓捕捉效应是指当一个节点同时收到两个包时，那个有较强接收功率的数据包能够被正确捕捉。假设在一种环境下，接收组中的代表离接入点(AP)非常近，另一个节点距离AP比较远。那么当AP响应CTS，而另一个节点响应NCTS时，本来这个NCTS是应该和CTS发生冲突的，但是由于捕捉效应，AP发送的CTS被源端正确接收了，而远离AP的节点发出的NCTS响应未被正确接收。这就导致源端错误地认为自己已经可以发送数据了。

DBP方法和LBP方法的不同之处在于：(1)它只用CTS来预约信道。(2)它用一个随机定时器来避免多个CTS的冲突。

下面描述DBP方法的工作过程。首先，源端启动一个超时定时器(周期为T)，然后发送MRTS(多播请求发送分组)来预约信道。可以假设定时器的周期为T。所有接受方的组员在监听到MRTS之后，就会启动一个定时器(定时周期可以从{1，2，…，L}中随机选择)。在定时器到时之前，如果节点A监听到其他节点发送的CTS分组，则取消自己的定时器，不发送CTS分组。如果节点A没有监听到CTS分组，那么当定时器到时，就发出CTS响应。源端等候T时间，如果收到CTS分组，就开始发送数据。接收方的组员们正确收到数据之后，不发出响应。如果发现接收的数据错误，则发出NACK分组做出响应。PBP方法与DBP方法非常相像，唯一的区别在于PBP方法利用概率来避免CTS的冲突。

与LBP方法相比，PBP和DBP方法需要花更多的时间来预留信道。另一方面，如果想要选择最优的PBP响应的概率和DBP的随机定时周期，需要知道这个多播组的大小，而在此阶段无法获得多播组的大小。因此为了获得最优的概率或随机定时周期之类的参数值，必须要获得而外的信息。这也是PBP和DBP方法所存在的缺陷。

另外，对于现有技术中提出的基于正反馈的方法，通常采用BMW(广播媒体窗协议)和BMMM(批处理多播协议)方法。这些基于正反馈的方法克服了上述负反馈方法中的缺陷，但产生了其它问题。例如，BMW方法只是简单的把一个多播过程看作是多个单播而已，因此它效率较低。为了提高效率，提出了BMMM方法。在BMMM方法中，为了协调接收方组员的ACK响应，引入了一个新的包类型(RAK：请求肯定确认)。RAK分组被设置在ACK分组之前，用于指示接收方的组员按顺序发出ACK响应。

图1示出了BMMM方法的基本工作过程。在BMMM方法中，如果有一个发送方与n个接收方进行多播通信，在前期经过n个RTS/CTS的交互之后，发送方开始发送数据分组(DATA)。发送完DATA之后，发送方向每个接收方轮询地发送RAK分组。接收方接收到RAK分组之后，向发送方发出ACK响应。虽然BMMM方法比BMW方法更可靠，但在传输过程中需要有n对RTS/CTS交互和n对RAK/ACK交互，使其控制包的开销(RTS、CTS、RAK和ACK)非常大。下面的表1给出了物理层控制包的开销和数据包的开销。

表1

 

RTS	CTS	DATA	ACK
				40个时隙	40个时隙	15个时隙	40个时隙

表1中比较了物理层控制包的开销和数据包的开销，其中假设需要传送512字节的数据包。从表1中我们可以看到，传输数据包占用了15个时隙，而(RTS、CTS、和ACK)占用了120个时隙，传输数据包的资源还不到整个资源的10％。

从前面的描述中可以发现，已经提出的多播方法虽然在一定程度上解决了反馈冲突和控制包开销的问题，但是仍然存在其它问题。例如，单从应用范围来说，这些多播传输方法都是基于IEEE 802.11a/b/g设计的，而不能很好地应用于IEEE 802.11n。从WLAN的发展来看，新兴的802.11n标准具有最高600Mbps的传输速率，被公认为是下一代的无线网络技术。为了提高WLAN的吞吐量，IEEE 802.11n引入了一些新的特征，例如，物理层的MIMO(多输入多输出)，MAC层的数据结合(data aggregation)(即网络接入点一次可以发送多个数据包)、多达576种的可选速率配置等等。前面提到的几种多播协议，并没有考虑这些新特征，因而，无法支持更高速的多播传输。

针对可靠多播方法要解决的上述第三个问题(如何调整多播发送速率)，现有技术中已经提出了一些自适应速率调整算法。与单播中的自适应速率调整相比，多播中的自适应速率调整需要解决两个特殊的问题：(1)如何根据多个组成员的反馈来获得信道条件。在单播情况下，通常是根据接收节点发送的CTS包的信号强度来判断信道条件。然而，在多播情况下，如果多个接收节点同时发送CTS包，则会发生冲突。(2)如何根据多种不同的信道条件来调整发送速率。

例如，在J.Villalo′n等人发表的题为“ARSM：a cross-layer autorate selection multicast mechanism for multi-rate wireless LANs”的文章中(参见IEEE Commun.，2007，下文中称之为对比文献1)提出了ARSM(自动速率选择多播)算法。该方法要求每个节点在发送CTS包之前，先回退一段时间。这个回退时间根据节点自己的信道条件来决定。如果信道条件好，那么相应节点回退时间就长一些，如果信道条件差，则相应节点回退时间短一些。这样，信道条件最差的节点会优先占用信道。AP一旦接收到第一个反馈的CTS，就会根据这个CTS的信号强度，来调整发送速率。

在Miao Zhao等人提出的题为“Contention-Based PrioritizedOpportunistic Medium Access Control in Wireless LANs”的文章(参见IEEE ICC，2006，下文中称之为对比文献2)中提出了一种CTS冲突检测法。该方法定义所有的接收节点同时发送CTS包，但是每个节点发送的CTS包的长度是不同的。如果信道条件好，所发送的CTS包的长度可以长一些，如果信道条件差，则CTS包的长度可以短一些。这样，在AP处，多个CTS包虽然会发生冲突，但是冲突之后，最长的CTS包依然还是会被AP检测出来。可以理解，基于该方法，AP可以检测出信道条件最好的节点发送的CTS包。此后，AP可以根据这个CTS的长度来调整发送速率。

另外，Anas Basalamah等人发表的题为“Rate Adaptive ReliableMulticast MAC Protocol for WLANs”的文章(参见IEEE VTC，2006，下文中称之为对比文献3)中提出了基于优先级的竞争方法。该方法引入了一种新的黑色冲突(Black Burst：BB)包。所有接收节点在发送CTS包之前，需要先发送BB包来抢占信道。如果信道条件好，BB包可以长一些；如果信道条件差，BB包可以短一些。接收节点发出BB包后，开始监听信道。因为BB是同时发送的，因此在BB包之间会产生冲突。但是冲突过后，AP会监听到最长的BB包。这样，信道条件最好的接收节点能够通过最长的BB包抢占到信道，从而成功地发送CTS包。AP接收到该CTS包之后，会根据其信号强度来调整发送速率。

对于上述三种方法，在ACM(自适应编码调制)的配置比较少的时能够很好的工作。例如，在Miao Zhao等人提出的方法中，规定CTS的长度变化有四种值，分别对应IEEE 802.11b的4种ACM配置。但是当标准中支持的ACM配置很多时，这种方法就无法工作。例如，在IEEE 802.11n中，最多可以支持576种速率配置，如果相应地把CTS的长度变化也定义为576种，很明显会带来非常大的资源浪费。与此类似，其他两种算法也存在这个问题。

鉴于上述问题，需要一种可靠的MAC层多播传输方法，使得该方法能够适用于ACM配置的情况，基于本专利申请的同一申请人于2007年11月19日提交的中国专利申请No.200710186021.7提出了本发明中的一些具体方案，在此引入该申请作为参考。

发明内容

本发明的一个目的是提供一种在无线网络的MAC层中执行多播传输的方法，该方法对接收组成员进行分组，只由每个小组的代表节点向发送方返回MCTS包，并把ACK信息搭载在MCTS包中，能够提高多播协议的效率，减少控制包的开销，避免多个MRTS的冲突，并且能够降低多个接收节点向发送节点返回MCTS的时延。

本发明还提供了一种对多播组成员进行分组的方法，使得在无线网络中执行的多播传输过程中，不需要每个多播成员都发送反馈信息，而只需要每个小组中有一个节点反馈信息，从而降低多个接收节点向发送节点返回CTS的时延。

根据本发明的一个方面，提供一种在无线网络中的媒体接入控制(MAC)层中执行多播传输的方法，包括步骤：发送方根据多播组成员的信道条件将多播组成员分成小组，并指示每个小组的代表节点；发送方向多播组成员多播包含指示是否有要发送到多播组的数据包的多播请求发送分组，并等待来自每个小组代表节点的多播清除发送分组；发送方在接收到来自每个小组的代表节点的多播清除发送分组后，向多播组成员多播至少一个数据包，并记录当前发送的数据包的序号；每个小组中的代表节点在接收到多播的至少一个数据包之后，在各自的多播清除发送分组的位映射字段中记录指示是否正确接收到此次发送的相应数据包的值，并在预定时间周期后向发送方发送多播清除发送分组，而不发送肯定确认(ACK)包；和发送方从来自每个代表节点的多播清除发送分组的位映射字段中记录的值来判断是否出现数据包丢失，并在出现数据包丢失的情况下，在下次发送数据包时将丢失的数据包与要发送的新数据包一起多播。

根据本发明，提供了一种可靠的MAC层多播传输方法。该方法采用了一种可扩展的隐式确认(EIA)方法。利用该方法，在MCTS包中，通过搭载确认信息的方式，去除了ACK包的发送。另外，由于去除了ACK包的发送，从而消除了ACK/NAK包丢失和碰撞的概率，另一方面，通过在MCTS中搭载指示最近成功接收到的数据包的序号，解决了其他协议中存在的不必要重传的问题。

此外，根据本发明，把多播组成员分成小组(sub-group)，由每个小组中的一个代表节点向发送方反馈信息，而不需要每个多播成员分别向发送方反馈信息。因此，本发明的方法可以降低多个接收节点向发送方返回MCTS的时延。

此外，本发明考虑到802.11n在MAC层的诸如数据包集合(dataaggregation)，即发送方一次向接收组成员发送多个数据包之类的新特性以及多种发送速率配置，提出了适应于多播传输的数据集合和自适应速率调整算法。

附图说明

通过下面结合附图说明本发明的优选实施例，将使本发明的上述及其它目的、特征和优点更加清楚，其中：

图1是表示现有技术的BMMM方法的基本工作过程的示意图；

图2是表示现有技术中的RTS的帧格式的示意图；

图3是表示根据本发明实施例的多播传输中MRTS的帧格式的示意图；

图4是表示根据本发明实施例的多播传输中MCTS的帧格式的示意图；

图5是表示图4所示的MCTS帧格式中的位映射(Bitmap)的一个实例的示意图；

图6是表示多播数据包的帧格式的示意图；

图7是表示WLAN中执行多播的一个实例的示意图；

图8是表示利用互联网组管理协议包来获得信道信息的流程图；

图9是表示根据本发明由小组中的代表节点返回的MCTS包中携带的位映射的一个实例的示意图；

图10是表示根据本发明由AP与相应接收小组的代表节点之间进行的传输过程的示意图；

图11是表示根据本发明实施例执行多播传输方法的流程图；和

图12至14是显示根据本发明的方法与现有技术相比所得到的性能改善的曲线图。

具体实施方式

下面参照附图对本发明的实施例进行详细说明，在描述过程中省略了对于本发明来说是不必要的细节和功能，以防止对本发明的理解造成混淆。

图2示出了现有技术中的RTS的帧格式的示意图。如图2所示，在802.11中定义的现有技术的RTS帧中包括帧控制(frame control)域，持续时间(duration)域，DA(目的端地址)域，TA(发送端地址)域，和CRC(循环冗余码校验)。其中，帧控制域主要用来指明帧的类型，持续时间域用来预约信道，CRC域用于判断接收到的帧是否正确。

图3示出了根据本发明实施例在MAC层执行多播传输的MRTS的帧格式的示意图。如图3所示，根据本实施例的MRTS的帧格式与图2所示的现有技术的RTS帧格式的唯一的区别在于将指示目的端地址的DA域改为用于指示接收组地址的RA域。这种改变不需要改变帧的构成格式。应该指出的是，这个组地址是根据IP组播地址转换而来的。本领域已知的是，IP地址有32比特，而MAC地址则有48比特。IP组播地址都属于D类IP地址，它的高四位都是1110，因此剩下的28个比特可以被用来映射为MAC层的多播地址。作为实例，可以把这28个比特看作十进制数，然后将其转换成16进制数，结果就是需要的MAC地址了。

图4示出了根据本发明实施例的多播传输中MCTS的帧格式的示意图。如图4所示，MCTS帧包括帧控制(frame control)域，持续时间(duration)域，GA(组地址)域，TA(发送端地址)域，位映射(Bitmap)字段，和CRC(循环冗余码校验)。其中GA(组地址：Group Address)是从IP组播地址转换而来的，它和图3中RA域的产生方法一致。加入Bitmap字段是考虑到IEEE802.11n中的数据集合特征。即，节点抢占一次信道，可以发送多个数据包。Bitmap一共占用8比特(bit)。当接收某个数据包出现错误时，可以将Bitmap字段中的相应比特设置为0。反之，如果数据包被正确接收，Bitmap字段中的相应比特被设置为1。在上面的实例中，AP一次最多可以发送8个数据包。然而，本发明不限于此，也可以通过设置不同的比特位来发送多于或少于8个数据包。

图5示出了位映射(Bitmap)字段的一个实例的示意图。例如，可以假设网络AP一次发送了5个数据包Data(1)，Data(2)，Data(3)，Data(4)和Data(5)。如果接收数据包Data(2)和Data(4)时发生错误，如图5所示，可以将Bitmap的第2和第4比特设置为“0”，而其余比特设置为“1”的MCTS返回到AP。AP接收到接收节点返回的MCTS后，通过检测其中Bitmap字段中各个比特的值，即可判断对此前发送数据包接收的对错情况了。

图6描述了根据本发明的多播数据包的帧格式。除了图6中的深色区域由原来标准中定义的1个Address4(6个字节)变成了3个Station ID(各2个字节)之外，图6所示数据包的格式与IEEE 802.11中定义的完全一样。Station ID是在节点和AP的初始协商过程中由AP分配的，这个过程的详细细节可以在IEEE 802.11标准中看到。也就是说，一旦一个节点与网络AP完成了初始的协商过程，该节点就会被分配一个2字节的Station ID。在IEEE 802.11中，Address4这个字段很少被用到。只有当数据从AP发往AP时，才会用到Address4字段。因此，根据本发明利用了这个空闲的字段，来通知每个小组的代表节点(sub-group 1eader)的Station ID。在图6中，示出了Station ID 1，Station ID 2，和StationID 3三个字段

图7是表示WLAN中执行多播的一个实例的示意图。如图7所示，小区1中的源节点要向小区2中的多播组发送数据。源节点产生的多播数据经由小区1中的接入点AP1和小区2中的接入点AP2，最后被传输到小区2中的多播组G。

其中，小区2中的接入点AP2利用本发明的多播方法来向接收组进行传输。为了便于描述，下面的表2中列出了在描述中需要使用的一些数值的含义。

表2

 

N	多播组中的成员数目
		SIFS	短帧间隔
TMCTS	发送MCTS包所需要的时间

当小区2中的网络AP2的MAC层接收到来自上层的多播数据包时，AP2首先把IP层的多播地址翻译成MAC层的组地址。然后，准备发起MRTS/MCTS握手机制来预留信道。在发送MRTS之前，AP2首先判断在自己的输出队列中，是否还有发往多播组G的数据包。如果有的话，AP2则把MRTS包中帧控制域的subtype值设为0000(该值在IEEE 802.11中是预留的)，用于指示有要发往多播组G的数据包。反之，如果没有要发往多播组G的数据包，AP2则把MRTS包中帧控制域的subtype值设为0001(这个值在IEEE802.11中是预留的)，用于指示没有要发往多播组G的数据包。经过了冲突避免过程，当信道空闲的时候，AP2就开始多播MRTS了。

收到来自AP2的MRTS包之后，每个组成员记录MRTS中的Subtype值，然后响应接收到的MRTS包，向AP返回MCTS包。由于多播组G中有多个成员，如果每个成员都响应AP2发送的MRTS包而向AP2返回MCTS包，那么AP2可能会接收到多个冲突的MCTS包。为了避免这些包的冲突，同时减少控制包的开销和时延，根据本发明的实施例，可以把一个大的多播组分成若干个小组(sub-group)。对大的多播组分组后，不需要每个节点向AP2反馈MCTS包，而只需要每个小组的组成员中的一个代表(leader)顺序地向AP2反馈MCTS包就可以了。

下面描述如何对大的多播组进行分组，如何选取分组后的小组中的组成员代表节点，以及如何向每个节点通知某个节点为代表节点。

对多播组的组成员进行分组的目的是为了把信道条件接近的节点分到一个小组中。可以近似认为，只要小组内的一个成员成功地接收到了数据包，那么同小组中的其他成员也能够成功地接收到了该数据包。基于这样的前提，不需要小组中的每个节点都向AP2发送反馈MCTS信息。为了把信道条件相似的节点分在一个小组中，需要知道AP2和多个接收节点间的信道条件。根据本实施例，作为实例，可以采用互联网组管理协议(IGMP：Internet Group Management Protocol)包来获得信道条件。IGMP是一个组管理协议，想要在Internet上支持多播，首先需要支持IGMP协议。

图8示出了利用互联网组管理协议包来获得信道信息的流程图。如图8所示，当节点想要加入多播组时，首先，在步骤S801，网络中的节点需要向自己连接的路由器发送多播组加入信息(IGMP host membershipreport：IGMP主机成员报告)以向AP或路由器进行注册。节点成功加入多播组后，在步骤S802，路由器需要每隔1秒钟向加入的节点发送查询信息(IGMP host membership query：IGMP主机成员查询)，来确认加入的节点是否还在组内。收到查询信息后，在步骤S803，节点需要向AP或路由器发送响应信息(IGMP host membership response：IGMP主机成员响应)。最后，在步骤S804，当加入的节点希望离开多播组时，需要向AP或路由器发送离开信息(Leave message)。

通过上述过程可以看到，当节点初始加入多播组以及此后每隔一秒，节点都要向AP或路由器发送IGMP信息。通过由AP监测IGMP信息，当AP接收到来自各个组成员的IGMP包后，AP可以测量来自各个组成员的接收信号强度(RSS)。然后，AP根据接收到的节点的RSS值，对这些节点进行分组。因为多播数据包格式的限制，目前可以支持的小组的数目为3。应该指出，本发明所支持的小组数目不限于3，而是可以按照本发明的思想通过改变多播数据包的格式来支持更多数目的小组。

对接入网络的每个组成员进行分组后，需要在每个小组中选择一个节点作为代表。作为实例，可以采用轮询法来选择每个小组的代表。即，每个小组中的组成员轮流作为本小组中的代表节点，这样每个节点都有机会成为代表。应该指出，本发明不限于此，也可以采用其它方法来选择每个小组的代表节点，例如，选择相应小组中信号强度最弱的节点作为代表，以确保AP在接收到该小组的代表返回的MCTS信息后，能够确保该小组中的每个节点正确接收到相应的数据包。

选择出每个小组的代表节点后，需要向小组中的组成员通知某个节点被选为本小组的代表。从前面对多播数据包格式的描述中可以看到，组播数据包(Multicast Data)中有3个Station ID字段。AP可以把作为各个小组代表节点的ID信息分别放置在这三个字段中。当组播成员接收到数据包时，首先会检查数据包中携带的Station ID字段是否和自己的ID相同。如果相同，该组播成员由此可以知道自己被选为其所在小组的代表节点。于是，该节点需要向AP反馈MCTS包。为了能够使代表节点顺序地向AP反馈MCTS信息，以避免MCTS包之间的冲突，可以设置每个代表节点反馈MCTS包的优先级与它的ID在多播数据包中的位置有关。例如，如果某个代表节点的ID出现在Station ID字段中的第2位，则意味着该节点在收到MRTS包后，不要立刻反馈CTS包，而是等TMCTS之后再发送MCTS包。就是说，AP通过在数据包的节点ID字段中放置每个小组的代表节点的节点ID的位置来指示所述代表节点的优先级。如果组播成员检查发现DATA包中的3个Station ID都与自己的ID不同，那么该节点就保持静默，不发送任何反馈信息。

AP2成功收到了所有小组的代表节点返回的MCTS包之后，开始发送多播数据。此后，所有多播组成员接收多播数据。多播组成员根据MRTS包中的帧控制域中之前记录的subtype值来决定是否需要响应ACK。只有当subtype值为0001，指示AP没有要发送到多播组的数据时，组成员才会向AP响应ACK。反之，如果subtype值为0000，表示AP还有要发送到多播组的数据。这种情况下，组成员不向AP响应ACK，而仅仅记录该数据包是否被成功接收即可。

可以假设AP2有多个数据包需要发送给多播组G。这种情况下，AP将MRTS包中的subtype字段设置为0000。接收组成员检测到该设置后，即可知道他们不需要响应ACK。

经过一个会话过程(MRTS/MCTS/DATA)之后，AP2并不知道所发送的数据包是否被所有节点成功地接收。接下来，AP2开始为下一个数据包发起MRTS的握手过程以便预留信道。接收到这个MRTS包之后，小组的代表节点将此前记录的对AP一次发送的多个数据包的接收情况加入到要向AP返回的MCTS包的bitmap字段中(有关bitmap字段的详细描述请参看图5所示的bitmap设置实例)。然后，小组代表节点将MCTS包发送给AP2。AP2接收到了所有小组代表节点发送的MCTS包之后，将MCTS包中携带的bitmap字段中每个比特的值做“位与”运算，得到一个确认标记confirm_flag值。AP利用所得到的confirm_flag值来判断如何重传未成功接收的数据包。

下面结合图9描述AP如何判断多播组成员未成功接收的数据包。图9示出了根据本发明由小组中的代表节点返回的MCTS包中携带的位映射的一个实例的示意图。可以假设AP2一次向多播组成员发送了8个数据包Data(1)，Data(2)，Data(3)，Data(4)，Data(5)，Data(6)，Data(7)和Data(8)。如图9所示，3个小组的代表节点向AP2返回的MCTS包中分别搭载了以下位映射(bitmap)信息。可以假设小组1的代表节点1成功接收到数据包Data(1)，Data(3)，Data(5)，Data(6)，Data(7)和Data(8)，而未能成功接收数据包Data(2)和Data(4)。这种情况下，代表节点1将MCTS包中位映射字段的第1，3，5，6，7，和8个比特设置为“1”，表示成功接收到数据包Data(1)，Data(3)，Data(5)，Data(6)，Data(7)和Data(8)；另外，代表节点1将MCTS包中位映射字段的第2，和4个比特设置为“0”，表示未能成功接收到数据包Data(2)和Data(4)。同样，小组2的代表节点2成功接收到数据包Data(1)，Data(2)，Data(5)，Data(6)，Data(7)和Data(8)，而未能成功接收数据包Data(3)和Data(4)。于是，代表节点2将MCTS包中位映射字段的第1，2，5，6，7，和8个比特设置为“1”，表示成功接收到数据包Data(1)，Data(2)，Data(5)，Data(6)，Data(7)和Data(8)；另外，代表节点2将MCTS包中位映射字段的第3，和4个比特设置为“0”，表示未能成功接收到数据包Data(3)和Data(4)。与此类似，小组3的代表节点3成功接收到数据包Data(1)，Data(3)，Data(5)，Data(6)，和Data(8)，而未能成功接收数据包Data(2)，Data(4)和Data(7)。于是，代表节点3将MCTS包中位映射字段的第1，3，5，6，和8个比特设置为“1”，表示成功接收到数据包Data(1)，Data(3)，Data(5)，Data(6)，和Data(8)；另外，代表节点3将MCTS包中位映射字段的第2，4和7个比特设置为“0”，表示未能成功接收到数据包Data(2)，Data(4)和Data(7)。此后，AP对代表节点1至3返回的MCTS包中位映射字段中的对应比特进行“与”运算，得到确认标记confirm_flag值。如图9中的confirm_flag对应的值所示，经过对各个代表节点返回的位映射字段中对应比特进行“与”运算后，得到第1，5，6，和8个比特为“1”，而第2，3，4，和7个比特为“0”。于是，AP确认数据包Data(2)，Data(3)，Data(4)，Data(7)的传送发生错误，并且重传这些数据包Data(2)，Data(3)，Data(4)，Data(7)。

下面参考图10描述根据本发明实施例在AP与组成员之间进行的传输过程。如图10所示，可以假设在多播组中有一个发送方(AP)和3个接收小组。首先，AP依据IGMP信息对多播组进行分组，指定每个小组的代表节点。在发送方(AP)发送数据时，通常有多个数据包要向外发送。如前所述，基于数据包集合特性，发送方一次可以发送多个数据包。在第一次发送数据包之前，发送方在第一对话过程中首先发送MRTS，接收小组中的代表节点(GH1至GH3)发出MCTS进行交互。图10中示出了接收小组的代表节点按照优先顺序回复MCTS包，以避免造成MCTS包的发送冲突。MRTS/MCTS交互完成之后，发送方开始第一次发送数据包(图10中带阴影线的数据包)。至此，第一个对话过程结束。

在其它协议中，为了确认可靠传输，接收方在接收到每次发出的数据包之后发出ACK包，以确认接收到所发送的数据包。与其它协议不同，在本发明中，在数据包没有发送完之前，即MRTS包中帧控制域中的subtype字段为0000时，接收小组的代表节点去掉了针对每个数据包发送的ACK包。此后，在第二对话过程中，为了第二次发送数据包，发送方和接收小组的代表节点之间同样需要进行MRTS/MCTS交互以执行初始化。发送方在第二对话过程中发送了MRTS包之后，接收小组的代表节点要回馈MCTS包。如前所述，此时回馈的MCTS已经被改变，其中包含有指示最近一次成功接收到的最新数据包的序号的Bitmap字段。假设发送方第一次发送的多个数据包已经被所有的接收小组的代表节点正确接收，第二对话过程中每个接收小组的代表回馈的MCTS包的Bitmap字段中与各个数据包序号相应比特的值被设置为1。当发送方发现所有接收小组的代表节点回馈的MCTS包中Bitmap字段中与数据包序号相应比特的值都等于1时，则可以判断所有接收方正确接收到第一次发送的所有数据包，并开始第二次发送传输数据包。应该指出，发送方在第一次发送数据包后，可以诸如依据轮询之类的原则指示新的代表节点。当然，也可以仍然使用原来指示的代表节点。

发送完第二次的多个数据包之后，发送方在第三个对话过程中准备第三次发送数据包。同样，在第三次发送数据包之前，发送方与接收方之间执行MRTS/MCTS交互。由于第二次发送的数据包可能在传输中的某个代表节点丢失，在发送方发送完MRTS包之后，接收小组的代表节点回馈MCTS包。此时，某些代表节点可能丢失第二次发送的数据包中的某些数据包，因此，其回馈的MCTS包中Bitmap字段中与丢失的数据包序号相应比特的值可能因该数据包丢失被设置为0，而成功接收到第二次发送的数据包的接收小组的代表节点回馈的MCTS包中Bitmap字段的相应比特的值是1。发送方对接收方回馈的MCTS包中的相应位的比特进行“与”运算后得到的对应确认标记为0时，可以判断接收方丢失的第二次发送的数据包。这种情况下，发送方在第三个对话过程中首先发送第二次发送中丢失的数据包，然后发送第三次要发送的数据包。依此类推，直到在第四个对话过程中发送完所有数据包。

根据本发明，利用对下一次DATA包进行响应的MCTS包来确认接收方是否正确接收到前一次发送的数据包，从而节省了ACK包的开销。另外，通过对接收方的组成员按照接收信号强度等因素进行分组，只由相应小组的代表节点返回MCTS包，可以降低多个接收节点向发送节点返回MCTS的时延。此外，将所要发送的新数据包与前面发送的数据包在同一个对话过程中发送出去，由此节省了一部分交互开销。

下面参考图10描述根据本发明由AP与分成小组的代表节点之间进行的传输过程。首先，在步骤S1101，发送方(AP)启动，AP依据IGMP信息对多播组进行分组，指定每个小组的代表节点。然后，AP向无线网络中多播MRTS包。另外，发送方在步骤S1102启动发送方中的定时器，设置定时器的周期为T₁＝T_MCTS+SIFS(表2中列出了各参数的具体含义)，并等待接收方返回的MCTS。接收方接收到MRTS包之后，在步骤S1103，每个小组的代表节点根据自己的优先级，计算自己在响应MCTS之前应该等待多长时间。各代表节点的等待时间计算如下：T₂＝m×SIFS+(m-1)×T_MCTS(其中，m是每个代表节点的优先级)。每个代表节点按照自身计算的等待时间，设置自身的定时器的定时周期为T。此后，在步骤S1104，每个代表节点在MCTS包的Bitmap字段中与所接收的多个数据包序号对应的比特搭载指示是否成功接收到该次发送的相应数据包的值。如果未成功地接收到相应的数据包，则设置对应的比特为0。如果成功接收到相应的数据包，则设置对应的比特为1(如前所述)。在该代表节点的定时器到时，即经过T2时间后，向发送方发送MCTS包。

接下来，在步骤S1105，发送方判断在自身定时器的周期T₁到期前是否接收到接收方回馈的MCTS包。如果在步骤S1105判断在周期T₁之前没有收到MCTS包，发送方则返回到步骤S1101。如果在周期T₁之前收到回馈的MCTS包，发送方则进行到步骤S1106，消除当前的定时器，从接收的MCTS包的Bitmap字段中提取对应的各个位的值，并记录各位的值。此后，在步骤S1107，发送方判断是否接收到所有代表节点回馈的MCTS包。如果在步骤S1107判断未接收到所有代表节点回馈的MCTS包，流程则返回步骤S1102，等待其它MCTS包。如果在步骤S1107判断已接收到所有小组的代表节点回馈的MCTS包，流程则进行到步骤S1108。在步骤S1108，对发送方对各个代表节点返回的MCTS包中位映射字段中的对应比特分布进行“与”运算，以得到确认标记confirm_flag值。此后，在步骤S1109，判断所得到的confirm_flag对应的各个位的值是“0”还是“1”。当得到相应位的对应值为“1”时，则说明代表节点成功接收到发送方上次发送的多个数据包值的对应数据包，而当得到相应位的对应值为”0”时，该接收节点未能成功地接收发送方上次发送的多个数据包值的对应数据包。

接下来，当在步骤S1109的判断结果为否定时，流程进行到步骤S1110，发送方根据未能被成功接收的数据包的数目，在此次要发送的多个数据包中加入未能被成功接收的数据包，并去除与重发的数据包的数目对应的新数据包。另外，当在步骤S1109的判断结果为肯定时，表明代表节点已经成功地接收了此次发送的所有数据包。这种情况下，流程进行到步骤S1111，发送方向接收方发送新的数据包。在步骤S1110和S1111之后，发送方在步骤S1112，按顺序向接收方发送要发送的多个数据包(可能包括重发的数据包)。此后，在步骤S1113，接收小组的代表节点检测是否有未成功接收的数据包。如果未成功地接收到相应的数据包，则设置对应的比特为0。如果成功接收到相应的数据包，则设置对应的比特为1(如前所述)，由此构成MCTS包。步骤S1113可以接在步骤S1104之后，在该代表节点的定时器到时，即经过T2时间后，向发送方发送MCTS包。

另外，在前面对现有技术的介绍中，已经提到了现有技术中针对WLAN中多播的自适应速率调整算法(参见前面提到的对比文献1至3)。对于多播的自适应速率调整，需要解决两个问题：(1)如何解决多个反馈信息冲突的问题；(2)如何根据多个接收节点的信道情况来调整发送速率。对于上述问题(1)，由于在本发明提出的方法中MCTS包是基于顺序反馈的，所以反馈信息的冲突很容易就得到解决了。对于上述问题(2)，对比文献1和2中都是根据最差的接收节点来调整发送速率，这种方法虽然可以提高可靠性，但是也会使系统的效率降低。对比文献3提出的方法是根据最好的接收节点来调整速率，这样的调整方法比较激进。按照对比文献3提出的方法，虽然可以得到比较好的系统吞吐量，但是无法保证用户的可靠性。为了平衡数据包接收的可靠性和系统吞吐量这两个要求，本发明提出了新的自适应速率调整算法，这种算法可以满足一定的可靠性，同时使得系统平均吞吐量最大。

根据本发明，可以把自适应速率调整看作是一个有约束的优化问题，它的优化函数如下面的表达式(1)所示，

${\mathrm{MaxThr}}_{\mathrm{ave}}\left(R\right)=\frac{\underset{i=1}{\overset{N}{\mathrm{\Σ}}}R(1-{\mathrm{BER}}_i\left({\mathrm{SNR}}_i\right))}{N}\·\·\·\·\·\·\left(1\right)$

其限定条件可以由下面的表达式(2)定义。

sub PDR>P_thr        ......(2)

其中，Thr_ave表示组播成员的平均吐量，R表示在一定ACM调制方式下的发送速率，BER表示在一定的信噪比情况下，采用特定的ACM方式得到的误比特率，SNR表示信道的信噪比，N是组播成员的个数，PDR(PacketDelivery Ratio)表示数据包被成功接收的比例。在IEEE 802.11中，可以假设采用BPSK调制方式，则R＝1Mbps。在上面的表达式中，指示数据包被成功接收的比例的参数PDR是一个可靠性指标，可以由下面的表达式(3)具体定义PDR。

$\begin{array}{c}\mathrm{PDR}=\frac{\underset{i=1}{\overset{N}{\mathrm{\Σ}}}\mathrm{successfully}\_\mathrm{received}\_\mathrm{packet}}{\mathrm{need}\_\mathrm{received}\_\mathrm{packet}\×N}=\frac{1}{N}\underset{i=1}{\overset{N}{\mathrm{\Σ}}}(1-{\mathrm{PLR}}_i)\\ {\mathrm{PLR}}_i=1-{(1-{\mathrm{BER}}_i)}^{\mathrm{packet}\_\mathrm{size}}\end{array}---\left(3\right)$

PLR_i＝1-(1-BER_i)^packet_size

其中，PLR(Packet Loss Rate)表示数据包丢包的概率，BER(Bit Error Rate)表示数据包中比特错误的概率。

从上面的描述可以看出，这个算法的优化目标是使得平均吞吐量最大，约束条件是满足一定的成功发包率。

图12至14是显示根据本发明的方法与现有技术相比所得到的性能改善的曲线图。

本发明利用0PNET 11.5实现了EIA，LBP，DBP，BMW和IEEE 802.11算法。为了衡量本发明方法的性能，使用了下面的指标：

(1)数据包被成功接收的比例(PDR)：成功接收到数据包的数目/应该接收到数据包的数目。

(2)平均包的时延：这个时延由数据包进入AP的MAC层队列开始算起，直道它被多播组员成功接收为止。

(3)时延抖动。

在针对本发明的方法进行的比较中，采用了下面的表3中所列出的参数。

表3

 

参数	值
		节点数目	30
应用描述	FTP下载
		文件大小	1000字节
请求间隔	常数(1秒)
		仿真时间	5分钟
传输范围	300米
		带宽	11M
节点布置	随机
		无线传播模型	Two ray ground(双径传播模型)
MAC协议	IEEE 802.11，LBP，EIA，DBP
		传送协议	UDP

图12示出了PDR随多播组成员数目的变化曲线。从图12可以看出，EIA获得了最好的PDR。这主要归因于两个方面：(1)组员顺序反馈，使得AP可以获得每个小组的信息。而对于其他基于负反馈的协议来说，由于碰撞，超时等因素，AP可能无法获得所有组员的信息。(2)MCTS中搭载了确认信息，减少了由于ACK包丢失和冲突产生的重传。

图13示出了时延随多播组成员数目的变化曲线。该图比较了时延多播随组成员数目的变化趋势。由于IEEE 802.11没有任何握手机制和重传机制，因此它的时延最小。EIA的时延仅仅大于IEEE 802.11的时延，而小于其他算法的时延。

图14示出了时延抖动的比较示意图。如图14所示，比较了几个协议所带来的不同时延抖动。从图14中看到，EIA所产生的时延抖动是最小的。这是因为，对于LBP和DBP，在一个会话中，多播组成员需要响应两个控制包(CTS/NCTS和ACK/NAK)。而且在响应ACK/NAK时，总存在丢失或产生冲突的可能性，从而发起下一个不必要的传输。但本发明的方法不存在这个问题。

至此已经结合优选实施例对本发明进行了描述。本领域技术人员应该理解，在不脱离本发明的精神和范围的情况下，可以进行各种其它的改变、替换和添加。因此，本发明的范围不应该被理解为被局限于上述特定实施例，而应由所附权利要求所限定。

Claims (20)

1.一种在无线网络中的媒体接入控制(MAC)层中执行多播传输的方法，包括步骤：

发送方根据多播组成员的信道条件将多播组成员分成小组，并指示每个小组的代表节点；

发送方向多播组成员多播包含指示是否有要发送到多播组的数据包的多播请求发送分组，并等待来自每个小组代表节点的多播清除发送分组；

发送方在接收到来自每个小组的代表节点的多播清除发送分组后，向多播组成员多播至少一个数据包，并记录当前发送的数据包的序号；

每个小组中的代表节点在接收到多播的至少一个数据包之后，在各自的多播清除发送分组的位映射字段中记录指示是否正确接收到此次发送的相应数据包的值，并在预定时间周期后向发送方发送多播清除发送分组，而不发送肯定确认(ACK)包；和

发送方从来自每个代表节点的多播清除发送分组的位映射字段中记录的值来判断是否出现数据包丢失，并在出现数据包丢失的情况下，在下次发送数据包时将丢失的数据包与要发送的新数据包一起多播。

2.根据权利要求1所述的方法，进一步包括发送方在发送多播请求发送分组之前首先把IP层的多播地址翻译成媒体接入控制层的组地址的步骤。

3.根据权利要求1所述的方法，其中发送方将信道条件相近的多播组成员分到一个小组中。

4.根据权利要求3所述的方法，其中所述发送方通过测量来自各个多播组成员的接收信号强度对多播组成员进行分组。

5.根据权利要求1所述的方法，其中所述发送方通过在多播数据包中设置节点ID来指示每个小组的代表节点。

6.根据权利要求5所述的方法，其中所述发送方通过在数据包的节点ID字段中放置每个小组的代表节点的节点ID的位置来指示所述代表节点的优先级。

7.根据权利要求6所述的方法，其中所述多播数据包中包含三个节点ID字段。

8.根据权利要求1所述的方法，其中所述多播组成员最多被分成三个小组。

9.根据权利要求1所述的方法，其中所述多播清除发送分组的位映射字段中包含多个用于指示代表节点是否正确接收到发送方一次发送的所述至少一个数据包中的每一个的比特位。

10.根据权利要求9所述的方法，进一步包括当代表节点未能成功接收一个或一个以上的数据包时，所述代表节点将所述位映射字段中与未能成功接收到的数据包的序号对应的比特位设置为“0”的步骤。

11.根据权利要求9所述的方法，进一步包括当代表节点成功接收到数据包时，所述代表节点将所述位映射字段中与成功接收到的数据包的序号对应的比特位设置为“1”的步骤。

12.根据权利要求10或11所述的方法，进一步包括所述发送方将每个代表节点返回给发送方的多播清除发送分组的位映射字段中包含比特位中的对应比特位分别进行“与”运算，以用于确定多播组成员未能成功接收的数据包的确认标记，并重发多播组成员未能成功接收的数据包的步骤。

13.根据权利要求12所述的方法，其中当经过“与”运算的比特位的值为0时，所述发送方确定序号与该比特位对应的数据包未被成功接收。

14.根据权利要求12所述的方法，其中当经过“与”运算的比特位的值为1时，所述发送方确定序号与该比特位对应的数据包被成功接收。

15.根据权利要求1所述的方法，其中所述发送方通过多播请求发送分组中的帧控制域的subtype字段向多播组成员指示是否还有要发送给多播组成员的数据包。

16.根据权利要求15所述的方法，其中在发送方没有要发送给多播组成员的数据包时，发送方设置subtype字段为0001。

17.根据权利要求15所述的方法，其中在发送方仍有要发送给多播组成员的数据包时，发送方设置subtype字段为0000。

18.根据权利要求1所述的方法，进一步包括每个代表节点根据各自的优先级，计算自身在发送多播清除发送分组响应之前应该等待的时间周期，并顺序地向发送方发送多播清除发送分组的步骤。

19.根据权利要求1所述的方法，进一步包括在发送方指示没有要发送的数据包时，代表节点在接收到最后发送的数据包后，向发送方回馈肯定确认包的步骤。

20.根据权利要求1所述的方法，其中所述发送方根据下面表达式对多播速率进行自适应速率调整，

$\mathrm{Max}{\mathrm{Thr}}_{\mathrm{ave}}\left(R\right)=\frac{\underset{i=1}{\overset{N}{\text{\Σ}}}R(1-{\mathrm{BER}}_i\left({\mathrm{SNR}}_i\right))}{N}$

其限定条件为

sub PDR>P_thr

其中，Thr_ave表示组播成员的平均吐量，R表示在一定ACM调制方式下的发送速率，BER表示在一定的信噪比情况下，采用特定的ACM方式得到的误比特率，SNR表示信道的信噪比，N是组播成员的个数，PDR表示数据包被成功接收的比例，由下面的表达式表示

$\mathrm{PDR}=\frac{\underset{i=1}{\overset{N}{\mathrm{\Σ}}}\mathrm{successfully}\_\mathrm{received}\_\mathrm{packet}}{\mathrm{need}\_\mathrm{received}\_\mathrm{packet}\×N}=\frac{1}{N}\underset{i=1}{\overset{N}{\mathrm{\Σ}}}(1-{\mathrm{PLR}}_i)$

PLR_i＝1-(1-BER_i)^packe_size

Images