4. 协议栈排查：Beacon间隔、监听间隔、PS-Poll机制、U-APSD配置、802.11ax TWT
协议栈这一层，说白了就是Wi-Fi的“交通规则”。功耗高不高，很多时候不是硬件不行，而是设备跟AP之间没商量好“什么时候说话、什么时候闭嘴”。我排查过不少案子，硬件功耗数据看着挺好，一抓空口包发现设备一直在瞎忙活——该睡的时候不睡，不该醒的时候乱醒。
这一章我们聚焦五个关键参数：Beacon间隔、监听间隔、PS-Poll、U-APSD和TWT。它们直接决定了设备在省电模式下的行为。
4.1 Beacon间隔：AP的“心跳”频率
Beacon是AP定期广播的信标帧，里面带了时间戳、能力信息、DTIM计数等。设备靠它同步时钟、判断要不要醒来收数据。
- 标准间隔：默认100 TU（102.4 ms）。大部分AP出厂就是这个值。
- 长间隔：有些AP支持200 TU、300 TU甚至500 TU。间隔越长，AP发包越少，设备可以睡更久。
- 短间隔：游戏路由或低延迟场景可能设50 TU甚至25 TU。设备醒得更频繁，功耗自然上去。
关键结论：Beacon间隔每翻一倍，设备理论待机功耗可降低约15%-25%。但代价是时间同步精度下降，漫游响应变慢。
我遇到过一款智能门锁，待机功耗死活降不下来。抓包发现AP的Beacon间隔是50 TU，门锁每50ms就得醒来一次处理Beacon。跟客户商量后把AP改成200 TU，待机电流直接从2.1mA降到1.3mA。嗯，有时候问题就这么简单。
4.2 监听间隔：设备决定“多久听一次”
监听间隔（Listen Interval）是设备告诉AP的：“我每N个Beacon才醒来一次，你有缓存数据就在对应的DTIM Beacon里通知我。”
这个值在关联请求帧里协商。设备设得越大，睡的时间越长，但数据延迟也越大。
| 监听间隔 | 典型场景 | 功耗表现 | 延迟代价 |
|---|---|---|---|
| 1 | 实时音视频、游戏 | 高（每100ms醒一次） | 低（<100ms） |
| 3-5 | IoT传感器、智能家居 | 中等 | 300-500ms |
| 10-20 | 电池供电的温湿度计 | 低 | 1-2秒 |
我的调试习惯：先设监听间隔=3做功能验证，确认AP能正常缓存数据。再逐步加大到5、10、20，每步测一次功耗和延迟。不要一上来就设20，万一AP不支持长间隔缓存，丢包了你还得回头查。
4.3 PS-Poll机制：经典的“睡醒取件”模式
PS-Poll是802.11省电模式的基础。设备醒来后发一个PS-Poll帧给AP，AP收到后把缓存的下行数据发下来。流程大致这样：
- 设备睡眠，AP缓存发往该设备的数据。
- 设备在DTIM Beacon时刻醒来，检查TIM字段是否有自己的位被置1。
- 如果有数据，设备发PS-Poll帧请求数据。
- AP回复数据帧（可能分多帧）。
- 设备收完数据，发Null Data帧通知AP“我要睡了”，然后再次进入睡眠。
这个机制的问题在于：每次取数据都要来回握手，效率不高。如果AP缓存了多个小包，设备得发多次PS-Poll，每次都要等ACK，功耗浪费在空口交互上。
我曾经踩过的坑：有个项目用PS-Poll模式，设备每30秒上报一次数据，功耗却比预期高了40%。抓空口日志发现，AP把一次上报的3个小包分成了3次PS-Poll交互。后来改成U-APSD，一次触发就把3个包全拉下来，功耗直接降了30%。
4.4 U-APSD配置：更聪明的“一键取件”
U-APSD（Unscheduled Automatic Power Save Delivery）是802.11e引入的增强省电机制。它允许设备通过发一个QoS Data帧或QoS Null帧来触发AP一次性下发所有缓存数据，不需要反复发PS-Poll。
配置U-APSD时，主要关注两个参数：
- Delivery Enabled：哪些AC（接入类别）启用U-APSD。通常BE（Best Effort）和BK（Background）都开，VI（Video）和VO（Voice）看场景。
- Trigger Enabled：设备是否允许用数据帧作为触发帧。开的话，设备发上行数据时顺便把下行数据也拉下来，省一次交互。
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| Delivery Enabled | AC_BE + AC_BK | 数据类业务启用U-APSD |
| Trigger Enabled | AC_BE + AC_BK | 允许数据帧触发下行传输 |
| Max SP Length | 2或3 | 一次触发最多收几帧，设太大可能延迟其他设备 |
核心差异：PS-Poll是“问一次拿一个”，U-APSD是“问一次拿一堆”。对于小包频繁的场景，U-APSD能减少50%-70%的空口交互次数。
4.5 802.11ax TWT：精确到微秒的“预约睡眠”
TWT（Target Wake Time）是802.11ax（Wi-Fi 6）最重要的省电特性。它让设备和AP协商一个精确的唤醒时间表，设备只在约定的时间窗口醒来，其他时间深度睡眠。
TWT有两种模式：
- Individual TWT：设备跟AP一对一协商，每个设备有自己的唤醒时间。适合IoT设备。
- Broadcast TWT：AP广播一个公共的唤醒时间表，多个设备共享。适合大批量传感器。
配置TWT时，关键参数有：
| 参数 | 含义 | 典型值 |
|---|---|---|
| Wake Interval | 两次唤醒之间的间隔 | 1秒、5秒、30秒 |
| Wake Duration | 每次唤醒后保持清醒的时间 | 10ms-50ms |
| Target Wake Time | 第一次唤醒的绝对时间 | 由AP计算并分配 |
我个人的经验：TWT的功耗收益非常可观。一个温湿度传感器用传统省电模式，待机电流约500μA；开启TWT后（唤醒间隔5秒，持续20ms），待机电流降到80μA。但要注意，TWT需要AP和STA都支持802.11ax，而且有些老AP虽然标了Wi-Fi 6，TWT实现有bug，得实测验证。
4.6 知识体系总览
下面这张图把五个协议栈参数的关系串起来了。你可以看到，从Beacon间隔到TWT，省电粒度越来越细，配置也越来越灵活。
4.7 排查清单与避坑指南
最后给一份实战排查清单，你排查功耗问题时可以逐项核对：
- 抓Beacon帧：确认AP的Beacon间隔是否跟预期一致。有些AP虽然配置了100 TU，实际发包间隔有抖动。
- 检查关联请求：确认设备上报的监听间隔是否被AP接受。AP有权修改这个值，抓关联响应帧看最终协商结果。
- 统计PS-Poll次数：用空口抓包工具统计单位时间内PS-Poll帧的数量。如果每秒超过5次，说明U-APSD没生效或者配置不对。
- 验证U-APSD协商：在ADDTS请求/响应帧里确认Delivery Enabled和Trigger Enabled的AC位图是否正确。
- 测试TWT建立：发TWT Setup帧，确认AP回复TWT Setup Response的状态码是0（成功）。如果AP返回拒绝，检查AP固件版本。
我曾经踩过的坑（续）：有个项目在实验室测TWT功耗数据非常漂亮，一上现场就崩了。排查发现现场AP是某厂商的早期Wi-Fi 6产品，TWT实现有bug——设备发TWT Setup后AP虽然回复成功，但实际根本不按约定时间唤醒设备。最后只能降级用U-APSD。所以，TWT一定要做兼容性测试，别信AP的规格书。
协议栈排查这块，说白了就是让设备和AP“约法三章”。Beacon间隔定节奏，监听间隔定睡多久，PS-Poll和U-APSD定怎么取数据，TWT定什么时候醒。把这五个参数调明白了，功耗问题至少能解决一半。