下一代无线局域网(802.11n) 第8章 MAC吞吐率提升措施

本文深入探讨了802.11n标准如何通过数据突发、立即块确认、精简帧间间距等手段提升MAC吞吐率。重点介绍了A-MSDU和A-MPDU聚合机制,以及HT立即和延迟块确认如何优化数据传输效率。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

8.1 改进的原因

  1. 随着PHY速率的提升,系统吞吐率的提升变得平缓。
  2. 随着PHY速率的提升,前导码的开销占比越来越大,MAC效率明显下降

提升MAC吞吐率的措施

  • 数据突发
  • 立即块确认
  • 精简帧间间距
  • 隐式BAR
    在这里插入图片描述

8.2 聚合

在MAC的顶部是MSDU聚合(或A-MSDU),在外出方向,MSDU聚合是MPDU的第一步。在MAC的底部是MPDU聚合(或A-MPDU),它在外出方向聚合多个MPDU,形成传递到PHY的PSDU,形成单次传输的有效载荷。相反的MPDU和MSDU解聚合功能在进入方向处于相同的逻辑位置。
在这里插入图片描述
1. A-MSDU
通过A-MSDU,从LLC接收的、目的为同一接收方、相同业务类别(相同流量标识符或TID)的MAC服务数据单元(MSDU)可以累加并封装到单个MAC协议数据单元(MPDU)中。如图8.8所示。
在这里插入图片描述
在正常确认策略下,接收方必须支持A-MSDU。在块确认建立握手期间,在块确认策略下对A-MSDU的支持可以由双方在建立块确认的握手过程中协商。站点在HT PPDU中可以接收的最大长度A-MSDU在其HT Capabilities信息单元中声明为3839字节或7935字节。

2. A-MPDU
使用A-MPDU,完全形成的MAC PDU在MAC的底部被逻辑聚合。在每个MPDU前添加一个短的MPDU定界符,并将聚合后作为PSDU呈现给PHY,以便在单个PPDU中传输。A-MPDU封装如图9.10所示。
在这里插入图片描述
接收端实现利用每个分隔符中的长度解析A-MPDU成帧结构,提取MPDU。一个A-MPDU中的所有MPDU都发往同一个接收方,所有MPDU都属于同一个业务类别(TID相同),并且所有MPDU的MAC头中的Duration/ID字段都设置为相同的值。

在使用HT立即块确认时,一个A-MPDU可以承载:

  • 单个BA,作为聚合中的第一个MPDU
  • 属于同一个TID,并且满足块确认协议限制的QoS数据 MPDU。
  • 任何具有子类型“无需确认的功能”的管理MPDU。

在使用HT延迟块确认时,一个A-MPDU可以承载

  • 一个或者多个BA MPDU,其“BA确认策略”字段为“不确认”
  • 属于同一个TID,并且满足块确认协议限制的QoS数据 MPDU。
  • 任何具有子类型“无需确认的功能”的管理MPDU。
  • “BA确认策略”字段为“不确认”的bar MPDU。

站点在其HT Capabilities元素中通告其可接收的HT PPDU的最大A-MPDU长度。通告的最大长度可以是以下之一:8191、16 383、32 767或65 535字节。

3. A-MSDU
在802.11n开发的提案阶段,提出了逻辑上位于PHY顶部的聚合方案(Hansen和Edwards, 2004)。图8.10对这一技术进行了概念性说明。该提议要求在PPDU前面有一个单一的训练序列,然后是帧结构,该帧结构由限定一个或多个PSDU的PHY信令字段(HT-SIG)组成。
在这里插入图片描述
最终,这个方案被拒绝,因为使用A-MPDU聚合可以更有效地处理数据聚合到单个站点的更为常见的使用案例。对于这种使用场景, A-PSDU技术具有更高的开销(每个HT-SIG字段占用至少一个4μs符号),并且由于HT-SIG字段之一中的单个错误将阻止聚合的其余部分被解调,所以其鲁棒性较低。

