802.11ax TWT详解2

Posted 2022-10-15 爱吃蛋挞的Dolly

学习转载：https://blog.csdn.net/qq_33307581/article/details/111826899
参考文献 802.11ax Draft 8.0

TBTT（Target Beacon Transmission Time）：信标预定传送时间，类始于现在是几点，实际上这个是一个定时后的发送/接收beacon动作的周期，其周期的时间就是由Beacon Interval所决定的。当TBTT时间到达的时候，AP会主动发送beacon帧，而节点也都会主动接收该beacon帧（包括休眠模式的节点，也会苏醒过来接受该beacon），然后利用beacon进行时间同步，并且查看TIM字段，若没有自己的数据缓存，那么节点继续转为休眠模式，直到下一个TBTT时间到来。
http://www.bubuko.com/infodetail-2439083.html关于相关概念可参考此文章。

802.11ax TWT

说在前面：本文说的Individual TWT虽然包括STA–STA之间、STA–AP之间的协议；但是，偏重于STA–AP之间建立的individual TWT ahreement。

TWT机制中，通信双方严谨的名称，indivudual TWT：TWT requesting STA、TWT responing STA；broadcast TWT：TWT scheduing AP、TWT scheduled STA。 但是为了方便，下文如果提到AP和STA，就默认STA是TWT requesting STA或者TWT scheduled STA； AP是TWT responing STA或者TWT scheduling AP。

简介

802.11ax中的TWT分为两种：individual TWT和broadcast TWT。

individual TWT是建立在两个设备之间的协议，即individual TWT agreements，（例如：STA-AP，STA-STA（TDLS）），目前有be的提案提到希望可以将TWT推广到peer-to-peer STA。（参考802.11be提案，提案号为1046）。

broadcast TWT是由HE AP统一调度，HE STA可以通过主动申请或者被邀请的方式加入一个broadcast TWT（一个broadcast TWT由一个<Broadcast TWT ID，MAC address>元组唯一标识），成为其成员，然后在特定时间苏醒，进行帧交换。

TWT能力支持字段

TWT Requester Support subfield； TWT Responder Support subfield； Broadcast TWT Support subfield 这三个字段都是在HE Capabilities element元素中的，所以是在管理帧中存在的。它们表明此HE STA（重点注意：需要是HE STA）在individual TWT和broadcast TWT中可以扮演的角色。前两个用在indiviual TWT agreement；最后一个用在broadcast TWT中。

在一个STA/AP发送的帧中，只要Broadcast TWT Support sufield被设置为1就代表此STA/AP支持broadcast TWT；并且如果是HE STA，那就是扮演TWT scheduled STA角色；如果是HE AP，那就是扮演TWT shceduling AP的角色。

1. HE AP会向与其关联、并且已经宣布支持TWT的STAs请求其参加TWT机制。其实这里用“请求”这个词不是很合适，我觉得应该“通知”更好，即HE AP将HE Operation element中的TWT Required subfield设置为1来通知STA：“我（AP）支持你（STA）和我建立TWT（individual TWT或者broadcast TWT）”
2. non-AP STA通过TWT Requester Support subfield和Broadcast TWT Support sufield来表明自己可以扮演TWT Requesting STA（individual TWT）和TWT scheduied STA（broadcast TWT）的角色；
3. 当以上两个信息通过管理帧在AP和STA之间沟通完后，STA就可以和AP建立indvidual TWT agreement或broadcast TWT。

涉及到的元素和字段

Conrol field字段中的Negotiation Type字段是指示要建立Individual TWT还是Broadcast TWT。其中Bit3叫做Broadcast field，当它为1时，代表是Braodcast TWT；为0时，代表是Individual TWT。

1. 00：代表这个TWT element中仅包含一个indiviual TWT parameter set；
2. 01：代表这个TWT element中仅包含一个indiviual TWT parameter set；
   不同之处在于，不同值情况下，Target Wake Time field和TWT Wake Interval Mantissa、TWT Wake Interval Exponent fields三个字段的设置不同；具体可以看Draft 8.0 Page184。
3. 10：代表这个TWT element包含一个或者多个broadcast TWT parameter sets；（TWT scheduling AP利用此设置来向TWT scheduled STA提供broadcast TWT schedules）
4. 11：同上。（TWT scheduling AP和TWT scheduled STA利用此设置来管理broadcast TWT内的成员关系，比如加入和退出）

