# Target Wake Time(TWT)详解 TWT(Target Wake Time,目标唤醒时间)是 WiFi 6 引入的革命性省电机制。它允许 AP 和客户端协商精确的唤醒时间表,使客户端在不需要通信时进入深度睡眠状态。 ## TWT vs 传统省电模式 ### 传统 PS-Poll / uAPSD ``` STA 必须定期醒来检查 Beacon: Beacon周期 (通常100ms): │👁️😴😴😴😴😴😴😴😴😴│👁️😴😴😴😴😴😴😴😴😴│👁️... ↑ ↑ ↑ 检查 TIM 检查 TIM 检查 TIM 问题: ├── 频繁唤醒 → 射频无法深度睡眠 ├── 所有 STA 同时醒来 → 信道竞争加剧 └── 无数据时仍然浪费电量 ``` ### TWT 模式 ``` 协商好的唤醒时间表: STA_A: │😴😴😴😴😴│👁️📥│😴😴😴😴😴😴😴😴😴😴😴😴😴😴😴│👁️📥│ T=0 T=1000ms T=2000ms STA_B: │😴😴😴😴😴😴😴😴😴😴😴😴😴│👁️📥│😴😴😴😴😴😴😴😴│👁️📥│ T=1500ms T=3000ms STA_C: │😴😴😴😴😴😴😴😴😴😴😴😴😴😴😴😴😴😴😴│👁️📥│... T=2500ms 优势: ├── 唤醒时间错开 → 无竞争 ├── 深度睡眠时间长 → 省电显著 └── 按需唤醒 → 无数据时不浪费 ``` ## TWT 协商流程 ### TWT Setup Exchange ``` Setup Request (STA → AP): ┌─────────────────────────────────────┐ │ TWT Info Field: │ │ ├─ TWT Type: Individual/Broadcast │ │ ├─ Request Type: Setup │ │ ├─ TWT Wake Interval: 1000 ms │ │ ├─ TWT Window Duration: 50 ms │ │ ├─ TWT Start Time: Now + 500 ms │ │ └─ TWT Desired Remain Awake: 0 │ └─────────────────────────────────────┘ Setup Response (AP → STA): ┌─────────────────────────────────────┐ │ TWT Info Field: │ │ ├─ Request Type: Response │ │ ├─ TWT Wake Interval: 1000 ms ✓ │ │ ├─ TWT Window Duration: 50 ms ✓ │ │ ├─ TWT Start Time: Now + 500 ms ✓ │ │ └─ Status: Success │ └─────────────────────────────────────┘ → TWT Agreement established! ``` ### TWT Operation ``` Service Period (SP): ┌──────────────────────────────────────────┐ │ TWT Wake Interval │ │ ┌──────────────────────────────────┐ │ │ │ Deep Sleep Period │ │ │ └──────────────────────────────────┘ │ │ ┌───────┐ │ │ │ SP │ ← STA wakes up, TX/RX data │ │ └───────┘ │ │ ↑ │ │ TWT Start Time │ └──────────────────────────────────────────┘ SP 内操作: 1. STA 醒来,射频启动(~5ms) 2. TX/RX 数据帧(使用标准 CSMA/CA) 3. SP 结束 → STA 回到深度睡眠 ``` ## TWT 类型详解 ### Individual TWT(个人 TWT) ``` 特点: ├── AP 与单个 STA 私有的协商 ├── 精确的唤醒时间控制 ├── 每个 STA 可以有不同的时间表 └── 适合关键任务 IoT 设备 示例: STA_A: 每 1000ms 醒来一次(传感器上报) STA_B: 每 5000ms 醒来一次(状态检查) STA_C: 每 60000ms 醒来一次(心跳) ``` ### Broadcast TWT(广播 TWT) ``` 特点: ├── AP 在 Beacon/Probe Response 中广播 TWT 时间表 ├── 多个 STA 共享相同的唤醒时间 ├── 无需单独协商 → 减少信令开销 └── 适合大量同类 IoT 设备 Beacon 中的 Broadcast TWT IE: ┌─────────────────────────────────────┐ │ Element ID: 87 (TWT) │ │ Length: variable │ │ Partial AID: Group ID │ │ TWT Temporal Information: │ │ ├─ TWT Wake Interval: 1000 ms │ │ └─ TWT Start Time: ... │ └─────────────────────────────────────┘ 所有属于该 Group 的 STA 在同一时间醒来。 ``` ### Spontaneous TWT(自发 TWT) ``` 特点: ├── STA 在数据帧中附带 TWT Request ├── 无需预先协商 → 即时生效 └── 适合突发数据传输场景 示例: STA 发送 QoS Data + TWT Request in QoS Control field → AP 回复确认 → 临时 TWT SP 建立 ``` ## TWT 参数详解 | 参数 | 范围 | 说明 | |------|------|------| | TWT Wake Interval | 128 μs ~ 2^32 ms | 两次唤醒之间的间隔 | | TWT Window Duration | 0 ~ 2^16 TU | 服务期持续时间 | | TWT Start Time | 64-bit timestamp | 首次唤醒时间 | | Maximum Trigger Time | variable | AP 最晚触发时间 | | Minimum Trigger Time | variable | AP 最早触发时间 | ## TWT 省电效果量化 ### IoT 传感器场景 ``` 设备: 温度传感器,每 5 分钟上报一次数据 传统 PS-Poll: ├── Beacon 监听: 每 100ms 醒来 ~2ms → 平均功耗 2% ├── 射频待机: 98% 时间在低功耗监听模式 └── 电池寿命: ~30 天 TWT (Individual): ├── 深度睡眠: 299.95 分钟完全关闭射频 ├── 唤醒传输: 0.05 分钟 (~3s) TX/RX └── 电池寿命: ~6 个月(提升 12x) TWT (Broadcast, 批量上报): ├── 多个传感器在同一 TWT SP 内上报 ├── AP 批量处理 → 减少信令开销 └── 电池寿命: ~12 个月 ``` ### AR/VR 头显场景 ``` 传统模式: ├── 持续连接,射频始终活跃 ├── 平均功耗: ~2W(WiFi 部分) └── 续航: ~2 小时 TWT + 帧率同步: ├── 视频帧间隔内进入微睡眠(90Hz → 每 11ms 一帧) ├── TWT SP 对齐帧发送时间 ├── WiFi 功耗降低: ~30% └── 续航提升: ~2.5 小时 ``` ## TWT 部署建议 | 场景 | TWT 类型 | Wake Interval | Window Duration | |------|---------|---------------|-----------------| | IoT 传感器(低频) | Individual | 60s - 300s | 100ms | | IoT 传感器(高频) | Broadcast | 1s - 10s | 50ms | | 智能家居设备 | Individual | 10s - 60s | 200ms | | AR/VR 头显 | Spontaneous | N/A (frame-sync) | 动态 | | 手机(待机) | Broadcast | 1s - 5s | 100ms |