Bluetooth Mesh Node Principles and Optimization#

This section focuses on the network operation from the node perspective.

Bluetooth Mesh Stack Layers#

The current Bluetooth mesh stack (Bluetooth Mesh profile/model spec 1.0.1) is built on top of the Bluetooth Low Energy core specification. The following image illustrates the layers composing the Bluetooth mesh stack running on each node:

image2image2

The Bluetooth mesh specification defines two bearers over which mesh may be transported:

  • An advertising bearer, using advertising packets as defined in the Bluetooth Low Energy core specification with dedicated mesh AD types.

  • A GATT bearer, which allows devices not supporting the advertising bearer to participate to a mesh network. The GATT bearer can transmit and receive network layer packets, encapsulated in what is called the “Proxy protocol”, through regular Bluetooth Low Energy connections.

The network layer defines the Network packet data unit (PDU) format that allows data to be transported by the mesh bearers. It decrypts, authenticates, and forwards packets upstream, to the Lower Transport Layer, and downstream, to the bearer layer. For more detail on the Network layer and the Networks PDUs, see Bluetooth Mesh networking principles.

The Lower Transport Layer and Upper Transport Layer handle Transport PDUs. The Lower Transport Layer implements message segmentation and reassembly of Transport PDUs. Also at that level application keys associated with the message are identified. In the case of a friend node, a list of messages is stored for each associated low power (LP) node at this level. For more detail, see Friend.

The Upper Transport Layer implements message integrity checking and encryption/decryption.

Finally, the Access Layer defines the format of application data such as models. It also handles model publishing and subscribing. The access layer mainly handles application data and therefore will not be described extensively in this document, as it focuses on mesh networking operation.

Node Features#

Node functionality is determined by the features that they support. Each node can support one or several of the features described in the Introduction, that is:

  • Relay node

  • Proxy node

  • Friend node

  • Low Power node

This section exposes the meaning of each feature with some practical recommendations.

Relay#

Bluetooth mesh expands the range of the network by relaying messages. Any Bluetooth mesh device supporting the feature may be configured to act as a relay, but it is not mandatory for a network to have relay nodes (in case of small networks for example).

This relaying is undirected and is referred to as “message flooding”. It ensures a high probability of message delivery, without requiring any information on the network topology.

The Bluetooth mesh profile specification does not provide any routing mechanisms. As a result, all messages are forwarded by all relays until a counter-based time-to-live (TTL) mechanism reaches zero (more detail on TTL can be found in the dedicated section in the Bluetooth mesh profile specification). To avoid messages being forwarded by the same relays over and over, all Bluetooth mesh devices maintain a message cache, used for filtering out packets that the device has already handled.

Recommendations

The flooding-based approach to message relaying can cause a lot of redundant traffic on air, which may impact the throughput and reliability of the network. Therefore, it is highly recommended to limit the number of relays in a network to restrict this effect.

The number of relay-enabled devices in the network is a trade-off between message redundancy and reliability. It should be tuned according to:

  • Network size (number of nodes)

  • Traffic volume

  • Requirements for reliability and responsiveness

Proxy#

To enable support for legacy Bluetooth LE devices that do not support receiving mesh network packets, Bluetooth mesh defines a separate protocol for tunneling mesh messages over the Bluetooth LE GATT protocol. For this purpose, the Bluetooth mesh profile specification defines a GATT bearer and the corresponding GATT Proxy Protocol. This protocol allows legacy Bluetooth LE devices to participate in the Bluetooth mesh network by establishing a GATT connection to a Bluetooth mesh device that has the proxy feature enabled.

The legacy device gets assigned an address and the necessary keys to become a full-fledged member of the network. The device receives the security credentials through the regular provisioning procedure or through some out-of-band mechanism.

Recommendations

Unprovisioned devices should support both the advertising bearer and the GATT bearer.

A provisioner should support at least one of the bearers. It is highly recommended that it support the advertising bearer.

For a provisioner, when provisioning over the GATT bearer (PB-GATT) it is highly recommended that the connection interval for the connection between a Provisioner and device be between 250 and 1000 milliseconds (implementation-specific). This enables very low power operation for the device and allows the device to calculate the Diffie-Hellman shared secret without wasting significant energy to maintain an idle link.

Friend#

To enable broadcast-based communication, the devices must continuously keep their radio in listening mode. This causes significantly higher power consumption than in a typical Bluetooth LE device.

To enable low power devices to take part in the mesh network, Bluetooth mesh contains a friendship feature. This protocol lets low power devices establish a relationship with a regular Bluetooth mesh device, which will then cache and forward messages to the low power device at regular intervals. This saves the low power device from having to stay on to listen for incoming messages.

Recommendations

Limit the number of friend relationship a node can have, as this has direct effects on the message queue the friend node needs to maintain for the low power nodes it is associated with. If the friend queue is full and a new message needs to be stored, the oldest entries of the friend message queue will be discarded to make room for the new message.

Low Power (LP) Node#

Some types of nodes have limited power resources, such as coin cell batteries. Those battery-powered devices need to conserve energy as much as possible. The low power node feature allows nodes that support it to establish an association with other nodes within radio range, to store mesh packets for them while they are on energy saving mode (deep sleep).

The devices at the other end of that relationship are called friend nodes. An LP node can only have one friend node, but a friend node can have a friend relationship with several LP nodes.

Furthermore, devices of this type may be predominantly concerned with sending messages but still have a need to occasionally receive messages.

Recommendations

Low power edge nodes that mostly sends requests, such as light switches, do not need to act as a relay. Adjust the time-to-live counter (TTL) setting based on location within radio range of devices it controls.