Individual TWT

Individual TWT中通信双方分别叫做：TWT requesting STA和TWT responing STA。

individual TWT agreement可分为两种：implicit TWT agreement和trigger-enabled TWT agreement（trigger-enabled TWT agreement的TWT responding STA一定是HE AP）。
Draft主要讲的是Trigger-enabled TWT agreement，所以下面的内容基本都是在trigger-enabled TWT agreement的前提下说的。

一个individual TWT的示例

下图是一个trigger-enabled TWT agreement的例子：

1. TWT responsing STA是HE AP，其在TWT response中告知TWT requesting STA其接受individual TWT agreement的建立，并且告知STA下一次TWT开始的时间，然后STA在对应的时间苏醒；

2. STA2和AP建立individual TWT agreement的方式是通过TWT responing AP主动发送unsolicited TWT response的方式；此TWT response的TWT Setup Command field可能有以下几种value：accept TWT, Alternate（备用） TWT 或者 Dictate（命令、指挥） TWT；
   2.1 带有Alternate TWT or Dictate TWT的unsolcitied TWT response会告知STA “我AP很可能接受的TWT parameter”，接下来你（STA）发送的TWT request如果带有这些TWT parameter，那么我AP应该会接受；
   2.2 带有Accept TWT的unsolicited response 代表AP接受你（接收者STA）和我建立individual agreement，接下来就看你的意思了，你接受就建立，不接受就发一个TWT Teardown Frame来拒绝。

3. 然后TWT responing STA（即，AP）在trigger-enabled TWT SP时期内发送Trigger帧；（通过将Trigger子字段设置为1来设置一个Trigger-enabled TWT）
   3.1 这里要注意的一点，这里直接说的是AP在TWT SP开始时向STA发送Trigger，而未说明AP是如何获取这个TXOP的。

4. 接收到Ttigger帧后，TWT requesting STA利用一个帧（这里是PS-Poll帧和Qos Null帧）来告知响应STA其已苏醒；
   4.1 注：以下内容同样适合broadcast TWT；
   4.2 TWT requesting STA要向TWT responing STA发送“已苏醒指示”，就代表这个TWT SP是一个announced TWT SP，announced TWT SP的意思是：在TWT responing STA要向TWT requesting STA发送帧之前，它要先接收到“苏醒指示”。与之对应的是unannounced TWT SP，这种情况下，TWT requesting STA在TWT SP开始时自动转入awake状态，TWT responing STA在发送帧之前不用等待来自TWT requesting STA的“已苏醒指示”。
   4.3 STA1利用PS-Poll帧来做苏醒指示，就代表STA1是工作在PS mode模式下，当TWT SP是一个announced TWT SP时，在PS mode模式下的STA还可能发送U-APSD帧来表明其苏醒状态；PS mode工作模式下的STA可以侦听Beacon帧，AP可以利用Beacon帧中的TIM element，将对应STA的AID Bit位设置为1，来通知STA有其下行缓存数据，在TWT SP开始后，STA可以申请下行数据的发送（下行数据传输方式）
   4.4 STA2发送的是Qos-Null帧，这是利用其他指示帧来指示其苏醒状态；在Draft中指出，可以用任何指示帧来指示苏醒状态。PS-Poll帧、U-APSD帧是针对PS mode、announced TWT SP的STA来说的
   4.5 这个“苏醒指示”有三个作用：1. 告知AP其已苏醒；2. 作为对AP所发的Trigger帧的响应；3. 请求下行数据
   4.6 在TWT requesting STA表明苏醒状态后，TWT responing STA就应该在不超过TWT SP时间、TWT requesting STA保持awake状态时，尽可能多的向TWT requesting STA发送缓存数据；

5. 然后AP和STA进行帧交互；

6. 交互完成之后，TWT requesting STA进入休眠状态；

7. 至于下一次TWT requesting STA何时苏醒，这里Individual TWT agreement涉及到两种：隐式TWT和显示TWT。这个点在802.11ah中就已经存在
   7.1 隐式TWT：TWT requesting STA通过加上一个固定的值来自行计算下一次苏醒时间；
   7.2 显示TWT：在TWT SP期间进行帧交互的时候，TWT responing STA会显示的告知TWT requesting STA下一次苏醒时间。

