802.11ax TWT（Target Wake Time）机制

参考文献 802.11ax Draft 8.0 、IEEE Std 2016、https://zhuanlan.zhihu.com/p/79572297

首先，明确一个时间点，TWT功能是802.11ah中首次提出的；但是，在802.11ax中进一步扩展。

TWT STA & TWT AP
target wake time (TWT) scheduled station (STA): A STA that follows the broadcast TWT schedules provided in a broadcast TWT element.

遵循broadcast TWT element中提供的broad TWT schedules 的STA。

target wake time (TWT) scheduling access point (AP): An AP that schedules broadcast TWTs and provides these broadcast TWT schedules in a broadcast TWT element.

调度broadcast TWT并在broadcast TWT element中提供这些broadcast TWT调度的AP。

NOTE–由以上定义可知，broadcast TWT调度的发起者是AP，服从者是STA。

TWT涉及到的字段：TWT Element、TWT Requester Support Element和TWT Responder Support Element
IEEE Std 2016 管理帧

NOTE–在管理帧中，HT Control字段的存在与否是不一定的，具体是由Frame Control字段中的+HTC/Order字段决定的，可以参考我之前的博客内容“802.11ax BSR机制”。

管理帧的Frame Body 字段

管理帧的frame body 由字段组成，后跟为每个管理帧子类型定义的元素。 除非另有说明，否则所有字段和元素都是强制性的，并以指定的相对顺序出现。 遇到在接收到的管理帧的frame body中无法识别的元素ID的STA会忽略该元素，并继续解析管理帧主体的其余部分（如果有）以获取具有可识别元素ID的其他元素。 见10.27.7。 保留未使用的元素ID代码。

什么是Element元素

Elements被定义为具有1个octet的Element ID字段，1个octet的Length字段，一个可选的1个octet的Element ID Extension字段以及一个可变长度的特定Element信息（variable-length element-specific Information field）字段组成的通用格式。

Element的类型由谁确定

每个Element都由Element ID以及此标准中定义的Element ID Extenion字段（如果存在）标识。

对于具有已定义element ID Extension的那些Element，Extension Element ID是Element ID和Element ID Extension 的组合。 Length feild指定Length field后面有多少个字节。

802.11ax Draft 8.0 管理帧之Beacon Frame
在IEEE Std 2016中Beacon Frame的Element ID范围是1 - 67，外加一个Last。

Beacon Frame中的TWT element

在802.11ax Draft 8.0中，添加/修改了一些Element ID，其中就包括TWT Element元素，其Element ID 是79；以及 TWT Constraint Paramenters元素（TWT 约束参数），其Element ID是88。

还有哪些管理帧中有TWT Element呢？
由AP发送的帧：

1, Association Response frame body
2, Reassociation Response frame body
3, Probe Response frame body
注意：以上三种管理帧中都可能有TWT Element元素和TWT Constraint Paramenters。
由STA发送的帧

由STA发送的Probe Request frame body中只有TWT Constraint Paramenters元素，没有TWT Element元素。

(注:在实际抓包中,使用小米11和小米AX6000关联的过程中,association response frame body中未看看elementid为78 79 88的元素;只在element id为255的元素中,看到有两个bit,分别用以表示是否支持twt requester support, twt responder support).

TWT Requester Support元素和TWT Responder Support元素

在802.11ax Draft8.0中还有以上两种元素。分别用来指示发起者和响应者是否支持TWT功能。(注:在实际抓包中,使用小米11和小米AX6000关联的过程中,association response frame body中未看看elementid为78 79 88的元素;只在element id为255的元素中,看到有两个bit,分别用以表示是否支持twt requester support, twt responder support,见下图).

TWT Element(Element ID = 79 ?)格式

各个字段详解可以参考802.11ax Draft 8.0的9.4.2.199小节。

TWT Element --Control字段格式详解

1, Negotiation Type subfield:

Negotiation Type subfield子字段指示TWT元素中的信息是指broadcast或individual TWT的参数的协商还是唤醒TBTT间隔。 Negotiation Type subfield子字段的MSB（most significant Bit）是Broadcast field。即，B3。

2, TWT Information Frame Disabled subfield：

TWT信息帧禁用子字段被设置为1以指示STA禁用了TWT信息帧的接收； 否则，它设置为0。

3, Wake Duration Unit subfield：

Wake Duration Unit subfield指示Nominal Minimum TWT Wake Duration field的单位。 如果单位是256 us，则唤醒持续时间单位子字段设置为0，如果单位是TU，则设置为1。 非HE STA将唤醒持续时间单位子字段设置为0。

4, TWT parameter sets

如果Negotiation Type subfield的Broadcast field为1，则在TWT Element中包含一个或多个broadcast TWT parameter sets（广播TWT参数集)（请参阅图9-687b（“广播TWT参数集”字段格式））。

如果Negotiation Type subfield的Broadcast field为0，则TWT Element中仅包含一个Individual TWT parameter set（请参见图9-687a（“单独的TWT参数集”字段格式））。 S1G STA将协商类型子字段设置为0。

5, 在Control field中将Broadcast field设置为1的TWT Element称为broadcast TWT element。

6, Negotiation Type subfield确定对TWT element的目标唤醒时间子字段，TWT唤醒间隔尾数和TWT唤醒间隔指数子字段（Target Wake Time, TWT Wake Interval Mantissa and TWT Wake Interval Exponent）的解释，如Table 9-296a。

