【WiFi】802.11AX TWT(Target Wake Time)机制整理

参考链接

CTS 164: 802.11ax Target Wake Time

Wi-Fi 6(802.11ax)解析18:TWT节能机制(Target Wake Time) - 知乎

[1804.07717] Target Wake Time: Scheduled access in IEEE 802.11ax WLANs

WIFI6 TWT机制介绍-CSDN博客 

TWT节能机制简介(Target Wake Time)

         TWT定时唤醒机制(Target Wake TimeTWT)首次出现在802.11ah “Wi-Fi HaLow”标准中,其用于支持大规模物联网环境下的节能工作。随着IEEE 802.11ax标准的发展,TWT的功能获得了进一步的扩展,这使得IEEE 802.11ax标准能够更加优化设备的节能机制,提供更可靠,更节能的传输机制。在802.11ax中,TWT机制在ah的基础上,已经被修改为支持基于触发的上行链路传输,从而扩展了TWT工作的范围。

         在TWT中,终端和AP之间建立了一张时间表(该时间表是终端和AP协定的),时间表是由TWT时间周期所组成的。通常终端和AP所协商的TWT时间周期包含一个或者多个beacon周期(总体时间比如几分钟,几小时,甚至高达几天)。当终端和AP所协商的时间周期到达后,终端会醒来,并等待AP发送的触发帧,并进行一次数据交换。当本次传输完成后,返回睡眠状态。每一个终端和AP都会进行独立的协商,每一个终端都具有单独的TWT时间周期。AP也可以将终端们根据设定的TWT时间周期进行分组,一次和多个终端进行连接,从而提高节能效率。

        使用 TWT,每个STA与AP协商唤醒周期以传输和接收数据包,其余时间站点保持休眠模式,从而节省能源。一方面,这降低了参与STA的能耗,另一方面,也显著降低了争用水平,甚至在STA分布在不同的 TWT 会话中时也支持无冲突和确定性操作。因此,在具有多个异构流量流的场景中,如果遵循适当的唤醒/休眠时间表,即能够为每个流量提供所需的时间和传输机会的时间表,则使用 TWT 可以进一步提高频谱利用率。请注意,IEEE 802.11 MAC 的点协调功能 (PCF) 现已过时,可能不会包含在后续版本的标准中。此外,它仅提供 TWT 的有限功能和优势。事实上,TWT 在传输周期的使用方式上提供了更高的灵活性,因为它允许上行和下行流量,并且不将传输仅限于基于轮询的传输。此外,站点不需要监听所有信标,从而显着降低了能耗。

        在TWT模式下,User 1和User 2分别和AP协定了两个TWT时间周期,分别为TW1和TW2。终端User 1和User 2默认就工作在睡眠模式下(sleep mode),保持一个较低的功耗。当TWT时间周期到达时,AP会发送一个触发帧(Trigger)给终端,终端进而苏醒并和AP执行数据交换,当数据交换完成后,终端恢复睡眠模式。如果是传统PS模式,若本轮beacon帧中提示有User 1的信息,那么其不会在TW1时间内睡眠,会保持苏醒,直到数据交换完成。

        TWT和传统PSM模式的差别是,终端只在TWT时间开始的时候苏醒,而在PSM模式中,从该beacon周期开始,终端就会通过该beacon帧中的DTIM信息,观察AP是否由缓存了自己的数据帧,如果有的话,那么就保持苏醒,直到接收完成后,才恢复到睡眠模式。即beacon与设备休眠时间不再具有紧密联系,STA可以请求在将来的任意时间唤醒。(TWT可以以一个或多个beacon周期为单位)

IEEE 802.11ax 中的 TWT 

       利用 TWT 机制,STA可以与 AP 商定一个共同的唤醒调度,允许它们仅在需要时唤醒,从而最大限度地减少基本服务集 (BSS)(即由 AP 和相关站点组成的无线网络)内的能耗和争用。了解 TWT 工作原理的关键概念有两个。TWT 会话或会话周期 (SP) 是STA唤醒以接收或发送数据的时间段。TWT 协议是 AP 和STA之间经过协商后达成的最终安排,用于定义STA所属的 TWT SP 的详细信息,例如STA必须唤醒的时间。实际上,一个 TWT 协议允许STA参与定期唤醒的多个 TWT SP。请注意,修正案没有指定选择 TWT 会话STA的任何标准或如何安排它们,因此这取决于实施。 TWT 协议可能允许 DL、UL 或两种类型的传输,具体取决于协商以及 AP 在每个 TWT SP 开始时提供的进一步指示,例如通过触发帧。最后,值得一提的是,使用 TWT 的STA可以在任何时刻唤醒,以使用分布式协调功能 (DCF) 启动新的传输。 IEEE 802.11ax 中的 TWT 机制基于 IEEE 802.11ah 中的实现。除了个人 TWT 之外,它还包括广播 TWT。预计这种新型协议将能够提高 TWT 操作的效率,并进一步利用 IEEE 802.11ax 的新多用户功能。

