ncs3.2.4 dfu distributor QA

[liujy]

Hi：

What is the maximum number of targets that a DFU distributor can support for simultaneous upgrade, and what is the upper limit? I haven't found any detailed explanation about it in the DFU interface documentation I reviewed

https://docs.nordicsemi.com/bundle/zephyr-apis-latest/page/group_bt_mesh_dfd_srv.html#ga126e2d4df8f58b7de36da46c14b2c804

#define CONFIG_BT_MESH_DFD_SRV_TARGETS_MAX  

Especially, how many can it support at most while ensuring stability in practical applications? This is very important for me to evaluate the project.

Thank you.

[tesc]

Hi,

For practical applications, the number of concurrent updates depend on the system capacity of the distributor node, most importantly size of the replay protection list (RPL, CONFIG_BT_MESH_CRPL), mechanism of RPL storage, and wear-leveling extra tolerance used for the settings partition.

If default settings are used, then RPL is stored with continuous writes as per CONFIG_BT_MESH_RPL_STORE_TIMEOUT. It is recommended to leave out 2.5-3x size of the RPL footprint for the settings partition to allow wear leveling (more size is needed if incoming traffic on distributor is high). RPL has 64 byte footprint per entry.

If you use the emergency data storage (EMDS), then the partition size should be as per the EMDS documentation. However please be aware that the numbers for RRAM write current and write speed in the datasheet are both typical values (not max), so if using EMDS you must define enough tolerance for backup capacitor to allow the entire RPL to be written safely upon power failure.

In summary, the number of nodes to simultaneously upgrade depends on the RPL size (64 bytes per node) times size increase for wear leveling, as well as capacity for writing the RPL (in the case of using EMDS).

Regards,
Terje

[liujy]

Hi tesc，

Thank you for your reply.

The specific quantity depends on the size of the RPL.I have two more questions to ask at the end.

Whether the upgrade is done serially or in parallel?And whether stability can be evaluated?

Thanks

[tesc]

Hi,

liujy said:

Whether the upgrade is done serially or in parallel?

Yes, the upgrade is done in parallel, with the distributor keeping track of the recipients. Please note however that a typical file transfer might take a couple of hours, as Mesh DFU is designed to have minimal impact on network traffic.

liujy said:

And whether stability can be evaluated?

We do not have numbers for this, other than the default settings being reasonable for most standard setups. You might experience that properties such as relay node density and network parameters might affect network performance. If for some use cases you experience poor performance, then you might consider different settings for those use cases. I encourage you to get familiar with and test Bluetooth Mesh DFU through our DFU related samples. For looking into our Bluetooth Mesh DFU solutions, including the samples, a good starting point is DFU over Bluetooth Mesh.

Regards,
Terje

[liujy]

Hi tesc，

many thanks with you reply.