下一代无线局域网--MAC吞吐率提升措施

一、改进的原因

1 无MAC改进的吞吐率

虽然通过引入TXOP概念和块确认提升了MAC性能，但并不大。由于PHY性能显著提升的可能性，现有的MAC协议并不能很好地适应PHY数据速率的增长

下图描述了MAC以上的吞吐率相对于PHY速率的低扩展性。可以看出一个PHY数据速率为270Mbit/s的40MHz 2 x 2系统在MAC以上只能达到92Mbit/s的吞吐率。此外，一个PHY数据速率为540Mbit/s的40MHz 4 x 4 系统所能达到的吞吐率几乎与前者相同

下图显示了效率随着数据速率的增加而降低。这时因为前导码及帧间距的固定系统开销所造成的。

当数据载荷的时长变短时，这些系统开销占用了更大比例的空中传输时间。为了在高数据速率时支持多个空间流，需要更长的前导码，从而增加了额外的固定开销。

2 MAC吞吐率提升措施

下图是对MAC吞吐率提升做的一系列措施：

1. 引入立即块确认，让数据帧被编组在一起。
2. 减小连续传输之间的帧间距。由于站点在突发期间保持在发送状态，所以不需要在帧间维持较长的SIFS。
3. 更进一步的精简可以去掉帧间距和前导码，把数据帧连接起来一次发送，在802.11n中，这称为聚合。
4. 要求一个BA帧，通过在组成聚合的每一个数据帧上捎带一个比特来实现。这种方式效率高，强健性也好。

3 MAC效率增强后的吞吐率

下图可以看出，现在吞吐率基本上随着PHY数据速率线性增长。主要是因为聚合允许了在TXOP时限内的长数据传输，隐式BAR与压缩BA帧格式的使用进一步提高了效率。

二、聚合

1. 位于MAC顶端的是MSDU聚合(A-MSDU)，建立MPDU的第一步是在流出方向上对MSDU进行聚合
2. 位于MAC底端的是MPDU聚合(A-MPDU)，将多个MPDU聚合进行一个PSDU，该PSDU被转交给PHY作为一次传输的载荷

1 聚合MSDU

A-MSDU中，来自LLC去往同一个接收端的同一个服务类型的MAC服务数据单元可以被累积起来封装在一个MAC协议数据单元(MPDU)中。

从LLC接收到的MSDU带有一个14字节长的子帧前缀。该前缀包括目的地址(DA)、源地址(SA)以及一个长度字段。

2聚合MPDU

在A-MPDU下，组装好的MPDU逻辑上在MAC的底端被聚合起来。每个MPDU前被加上一个短MPDU分割符，随后聚合被作为要在单个PPDU中发送的PSDU送给PHY

MPDU分割符的长度为32bit，一个接收端的实现通过使用各个分割符中的长度信息取出跟随其后的MPDU，从而解析A-MPDU帧结构。即使一个分隔符损坏，接收端可以向前扫描来寻找在32bit边界上的下一个分隔符，这样一来就可以提出该MPDU以及后续的MPDU。A-MPDU帧结构具有强健性，因为跟随在已损坏分隔符后的MPDU仍可以得到恢复。

一个A-MPDU中的所有MPDU都以同一个接收端为其目的地址。

在需要传送大量短分组的情况下，如果仅使用A-MPDU，可能会导致在一个单一聚合里达到能接收64个未分片MPDU的上限，从而使TXOPbn被完全利用。即使使用较大的分组，在很高的PHY速率下也可能出现同样的情况。在这两种情况下，通过使用A-MSDU来把两个或更多的MSDU聚合到一个MPDU中，然后再聚合生成较大的MPDU，可以增加聚合传输的数据量，从而提高效率。

三、块确认

通过允许一个BA帧来确认一整块数据帧的传送，而不是对每一个数据帧发送一个确认帧。

1 立即与延迟块确认

使用块确认机制，站点间需要通过进行一个“ADDBA 请求”与“ADDBA响应”交换来建立一个块确认回话。(两个站点所建立的一个块确认会话具有一个特定的通信标识符，且只被用于从发起端到响应端的单向数据传送)

在一个成功的ADDBA交换后，节点间进入数据传送阶段，发前端先发送一个连续数据块，然后发送一个BAR。响应端则回应一个BA。

发起端或接收端可以通过发送一个“DELBA 请求”来终止块确认会话。如果对应的一方正确接收到DELBA，则其发送一个ACK作为确认

立即块确认与延迟块确认的差别在于数据传输阶段对BAR与BA帧的处理，在使用立即块确认时，BAR要求一个即使的BA响应，而在使用延迟块确认时，对BAR帧的正确接收是通过ACK来确认的，BA则在另外的信道接入中被返回，并被另一个ACK确认。

立即块确认的优点是性能高，而延迟块确认的设计宗旨是易于实现。当使用延迟块确认时，接收端有更多的时间来处理BAR，因此延迟块确认适用于那些BA处理工作主要通过主机的软件来完成的具体实现。

2 重排序缓冲区操作

在一个块确认会话中，当接收端收到一个QoS数据帧时，会将这个帧放入缓冲区。如果收到的这个MPDU使重排序缓冲区头上的MSDU变得完整，则接收端将这个完整的MSDU以及重排序缓冲区中后续的完整MSDU按顺序发送到上层，直到遇到一个在序列空间造成空洞的不完整MSDU为止。

