Bluetooth Mesh Networking Principles#

This section describes Bluetooth mesh networking and the parameters influencing good operation. The information presented in this section focus on the following principles:

• Scalability: Adding and removing a node from a network should be a seamless procedure.

• Robustness: All information needed by a node for normal operation should reach it.

• Efficiency: Irrelevant radio communication should be reduced as much as possible to avoid collisions and unnecessary power consumption.

• Security: No weakness should be introduced in the network due to incorrect parameter settings.

Bluetooth Mesh Network Layer#

The following description defines the Network PDU format:

The following table describes the fields:

(1) Fields are obfuscated, meaning that they are combined with the result of a single encryption function designed to prevent a passive eavesdropping.

(2) Fields are encrypted and authenticated. Authentication and encryption in this context is equivalent to Bluetooth LE terminology. For more detail on Network PDU encryption and obfuscation, refer to the Bluetooth mesh profile specification.

In the Network PDUs, not all fields are relevant for network operation optimization. The following parameters are the ones that should be considered first.

IV Index#

The IV index is a 32-bit value known and shared by all nodes of a network. It is used for authentication and encryption at various levels in the stack (network, transport and application layers). For more information, see IV Update in a Bluetooth Mesh Network.

Time to Live (TTL)#

Every device acting as a relay will decrement the time-to-live (TTL) value in received messages and forward them if the TTL equals two or higher.

The following values are defined for the time-to-live counter:

• 0: A Network PDU has never been relayed and will not be relayed.

• 1: The Network PDU has been relayed but will not be relayed. All Network PDUs with this TTL value will be dropped by the node’s network output filter.

• 2 to 126: The Network PDU has been relayed and can be relayed.

• 127: The Network PDU has not been relayed and will not be relayed.

The default TTL value of a node can be accessed and modified in the application code by any node supporting the configuration client model (typically the provisioner, but not necessarily):

• sl_btmesh_config_client_get_default_ttl(net_key_index,node_address,pointer_to_handle)

• sl_btmesh_config_client_set_default_ttl(net_key_index,node_address,default_ttl_value,pointer_to_handle)

This can also be done on model basis:

• sl_btmesh_config_client_get_model_pub() /\* See BT Mesh API documentation for the arguments \*/

• sl_btmesh_config_client_set_model_pub() /\* See BT Mesh API documentation for the arguments \*/

Note that the test API in the Silicon labs Bluetooth mesh API also allows modification of the TTL value for debugging purposes.

Adjust the default TTL value of a node carefully, depending on the supported features.

Typically, publishing model TTL value should be tailored to the application’s need. As a trivial example, a lightness client model controlling a room within direct radio range should be set to publish with TTL=0. A sensor that sends data to a collector node somewhere in the network should publish with a TTL value big enough to just reach the collector across a chain of relays with and addition of 1 or 2 hops for relay redundancy.

Default TTL should be set so that Network PDUs can reach the Provisioner. If the provisioner is a mobile device accessing the network via a proxy node, the default TTL needs to be set so that the node reaches the whole network.

SEQ#

Each Network PDU increments a sequence counter (SEQ) to protect the receiver node from replay attacks. It is a 24-bit value that can be combined with the source address and IV index of a network to identify messages individually. This value is part of the network cache and replay protection list entries in the Silicon Labs Bluetooth mesh stack.

SRC and DST#

The SRC and DST fields are 16-bit values identifying the source and destination of the Network PDU. The SRC field is a unicast address, while the DST field may be a unicast, group, or virtual address.

Both fields are untouched when the PDU is relayed.

Message Replay Protection#

A malicious device can passively receive all traffic whether encrypted or not, and then replay one or a sequence of messages to take advantage of the infrastructure. In common security terms, this is called a replay attack.

Since the originating element has encrypted and authenticated the message using the correct keys, the receiver node has no means to determine whether it is under a replay attack.

To increase protection against replay attacks, each element increases the sequence number (SEQ) for each new message that it sends. If a valid message has been received from an originating element with a specific sequence number, any future messages from the same originating element that contain numerically lower or equal sequence numbers than the last valid sequence number are very likely replayed messages and should be discarded. Therefore, messages are delivered to the access layer in sequence number order.

To guard against malicious devices replaying previous messages, every device keeps a running sequence number, which is used for outbound messages. Each Bluetooth mesh message is sent with a unique pair of sequence number and source address. When receiving a message, the receiving device stores the sequence number and makes sure that it is more recent than the last sequence number it received from the same source address. This is handled by the replay protection list described In the following section.

