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

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

引用

CSDN

1.

https://blog.csdn.net/zhfcmx1/article/details/136961787

随着Wi-Fi 6的普及，其节能特性TWT（目标唤醒时间）越来越受到关注。本文将详细介绍TWT的工作原理、优势以及具体实现方式，包括Individual TWT和Broadcast TWT两种模式。

在Wi-Fi 6之前，已经有不少节能特性，如PSM（Power Save Mode）、PSMP（Power Save Multi-Poll）、APSD（Automatic Power Save Delivery）。在一个 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时间。

其大致工作流程如下：

1. 终端想要建立一个TWT连接，其会将自己的节能调度信息告知给AP
2. AP将会分配TWT周期，并将该周期反馈给终端
3. 终端会在指定的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时间周期性苏醒和接收数据，以实现高效的广播通信。