当在收到一个MPDU时重排缓冲区已满，则重排缓冲区中的第一个MSDU被丢弃。如果收到的是一个BAR帧，则所有比该BAR帧起始序列号低的完整MSDU都被转发到上层，而所有比该BAR帧起始序列号低的不完整MSDU则被丢弃。

下图是一个重排缓冲区的例子。MSDU 1被完整的接收，重新组装后发送到高层；MSDU 2中的2.1丢失，先放入重排缓冲区中直到MSDU 2变得完整，这样后继的MSDU即使是完整的也会被暂时扣住，直到MSDU 2完整发送到高层。

四、HT立即块确认

将HT立即块确认制定为一个独立协议的目的是为与传统设备向后兼容。

1 聚合中的正常确认策略

如果聚合中的一个或多个QoS数据MPDU将其“确认策略”字段设为“正常确认”，则响应端将此聚合回应一个BA帧

尽管可以使用“正常确认”策略来要求一个BA帧，但这并不排除BAR帧的必要性。

BAR帧有两个作用，第一个作用是要求BA响应；第二个作用是冲刷重排序缓冲区中由于先前不完整MSDU而被暂时扣住的MSDU。

如果发起端没有收到对一个已经超时的MSDU的确认，则必须发送一个BAR来冲刷接收端重排序缓冲区中此MSDU后继的完整MSDU，否则这些MSDU将一直不能被送到上层

2 压缩块确认

在HT的高速率下，分片带来的好处并不大。802.11n引入了一种压缩BA。压缩BA只为每个MSDU保留一位，而不是按分片数保留16位。这样一来记分板只有64位，同时减轻了传输负担以及对接收端内存的要求

3 全状态与部分状态块确认

全状态块确认操作

在全状态块确认下，接收端为每个块确认会话维护一个确认状态记分板，记分板记录最多64个MSDU的确认状态。当使用分片时每个MSDU可能被分成至多16片，这样记分板是一个最多由64个条目组成的数组，数组中的每个条目是一个16比特值

记分板窗口由起始序列号WinStart、终止序列号WinEnd以及窗口长度WinSize定义，记分板在块确认会话建立时初始化，其WinStart值被设置为“ADDBA请求”中所提供的起始序列号

当接收端收到一个QoS数据帧，如果序列号落在记分板所表示的空间中，则接收端使用该数据帧的序列号做下标来找到记分板中的相应条目，并记录该帧被正确接收。如果该序列号落在记分板表示的空间之外，但位于WinEnd到WinStart + 2¹¹ 的范围内，则接收端将记分板右移，直到记分板窗口最右端包含这个新的序列号为止

当收到一个BAR帧时，将其记分板右移，以使WInStart等于BAR帧中提供的SSN值。随后接收端返回一个包含积分板内容的BA响应。

采用部分状态块确认的原因

在使用传统块确认机制时，需要在整个块确认会话期间保持记分板的状态。这需要维护所有活跃块确认会话的状态，从而增加了接收端的实现负担。

状态内存可以被有效地用作缓存，存储最近的活跃块确认会话的状态。

部分状态块确认操作

当接收到序列号为SN的QoS数据帧时，接收端校验自己是否有相关块确认会话的块确认记分板记录，如果没有，则接收端为此会话创建一个记分板。对于随后的每个数据帧，有以下3中情况：

1. 如果SN(序列号)落在当前记分板窗口内，即WinStart ≤ SN ≤ WinEnd，则记分板在SN表示的偏移量处记录收到该帧
2. 如果SN落在窗口外，但位于序列号空间范围的一半内，即WinEnd < SN < WInStart + 2¹¹ ，则记分板右移以适应SN
3. 如果其SN超出窗口外一半序列空间以上，即WinSatart + 2¹¹ < SN < WinStart，则不对记分板做任何改变。

部分状态与完全状态块确认操作的主要不同在于接收端保留记分板的短暂性，使用部分状态块确认时，发起端需要确认其接收到确认状态时间基本上可以肯定要早于另一个站点有机会发送数据给接收端并擦除会话的块确认记分板的时间。

4 HT立即块确认TXOP序列

序列a中通过把组成聚合的QoS数据MSDU中的“确认策略”字段设置为“正常确认”来完成一次聚合数据传输。

序列b与a类似，不同之处在于两个聚合传输被连续发送，形成一次突发，这样做可以提高强健性。

当一个MSDU因为超时而被丢弃，从而需要发送BAR帧来释放接收端重排序缓冲区中可能被阻挡的完整MSDU时，可以使用序列c和d。c中存在数据帧，一般在BAR之前发送。虽然BAR可以和数据帧聚合在一起，但是一般会作为一个单独的被更强健调制的帧发送。由于BAR并不经常发送，牵涉BAR的序列不需要优化，因为这样的总体收益不大。

五、HT延迟块确认

HT延迟块确认与延迟块确认协议的不同在于对BAR与BA帧的确认方式。

当使用HT延迟块确认时，BAR与BA帧分别带有一个“BAR确认策略”与“BA确认策略”字段。如果这个字段被设置为1，则标示这一帧的接收端不应该返回一个ACK响应。

TXOP以一个短的帧交换开始，该交换可以是RTS/CTS或者是数据/ACK。