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

[Amanda Hsieh]

With TRACE_ZGP1, the store and restore frame-counter traces will appear. Increasing the trace level will show more detail around other GP operations. TRACE_ZGP3 is needed to show the trace about decryption failure.

Notice that the traces are collected as binary, and we need to decode them.

For the follow-up questions, yes, Green Power devices are best-effort.

In congested environments, occasional lost events are expected. Because these devices prioritize energy savings, they typically lack the power to check for a clear channel or handle two-way acknowledgments, resulting in a "fire and forget" transmission.

In areas with high traffic or interference from Wi-Fi and overlapping networks, these short bursts are easily drowned out. Systems should be designed to tolerate occasional misses rather than assuming 100% delivery.

[Marco_A]

Hi Amanda,

 thank you for the detailed clarification, this is very helpful and answers our questions clearly.

 Thanks also for explaining the expected Green Power behavior and its best‑effort nature in congested environments — this helps us set the correct assumptions at the application level.

 As next steps, we’ll run additional validation tests enabling **TRACE_ZGP1** to monitor the frame counter store/restore behavior.

If during these tests we observe any indication that the frame counter might not be properly restored after a security failure, we will collect a more detailed log with **TRACE_ZGP3** enabled as well and share the decoded traces with you for further analysis.

 Thanks again for your support.

 Best regards, 

Marco

[Marco_A]

Hi Amanda,

 
We can enable TRACE_ZGP1 and TRACE_ZGP3 and capture the binary ZBOSS trace output on UART.

At the moment, our difficulty is not collecting logs, but correctly interpreting them.

We currently don’t have a supported way to decode these binary traces into human‑readable ZGP messages (store/restore frame counter, duplicate drop, etc.). 

Because of this, when we observe a missed Green Power event, we cannot reliably distinguish between:

1) all repeated GPDF transmissions being lost on air due to RF congestion/interference, or

2) the first transmission being received but failing security checks, and subsequent repetitions being discarded internally (e.g. no frame counter restore).

 
Without being able to make this distinction, it’s difficult for us to know whether we are capturing a purely RF-related best‑effort loss, or a potential corner case in the Green Power handling.

 

Exist a tool to decode TRACE_ZGP1/TRACE_ZGP3 binary logs on Windows for nRF5_SDK_for_Thread_and_Zigbee_v4.2.0 ?
or there is an alternative logging method, trace flag, or observable indication that would allow us to confirm whether the frame counter restore path is being executed?

 
Our goal is to make sure we provide you with focused and meaningful logs, rather than large captures that may not contain actionable information.

 

Thanks in advance 

Best regards,

Marco