Zigbee PRO 2017协议栈睡眠终端设备的精准唤醒时序设计

在Zigbee PRO 2017网络中，睡眠终端设备(SED)通过周期关闭射频和MCU实现低功耗，但其唤醒时序并非简单的“定时醒来发送数据”。协议栈要求设备在唤醒后完成射频恢复、父节点同步、轮询/发送、处理下行消息，再回到睡眠。若唤醒窗口过短，可能导致APS ACK、重传或下行命令丢失;若唤醒窗口过长，则显著增加平均电流。因此，精准唤醒时序设计的核心在于协调应用任务、MAC层轮询、协议栈事件和硬件睡眠定时器。

程序框架分析

典型SED程序框架可分为五层：

应用层：负责传感器采样、数据封装、ZCL命令发送和事件调度。

协议栈层：维护网络状态、APS重传、轮询控制和消息缓存。

MAC层：负责向父节点发送Data Request，判断父节点是否有挂起数据。

OS/调度层：通过事件定时器、任务循环和空闲回调决定何时进入睡眠。

硬件层：由RTC、睡眠定时器、低功耗模式(如PM2/EM2/Stop2)提供唤醒源。

以TI Z-Stack/SDK为例，应用层通常使用osal_start_timerEx()或应用定时器产生周期性事件;当系统无待处理事件时，协议栈自动进入低功耗模式。以Silicon Labs EmberZNet为例，SED通过长轮询维持父子关系，在需要响应ZCL消息时进入短轮询或快速轮询模式。以STM32WB为例，M0+核维持协议栈运行，M4核可在无任务时进入Stop2，由RTC或RF事件唤醒。不同平台实现不同，但时序约束一致。

精准唤醒时序设计

SED唤醒时序建议采用“最小唤醒窗口 + 快速轮询保护 + 事件驱动回睡”的策略。

1. 唤醒起点：硬件定时器对齐

应用层不应直接控制底层睡眠寄存器，而应通过协议栈提供的定时器或事件机制设置下一次唤醒。硬件睡眠定时器负责从深度睡眠中唤醒MCU和RF，协议栈再根据当前网络状态决定是否允许睡眠。

2. 射频恢复与网络状态检查

唤醒后首先确认设备仍处于已入网状态。若网络状态异常，应进入重连流程，而不是立即发送应用数据。否则可能出现数据发送失败、父节点不同步或APS层反复重传。

3. 发送上行数据

若本次唤醒目的是上报数据，应在射频稳定后立即发送单播或组播帧。发送完成后，需等待APS ACK或应用层响应。此时设备应进入短轮询模式，以便及时接收父节点可能返回的确认或下行命令。

4. 轮询下行消息

SED必须周期性向父节点发送Data Request，查询是否有挂起消息。Zigbee PRO 2017中，父节点通常仅在收到轮询请求后才向SED转发数据。若应用需要可靠接收下行消息，轮询间隔应小于父节点消息保持时间;例如EmberZNet默认间接传输超时为7.68秒，意味着设备应在此时间内至少轮询一次。

5. 快速轮询超时保护

在发送数据或等待响应的阶段，应启用快速轮询;当没有待处理事务时，切换回长轮询。快速轮询时间不宜过长，通常1～3秒即可覆盖大多数ZCL响应场景。

6. 回睡条件

设备进入睡眠前应满足：无待发送应用事件、无未确认APS帧、无快速轮询任务、协议栈空闲回调允许睡眠。若任意条件不满足，应延长唤醒窗口，而不是强制睡眠。

程序实现要点

使用协议栈定时器而非裸延时：应用层通过事件定时器触发采样和发送，协议栈在空闲时自动进入低功耗。

区分长轮询与短轮询：空闲期使用长轮询降低唤醒次数;发送后或等待响应时使用短轮询。

避免在发送后立即睡眠：发送完成后应保留足够时间接收APS ACK和可能的下行帧。

限制最大唤醒窗口：设置唤醒超时，防止因网络异常导致设备长期不睡眠。

记录唤醒原因：区分定时器唤醒、GPIO唤醒、RF唤醒和重连唤醒，便于功耗分析和故障定位。

跨平台适配：TI平台关注POWER_SAVING、POLL_RATE、RESPONSE_POLL_RATE等配置;Silicon Labs平台关注poll control、wake timeout和AF任务位;STM32WB平台关注M4/M0+同步、RTC唤醒和协议栈睡眠约束。

测试与优化方案

实际工程中，精准唤醒并不意味着固定周期绝对不变，而是在保证网络可靠性的前提下，让设备尽可能短地唤醒、尽可能久地睡眠。推荐先通过抓包确认轮询、ACK和下行消息时序，再通过电流波形验证唤醒窗口是否合理。最终目标是在“不丢消息、不误触发、不超时掉线”的约束下，获得最低的平均功耗。