第三章 电源管理与传入动作帧唤醒处理流程

在设备进入低功耗状态（Dx 状态）之前，操作系统会根据当前激活的 QoS 功能（如 MSCS 或 QoS 映射）向驱动程序下发相应的传入动作帧唤醒卸载（offload）请求。驱动程序必须正确配置硬件过滤器，使设备在低功耗状态下仍能监测特定动作帧，并在匹配时触发唤醒。

3.1 进入 Dx 状态前的配置

当操作系统决定将设备转入 Dx 状态时，它会通过 WiFiCx 框架向驱动程序传递一组唤醒模式（Wake Pattern）。每个模式对应一种动作帧的匹配规则，例如：

• - 对于 MSCS：匹配包含 MSCS 响应帧标识的动作帧。
• - 对于 QoS 映射：匹配包含 QoS 映射配置动作帧标识（或关联响应中的映射元素）的帧。

驱动程序必须将 OS 下发的每个模式转化为硬件可识别的过滤器，并加载到固件中。如果 OS 请求的模式数量超出固件能力（由 `MaxNumConfigurableActionFrameWakePatterns` 限定），则 OS 会提前禁用相关功能，因此实际下发的模式数不会超过该限制。

需要注意的是，某些平台可能支持多个 NETADAPTER（例如主 Wi‑Fi 接口和辅助 Wi‑Fi 接口），每个适配器可能独立进入 Dx 状态。此时，OS 可能为每个适配器分别配置唤醒模式，而驱动程序需要管理每个适配器各自的过滤器，并确保不同适配器之间的模式互不冲突。

3.2 在 Dx 状态下接收动作帧

当设备处于 Dx 状态（如 D3 热或 D3 冷）时，硬件保持最低限度的电路活动以监听无线介质。一旦接收到一个 802.11 动作帧，硬件会提取帧内容，并与先前加载的唤醒模式过滤器进行比对。如果帧内容匹配某个已卸载的模式（例如，帧类别和字段与 MSCS 响应或 QoS 映射配置一致），则硬件必须立即发起唤醒信号，将设备从 Dx 状态唤醒至工作状态（D0）。

唤醒动作应尽量快速，以避免丢失后续数据包。硬件设计应保证从帧匹配到系统可响应的时间在可接受的毫秒级范围内。驱动程序无需在唤醒过程中执行额外的模式匹配验证，因为硬件已经完成了匹配判定；但驱动程序在接收唤醒指示后，应保留原始动作帧的内容，以便后续上报给 OS。

3.3 唤醒上报与动作帧指示

唤醒发生后，驱动程序必须使用 `WifiAdapterReportWakeReason` 函数向操作系统报告唤醒原因，并将原因类型指定为 `WifiWakeReasonTypeIncomingActionFrame`。同时，驱动程序必须通过 `NDIS_STATUS_WDI_INDICATION_ACTION_FRAME_RECEIVED` 状态指示，将实际接收到的动作帧内容完整地上报给 OS。OS 收到该指示后，会解析动作帧，并根据其类型执行相应的 QoS 更新处理（例如更新映射表或处理 MSCS 会话变更）。

上报动作帧的时机至关重要：驱动程序应在唤醒完成后、处理任何其他数据包之前，首先上报该动作帧，以确保 OS 能第一时间响应 QoS 配置变化。如果在上报之前有其他数据包干扰，可能导致 QoS 状态不一致。

3.4 退出 Dx 状态后的稳定处理

完成唤醒上报后，设备即完全进入 D0 工作状态，OS 会重新接管所有正常的 Wi‑Fi 数据收发和管理流程。驱动程序应清除已匹配的唤醒模式过滤器，或者保持其存在以备下次进入 Dx 状态时复用（具体取决于 OS 的配置策略）。通常情况下，OS 会在每次进入 Dx 时重新下发唤醒模式，因此驱动程序无需永久保存模式，只需在下次配置时覆盖即可。

若设备因其他原因（如用户活动或计时器）被唤醒，而非由传入动作帧触发，驱动程序不应上报 `WifiWakeReasonTypeIncomingActionFrame`，以免误导 OS 执行不必要的 QoS 处理。

3.5 错误处理与兼容性

如果硬件在 Dx 状态下检测到动作帧但无法成功匹配或唤醒，驱动程序应记录错误事件（通过 WPP 或 ETW 日志），并在下次唤醒后向 OS 报告链路状态异常。此外，驱动程序应支持在运行时动态调整唤醒模式，因为 OS 可能在设备处于 D0 状态时启用或禁用 QoS 功能，并相应更新唤醒模式集。硬件固件应支持在不重启设备的情况下添加或删除过滤器。

总之，传入动作帧唤醒是连接 QoS 策略与电源管理的桥梁，其实现质量直接影响到 Windows 系统在 Wi‑Fi 场景下的综合性能和功耗表现。驱动程序开发者应投入充分的测试，验证在各种低功耗状态（包括 S0 低功耗空闲、S3 睡眠、S4 休眠等）下唤醒的可靠性，以及不同 QoS 功能组合场景下的模式管理正确性。