TWT：一个让WiFi6更省电的特性

更多精彩内容在公众号。

再wifi6前，已经有了不少节能特性：PSM,PSMP,APSD。在一个 Beacon 周期内，终端 会观察 AP 是否会向其发送数据，如果是，那么终端就保持等待，直到接收完成后， 才会进入休眠模式。这其实对业务量很低的终端相当不公平，例如智能电表这种，可能很久才需要跟 AP 通信一次，大部分时间都要等待，这就造成了终端电量不必要的 消耗。

Wi-Fi 6引入了TWT（Target Wake Time，目标唤醒时间）特性，旨在提高网络效率并降低设备的功耗，特别是对于IoT（物联网）设备和移动设备。以下是TWT特性的一些关键点：

1. 节能：TWT允许设备与接入点（AP）协商一个特定的唤醒时间，以便在预定的时间进行数据传输。在非唤醒期间，设备可以关闭其Wi-Fi功能，从而节省电池电量。

2. 减少干扰：通过减少设备唤醒的时间，TWT有助于减少网络中的干扰，因为设备不会在不需要的时候占用信道。

3. 提高网络效率：TWT使得网络能够更有效地管理设备的通信时间，从而提高整体网络的吞吐量和效率。

4. 适用于IoT：TWT特别适合于IoT设备，这些设备通常需要长时间运行在电池供电下，且数据传输需求较低。例如，智能电表和传感器等设备可以从TWT中受益。

5. 单播和广播TWT：TWT分为单播TWT和广播TWT。单播TWT用于点对点通信，而广播TWT用于一对多的通信场景。

6. 降低功耗：据报道，TWT最多可以降低三分之一的Wi-Fi功耗，这对于延长移动设备的电池寿命至关重要。

7. 与Beacon帧的关系：在TWT协议下，设备不需要定期接收Beacon帧，而是在更长的周期内唤醒。这减少了网络的信令开销，提高了网络的稳定性。

在TWT中，终端和AP之间建立了一张时间表（该时间表是终端和AP协定的），时间表是由TWT时间周期所组成的。通常终端和AP所协商的TWT时间周期包含一个或者多个beacon周期（总体时间比如几分钟，几小时，甚至高达几天）。

当终端和AP所协商的时间周期到达后，终端会醒来，并等待AP发送的触发帧，并进行一次数据交换。当本次传输完成后，返回睡眠状态。每一个终端和AP都会进行独立的协商，每一个终端都具有单独的TWT时间周期。

AP也可以将终端们根据设定的TWT时间周期进行分组，一次和多个终端进行连接，从而提高节能效率。

TWT一共有两种种工作模式，分别是：

1）Individual TWT，

2）Broadcast TWT，

individual TWT

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

其大致工作流程如下：

终端想要建立一个TWT连接，其会将自己的节能调度信息告知给AP

AP将会分配TWT周期，并将该周期反馈给终端

终端会在指定的TWT周期时苏醒，并和AP进行数据帧交换

在本轮交换中，会分成显式和隐式两种工作模式

显式工作模式

在本次数据帧交换中，AP会显式告诉终端下一轮的TWT周期

终端会在新的指定的TWT周期时苏醒，并再一次和AP进行数据帧交换

隐式工作模式

在本次数据帧交换中，AP不会告诉终端下一轮的TWT周期

终端会自己计算出下一轮的TWT周期（通过在当前TWT周期上增加一个特定的时间）

终端会在自己计算的TWT周期时苏醒，并再一次和AP进行数据帧交换。

终端会在苏醒的时候，首先和AP发起一个TWT建立请求，终端和AP协商一个TWT时间（即图中Negotiate a schedule），当协商完成后，终端就进入睡眠状态。

在该图上，AP发送Beacon时，也会包含了公开的TWT信息，在Individual TWT工作模式下，Beacon中的该信息终端是不需要的。终端一直保持睡眠状态，直到TWT时间到达。

