Zigbee Concentrator Mode impacting OTA upgrade reliability (nRF52840, nRF5 SDK)

[Marco_A]

Hi,

I am working on a Zigbee coordinator based on nRF52840 using the nRF5 SDK (ZBOSS stack).

My network includes up to ~50–60 devices (both mains-powered and battery-powered), and I was advised (by Nordic) to enable concentrator mode to improve routing efficiency and overall network robustness.

I enabled concentrator mode using:    zb_start_concentrator_mode(0, 120);

This does improve network routing behavior, however I am experiencing consistent issues with OTA firmware updates (Zigbee OTA cluster):

- in my older version, OTA works reliably when concentrator mode was NOT enabled

- now OTA becomes unstable or fails when concentrator mode is active

What I have already tested:

1. Calling zb_stop_concentrator_mode() before starting OTA

   → This does not solve the issue (OTA still fails)

 I am currently testing starting concentrator mode with radius = 0xFFFF only after OTA (instead of 120), to see if helps.

Is it expected that concentrator mode negatively impacts OTA performance on networks of this size?

What is the recommended approach to combine:

    - a large network (50+ nodes)

    - concentrator mode (for routing efficiency)

    - reliable OTA firmware updates?

Any guidance or reference configuration would be greatly appreciated.

Thanks in advance,

Arnaboldi Marco

[Marco_A]

Hi Jonathan,

as another attempt, I would like to test the concentrator mode with a much longer discovery interval, for example:

zb_start_concentrator_mode(0, 3600);

So, in this case, my understanding is that the concentrator would perform the MTORR/discovery procedure only once every hour.

Does this also mean that during the rest of the time there should be minimal impact on OTA traffic and network congestion?

If that is correct, is there any way to know exactly when the MTORR procedure is about to start (or is currently running)?

My idea would be to notify the main MCU and temporarily avoid starting an OTA process during that specific time window, in order to reduce conflicts between OTA traffic and routing broadcasts.

Best regards,
Marco

[JONATHAN LL]

Hi Marco, 

Marco_A said:

We performed some tests with different configurations:

Using zb_start_concentrator_mode(0, 0); and calling zb_stop_concentrator_mode() before starting OTA:
OTA works correctly

Good

Marco_A said:

Using:

zb_start_concentrator_mode(0, 60);
or

zb_start_concentrator_mode(0, 120);
 and calling zb_stop_concentrator_mode() before starting OTA:

OTA does not work properly (likely due to increased routing/broadcast traffic

This could be a bug, the concentrator mode for the nRF5 SDK has not been tested a lot so we probably don't have a full overview of potential bugs and quirks.
Instead of calling stop() and expecting it to work you can try to use set_mode(0,0) then stop().  

So one possibility could be to use manual mode and run it once an hour or something alike unless a DFU in on the way. 

Marco_A said:

As a next step, I will try one last configuration by increasing the discovery time to see if I can find a balance between MTORR activity and OTA stability.

If this attempt does not bring improvements, I will proceed without using the concentrator mode.

We would like to be updated on whatever result you go for here as it might be good to know in the future. 

Marco_A said:

In parallel, I am also pushing internally to migrate to the newer SDK, so we can benefit from the latest ZBOSS improvements and APIs.

This is what we will recommend here and what we consider the best approach.

Marco_A said:

Do you suggest any specific range for the timeout value?

We dont have a known good time here, the idea I had in mind was to use some value that will allow the FOTA to complete without triggering a MTORR during the download process. That's probably something above 10 or 20 minutes, but could be better than nothing when comes to recovering those lost devices.

Regards,
Jonathan