关于individual TWT的下行传输

上面已经提到了一个点，即AP利用Beacon帧来告知STA有其下行缓存，然后STA苏醒后利用“苏醒指示”来请求下行数据的发送。

这里补充一点，如果STA工作在active mode模式，那么AP可以在任何时候向STA发送下行数据；如果STA工作在PS mode，那么只要STA是awake状态（无论是在TWT SP之内/之外），那么AP就可以向其发送下行数据。

关于individual TWT的上行传输

首先，协议指出，一个TWT requesting STA不应在协商的TWT SP之外的时间向TWT responding STA发送帧，也不应在trigger-enabled TWT SPs内向TWT responding STA发送未包含在HE TB PPDU内的帧。

但是，上面所说的只是正常情况。当TWT requesting STA有上行数据时，TWT requesting STA会决定要在TWT SP内或外发送哪些帧，并且当TWT requesting STA被建议不要在TWT SP内使用EDCA机制时，TWT requesting STA仍然可能这样做。即，如果STA决定进行上行传输，则STA可能会争夺对信道的访问，并且可能会竞争到TWT SP之外的信道，然后进行上行传输。

trigger-enable TWT的上行传输

trigger-enabled TWT agreement下的TWT responding STA必须在每个TWT SP内为该TWT agreement调度用于TWT requesting STA的Trigger帧；并且此Trigger帧可以用包含TRS Control子字段的、包含在DL MU PPDU中的帧来代替，前提是需要在这个帧中为STA分配足够的上行资源让其来上传它的BSR报告，并且，在接下来发送的Trigger帧中为STA分配足够的资源来让其上传它在BSR报告中报告的上行缓存。
上面所说内容说明了trigger-enable TWT SP中上行传输的方式。

注：关于implicit TWT agreement，Draft中未提到在TWT SP中的传输机制。

一些个人理解

依据802.11提案和Draft 26.8.2开头部分所讲到的内容，有以下个人理解：

现在TWT一般都会用保护机制，即NAV，例如RTS/CTS等等。在这条规则下，如果之前的传输未完成，则TWT SP开始时间可能会有所不同；这将导致延迟的不可预测性和抖动的增加。（即，如果TWT SP已经开始了，但是在其开始前，其他设备的TXOP还未完成，占用了TWT SP时间内的资源。）

所以，包括上面提到的以及下面将要提到的Broadcast TWT，在TWT SP开始时，如果AP要发送Trigger帧，或者RTS/CTS帧，都是需要先获得TXOP的；同样的，TWT SP开始时苏醒的STA想要进行上行数据传输，也是需要先竞争信道的。

对于有上行数据的STA，要么等待Trigger帧的调度，要么自己用EDCA来竞争信道。

broadcast TWT

broadcast TWT的通信双方一定是HE AP和HE STA，分别叫做TWT scheduling AP和TWT scheduled STA。

TWT scheduling AP和TWT scheduled STA都会把HE Capabilities element元素中的Broadcast TWT Support field设置为1来表明自己支持broadcast TWT。

broadcast TWT也有两种：trigger-enabled broadcast TWT和non trigger-enabled broadcast TWT（这种在Draft中未介绍太多）。AP在non trigger-enabled的TWT SP期间不应该安排发送Trigger帧，而应在trigger-enabled的TWT SP期间安排Trigger帧。

STA加入Broadcast TWT成员资格的方式(两种)

1. TWT scheduling AP可以通过向TWT shceduled STA发送一个**（Re）association Response frame**（或称作unsolicited TWT response）（此帧的Negotiation Type subfield被设置为3（即，11），Draft的第9节说过，Negotiation Type subfield的Bit3为Broadcast field字段。当Broadcast subfield为1时，代表此TWT element是一个broadcast TWT element），从而主动将一个STA（此STA需要支持broadcast TWT，支持的方法是将Broadcast TWT Support field设置为1）配置成broadcast TWT schedule成员。
   1.1 此unsolicited TWT response的TWT Setup Command field可能有以下几种 value：accept TWT, Alternate（备用）TWT 或 Dictate（命令、指挥）TWT；
   1.2 带有Alternate TWT or Dictate TWT的 unsolcitied TWT response会告知STA我AP很可能接受的TWT parameter，接下来你STA发送的TWT request如果带有这些TWT parameter，那么我AP应该会接受；
   1.3 带有Accept TWT的unsolicited response代表AP接受你（接收者STA）和我建立 individual agreement，接下来就看你的意思了，你接受就建立（无需发送帧），不接受就发一个TWT Teardown Frame或者一个TWT response。
