Bluetooth Mesh Node Power Consumption#

Bluetooth mesh nodes (other than Low Power nodes) are always listening for messages from the other nodes. Because the nodes are always on and receiving, they consume quite a lot of power and are typically connected mains or respective power sources (for example, coin or button cell batteries might have too short a lifespan for actual usage). You can learn about the radio/power operation and consumption in the datasheets for your part, SoC, or module.

The Mesh Profile Bluetooth® Specification Revision v1.0.1 defines a Low Power Node, Friend node, and the concept of friendship as follows:

  • Low Power Node: The ability to operate within a Bluetooth mesh network at significantly reduced receiver duty cycles. Minimizing the time the radio receiver is on leads to lower power consumption with the node only enabling the receiver when strictly necessary. LPNs achieve this through establishing a friendship with a Friend node.

  • Friend Node: The ability to help an LPN operate by storing messages destined for the LPN and only forwarding them to it when the LPN explicitly requests messages from the Friend node.

Low Power Node and Friend Node#

An LPN must first make a friendship with a Friend node. Once this has been established, the Friend node will receive and queue various messages going to the LPN on behalf of the LPN. There are configurable limitations for the messages that the Friend node can store for LPNs to control Friend node memory usage. Because the LPN does not have to be on and receiving all the time, it can sleep and periodically check the incoming messages from its Friend node. The LPN can send a mesh message to the Friend node and other nodes at any time. There are also some mechanisms like timeouts and maximum retries set for the communication and if those occur, the friendship will end. The friendship does not remain after restarting the device (LPN or Friend node). However, it is always possible to establish the friendship again.

Creating a Friendship#

When the Friend node is started, it does not have any friendships with LPNs; it is just waiting for a Friend Request from LPNs. A Friend node can have several friendships with LPNs at the same time, depending on the Friends resources. After receiving Friend Requests with requirements that the Friend node can serve, the Friend node will reply with a Friend Offer. An LPN can also have requirements that are not compatible with the Friend node. In this case, the Friend node will not reply.

When the LPN is started, it also does not recall any friendships but starts transmitting Friend Request and waits for Friend Offer replies. Currently an LPN can have only one friendship at a time in the Silicon Labs implementation. When establishing a friendship, the LPN uses a great deal of power, so it usually wants to find a reliable friendship quite soon and not waste any power when searching for Friend nodes.

As the LPN sends Friend Requests, it will inform the Friend node of its requirements such as the PollTimeout and ReceiveDelay parameters (see PollTimeout and ReceiveDelay). As a return it can get several Friend Offers from Friend nodes. The Friend node provides information about itself such as ReceiveWindow size, message queue size, message subscription list size and RSSI measured from the Friend node.

The timing parameters are illustrated in Figure 3.17: Friendship timing parameters of the Mesh Profile Bluetooth® Specification Revision: v1.0.1.

After receiving Friend Offers, a very good Friend Offer, or waiting for Friend Offers for a while (depending on the implementation), the LPN will use some algorithm to select a Friend Offer that fits the best and sends a Friend Poll message to the selected Friend node. The Friend node replies with a Friend Update message which concludes the process by providing the security parameters and the friendship is established.

The friendship establishment is illustrated with one Friend node in Figure 3.19: Establishment of a friendship and for multiple Friend nodes in Figure 3.21: Friend establishment example of the Mesh Profile Bluetooth® Specification Revision: v1.0.1.

Maintaining the Friendship#

A Friend node is always listening for messages. If it does not receive certain messages (typically a Friend Poll) from an LPN before the PollTimeout has passed, the Friend node will terminate the friendship. If the Friend node receives a correct message from an LPN, it will send a message back after ReceiveDelay during the ReceiveWindow. The Friend node responds to Friend Poll messages with queued Bluetooth mesh messages that could be normal messages, configuration messages, or security updates. The Friend node informs the LPN that it has no more queued messages using a Friend Update reply with the MD flag set to 0. Other messages or Friend Update replies with the MD flag set to 1 will continue being sent to the LPN.

