TWT：一个让WiFi6更省电的特性
TWT：一个让WiFi6更省电的特性
Wi-Fi 6作为新一代的无线网络标准，不仅带来了更快的传输速度，还在节能方面进行了重大改进。其中，TWT（目标唤醒时间）特性是Wi-Fi 6节能机制的重要组成部分，它通过优化设备的唤醒和休眠机制，显著降低了设备的功耗。本文将详细介绍TWT的工作原理、关键特性和具体应用场景。
在Wi-Fi 6之前，已经存在一些节能特性，如PSM（省电模式）、PSMP（省电多播）、APSD（自动省电交付）。这些机制通常在一个Beacon周期内，终端会观察AP是否向其发送数据。如果需要数据传输，终端会保持等待状态，直到接收完成后再进入休眠模式。这种机制对于业务量较低的终端（如智能电表）来说并不公平，因为它们可能需要长时间等待，导致不必要的电量消耗。
Wi-Fi 6引入的TWT（目标唤醒时间）特性旨在解决这一问题，通过优化设备的唤醒和休眠机制，显著降低设备功耗，特别是在IoT设备和移动设备上。以下是TWT特性的一些关键点：
节能：TWT允许设备与接入点（AP）协商一个特定的唤醒时间，以便在预定的时间进行数据传输。在非唤醒期间，设备可以关闭其Wi-Fi功能，从而节省电池电量。
减少干扰：通过减少设备唤醒的时间，TWT有助于减少网络中的干扰，因为设备不会在不需要的时候占用信道。
提高网络效率：TWT使得网络能够更有效地管理设备的通信时间，从而提高整体网络的吞吐量和效率。
适用于IoT：TWT特别适合于IoT设备，这些设备通常需要长时间运行在电池供电下，且数据传输需求较低。例如，智能电表和传感器等设备可以从TWT中受益。
单播和广播TWT：TWT分为单播TWT和广播TWT。单播TWT用于点对点通信，而广播TWT用于一对多的通信场景。
降低功耗：据报道，TWT最多可以降低三分之一的Wi-Fi功耗，这对于延长移动设备的电池寿命至关重要。
与Beacon帧的关系：在TWT协议下，设备不需要定期接收Beacon帧，而是在更长的周期内唤醒。这减少了网络的信令开销，提高了网络的稳定性。
在TWT中，终端和AP之间建立了一张时间表（该时间表是终端和AP协定的），时间表是由TWT时间周期所组成的。通常终端和AP所协商的TWT时间周期包含一个或者多个beacon周期（总体时间比如几分钟，几小时，甚至高达几天）。
当终端和AP所协商的时间周期到达后，终端会醒来，并等待AP发送的触发帧，并进行一次数据交换。当本次传输完成后，返回睡眠状态。每一个终端和AP都会进行独立的协商，每一个终端都具有单独的TWT时间周期。
AP也可以将终端们根据设定的TWT时间周期进行分组，一次和多个终端进行连接，从而提高节能效率。
TWT一共有两种工作模式，分别是：
- Individual TWT
- 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时间周期性苏醒和接收数据，以实现高效的广播通信。