2. TWT shceduled STA也可以向TWT scheduling AP发送TWT request来申请加入某个broadcast TWT。
   2.1 每一个braodcast TWT由一个<broadcast ID, MAC address>元组来标识，broadcast TWT ID的值为Broadcast TWT ID subfield的值（大于0，等于0有其他意义，具体看Draft）；MAC address是TWT scheduling AP的地址;
   2.2 TWT element分为individual element和broadcast element，由Control field中的Broadcast subfield控制。每种element中都有一个TWT Parameter Information字段，在broadcast TWT Parameter Set field中有一个Broadcast TWT Info子字段。这个子字段中包含Broadcast TWT ID字段。
3. 加入成员和退出成员资格，是要通过AP和STA进行协商的；协商时所交换的帧中的TWT element中的Negotiation Type subfield被设置为3。

建立资格后的TWT调度

Braodcast TWT schedules是由TWT scheduling AP来广播的，所利用的帧的TWT element中的Negotiation Type subfield被设置为2。

用于成员TWT scheduled STAs的broadcast TWT schedules被值大于0的Broadcast TWT ID所标识；用于所有TWT scheduled STAs的 broadcast TWT schedules被值等于0的Broadcast TWT ID所标识。

具体可以看以下例子：

一个broadcast TWT的示例

1. TWT scheduling AP发送一个Beacon帧，在此Beacon帧中会包含一个braodcast TWT element， 此element指示了一个broadcast TWT SP，在此TWT SP内TWT scheduling AP打算向TWT scheduled STAs发送Trigger frames或者DL BUs。(Question1 :Beacon interval：通常100ms，但是可以根据实际情况来设置)
2. 在trigger-enabled TWT SP内，AP向STA1和STA2发送Basic Trigger frame，其中STA1和 STA2要向AP发送一个“指示帧”作为对Basic trigger帧的响应，以指示它们在TWT SP内苏醒。（和上面的individual TWT的trigger-enabled一样）

TWT scheduling AP应该遵循的规则

1. 在TBTT时刻，TWT scheduling AP会发送一个包含broadcast TWT element的 Beacon帧。这个TWT element可能包含一个或者多个TWT parameter sets，每一个参数集会指示一个周期性的TWT。TWT scheduled STA可以选择一个broadcast TWT申请加入。
   1.1 那么如何知道一个TWT Parameter之后是否还有呢？答：Broadcast TWT Parameter Set field的Request Type中有一个Last Broadcast Parameter Set subfield，通过它来控制；
   1.2 多个TWT parameter sets的作用：每个TWT参数集指定一个特定broadcast TWT，它会在这个broadcast TWT SP内生效。例如：通知下一次苏醒时间（Target Wake Time）、Flow Type（announced和unannounced）等等。
2. TWT scheduling AP将Trigger field设置为1，以指示一个trigger-enabled（TWT scheduled STA也会这样做）。否则，它将Trigger field设置为0（即，the TWT is not a triggerenabled TWT）。Trigger field的路径是Broadcast TWT parameter Set field–>Request Type subfield–>Trigger subfield。
3. 在一个trigger-enabed TWT SP期间，TWT scheduling AP会发送一个Trigger frame（其寻址可能是一个或者多个TWT scheduled STAs）；除此之外，（这一段和individual TWT内一样）这个帧可能会被带有TRS Control subfiled的、包含在DL MU PPDU的帧所替代，并且AP应该为 STA分配足够的资源让其上传其 BSR（此BSR是对DL MU PPDU的响应）。并且后续还要分配足够的资源让此STA上传其BSR内所指的内容。
4. 在一个trigger-enabled TWT SP期间，TWT scheduling AP应该尽可能多的在非零Broadcast TWT ID成员TWT scheduled STAs之间轮询，从而使得STA可以与AP进行帧交换；
   4.1 不清楚的点：为什么是轮询，AP是通过哪个字段来指定STAs上报BSR的??（User Info field？还是AID？这点未说明，待查）