TWT 工作模式

个人 TWT(Individual TWT)

       要启动 TWT 会话,首先要有一个协商阶段,AP 和目标站点在此阶段就一组通用参数达成一致,其中最相关的参数包括:

• Target Wake Time (TWT)

目标唤醒时间 (TWT):参与基于 TWT 的通信的站点应在下一次唤醒以进行 TWT 会话的时间(以微秒为单位)。

•TWT Wake interval

TWT 唤醒间隔:站点的后续 TWT 会话之间的时间间隔;当 TWT 是周期性的时,该值大于 0。

• Minimum TWT wake duration

最小 TWT 唤醒持续时间:自 TWT 会话开始以来,站点应保持唤醒状态的最短时间,以便能够从其他站点接收帧

• TWT Channel

TWT 信道:站点可以临时用作主信道的信道,类似于 IEEE 802.11ah 的子信道选择性传输。

• TWT Protection

TWT 保护:用于保护 TWT 会话免受外部站点传输(例如 RTS/CTS)影响的机制。

在协商阶段,还定义了以下方面。

首先,TWT 协议可以是显式的或隐式的:前者要求在每次新会话之前指定 TWT 参数,而后者允许依靠第一组参数设置定期会话,直到收到一组新参数。此外,TWT 会话中存在两种不同的操作模式:

1) 启用触发,其中 AP 使用触发帧来安排站点的传输;

2) 启用非触发,其中不需要使用触发帧,从而允许每个站点决定何时在 TWT 会话中自主传输。

最后,当 AP 与站点(或一组站点,见下文)建立 TWT 会话时,可以将其指定为已宣布或未宣布。前者意味着站点必须向 AP 发送消息以请求缓冲数据。后者允许 AP 无需等待站点的任何先前帧即可传送数据,利用 TWT 会话启动时所有站点都必须处于唤醒状态这一事实。一旦 TWT 参数达成一致,站点就可以进入休眠状态,直到下一次 TWT 会话开始。实际上,每个站点可以与 AP 建立最多 8 个 TWT 协议,因为每个协议都由 3 位值标识。TWT 单个协议如图所示

        让我们更详细地描述一下协商阶段的工作方式。在 IEEE 802.11ax 中,请求站是发起 TWT 会话设置的站,而响应站是接受或拒绝请求的站。原则上,标准允许任何站与任何站达成协议,但在实践中,所有协商过程的描述和定义都意味着 AP 和站之间的协议。出于这个原因,为了避免混淆,从现在开始,我们始终认为 AP 在 TWT 会话期间指定时间表,而其他情况留待将来考虑。 要创建新的 TWT 会话,请求站会向响应站发送 TWT 请求消息。在 TWT 请求消息中,它指定了 TWT 会话的参数,包括最小 TWT 唤醒持续时间、TWT 唤醒间隔和 TWT 信道。

此外,请求消息类型必须是以下之一:

• 建议:请求中包含的参数值集是请求站愿意使用的参数值集,但它会考虑接受替代集。

• 请求:请求站愿意设置 TWT 协议,并让响应站指定 TWT 参数集。

• 要求:请求站希望设置协议,但不会接受与请求消息中的参数集不同的参数集。 另一方面,响应站可以发送以下类型的响应:

• 接受:响应站接受请求,并使用响应消息中指定的参数值设置 TWT 协议。

• 替代:响应站提出一组替代参数值。

• 命令:响应站要求另一组参数,但无法进一步协商。