8.3 块确认

802.11e修正中引入了块确认机制,以便通过允许传输通过单个块确认(BA)帧而不是针对每个单独的数据帧的ACK帧来确认的数据帧块来提高效率。有数据要发送的站点称为数据的发起者,数据的接收方称为接收方。802.11e修改中定义了两种类型的块确认:立即块确认和延迟块确认。802.11n修订版对这两种模式进行了增强,以提高效率并利用聚合和更高的数据速率。增强机制称为HT-立即块确认和HT-延迟块确认。HT工作站可能支持所有四种类型,尽管原始机制仅用于与传统工作站的互操作性。

8.3.1 立即块和延迟块确认
虽然正常确认机制始终处于运行中,并且实际上构成了底层DCF的一部分,但是需要通过交换ADDBA请求和响应来建立块确认会话来启用块确认机制。块确认会话是在两个站点之间使用特定的通信标识符(TID)在发送方到响应方的单向数据传输而建立的。ADDBA交换成功后,进入数据传输阶段。发起者将发送一个数据块,然后是BAR,响应者将用BA来响应。BA对从前一个块正确接收的数据帧进行确认。发起方对未正确接收的数据帧进行请求,并可能在随后的块中发送它们。发起方或接收方可以通过发送DELBA请求来拆除块确认会话,如果正确接收,则用ACK确认。

立即块确认和延迟块确认在数据传输阶段对BAR帧和BA帧的处理不同。使用立即块确认,BAR请求立即BA响应,而使用延迟块确认, BAR帧本身的正确接收通过ACK确认,BA在单独的信道访问中返回,并使用另一个ACK确认。立即和延迟的块确认会话如图8.11所示,下面将更详细地描述。
在这里插入图片描述
8.3.2 初始化块确认会话
工作站通过在其Beacon帧、关联/重关联请求帧和响应帧的能力信息字段中设置即时块确认和/或延迟块确认能力位来指示其支持块确认的能力。如果工作站通告它支持一种或两种类型的块确认,则对端工作站可以与该工作站为特定通信类别建立兼容的块确认会话。块会话由发送ADDBA Request帧的发起方发起。响应方收到正确的ADDBA Request帧后,发送ACK。响应方在进一步处理后发送ADDBA响应帧,如果收到正确,则发送方将用ACK响应。如果没有收到预期的ACK,发起方和响应方将重新发送ADDBA请求/响应。发起方的不活动超时将检测到会话设置失败。

ADDBA请求和响应帧包括如下字段:

  • 块确认策略
  • TID
  • 缓冲区大小
  • A-MSDU支持
  • 块确认超时值
  • 起始序列号(SSN)

响应方在确认收到ADDBA请求后,可以通过向发起方发送DELBA帧来拒绝来自发起方的阻塞确认会话。

8.3.3 块确认会话中的数据传输
在数据传输阶段,发起方可以发送QoS数据帧块,以SIFS或RIFS间隔的突发,或者作为A-MPDU的一部分。块中的每个QoS数据帧的确认策略字段设置为“块确认”。接收者维护记分板以跟踪哪些MPDU被正确接收。数据块可以完全包含在单个TXOP内,也可以跨多个TXOP。数据块和TXOP没有任何耦合。发起方传送数据块后,发送BAR帧。该帧包括起始序列号(SSN) ,它是需要确认的块中最旧的MSDU的序列号。接收方收到BAR后,执行两个功能。首先,它使用记分板为该会话准备BA响应。记分板被转换为位图,其中第一位表示与BAR帧中的SSN相同的序列号的MPDU,后续位表示连续的序列号。因此,位图以SSN作为起始参考,以序号索引为一个数组。其次,它检查其重排序缓冲区的序列号在SSN值之前。这些MPDU要么被重组为完整的MSDU,然后转发到上层,要么在无法创建完整的MSDU的情况下丢弃。

