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

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
Parents
  • 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.

  • 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

Reply
  • 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

Children
No Data
Related