TWT Element – TWT Parameter Information字段

TWT Element的Control field中的Negotiation Type subfield的值决定了TWT Parameter Information字段是什么格式（individual TWT Parameter Set field或者Broadcast TWT Parameter Set field），并且决定了它俩内部的 “ Target Wake Time field ” 和 “ TWT Wake Interval Mantissa and TWT Wake Interval Exponent ” 的内容。

1, 如果Control字段中的Broadcast subfield为0，则TWT Parameter Information field包含a single Individual TWT Parameter Set field。

2, 如果Control字段中的Broadcast subfield为1，则TWT Parameter Information field包含one or more Broadcast TWT Parameter Set fields。存在的个数由Request Type fields内的Last Broadcast Parameter Set subfields 的值决定。

3, 下图，0–00，1–01，2–10，3–11 （顺序为B3 B2）

TWT requesting STA/TWT scheduled STA & TWT responding STA/TWT scheduling AP概念区分：
A STA that transmits a TWT element with the TWT Request subfield equal to 1 is a TWT requesting STA or TWT scheduled STA. Otherwise, it is a TWT responding STA or TWT scheduling AP。

这里标准还未总结完，有时间继续，接下来简单介绍一下TWT具体机制。

TWT节能机制简介（Target Wake Time）
TWT定时唤醒机制（Target Wake Time，TWT）首次出现在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的三种工作模式
TWT一共有三种工作模式，分别是：
1）Individual TWT，
2）Broadcast TWT，
3）Opportunistic PS。

Individual TWT

该模式下终端会和AP协商特定的TWT时间，该时间会被存放在AP的时间表中。终端会在特定的时间醒来并和AP进行帧交换。每一个终端仅仅知道自己和AP协商的TWT时间，不需要知道其他终端的TWT时间。

其大致工作流程如下：

1, 终端想要建立一个TWT连接，其会将自己的节能调度信息告知给AP
2, AP将会分配TWT周期，并将该周期反馈给终端
3, 终端会在指定的TWT周期时苏醒，并和AP进行数据帧交换
4, 在本轮交换中，会分成显式和隐式两种工作模式
   

显式工作模式(announced?)
5, 在本次数据帧交换中，AP会显式告诉终端下一轮的TWT周期
6, 终端会在新的指定的TWT周期时苏醒，并再一次和AP进行数据帧交换
   

隐式工作模式(unannounced?)
7, 在本次数据帧交换中，AP不会告诉终端下一轮的TWT周期
8, 终端会自己计算出下一轮的TWT周期（通过在当前TWT周期上增加一个特定的时间）
9, 终端会在自己计算的TWT周期时苏醒，并再一次和AP进行数据帧交换。

如上图所示，

1, 终端会在苏醒的时候，首先和AP发起一个TWT建立请求，终端和AP协商一个TWT时间（即图中Negotiate a schedule），当协商完成后，终端就进入睡眠状态。
2, 在该图上，AP发送Beacon时，也会包含了公开的TWT信息，在Individual TWT工作模式下，Beacon中的该信息终端是不需要的。终端一直保持睡眠状态，直到TWT时间到达。
3, 终端苏醒，并接收AP的触发帧，即TWT Trigger。当终端接收到该触发后，其会和AP进行数据帧交互。与此同时，AP会告知终端下一次的TWT时间（在显式TWT中，睡眠间隔的逐次设定的），终端会在新的TWT时间上，定时苏醒，并执行数据帧交换。
4, TWT的一次苏醒间隔有可能是小于一个beacon周期，也有可能是大于一个beacon周期的，相比于传统的PSM，APSD之类的节能方式，更加具有一般性。
5, 终端和AP可以关于TWT时间周期进行协商，终端可以要求取消TWT参数，或者向AP请求特定的TWT时间。如果AP同意终端的请求，其会反馈“Accept TWT”。还有多种协商的具体参数，可以参考上图，即协议中的Table 10-19a。

Broadcast TWT

1, 广播TWT机制是一种由AP负责管理的工作机制。在该机制下，TWT时间周期是由AP宣告，通常AP会在每一个beacon帧中宣告本轮的TWT时间周期。在一些特殊的情况下，AP也会在其他的管理帧中宣告，比如Association帧，Reassociation帧或者Probe Response帧等等。

2, 我们需要注意在Broadcast TWT中，存在加入组和离开组的交互动作，终端需要向AP申请加组才可以执行Broadcast TWT，这个加组交互动作也是通过在终端和AP交换管理帧中通过携带TWT elements完成的。

3, 当终端完成加组后，终端会按照最近接收到的TWT时间周期进行工作，此时这一类型的终端也被叫做“TWT Scheduled STA”，AP被称为“TWT Scheduling AP”。

4, 终端在TWT时间周期到达后进行苏醒，AP会发送广播的触发帧，发现哪些终端正在处于苏醒状态（加组后的终端们），并向这些终端发送数据帧，这里由于是广播通信，所以只有AP向节点发送。

5, 当AP发送完成后，终端恢复到睡眠状态，直到下一次广播TWT时间到达。通常，这种广播TWT中的时间间隔，我们也称为“TWT SP (Service Period)”。

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

Opportunistic PS：

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

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

————————————————
版权声明：本文为CSDN博主「落霞岛•ェ•」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_33307581/article/details/111352579