立即块确认和延迟块确认的主要区别在于接收方响应BAR的时间。在立即块确认下,接收方在SIFS之后用BA帧回应BAR。在延迟块确认下,接收方向BAR回应ACK。随后,在单独的信道接入中,接收方生成BA帧并发送给发起方。发起方对延迟的BA回复ACK。立即块确认提供了更好的性能,而延迟块确认的定义是易于实现的。使用延迟块确认,接收方有更多的时间处理BAR,并且适合于在主机系统上的软件中执行大量BA处理的实现。发送方收到BA后,释放已确认的MPDU,如果未确认的MPDU没有超过生存时间,则重新进行重传。

8.3.4 终止块确认会话
当发起方没有额外的数据要发送并且最终的块确认交换已经完成时,它可以通过向接收方发送DELBA帧来禁用块确认会话。接收方发送ACK响应,并释放为块确认会话分配的所有资源。如果发送方或接收方在块确认超时值的持续时间内没有收到属于该会话的BA、BAR或QoS数据帧,则阻塞确认会话也可能被终止。

8.3.5 非聚合中的正常确认策略
在块确认会话中使用普通确认可以获得较小的效率增益。许多流量模式是突发的,并且经常具有短周期,只需要发送一个帧。如果最后一个块传输已经完成,并且所有帧都已确认,则使用正常的确认过程发送数据帧比执行BAR/BA交换更有效。在这种情况下,QoS数据帧的确认策略字段设置为“普通确认”,并在非聚合PHY传输中发送。如果正确收到响应者将用ACK进行响应。帧在块确认会话记分板上被标记为正确接收。

8.3.6 重排序缓冲区操作
在一个块确认会话中,当接收方收到一个QoS数据帧,接收方将缓存该MPDU。如果到达的MPDU使得在重排序缓冲区头部的MSDU变的完整,则接收方依次将重排序缓冲区中的完整MSDU和后续的完整MSDU转发给高层,直到遇到在序列空间中形成空洞的不完整MSDU。如果MPDU到达时,重排序缓冲区中的前MSDU不完整,则保持该MSDU,直到前MSDU完成。如果MPDU到达并且重排序缓冲区已满,则重排序缓冲区中的第一个MSDU将被丢弃,以腾出空间。这还可能导致向高层释放完整的后续MSDU。如果收到BAR帧,则所有序列号小于BAR起始序列号的完整MSDU都将被转发到高层,所有序列号更低的不完整MSDU将被丢弃。因此,BAR帧具有双重作用。除了请求块确认响应外,它还为发起者提供一种机制,用于刷新接收方的不完全MSDU的重排序缓冲区或表示重传生存期已过期的MSDU的空洞。如果发送者由于生命周期到期而丢弃一个或多个MPDU,它必须发送BAR来清空接收方重排序缓冲区,以便后续的MSDU不至于被不必要的延迟等待序列完成。图9.13给出了重排序缓冲区行为的示例。
在这里插入图片描述
在BAR/BA交换之后,发起者获知丢失的片段,并连同其他可用的、适合于重排序缓冲区的MSDU一起重传它们。现在所有的MSDU都已经完成,并按顺序转发到高层。发起方获知所有MSDU都已成功地与另一次BAR/BA交换进行传输。

8.4 HT立即块确认

HT立即块确认是对立即块确认协议的重大修改,它作为一个单独的协议,用于向后兼容旧设备。希望与非HT工作站建立块确认会话的HT工作站必须使用原来的立即或延迟阻塞确认协议。HT工作站与另一个HT工作站建立块确认会话,使用HT立即或HT延迟块确认协议。HT变体与原始协议之间有许多共性,这简化了实现。所有HT站(和VHT站,因为VHT站也是HT站)都要求作为接收方支持HT立即阻塞确认。