5. 当在一个broadcast TWT SP期间发送的Trigger frame中的Broadcast TWT Recommendation subfield的值为0或3时，AP可能会分配0或多个RA-RUs； 当其值为1时，AP不会分配RA-RU。
6. 在一个announced TWT SP期间，当一个TWT scheduling AP收到来自一个工作在PS mode下的TWT scheduled STA发来的、指示其会在TWT SP内苏醒的指示时， AP应该向该STA发送尽量多的 buffered BUs。
   6.1 PS mode、unannounced TWT SP期间，AP也应该尽量多的向TWT shceduled STA发送buffered BUs；
   6.2 尽量多的意思：所发送的BU不超过TWT SP；TWT scheduled STA未进入休眠状态。
7. TWT scheduling AP可以在任意时刻向工作在active mode下的TWT scheduled STA发送帧；也可以向工作在PS mode下、但是在TWT SP时间外还处于awake状态的STAs发送帧。

TWT scheduled STA应该遵循的规则

1. TWT schedlued STA不应该在broadcast TWT SPs时间段之外向TWTscheduling AP发送帧 ；在trigger-enabled broadcast TWT SPs内，TWT scheduled STA不应该向TWT schedling AP发送未包含在HE TB PPDUs内的帧。
   1.1 上面说的只是建议，这段NOTE所说的意思是，尽管你建议我TWT scheduled STA不要在TWT SP之内/之外采用EDCA机制竞争信道。但是如果我STA想要进行上行传输，我还是可能这样去做。
2. 一个TWT scheduled STA申请加入broadcast TWT时（申请成员资格时）以及退出成员资格时，所需要发送的帧的字段设置在Page425。 STA会利用Broadcast TWT Parameter Set field–>Broadcast TWT Info–>Broadcast TWT ID子字段来表明其想要加入哪一个broadcast TWT；
   2.1 个人理解：前面在TWT scheduling AP处说过，AP会在Beacon帧包含多个TWT Parameters，那么多个TWT Parameter就会有多个Broadcast TWT ID，所以可以供STA来选择；
   2.2 一个TWT scheduled STA可以同时加入多个broadcast TWTs。
3. AP主动发送邀请帧的字段设置如下：只要一个TWT scheduled STA收到了一个 TWT element，其中TWT Request field =0、Negotia-tion Type subfield=3、TWT Setup Command field=Accept TWT，那么此STA就变成了此TWT element中所包含的 Broadcast TWT ID所标识的broadcast TWT的成员。但是，它可以通过发送“拒绝帧”来从中退出。
4. 工作在PS mode模式下的TWT scheduled STA在接收到一个Beacon frame（此Beacon帧带有一个TWT element，此element向STA指示了一个broadcast TWT的信息，例如何时开始等等）之后，会进入休眠模式； 然后，TWT scheduled STA会在broadcast TWT SP开始的时候苏醒，因为STA已经指示过它将会在此时苏醒。指示的方式有四种（Page427）
5. STA可以通过一个TWT Informationg frame来告知AP其在某个broadcast TWT开始时间不会苏醒；
   5.1 AP也可能通过一个TWT Informationg frame来告知STA在某个broadcast TWT期间不用苏醒。
6. 一个TWT scheduled STA在以下条件下，不会在TBTT时刻接收Beacon frame：
   6.1. STA已经收到了其所期待的Beacon帧（其中包含了一个TWT element，并且此element指示了一个broadcast TWT）
   6.2. 不接收的Beacon所对应的TBTT是 在最新接收到的Beacon帧（其中 包含了一个TWT element，并且此element指示了一个broadcast TWT）之后的下n个TBTT内;其中n等于1+Broadcast TWT Persistence subfield的值。（持久性）
7. 上面提到过很多次，在announced TWT SP期间，PS mode工作模式下的 TWT scheduled STA会利用两种帧来宣布自己的苏醒状态。这里添加以下两点：
   7.1. 这里TWT scheduled STA所发送的帧也叫做Trigger帧，利用的是 HE TB PPDU；但是此Trigger帧和AP发送的Trigger是不是一类， 还不确定；
   7.2. 发送此“苏醒帧”的目的是向AP请求下行缓存。
   NOTE-- 一个TWT scheduling AP如果想让某个TWT scheduled STA来 请求下行缓存，AP会将Beacon frame中的TIM element中的对应于此STA的AID的bit位设置位1，以此来通知这个STA。