• 拒绝:不接受 TWT 会话。

        第二和第三个选项将需要(至少)另一对请求-响应消息来结束协议协商阶段。当最终响应为接受类型时,TWT 协议已设置。从此刻起,请求站可以进入休眠状态,直到下一个 TWT 会话开始。

       TWT 协议的所有细节都包含在 TWT 元素中,如图 3 所示,该元素可以包含在 AP 和站点之间为关联过程交换的任何帧中。请求类型字段包含一些重要的子字段。TWT 设置命令字段指定消息的类型(例如,请求、建议、接受)。此外,触发和隐式字段用于指定操作模式,流类型字段指定它是已宣布的还是未宣布的。

        AP 可以有多个 TWT 协议,每个协议都与不同的站点签订,但其中一些协议可能在时间上重叠。在这种情况下,站点可能由 AP 调度以进行同时传输,或者必须通过随机访问来争夺介质,如第 2 节所述。此外,TWT 分组机制允许 AP 通过为每个组和组内的每个站点提供传输时间来从公共 TWT 会话的开始时间指定类似 TDMA 的调度。该修正案并未严格定义 AP 应如何对站点进行分组或调度传输,因此这些选项引发了许多有趣的研究问题,并为研究将 TWT 与 IEEE 802.11ax 的新多用户功能相结合的最合适的调度方法提供了空间。第 4 节提供了更深入的讨论。TWT 选项的概述如图 3 所示。

广播 TWT(Broadcast TWT)

        广播TWT机制是一种由AP负责管理的工作机制。在该机制下,TWT时间周期是由AP宣告,通常AP会在每一个beacon帧中宣告本轮的TWT时间周期。在一些特殊的情况下,AP也会在其他的管理帧中宣告,比如Association帧,Reassociation帧或者Probe Response帧等等。我们需要注意在Broadcast TWT中,存在加入组和离开组的交互动作,终端需要向AP申请加组才可以执行Broadcast TWT,这个加组交互动作也是通过在终端和AP交换管理帧中,通过携带TWT elements完成的。当终端完成加组后,终端会按照最近接收到的TWT时间周期进行工作,此时这一类型的终端也被叫做“TWT Scheduled STA”,AP被称为“TWT Scheduling AP”。终端在TWT时间周期到达后进行苏醒,AP会发送广播的触发帧,发现哪些终端正在处于苏醒状态(加组后的终端们),并向这些终端发送数据帧,这里由于是广播通信,所以只有AP向节点发送。当AP发送完成后,终端恢复到睡眠状态,直到下一次广播TWT时间到达。通常,这种广播TWT中的时间间隔,我们也称为“TWT SP (Service Period)”。  

在设置阶段,站点还可以协商其他两个基本参数:

• 下一个目标信标:信标的下一个传输时间,包括与站点相关的 TWT 信息,即与站点所属的广播 TWT 会话相关的信息。

• 监听间隔:携带与站点相关的 TWT 信息的后续信标之间的间隔。

       然后,站点进入休眠状态,并在下一个相关信标安排的时间唤醒。这些信标携带有关广播 TWT 会话的必要信息,使相关站点能够遵循会话时间表。此外,AP 还可以广播会话的 TWT 参数集的任何更新,以便所有相关站点都可以正确更新它。与个人协议一样,广播 TWT 会话可以是启用触发的,也可以不是,并且可以实现为已宣布或未宣布的,工作方式与上一节中所述相同。

       如上图所示,AP会在Beacon帧中,进行TWT Broadcast时间周期(即TWT SP时间)的宣告。终端们苏醒并接收该Beacon信息。然后在对应的TWT时间到达时,对应的终端们会提前苏醒,接收AP发送的TWT trigger,以及AP发送的下行数据帧,在此过程中,AP也由可能发送新的一次的TWT Broadcast时间周期(即TWT SP时间)。终端接收完成后,进入睡眠状态,并在新的TWT SP时间到达时,再次苏醒,以后以此类推。 

机会PS模式(Opportunistic PS) 

         机会PS模式和前面两种工作模式是类似的,但是没有AP和节点的协商过程。AP会在每一个Beacon内,公开宣告一个TWT时间。任意终端可以选择在这个公开TWT时间内进行苏醒,并和AP执行数据帧交换。这个交换可以是单个节点的,也可以是采用OFDMA机制进行交换。

如上图所示,AP在Beacon帧中宣告了一个公开的TWT时间,任意终端都可以直到该TWT时间。当该TWT公开时间到达后,AP会发送触发帧,此时苏醒的节点可以和AP进行交互,并执行数据帧的交换。在图中,由多个节点苏醒,从而触发了一次OFDMA类型的数据帧交互。

识别客户端是否支持 TWT 模式的字段

  • TWT Requester Support
  • TWT Responder Support
  • Broadcast TWT Support

TWT 元素

控制字段将指示协商类型:单独、广播或唤醒 TBTT 间隔。

单独 TWT参数信息

使用单独 TWT 时,TWT 参数信息字段将具有以下格式:

广播TWT参数

当使用广播TWT时,TWT参数信息字段将具有以下格式:

抓包查看相关字段

评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

wellnw

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

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

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

打赏作者

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

抵扣说明:

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

余额充值