Node Message Handling#

This section lays out the mechanisms put in place by the Bluetooth mesh stack for message handling on a node.

Network Interfaces and Filtering#

On each node, the network layer supports sending and receiving messages via multiple bearers. As a result, multiple instances of a bearer might be present. Each of these instances interacts with the mesh network via a network interface.

For example, a node may have two network interfaces: one for Network PDU handling via the advertising bearer and another one for Network PDU handling via a GATT bearer. This is illustrated in the following figure.

image3image3

The interface output filter of each interface makes sure only messages passing the defined rules are passed to the network layer and bearers. The output filter of the interface connected to advertising or GATT bearers must drop all messages with TTL values set to 1.

The following routines can be used to set up the input/output filtering rules for GATT bearers. For more information, see the Silicon Labs Bluetooth mesh API documentation:

- `sl_btmesh_proxy_allow()`
- `sl_btmesh_proxy_deny()`
- `sl_btmesh_proxy_set_filter_type()`

Network Message Cache#

To reduce unnecessary security checks and excessive relaying, nodes include a network message cache of all recently seen Network PDUs. If a Network PDU is received that is already in the network message cache, then the Network PDU is not processed (that is, immediately discarded). If a Network PDU is received and that Network PDU is not in the message cache, then the Network PDU is processed (for example, checked against network security and relayed) and, if it is a valid Network PDU, it is stored in the network message cache.

It is not mandatory, nor is it necessary, to store entire Network PDUs in the network cache. For instance, the network cache as implemented in the Silicon Labs Bluetooth mesh stack consists of a ring buffer of cache entries stored internally by the stack in RAM. For resource optimization purposes, only some of the Network PDU information is stored in cache, rather than the encapsulated Transport PDU.

A cache entry, in the Silicon Labs Bluetooth mesh stack, is structured as:

  • Network key index (2 bytes)

  • IV index and SEQ number (4 bytes)

  • Mesh source address (2 bytes)

That is 8 bytes in total. The total memory space allocated to the network cache is determined by the Network Cache size parameter in the Bluetooth Mesh Stack component. By default, this is set to 16 cache entries, or 128 bytes.

image4image4

Typically, it is good practice to set a large cache size for all nodes that support relaying and have it enabled.

Bluetooth Mesh Stack Component#

As mentioned earlier, the Bluetooth mesh stack on each node can be configured to optimize network operation. This is done through the Bluetooth Mesh Stack component. Open the project by double-clicking the .slcp file, go to the SOFTWARE COMPONENTS tab, and search for and select the Bluetooth Mesh Stack component. Click Configure.

image5image5

The Component Editor opens.

image6image6

Among the configurable parameters, some are especially relevant for network efficiency optimization. A list of parameters that should be considered follows. For an exhaustive description of all the parameters, refer to UG472: Bluetooth Mesh Stack and Configurator User’s Guide for SDK v2.x.

Network Cache size

For more detail on this, see Network Message Cache. It is good practice to increase the size of the cache on relay nodes. The number entered is the number of cache entries

Replay Protection List Size

For more detail on the replay protection list size see section Bluetooth Mesh Networking Principles. The number entered is the number of replay protection list entries.

Maximum Number of Segments Allowed for Transmitted/Received Packets

At the transport level, messages can be segmented, meaning that large length messages can be sliced into smaller entities called segments and sent/received in bursts (or batches).

In the case of a receiver, Maximum number segments allowed for received packets determines the number of segments the node’s stack receive task can process in one burst. To maximize throughput, it is good practice to increase the value of that parameter.

In the case of a transmitter, Maximum number segments allowed for transmitted packets determines the number of segments the node’s stack transmit task can process in one burst. To maximize throughput, it is good practice to increase the value of that parameter.

The maximum number of segments for both receiving and transmitting is 32, corresponding to the maximum length of the access layer PDUs payload.

Do not interfere significantly with segmentation as this could have negative consequences. The use of unsegmented messages is always preferred.

For more detail on segmentation, see the Bluetooth mesh profile specification.

Maximum Number of Friendship Allowed

This parameter indicates, on a node that supports the Friend feature, the maximum number of friendships that can be established. This should be adjusted on each node.

Maximum Size of Total Friend Cache

On a node that supports the Friend feature, this parameter indicates the amount of RAM dedicated for the LP node message queues. This is does not have a direct effect on network operation but is strongly correlated to the following parameter Maximum size of Cache for a single Friendship.

Maximum Size of Cache for a Single Friendship

On a node that supports the Friend feature, this parameter indicates the length of the logical structure used by the stack to store LP node messages. The length of the message queue should be adjusted to the LP nodes’ poll time, which is the duration they periodically spend in deep sleep.

Maximum Number of Connections to Reserve for GATT Proxies

On a node that supports the Proxy feature, this indicates maximum number of GATT bearer-based connections that can be made. This can be set to 0 when only the advertising bearer is used.

Radio Range#

One parameter to take in account when setting up a mesh network is the reach of each node. Nodes that do not have a strong power constraint can increase the TX output power to enhance their reach. As a result, on such nodes, setting transmit power to the maximum legal value is recommended. This is, of course, not the case for LP nodes. In case of relay overlap, it is good practice to increase radio range.

It is recommended to keep the node’s advertising rate as low as possible. Devices will usually have some advertising configured, including unprovisioned device/proxy advertisements and other miscellaneous advertising. As the number of nodes in the network increases, the rate of these advertisements can have a very detrimental effect on provisioning/configuration performance and network performance. The rate of these advertisements must be carefully selected by considering the expected size of the network and the application requirements (that is,. how quickly a mobile app needs to connect to a node, and so on).