8.4.1 聚合中的正常确认策略
在这里插入图片描述
8.4.2 压缩块确认
在更高的数据速率下,分片不会带来多大的好处。原来的BA帧由1024位记分板(128字节)定义,以支持64个MSDU,每个MSDU最多可以被16个分片。802.11n引入了一个压缩BA变体,该变体去掉了每个MSDU的16个比特用于分片。从而产生64位记分板(8个字节)。这既减少了广播开销,也减少了接收者的内存需求。

8.4.3 全状态与部分状态块确认
802.11e修正中定义的块确认机制称为全状态块确认,以区别于802.11n修正中引入的部分状态块确认。部分状态块确认与完全状态块确认向后兼容,因为使用部分状态规则的发起者将正确地操作,而接收方执行完全状态操作。

全状态块确认操作
在全状态块确认下,接收方为每个块确认会话维护一个确认状态记分板。记分板最多记录64个MSDU的确认状态。当使用分段时,每个MSDU最多可以被分段为16个分段,因此记分板是16位数组最多64个条目。具有有限内存的接收者实现可以通过在ADDBA响应中设置BufferSize参数来限制数组的范围。MSDU序列号是一个12位的值,因此记分板表示4096个值的序列号空间中的一个窗口。记分板窗口由起始序号WinStart、结束序号WinEnd和窗口长度WinSize定义。随着块确认会话的建立,记分板将初始化,WinStart设置为ADDBA请求中提供的起始序列号。当QoS数据帧到达时,如果序列号落在记分板所表示的空间内,则接收方将使用数据帧序列号(SN)索引记分板,并记录其正确接收。如果SN在记分板表示的空间之外,但在WinEnd到WinStart + 2 11 2^{11} 211的范围内(序列号空间的一半),则接收端将向右移动记分板,直到其窗口的最右边缘包含新的序列号。当BAR到达时,记分板窗口向右移动,使WinStart等于BAR帧中提供的SSN,并返回带有记分板内容的BA响应。

采用部分状态确认操作的原因
使用原始的块确认机制,要求记分板状态在块确认会话期间保持。这给接收方实现带来了需要维护所有活动块确认会话的状态的负担,而且在实践中,由于响应BAR而产生BA所需的低延迟,这意味着使用昂贵的片上存储器。通过802.11n修改,规则被放宽,以便为块确认状态保留的片上内存可以被不同的块确认会话重用。状态存储器有效地用作缓存,存储最近活动的块确认会话的状态。较新的规则称为部分状态块确认,并且完全向后兼容原来的完全状态块确认规则。要了解变更的动机,请考虑图8.15所示的典型实现。在立即BA中,当接收方收到一个BAR或包含带有“正常确认”策略的QoS数据帧的聚合帧时,接收方必须在接收到该BAR或聚合QoS数据帧SIFS时长后发送BA Response帧。由于接收路径上的解码延迟和发送路径上的编码延迟,因此几乎没有时间来定位适当的状态信息并形成BA响应。这在很大程度上需要片上存储块ack记分板,将在BA响应中返回。
在这里插入图片描述
块确认机制中另一个主要功能是重组和重排序功能,它重组完整的MSDU,然后将其转发到高层。这个操作的时间并不急迫,在重排序和重组过程中需要一个大的缓冲区来存储数据包,因此通常在安装网卡的主机系统中实现。

新的部分状态规则不影响重排序和重组过程,但是减少了网络接口中用于存储块确认记分板的资源需求。每个块确认会话仍然需要重排序缓冲区,但是由于它通常存储在主机内存中,所以相对便宜。存储块确认记分板所需的片上内存要少得多,因为相同的内存可以重复用于多个块确认会话。