An LPN can send a Bluetooth mesh message at any time to a Friend node or other nodes. But it has to send certain messages (typically a Friend Poll) to its Friend node before the PollTimeout has passed; otherwise, the Friend node terminates the friendship. Also, if the Friend node does not reply to LPN messages after several retries (the default is three times), the Friend node terminates the friendship.

PollTimeout timer is illustrated in Figure 3.18: Poll Timeout timer illustration of the Mesh Profile Bluetooth® Specification Revision: v1.0.1.

Low Power Node Settings#

The following subsections describe the LPN settings related to the power consumption.

PollTimeout#

The PollTimeout setting has the following characteristics:

  • Establishes a maximum time which may elapse between two consecutive requests sent by the LPN to its Friend node. If no requests from an LPN are received by the Friend node before the PollTimeout timer expires, the Friend terminates the friendship.

  • Duration: 10 to 3,455,999 in 100 ms = 1 sec to 345,600 sec = 5,760 min = 96 hours = 4 days

  • The longer the PollTimeout, the more the LPN can sleep. On the other hand, this also means that the LPN receives messages less often and it takes more time for other nodes or the Provisioner to communicate with the LPN.

  • This is the most important parameter when controlling the LPN power consumption.

ReceiveDelay#

The ReceiveDelay setting has the following characteristics:

  • The time which elapses between the LPN sending a request to the Friend node and the Friend node starting to listen for a response. This allows the Friend node time to prepare its response and send it back.

  • Duration: 10 to 255 ms

  • Requested by the LPN.

  • If it is too small, the Friend node might not send a Friend Offer.

  • Can be adjusted by the application.

  • Does not have much effect on LPN power consumption.

Friend Node Settings#

The following subsections describe the Friend node settings.

ReceiveWindow#

The ReceiveWindow setting has the following characteristics:

  • The time that the LPN spends listening for a response.

  • Duration: 1 to 255 ms

  • Defined by the Friend node.

  • The smaller the ReceiveWindow, the less time the LPN needs to stay on and listen for messages if no message is received.

  • If there is a response, listening stops immediately.

  • Usually set by the system, not the application.

  • Different Friend node brands have different ReceiveWindow sizes.

  • Silicon Labs products normally have a ReceiveWindow of 10 to 20 ms.

  • If the maximum of 255 ms is used for the ReceiveWindow setting in Friend node, the LPN power consumption can be much larger, as much as 25 times larger if no message is received in time.

  • The LPN can affect power consumption by selecting a Friend node with the smallest ReceiveWindow.

  • ReceiveWindow has a significant effect on LPN power consumption if the connection is not perfect. However, with a good signal and connection, the size of the ReceiveWindow does not matter.

Power Consumption-Related Guidelines#

  • Proxy feature uses a lot of power so avoid using this frequently. See the measurements in Low Power Node Friendship Established and Low Power Node Friendship Established with Proxy turned Off.

  • Transmit as few messages as possible as transmission always increases power consumption noticeably.

  • Subscribe as few messages as possible.

  • Do not change subscriptions often.

  • Target fewer unicasts to the LPN.

  • Be sure that the LPN receives a Friend node, and the friendship stays (that is, the signal is sufficient). An LPN that is just on the signal edge could make a friendship, then lose it, and make it again. Going back and forth like this is not very efficient because establishing every friendship consumes more power than being in a friendship.

  • Do not restart the LPNs or Friend nodes often as the friendship has to be established again.

  • When an LPN is establishing a friendship, do not blindly keep trying in a busy loop. Have a backoff policy if no acceptable Friend Offers are received.

  • Acknowledged messages and especially segmented acknowledged messages for other nodes might be slow as the acknowledgements return via the Friend node. This also might have an effect in power consumption.

  • Do not keep the node in unprovisioned state because it will remain awake and consume high current, accordingly.

For more detailed information about the LPN, Friend node, friendship, and timing parameters, see chapter 3.6.6 Friendship of the Mesh Profile Bluetooth® Specification Revision v1.0.1.