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

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

Parents Reply Children
No Data
Related