Replay Protection List#

A replay protection list entry in the Silicon Labs Bluetooth mesh stack, is structured as:

• Source address (2 bytes)

• IV index and SEQ number (7 bytes)

• IV index and SEQ number authenticated (7 bytes)

• Saved flag (1 byte)

That totals 17 bytes. The total memory space allocated to the network replay protection list (RPL) is determined by the Replay Protection List size parameter in the Bluetooth Mesh stack configuration component. The default setting for the replay protection list is 32.

The RPL size sets the upper limit for the number of devices (or more accurately, the number of elements) this device can communicate with. When the RPL cannot be amended with an entry corresponding to a new received message, because the RPL is full, any such message will be dropped

The composition data page 0, part of what is referred to as Device Composition Data (DCD) in the Silicon Labs Bluetooth mesh stack, contains a field indicating the minimum number of entries in a node replay protection list. The following table illustrate the content:

The CRPL value corresponds to the value set in the Bluetooth Mesh Stack component.

Silicon Labs’ stack allows you to save the replay protection list in non-volatile memory (NVM) to ensure replay protection over power cycles. The following routines can be used:

• sl_btmesh_node_save_replay_protection_list()

• sl_btmesh_node_get_replay_protection_list_status(uint16_t \* total_entries, uint16_t \* unsaved_entries)

The replay protection list should be saved regularly, especially after a topology change or an IV index update, for example. When a node is removed or added in the network. It is good practice to save the RPL before the devices power off.

The publish rate of a model on each node (set by the configuration client) is also a critical parameter. If the publish rate is too high, it can drastically increase the traffic on the network and cause sluggish performance.

For more information, see the Silicon Labs Bluetooth mesh API documentation.

Relays#

Relaying in Bluetooth mesh networks is important, but often misuse of that feature leads to problems. This section clarifies the functionality and suggests ways to improve robustness and scalability of your network.

As mentioned earlier in this document, message flooding is the mechanism put in place to ensure two nodes unable to reach each other directly by radio, can still communicate. This means that messages coming from the origin node will be received by relay nodes within radio range and then retransmitted to other relay nodes until the information finally reaches its original destination node.

This is a very effective and simple way to solve the network scalability issue but comes with some drawbacks:

• If too many relay nodes are enabled in the network, the redundant data traffic may increase in an uncontrollable way.

• Relay nodes must constantly listen for incoming advertising packets and retransmit them, which is very costly in term of power.

• A lot more information travels over the air, potentially making attacks easier.

As a result, a network designer must take caution when using the relay feature and limit the number of relay nodes to what is necessary.

For example:

• Devices powered by a building’s electric system, such as light bulbs, are not power-constrained and most likely will be active on the mesh network. As a result, it makes sense for these nodes to support the relay feature. The network cache and replay protection list size should be adjusted depending on how many nodes surrounds it. Additionally, the TTL value should be set based on the hop count needed to reach its configuration device.

• An LP node would typically never need to support the relay feature, as it is incompatible with its power constraints.

Network Repetitions and Repetition Delays#

Relays retransmit network PDUs. The configuration client (provisioner, configurator) determines whether a device behaves as a relay along with the number of retransmissions and the delay between retransmissions. The Silicon Labs configuration client commands for these are as follows:

• sl_btmesh_config_client_get_relay(net_key_index,node_address)

• sl_btmesh_config_client_set_relay(net_key_index,node_address,value,retransmit_count,retransmit_interval)

The number of retransmission count is encoded on 3 bits and goes from 0b000, meaning the messages are retransmitted once, to 0b111, meaning one transmission and 7 retransmissions.

The time interval between retransmissions is encoded on a 5-bit value multiplied by a 10 ms time step. The value 0b00000 represent 10 ms: (0b00000 +1) * 10 ms. The value 0b11111 represent 320 ms: (0b11111 + 1) * 10 ms.

This is described in the Bluetooth mesh profile specification as relay state and should be carefully set to achieve maximum network performance. Additionally, a similar mechanism at the network layer level exists for non-relay nodes This is described in the Bluetooth mesh profile specification as network transmit state.

• sl_btmesh_config_client_get_network_transmit(net_key_index,node_address,pointer_to_handle)

• sl_btmesh_config_client_set_network_transmit(net_key_index,node_address,transmit_count,transmit_interval,pointer_to_handle)

Those routines allow a configuring node that is supporting the configuration client model to set the network transmit state. For more information, see the Silicon Labs Bluetooth mesh API documentation.

Only in areas with very few relays should the network/relay repetitions be enabled.