Bluetooth Mesh Network Features and Functions - Friendly Nodes

Bluetooth Low Energy ( Bluetooth LE ) is one of the world's most powerful short-range wireless communication technologies. Its low power consumption is widely praised by developers and consumers. With the release of Bluetooth Mesh , developers may wonder whether Bluetooth Mesh is also designed for low power consumption. Does it inherit the advantages of Bluetooth LE low power consumption?

The answer is yes! Bluetooth mesh networking includes various measures to optimize power consumption, in particular a feature called " Friendship " .

Bluetooth Mesh Standard Overview

The applications for the Friendship feature in Bluetooth mesh networks could be very diverse. Some products, like lights, will be connected to the mains power supply, and the power consumption of the Bluetooth mesh module will be negligible compared to the power consumption of the light itself. But other products, like smart sensors or locks, will be power-constrained, meaning they will need to be powered by small batteries or energy harvesting techniques. Products like these are most likely to take advantage of the Friendship concept of Bluetooth mesh.

If you have read the earlier articles in our Bluetooth mesh series, then you already know that a node is a device that has been set up and is a member of a mesh network. Nodes have functionality related to the product type, but can also have functionality regarding the operation of the network itself and can take on special roles.

This is determined by the mesh features they support. All nodes can send and receive mesh messages in the network . In addition, nodes can optionally support one or more additional network features, as listed below:

Relay functionality: The ability to receive and retransmit mesh messages over a broadcast bearer to enable larger networks.

Proxy functionality : The ability to receive and retransmit mesh messages between GATT and advertising bearers.

Low Power Features: Ability to operate within a mesh network with a significantly reduced receiver duty cycle. Minimizing the time the radio receiver is on results in reduced power consumption for the node, with the receiver enabled only when strictly necessary. Low Power Nodes ( LPNs ) achieve this by establishing friendships with Friend nodes .

Friend functionality: The ability to help the LPN operate by storing messages addressed to the LPN , and only forwarding them when the LPN explicitly requests messages from a “Friend” node.

To understand how Friendship enables LPNs to reduce power consumption, consider sensors. Sensors are a good example of a type of node that might take advantage of Friendship and act as an LPN . They typically spend the most time transmitting data, and rarely need to receive data. Perhaps a sensor only sends a temperature reading when it is outside a set of configured limits, and perhaps this only happens twice a day. This infrequent data transmission keeps the energy consumption of this type of device low.

But what if these temperature limits need to be modified to use different values ​​depending on the season, and the modification of these limits is achieved by sending configuration messages to the sensor? For the sensor to receive such a message directly, it needs to switch the radio on and listen. Most of the time it is listening, not receiving anything, but energy is consumed.

So, working with a Friend allows the LPN to schedule the use of wireless to receive messages to whatever frequency makes sense for that device, and at a much lower frequency than it would otherwise need if it had to receive messages all the time. LPNs poll their Friend for new messages, and the Friend only stores them occasionally. This is how power is saved.

Friendly neighbors and low-power nodes

The LPN must establish a Friendship relationship with another node that supports the Friend function to reduce its receiver duty cycle and save energy. Figure 1 is taken from the Bluetooth mesh specification. In addition , it illustrates the relationship between the LPN and the Friend node. In particular, it shows :

· Light blue: LPNs

· Dark grey: Friend nodes associated with and service specific LPNs

· Light grey: Friend nodes which do not have a relationship with anLPN

Light blue: LPN

Dark grey: Friend nodes associated with a specific LPN

Light grey: Friend nodes that have no relationship with LPN

Figure 1 - Example of a mesh network topology

Friend node P has a Friendship relationship with LPNs I , J , and K. Friend node O has a Friendship relationship with LPNs L and M. Therefore, a message addressed to node I , J , or K will be stored and forwarded by Friend P. Node L or M will be stored and forwarded by Friend O. Forwarding by a Friend node occurs only when an LPN polls a Friend for a message waiting to be delivered.

Friend node parameters

The LPN needs to find "Friend" nodes and establish friendship relationships with them. The procedure involved is called Friend establishment. We will examine this process later, but before we introduce some key parameters about the LPN behavior, because these parameters are set during the Friend establishment process.

1. ReceiveDelay is the time that elapses between the LPN , sending a request to the Friend node, and starting to listen for a response. This allows the "Friend" node time to prepare its response and send it back.

2. ReceiveWindow is the time the LPN spends listening for a response. Figure 2 illustrates the timing involving ReceiveDelay and ReceiveWindow .

Figure 2- ReceiveDelay and ReceiveWindow timing

