Clarification on Green Power frame counter handling when first reception is corrupted (nRF52 / ZBOSS)

[Marco_A]

Good morning,

we are using the Zigbee stack (ZBOSS) on nRF52 devices with Green Power Sink enabled and we are integrating a Green Power door sensor.

nRF5_SDK_for_Thread_and_Zigbee_v4.2.0 with Green Power Sink add-on.

During validation we observed a specific and recurring behavior that we would like to clarify and confirm.

The Green Power Device transmits the same GPDF multiple times with the same frame counter (as defined by the GP specification). In packet captures (Wireshark / nRF Sniffer) all repetitions are visible on air.

However, in some situations the application on the nRF52 does not receive any Green Power notification, even though later repetitions of the same GPDF are clearly visible and correctly decoded by the sniffer.

From our analysis, it appears that the following sequence may occur:

1) The first GPDF transmission is received with marginal RF quality.
2) The Green Power header (including source ID and frame counter) is successfully decoded.
3) The frame counter is internally registered by the stack for duplicate / replay protection.
4) The same frame is then rejected before reaching the application layer due to payload / MIC validation failure.
5) Subsequent GPDF repetitions with the same frame counter are discarded as duplicates and never delivered to the application.

 

As a result, the full Green Power event is effectively lost, even though multiple GPDF transmissions were sent by the device and visible on air.

We would like to ask for confirmation of the following points:

 

1) Is it expected behavior that the Zigbee stack may register the Green Power frame counter before the full payload is successfully validated?

2) Is it compliant with the Green Power specification that subsequent repetitions with the same frame counter are discarded as duplicates even if the first transmission was rejected before application notification?

3) Is it therefore expected that Green Power events are not 100% reliable and that applications must be designed to tolerate the occasional loss of a door open / close event?

 

We are looking for a confirmation of the intended behavior, as this has implications on higher-level application state machines relying on Green Power sensors.

Thank you in advance for your support.

Best regards,

Arnaboldi Marco

[Amanda Hsieh]

Hi Marco, 

The team has checked the code, and how ZBOSS handles it is:

• During header processing, the frame counter is incremented.
• Upon security processing failure, the frame counter is reverted.

This doesn't match your description, unless there is some bug in the restore path.

I don't know if you had the chance to collect traces on the nRF5 SDK, but those would clarify if FC is really being restored (`TRACE_SUBSYSTEM_ZGP`).

Regards,
Amanda H.

[Marco_A]

Hi Amanda,

thank you for checking the code and for the explanation, that is helpful.

Unfortunately, I’m not able to open the internal Bitbucket link you shared (access denied on our side), so I can’t directly review the referenced code.

Just to clarify our setup: we are using **nRF5_SDK_for_Thread_and_Zigbee_v4.2.0** with the **Green Power Sink add-on**, not the nRF Connect SDK.

We can definitely collect additional traces to clarify what happens at runtime.

On our side we can provide:

- On-air captures using Wireshark + nRF Sniffer

- Internal stack logs from the nRF52840 (ZBOSS trace output over UART)

If you can point us to:

- which **TRACE_SUBSYSTEM_ZGP** messages should be enabled,

- and which specific log entries would confirm that the frame counter is restored after a security (MIC) failure,

we’ll collect and share the relevant traces.

In addition, we would like to ask a more general question regarding Green Power reliability.

From a system perspective, is it expected that **Green Power events may occasionally be lost** in environments with:

- high Zigbee traffic (many devices),

- overlapping Zigbee networks,

- and Wi‑Fi interference on the same 2.4 GHz band?

In other words, should Green Power devices (e.g. door sensors) be considered **best‑effort**, with the expectation that applications must tolerate the occasional loss of single events, or is the protocol intended to reliably deliver such state changes even in congested RF conditions?

This clarification would help us set the correct assumptions at the application level.

Thanks in advance for your guidance.

Best regards,

Marco