部分状态块确认操作
当接收带有序列号SN的QoS数据帧时,接收方检查它是否有该块ACK会话的块ACK记分板记录,其中该会话由发送地址(TA)和TID标识。如果没有,则它会为这个会话创建一个记分板,WinEnd = SN, WinStart = WinEnd - WinStart + 1,也许可以重用另一个会话的内存。通过在代表SN的位置(即WinEnd)设置1来记录数据帧的正确接收。对于此后的每个数据帧: ①如果SN在当前记分板窗口内,即WinStart ≤ SN ≤ WinEnd,则记分板在由SN表示的偏移处记录接收。②如果SN在当前记分板窗口之外,但在半序列空间范围内,即WinEnd < SN < WinStart + 2 11 2^{11} 211,则记分板将向右移动以容纳SN。③如果SN大于窗口外序列空间的一半,即WinStart + 2 11 2^{11} 211 < SN < WinStart,则不做任何更改。记分板操作如图9.17所示。
在这里插入图片描述
当收到BAR时,接收方向右移动记分板,使WinStart = SSN从BAR返回一个包含记分板内容的BA帧。

部分状态和全状态块确认操作的主要区别在于接收者保留的记分板的瞬态性质。在部分状态块确认下,发起者应确保在另一个工作站有机会向接收方发送数据并可能擦除会话块确认记分板之前,它以高概率检索确认状态。在实践中,这意味着发起者应该在每个TXOP结束之前尝试检索块确认记分板。如果在TXOP期间偶尔没有检索块确认记分板(可能错误地接收了BA帧),那么很有可能在接收端收到属于另一个块确认会话数据,而导致会话的块确认计分板被抹除前,发起端还会进行一个后续的信道接入。因此,发起者可以在随后的信道访问中使用BAR帧来检索确认状态。在不可能的情况下,块确认记分板不再可用,BA将显示所有零,并且发起者将需要重新发送MSDU。或者,如果发起者发送了由具有“正常确认”策略的QoS数据帧组成的单一聚合,并且未收到BA,则发起者可以假定没有QoS数据帧通过,并且简单地重传QoS数据帧。虽然允许更复杂的行为,但大多数实现将通过在每个TXOP中发送单个聚合来遵守部分状态规则,通过将组成聚合的QoS数据帧的ack策略设置为“正常确认”来请求BA。在MSDU生存期未得到确认就到期的极少数情况下,发起者会发送BAR帧来清除重排序缓冲区中的空洞。实现此行为的发起者将同时使用接收者中的完全状态和部分状态实现。

8.4.4 HT立即块确认TXOP序列
HT立即块确认下的TXOP序列如图8.17所示。TXOP通常包含一个A-MPDU,其中携带多个QoS Data MPDU,每个MPDU都具有“正常确认”策略,随后是立即BA响应。如果出现大量误帧,MPDU在多次重传后被丢弃,则可能出现BAR/BA交换的TXOP。此外,在一些环境中,将每个聚合BA交换前缀为RTS/CTS交换可能是有益的。这种短帧交换在很多站点竞争信道接入时起着低开销冲突检测机制的作用,并作为对隐藏节点的保护机制。
在这里插入图片描述

8.5 HT延迟块确认

HT延迟块确认是延迟块确认协议的扩展,与BAR和BA帧确认方式不同。支持HT延迟的块确认是可选的,工作站通过在HT Capabilities元素中设置HT延迟的块确认能力位来通告支持。对端站可以与通告自己具有HT延迟块确认能力的站建立HT延迟块确认会话。在HT延迟块确认下,BAR帧和BA帧分别携带BAR Ack Policy和BA Ack Policy字段。如果设置为1,则指示帧的接收方不应返回ACK响应。

HT延迟块确认下的典型TXOP序列如图9.19所示。TXOP开始于短帧交换,可以是RTS/CTS 或Data/ack。HT延迟块允许发送者充分利用TXOP,因为响应者不需要立即响应。(a)显示发起者发送一个集合,其确认策略设置为“块确认”,然后是BAR。当数据双向流动时,BA可能与反方向的数据合并,这如(b)所示。在鲁棒性降低的情况下,可以将BA帧和BAR帧与数据聚合在一起。这如(c)显示。
在这里插入图片描述


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

sundaygeek

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值