BLE Mesh: Friends are the Key to a Long [Battery] Life

By Mahendra Tailor

Principal Bluetooth Consultant

Tailored Technology Limited

July 16, 2019


BLE Mesh: Friends are the Key to a Long [Battery] Life

An introduction to achieving energy efficiency in battery-powered BLE mesh devices.

Friendship is powerful. It’s well established that friendships help people live longer, happier, more fulfilling lives. The same is true for Bluetooth Low Energy (BLE) devices when it comes to battery life: Friendship between BLE mesh devices is the key to achieving extended battery life and a successful BLE mesh deployment.

Friendship Makes BLE Mesh Last

BLE mesh devices in their standard configuration are not energy-efficient. That is because BLE mesh networks operate on an always-on, always-listening, always-communicating model that enables the communication that is so central to what makes this type of networking advantageous for wireless network applications. But there is a downside to the always on approach: high power consumption and shortened battery life.

A BLE mesh device that is always listening and communicating is putting a constant drain on its battery, shortening what would otherwise be a months-long battery life into a battery that uses up its last ions within weeks or even days. That simply is not practical for battery-powered wireless sensors and other wireless devices. It undermines the very reason why the engineering team is deploying easy-to-install wireless sensors in the first place. A wireless device network that needs to have batteries swapped out every couple of weeks would not be well received by customers.

So how do you avoid inefficient battery usage? The key is to use an important feature in BLE mesh that allows device designers and provisioners to designate “friendships” between the battery-powered low power node and a permanently powered friend node. This is done with the specific goal of the friend expending the energy to listen and cache mesh messages on behalf of the low power node while it sleeps most of the time.

Every BLE mesh device has four “roles” embedded into its capabilities that can be activated and utilized by the provisioning engineers working on a mesh deployment:

  • Relay capabilities
  • Proxy capabilities
  • Low power node capabilities (focusing on listening-only mode)
  • And friend device capabilities

These are not either/or capabilities. Every device that utilizes BLE mesh technology has all of these capabilities, the same way that a car has the embedded capability to be in park, reverse, first gear, second gear, etc. These four capabilities are all simply waiting for the provisioning engineer to choose what best suits the role of the node in the bigger scheme of the wireless device network.

Low power node and friend device capabilities are the two roles that effectively manage power consumption and battery life. In order to maximize battery life, provisioning engineers should envision clusters of “friendship” grouped nodes within their network deployments. This group is comprised of many battery powered low-power nodes in power-saving mode. They are linked to a wire-powered “friend” node that serves as a clearing house for communications to and from all of the devices around it. In this way, the friend node meets the always-on, always-listening role in a BLE mesh network and communicates to the low-power devices that are friends, only when those devices wake up briefly to check for messages to pull and then act on those messages.

It is possible to design low-power nodes in a battery-conserving configuration to not only wake up and check for messages, but also serve as a relay so that they are playing a hub-like role. It is possible since low-power nodes do not require the assistance of a friend node to send messages. However, design engineers will most likely opt for maximum battery efficiency by putting low power nodes into listening-only mode and relying on friend nodes to do the rest.

Friend Nodes are Hubs Within a Network

This network-within-a-network approach will be familiar to most wireless engineers that have envisioned and built wireless networks on hub and spoke-type models for decades. The difference with BLE mesh is that the hub is not a specialized gateway or other device that serves as the central brain or clearinghouse for communications. The friend node playing the role of hub is a BLE mesh device with the always on capability activated and the nodes it supports have the power saving mode turned on.

The friend node remains awake at all times, gathering messages and holding onto them until the low power devices wake up and check in. If there are messages for that given low-power device, the friend node delivers them one at a time per pull request. The receiving node then does its task, which may be to act on the message and then send response messages as appropriate. It then goes back to sleep and will wake up again and check in with the friend node to see if any other messages are waiting.

For the device designer, the key responsibility in designing BLE mesh devices is to ensure that each of the four capabilities are available within a device in order to give the provisioner the ability to designate devices as low power nodes or friend nodes. As with other design projects, utilizing a wireless module is a far more efficient approach than developing the hardware and software from scratch. Also, the time saved and speed to market typically achieve cost-efficiency over the build-it-yourself approach as well.

FCC Certification

Certifications are also a critical issue to look at when weighing one approach against another. Pre-built modules like those from Laird Connectivity come pre-certified with the FCC and other regulatory bodies, saving considerable time and cost.


There are no special security considerations that device designers and provisioners need to address in establishing these friendship relationships in a BLE mesh implementation. Enterprise class security is built into the foundation of Bluetooth 4.0 and subsequent releases of the protocol, and all of those security features are leveraged in BLE mesh networks, including double encryption. Friend devices in the same network utilize those security features to securely decrypt and encrypt messages that are held at the nodes serving as hubs and then accessed when low-power nodes wake up and check for relevant messages.


For device provisioners, the key responsibility is in designing and planning a network map of hard-wired friend nodes that support battery-powered low power nodes. Having devices designed this way gives the provisioner flexibility to designate devices in one role or the other and deploy them with the appropriate power source. During the provisioning process, the engineer establishes settings for low power nodes regarding how often they wake up and communicate to the central friend node – balancing frequency of wake/sleep cycles against the battery life they want to achieve. Once deployed, the activated friend devices and low power devices self-organize into clusters using the features built into BLE mesh.

I have 20 years industry experience of designing Bluetooth modules which either exposed an AT interface or an embedded interpreted programming language called smartBASIC. I am the creator of the event driven embedded smartBASIC language which allows functionality to be programmed without firmware experience or toolchains by end product developers. Leverage my experience to quickly help your product be Bluetooth or BLE Mesh enabled so that it can be an IoT device or have the new Audio capability.

More from Mahendra

Networking & 5G