nRF54L15: BLE Mesh protocol with thousands nodes, flash memory wearing in a few years of operation

[DavideDN]

We are building a line of product to be used in big size building light management and control.

We believe that both the IV values and a huge quantity of SEQ separate counters (one for each assigned unicast address), are being stored and continuously updated using nvm subsystem.

Since nvm is usually implemented by means of a set of internal flash pages, even in presence of a wear leveling algorithm, within a few year of operation the device flash will reach the maximum number of erase cycles.

We need more than 15 years of guaranteed flash life: our networks can have 1000 nodes with 8k total elements/addresses and they will exchange an enormous number of messages.

Do you believe it will be required to implement NVM using an external device, may be using a different technology such F-Ram or other?

Many thanks in advance

Davide De Nardis

[tesc]

Hi,

We believe that both the IV values and a huge quantity of SEQ separate counters (one for each assigned unicast address), are being stored and continuously updated using nvm subsystem.

The number of separate sequence numbers depend on the number of other devices the device is to receive messages from. The replay protection list (RPL) must be large enough for holding entries for all sender devices sending messages to be read by the local device (but not for messages only to be relayed.) Thus, the size requirement for the RPL is highly dependent on the message passing patterns of the network. I.e. a central gateway receiving messages from all devices need a large RPL, while a light bulb only receiving messages from a few light switches and gateways may need only a handfull.

within a few year of operation the device flash will reach the maximum number of erase cycles

This of course depends highly on the amount of incoming messages and the number of pages set aside for NVM. Please note that for the nRF54L15 the NVM is not Flash, but RRAM, which means usage patterns may differ. (NVS backend for Flash, v.s. ZMS backend for RRAM.) For high traffic scenarios there are settings delaying store to NVM, leading to fewer writes. We have formulas for calculating flash endurance under Persistent storage sizing for RPL in the documentation for Bluetooth Mesh stack configuration. As you can see, NVM life increases with increasing store timeout (CONFIG_BT_MESH_RPL_STORE_TIMEOUT), with larger space, and with smaller RPL size (CONFIG_BT_MESH_CRPL).

Do you believe it will be required to implement NVM using an external device, may be using a different technology such F-Ram or other?

It all depends on the size requirement of the RPL, the available NVM space (RRAM), and what store timeout you can live with. (The tradeoff with store timeout is that messages will not get their RPL entry updated in NVM until the timeout has passed. That means if the device gets powered off before the timeout has passed, messages can potentially be replayed when the device has been powered on again and before receiving additional messages from the same sender.)

As the calculation samples show (Persistent storage sizing for RPL, referenced earlier in this reply,) an nRF54L15 device with full RPL of size 255 receiving 1 message every 10 seconds and with 30 seconds store timeout, is expected to last for more than 20 years if using 128 KB of the 1524 KB available NVM for RPL storage.

If you find that you do not have enough RRAM available on the device for storing the RPL, there is an option to use Emergency data storage (EMDS) for storing the RPL. The basic principle of using EMDS is to store the data only when needed, on powering down. For that, the device must stay powered long enough for the write to succeed. See Emergency data storage (dedicated page) for details on EMDS.

Typically, the predominant data storage requirements of the Bluetooth Mesh stack is for the RPL, especially with large traffic volume scenarios such as what you describe. The remaining storage requirements are small in comparison and typically covered for decades by few pages. The exception is if you have a gateway device keeping track of keys, addresses, etc. for a large number of other devices on the network. For that kind of scenario you might need to look into external storage, but then mostly due to the mere size of the required data storage and not due to rewrite cycles.

Regards,
Terje