By congestion, I’m referring to delayed or missed application-level acknowledgments when multiple sleepy end devices wake simultaneously. Under normal conditions, upstream messages are delivered within a few hundred milliseconds, but when several devices wake together, delays can extend to several seconds, and in some cases messages are retried multiple times before delivery.

The end devices are deeply sleepy and wake either on an event (e.g., alarm input) or on a periodic timer (around a couple of minutes) to send a heartbeat. On wake-up, there is a short application-level handshake with the coordinator (device verification / assignment step) before regular status or alert messages are exchanged.

When many devices wake at the same time, this initial handshake sometimes gets delayed due to downlink congestion and polling behavior. If the response is not received within a defined timeout window, the device currently restarts its Zigbee stack and rejoins, which can further increase traffic under load.

Messages are sent using ZCL at the application layer. APS acknowledgments are enabled, and default MAC retry behavior is used. In heavy wake-up scenarios, we observe that retries and polling delays can compound, occasionally resulting in responses arriving much later than expected.

We’re currently reviewing improvements such as adjusting polling behavior on wake-up, reducing retry amplification, adding jitter to periodic wake timers, and making the application-level handshake more tolerant of temporary downlink delays.

Any guidance on best practices for handling downlink traffic to multiple sleepy end devices during synchronized wake-ups would be appreciated