1. PollTimeout establishes the maximum time that may pass between two consecutive requests sent by the LPN to its "Friend" node. If the Friend node does not receive a request from the LPN before the PollTimeout timer expires , the Friendship will be terminated.

Figure 3- PollTimeout timing

Friend node establishment

If two people want to establish friendship, a glance is enough! In order to establish friendship in Bluetooth mesh network , several steps are required.

1. The LPN issues a Friend Request message. This message is not relayed, so only "Friend" nodes in direct wireless range can process it. Nodes without Friend functionality discard it. The Friend Request message includes the LPN 's ReceiveDelay , ReceiveWindow , and PollTimeout parameters.

1. Each nearby Friend node that can support the requirements specified in the Friend Request message prepares a Friend Offer message and sends it back to the LPN . The message includes various parameters, including the supported ReceiveWindow size, the available message queue size, the available list size, and the RSSI value measured by the Friend node .

2. Upon receiving a "FriendOffer" message, the LPN selects a suitable Friend node by applying an implementation-specific algorithm. The algorithm may take various factors into account. Some devices may prioritize the receive window size to minimize power consumption, while others may focus more on RSSI values ​​to ensure they can maintain a good link quality with the "Friend" node. The exact algorithm used is determined by the product developer.

3. After selecting a Friend node, LPN will send a Friend Poll message to the Friend node .

4. After receiving the Friend Poll message from the LPN , the Friend node replies with a Friend Update message, which ends the Friend establishment process and provides security parameters. At this point, the Friendship is established .

Friend node information

After the Friendship is established, the "Friend" node stores all messages of the LPN in the Friend Queue . These are called stored messages. Figure 4 below illustrates the message exchange between the Friend node and the associated LPN .

When a Friend node receives a message addressed to the Friend node’s LPN , the Friend node buffers this message and stores it in an area called the Friend Queue . In Figure 4 , we can see that messages 1 and 2 are stored in the Friend node on behalf of the LPN .

Periodically , the LPN causes its transceiver to send a Friend Poll to the Friend node, requesting that any buffered messages be stored for it.

The “Friend” node first sends a stored message back to the LPN as a reply to the “ Friend Poll ” .

After each received message from a Friend node, the LPN will continue to send Friend Poll messages until it receives a FriendUpdate message with the MD ( MD = More Data) field set to 0. This means that the LPN has no more messages buffered. At this point, the LPN stops polling the Friend node.

图 4- Friendship messaging

safety

Security is ubiquitous in Bluetooth networks. This is also true for Friendship , which uses two special security credentials:

Master security material : Derived from the NetKey , it can also be used by other nodes in the same network. Messages encrypted using the master security material can be decrypted by any node in the same network.

Friend security material : Derived from NetKey , with some additional counter numbers generated by LPN and Friend nodes. Messages encrypted with Friend security material can only be decrypted by the Friend and LPN that possess it .

What are the two security materials used by LPN and Friend nodes ? The summary is as follows:

The corresponding Friendship message encrypted with Friend 's securitymaterials is:

· Friend Poll

· Friend Update

· Friend Subscription ListAdd/Remove/Confirm

Stores messages sent by Friend nodes to LPN

The corresponding Friendship message encrypted using the master security material is:

Friend Clear ​

Friend clear confirmation

Messages sent from the LPN to the Friend node will be encrypted using the master or Friend 's security profile , depending on the application settings .

Terminate neighbor nodes

Friendship can be terminated in certain circumstances :

If no Friend poll , Friend Subscription List Add , or Friend Subscription List Remove message is received by the Friend node before the PollTimeout timer expires , the Friendship terminates.

· The LPN can initiate the Friendship termination process by sending a Friend Clear message to a Friend node , causing the Friendship node to be terminated by the Friend .

Platform selection recommendations

Developers should consider the following guidelines when choosing a platform to implement Friend and LPN :

RAM capacity: The amount of RAM available directly affects how many LPNs a Friend node can support, and how many messages it can buffer for associated LPNs .

LPN : The general power performance of the selected MCU and module is key to the LPN . In addition, the wake-up / warm-up time from sleep mode to run mode affects the response speed and latency of the LPN .

As a developer, I believe we can share your expectations for the Bluetooth mesh SDK . Then we can share Bluetooth mesh " Friendly Nodes " together !

To learn more about Silicon Labs ’ Bluetooth mesh solutions and technology, visit:

https://cn.silabs.com/products/development-tools/software/bluetooth-low-energy/ble-mesh

Original link: https://blog.bluetooth.com/bluetooth-mesh-networking-series-friendship

You can also scan the following QR codes to follow Silicon Labs on social media: