nRF5 SDK for Mesh v5.0.0
Resource usage

To be functional, the Bluetooth mesh stack requires a minimum set of the hardware resources provided by the Nordic SoCs. The stack is designed to be built together with the user application and it resides in the application code space. Moreover, it relies on the SoftDevice being present and thus requires the same hardware resources as the SoftDevice.

For information on SoftDevice hardware resource requirements, see the relevant SoftDevice specification.

Table of contents


SoftDevice Radio Timeslot API

The Bluetooth mesh stack operates concurrently with the SoftDevice through the SoftDevice Radio Timeslot API. Because the stack takes complete control over the Radio Timeslot API, this API is unavailable to the application.


Hardware peripherals

The following hardware peripherals are occupied by the Bluetooth mesh stack:


RAM and flash usage

Depending on the application needs, the mesh core can be configured to achieve either higher performance and functionality or a reduced footprint.

When it comes to memory, the Bluetooth mesh stack:

See the Mesh memory manager interface for more details on how to replace the memory manager backend.

The following tables show the flash and RAM requirements for the Bluetooth mesh examples. The values are valid for all fully compatible configurations based on the nRF52 Series Development Kits.

The examples are built with the minimum recommended version of GNU Arm Embedded Toolchain.

Build type: MinSizeRel (-Os), Logging: On (default)

Flash usage (kB) RAM usage (kB) Example
98.904 12.300 Beaconing
102.176 12.592 DFU without serial interface
112.704 15.728 DFU with serial interface
114.888 13.552 Dimming client
125.640 14.680 Dimming server
116.088 13.960 EnOcean switch translator client
117.928 13.576 Light CTL client
154.136 17.856 Light CTL+LC server
146.388 17.076 Light CTL server
149.740 18.996 Light LC server
117.516 13.540 Light Lightness client
133.416 15.720 Light Lightness server
113.304 13.520 Light switch client
134.732 18.776 Light switch server
127.652 13.736 Low Power node
106.436 11.700 PB-remote client
102.516 12.140 PB-remote server
113.512 13.048 Provisioner
114.988 13.532 Scene client
122.584 17.640 Sensor client
121.160 13.808 Sensor server
100.316 14.996 Serial

Build type: MinSizeRel (-Os), Logging: None

Flash usage (kB) RAM usage (kB) Example
85.492 10.036 Beaconing
85.996 10.328 DFU without serial interface
95.708 13.464 DFU with serial interface
96.856 13.536 Dimming client
105.656 14.664 Dimming server
97.864 13.944 EnOcean switch translator client
98.104 13.560 Light CTL client
127.496 17.840 Light CTL+LC server
121.476 17.060 Light CTL server
123.516 18.980 Light LC server
97.948 13.524 Light Lightness client
112.376 15.704 Light Lightness server
96.520 13.504 Light switch client
112.380 18.760 Light switch server
111.852 13.720 Low Power node
85.840 11.684 PB-remote client
86.184 9.876 PB-remote server
90.600 13.032 Provisioner
96.940 13.516 Scene client
98.536 17.624 Sensor client
100.776 13.792 Sensor server
87.352 12.732 Serial

Flash hardware lifetime

The flash hardware can withstand a limited number of write and erase cycles. As the Bluetooth mesh stack uses the flash to store state across power failures, the device flash will eventually start failing, resulting in unexpected behavior in the Bluetooth mesh stack.

To improve flash lifetime, flash manager does wear leveling by writing a new data to the flash page by allocating a new entry and then invalidating the old one. Eventually, flash page fills up and must be erased and re-written (see flash manager documentation).

The Bluetooth mesh stack uses flash to store the following states:

Based on the assumption that the reconfiguration of keys, addresses, and access configuration is rare, the most likely source of flash write exhaustion are the network states. The network message sequence number is written to flash continuously, in user-configurable blocks.

Calculating flash lifetime

The following table lists parameters that must be defined to calculate the flash lifetime of a device.

Name Description and Configuration parameter Default nRF51 Series Default nRF52 Series Unit
MSG_PER_SEC The number of messages created by the device every second (relayed messages not included). The message sequence number field is 24 bits. It cannot be depleted within one IV update period, which must be at least 192 hours. Because of this, a device cannot possibly send more than 2^24 / (192 * 60 * 60) = 24.3 messages per second on average without breaking the specification.

Configuration parameter: N/A
24.3 24.3 messages/s
BLOCK_SIZE The message sequence numbers are allocated in blocks. Every block represents a set number of messages.

Configuration parameter: NETWORK_SEQNUM_FLASH_BLOCK_SIZE
8192 8192 messages
ENTRY_SIZE The size of a single allocated block entry in flash storage.

Configuration parameter: N/A
8 8 bytes
AREA_SIZE Size of the storage area. Must be in flash-page-size increments. Defaults to a single page.

Configuration parameter: N/A
1024 4096 bytes
AREA_OVERHEAD Static overhead in the storage area, per page.

Configuration parameter: N/A
8 8 bytes
ERASE_CYCLES The number of times the device can erase a flash page before it starts faulting.

Configuration parameter: N/A
20000 10000 cycles

The formula for the network state flash exhaustion is as follows:

FLASH LIFETIME [seconds] = ((AREA_SIZE - AREA_OVERHEAD) * ERASE_CYCLES) / (ENTRY_SIZE * MSG_PER_SEC / BLOCK_SIZE)

Flash example values

SoC Settings Case Result
nRF51 Default Worst case 26.97 years
nRF52 Default Worst case 54.58 years

As any changes made to the default flash configuration may significantly reduce the product lifetime, recalculate the network state flash exhaustion time if any of the parameters change.

Flash configuration parameters

While the default settings will be sufficient for most applications, there are tradeoffs in the flash configuration that you might want to take advantage of.

Sequence number block size

The sequence number block size affects the number of power resets that the device can do within a 192-hour IV update period.

For security reasons, the device can never send a message with the same sequence number twice within an IV update period. This means that the device must allocate a new block of sequence numbers before it sends its first packet after a power reset, to avoid a scenario where it reuses the same sequence number on next powerup. As a consequence, every power reset requires a sequence number block allocation, which can exhaust the sequence number space faster than accounted for in the lifetime calculations.

With the default block size of 8192, the device may reset 2048 times in a 192-hour interval. If you expect a higher rate of resets, consider a smaller block size. Keep in mind that this will directly affect the flash lifetime, because more frequent writes are required during the normal operation.

The block size can also be increased if the number of power resets is expected to be lower than 2048, resulting in longer device lifetime.

Flash area size

The flash area size affects the number of erases required for the configuration and network state areas.

This does not alter the device lifetime significantly, because the flash manager defragmentation process requires a separate backup page that will be erased for every backed-up page. Adding pages to the flash area will therefore result in fewer, but more expensive defragmentations, with effectively no change to the number of erases required.


Documentation feedback | Developer Zone | Subscribe | Updated