Configuring Bluetooth Mesh in nRF Connect SDK

The Bluetooth® Mesh support is controlled by CONFIG_BT_MESH, which depends on the following configuration options:

When the Bluetooth LE Controller is located on a separate image (like on the nRF5340 DK and Thingy:53 boards), the following configuration must be applied to the Bluetooth LE Controller configuration:

Optional features configuration

Optional features in the Bluetooth Mesh stack must be explicitly enabled:

The persistent storage of the Bluetooth Mesh provisioning and configuration data is enabled by CONFIG_BT_SETTINGS. See the Persistent storage section of Stack Architecture for details.

Mesh models

The nRF Connect SDK Bluetooth Mesh model implementations are optional features, and each model has individual Kconfig options that must be explicitly enabled. See Bluetooth Mesh models for details.

Mesh settings/performance

The following configuration options are used to configure the behavior and performance of a Bluetooth Mesh network. For more information about configuration options affecting the memory footprint of Bluetooth Mesh, see memory footprint optimization guide for Bluetooth Mesh.

Additional configuration options

This section lists additional configuration options that can be used to configure behavior and performance of Bluetooth Mesh. The provided values are meant as suggestions only, and should be individually adjusted for each application.

Logging

  • CONFIG_NCS_SAMPLES_DEFAULTS - Enables the Zephyr system logger with minimal logging implementation. This is enabled by default for all samples in nRF Connect SDK. For more information, see Zephyr system logger.

  • CONFIG_LOG_MODE_DEFERRED - Enables deferred logging. Setting this configuration option is recommended to avoid slowing down the processing of mesh messages. It improves the LPN power consumption when the friendship is established.

  • CONFIG_LOG_BUFFER_SIZE - Sets the number of bytes dedicated for the logger internal buffer. Increase the number to avoid missing logs in case of a complex protocol or functionality issue.

  • CONFIG_LOG_PROCESS_THREAD_SLEEP_MS - Sets the sleep period for the internal log processing thread. Decrease the value to flush logs more quickly.

GATT Proxy performance

These options are only compatible with devices supporting Bluetooth Low Energy (LE) v4.2 or higher.

Bluetooth settings/performance

The following configuration options are used to configure the Bluetooth Low Energy behavior and performance:

Disabled and unused Bluetooth features

The following feature options are by default disabled in the samples, but it needs to be considered if any of them are required by the application and thus should be enabled:

Emergency data storage (EMDS)

The following configuration options should be considered in case of large networks with high demands on storing the replay protection list (RPL) data. This will require additional hardware. For more information, see Emergency data storage.

Low Power node (LPN)

The Low Power node (LPN) is a power optimization feature specific to Bluetooth Mesh.

The following configuration options are relevant when using the LPN feature:

Persistent storage

Zephyr’s Mesh implementation has been designed to use the settings subsystem to store internal states and options in the persistent storage. The settings subsystem can be used with different backends. Bluetooth Mesh is configured with the non-volatile storage (NVS) as the settings backend.

Using the settings subsystem based on NVS can in some cases result in a significant store time increase. In a worst case scenario, the store time can be up to several minutes. This can for example happen when storing a large size replay protection list. It is recommended to configure the settings subsystem’s internal caches to improve the performance.

NVS lookup cache reduces the number of search loops within NVS’ application table.

The Settings NVS name cache reduces the number of search loops of internal parameter identifiers, keeping them in memory.

The size of the Settings NVS name cache, CONFIG_SETTINGS_NVS_NAME_CACHE_SIZE, is recommended to be at least equal to the number of settings entries the device is expected to store.

The Bluetooth Mesh stack stores the following data persistently:

  • Network information (primary address and device key)

  • Configuration parameters (supported features, default TTL, network transmit and relay retransmit parameters)

  • IV index

  • Sequence number

  • Heartbeat publication information

  • Application key(s) (the amount of entries is controlled by CONFIG_BT_MESH_APP_KEY_COUNT)

  • Network key(s) (the amount of entries is controlled by CONFIG_BT_MESH_SUBNET_COUNT)

  • Label UUIDs for virtual addressing (the amount of entries is controlled by CONFIG_BT_MESH_LABEL_COUNT)

  • RPL entries (the RPL size is controlled by CONFIG_BT_MESH_CRPL)

The following data is stored for each model by the Bluetooth Mesh stack:

  • Model subscription state

  • Model publication state

  • Bound application key(s)

  • Subscription list for group addresses

  • Subscription list for virtual addresses

  • Label UUIDs the model is subscribed to

  • Model-specific data

Model data stored persistently can be found under the Persistent storage section of the corresponding model documentation.

Using the Bluetooth Mesh: Sensor sample as an example, configured according to the sample’s configuration guide, results in the following list of possible entries (entries mentioned above are not included unless specifying the amount of entries):

  • 32 RPL entries - since the default Networked Lighting Control (NLC) configuration is used (CONFIG_BT_MESH_NLC_PERF_DEFAULT is set), the RPL size is 32.

  • Application keys - three keys are used.

  • Bound application keys - each of the three Sensor Server and Sensor Setup Server models has one bound application key.

  • Network keys - only one key is used.

  • Model subscriptions - each of the three Sensor Server and Sensor Setup Server models subscribes to a group address.

  • Model publication information - each of the three Sensor Server models publishes to a group address.

  • Virtual addressing is not used.

  • Sensor Server model data - each of the three Sensor Server models stores the following data:

    • Minimum interval

    • Delta thresholds

    • Fast period divisor

    • Fast cadence range

  • The following values are stored in the sample:

    • Temperature range

    • Presence motion threshold

    • Ambient light level gain

Adding up all entries, it is worth setting the cache size to minimum 71.