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

[Amanda Hsieh]

Hi, 

Concentrator mode introduces a lot of broadcast messages when MTORR are sent periodically, which interfere with the FOTA process.

Even when you stop the concentrator mode, those messages could appear during some time.

 

One idea could be to disable the periodic MTORR and trigger it only when a new device joins the network.

For this, you can:

- Call zb_start_concentrator_mode(0, 0);

- Call zb_concentrator_force_mtorr() when a Device Announcement is received (if FOTA is not in progress) in the signal handler.

- Call zb_stop_concentrator_mode() some time before the FOTA process.

- Call zb_start_concentrator_mode(0, 0) after the FOTA process.

 

You might also use radius=3 to further reduce the number of broadcast messages, but you will need to evaluate the impact on the network.

Regards,
Amanda H.

[Marco_A]

Hi Amanda, 

I checked the nRF5 SDK (ZBOSS) and I couldn’t find any API named
zb_concentrator_force_mtorr() or any equivalent function that explicitly triggers a MTORR.

Originally, I wanted to enable the concentrator mode because I noticed that some battery-powered end devices, after several days of inactivity, tend to get lost from the network or become difficult to reach. My expectation was that many-to-one routing and periodic MTORR would help keep routes refreshed and improve overall stability.

However, considering that:

• concentrator mode introduces additional routing traffic (MTORR, route updates),
• and FOTA requires a stable and low-congestion network,

my conclusion is that the safest approach is to disable the concentrator at all

Regards

[JONATHAN LL]

Hi Marco, I am standing in for Amanda here and will follow up here.

Marco_A said:

I checked the nRF5 SDK (ZBOSS) and I couldn’t find any API named
zb_concentrator_force_mtorr() or any equivalent function that explicitly triggers a MTORR.

It's again a confusion since the API is only present in newer ZBOSS and not available for the nRF5 SDK. Since the nRF5 SDK for Thread and Zigbee v4.2.0 many improvements and bugfixes have been applied to both ZBOSS and the SDK, the recommendation is to upgrade when possible.


You could try to find a balance between the concentrator mode discovery time and the OTA conflicts, in order to still be able to recover those lost end devices.

Regards,
Jonathan

[Marco_A]

Hi Jonathan,

thank you for your reply.

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
however, I’m not fully sure that concentrator mode is actually effective with parameters (0, 0)

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)

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.

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

Do you suggest any specific range for the timeout value?

Best regards,
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