终端苏醒，并接收AP的触发帧，即TWT Trigger。当终端接收到该触发后，其会和AP进行数据帧交互。与此同时，AP会告知终端下一次的TWT时间（在显式TWT中，睡眠间隔的逐次设定的），终端会在新的TWT时间上，定时苏醒，并执行数据帧交换。

TWT的一次苏醒间隔有可能是小于一个beacon周期，也有可能是大于一个beacon周期的，相比于传统的PSM，APSD之类的节能方式，更加具有一般性。

终端和AP可以关于TWT时间周期进行协商，终端可以要求取消TWT参数，或者向AP请求特定的TWT时间。如果AP同意终端的请求，其会反馈“Accept TWT”。还有多种协商的具体参数，可以参考协议中10.47.1

TWT command分以下几种：

Request TWT: requesting TWT STA 不会提供TWT parameter用于协商，而是让responding STA提供parameter

Suggest TWT: requesting TWT STA会提供TWT parameter, 但是仍有可能选择responding STA提供的paramter参数，而且如果responding STA返回Demand TWT, 那么requesting TWT只能采用responding STA携带的参数

Demand TWT: 表示requesting STA只能接收当前指示的twt参数

Accept TWT: responding STA发送，表示responding STA已经初始化了给定的参数

Alternate TWT: 表示双方可以对参数进行协商

Dictate TWT: 表示没有TWT协商创建，但只有当requesting STA发送一个新的twt setup request并带有TWT参数的时候，就采用该参数

Reject TWT: 表示拒绝TWT协商参数需要另外建立协商

TWT 命令交互参考Table10-31a

发送Request TWT, Suggest TWT, Demand TWT.  没有任何回应。则无法建立TWT协商

发送Demand TWT, 回复Accept TWT, TWT协商完成，而且只能用Demand TWT中的参数

发送Suggest TWT或者Request TWT, 回复Accept TWT, TWT协商完成并且使用回复帧中的参数

发送Demand TWT或者Suggest TWT, 回复Alternate TWT. 不建立TWT协商，requesting STA会发送一个新的请求携带TWT参数。Responder有可能采用此参数

发送Demand TWT或者Suggest TWT, 回复Dictate TWT. 表示responder不希望采用requesting STA发送的TWT 参数。RequestingSTA创建一个新的请求。并且只有在收到Accept TWT后才会使用Dictate的参数

发送Demand TWT或者Suggest TWT或者Request TWT,回复Reject TWT, 表示TWT协商失败

Broadcast TWT

广播TWT是由AP（接入点）负责管理的一种工作机制，其中TWT时间周期由AP宣告。终端需要向AP申请加入组才能执行广播TWT，并通过交换管理帧来完成加入组的交互动作。

一旦终端成功加入组，它将根据最近收到的TWT时间周期进行工作。这类终端被称为“TWT Scheduled STA”（计划苏醒终端），而AP被称为“TWT Scheduling AP”（计划调度AP）。

在TWT时间周期到达后，终端苏醒并接收AP发送的广播触发帧。AP会检测哪些终端处于苏醒状态（即加入组的终端），然后向这些终端发送数据帧。需要注意的是，由于这是广播通信，只有AP向节点发送数据帧。

完成发送后，终端恢复到睡眠状态，直到下一次广播TWT时间周期到达。这个广播TWT的时间间隔通常被称为“TWT SP”（服务周期）。

综上所述，广播TWT是一种由AP管理的工作机制，通过在特定的时间周期内让终端苏醒并接收AP发送的广播数据帧，从而实现高效的广播通信。

在Beacon帧中，AP宣告了TWT Broadcast时间周期（即TWT SP时间）。终端在接收到Beacon信息后苏醒，并根据TWT时间到达时刻提前苏醒。

一旦终端苏醒，它会接收AP发送的TWT触发帧和下行数据帧。在此过程中，AP也可能发送新的TWT Broadcast时间周期（即TWT SP时间）。终端接收完成后，进入睡眠状态，并在新的TWT SP时间到达时再次苏醒。

这个过程会循环进行，终端根据TWT SP时间周期性苏醒和接收数据，以实现高效的广播通信。