Since its beginning, Bluetooth Low Energy (BLE) has been an essential part of personal networking. Bluetooth connects devices like smart watches and wireless earbuds, which many people use every day. As the Internet of Things (IoT) grew, a new challenge appeared: connecting hundreds or thousands of devices across large spaces like offices or warehouses. However, the old ‘star’ network structure of BLE couldn’t handle this scale. It wasn’t suitable for smart building automation, where every light, sensor, and switch must communicate reliably. Therefore, engineers created Low-Power BLE Mesh, enabling large, energy-efficient networks for modern IoT needs.
To meet this market need, the Bluetooth Special Interest Group (SIG) introduced a major change in 2017 the Bluetooth Mesh standard. This was more than just an update. It was a complete evolution that added a true many-to-many communication system on top of the existing BLE technology. With this, BLE Mesh provided a standard, interoperable, and low-power solution for large device networks, making Bluetooth a leading technology for the IoT. It takes advantage of the huge number of existing devices that already have BLE hardware. Often, these devices only need a firmware update to gain mesh capabilities, which significantly lowers the cost and difficulty of creating advanced, connected environments.
How does Low-Power BLE Mesh network work?
The architecture of Bluetooth Mesh is a layered protocol stack designed for robust and interoperable communication. It builds directly upon the standard BLE physical layer, but its higher layers define the logic of the mesh itself.
Key layers include the Bearer Layer, which handles physical transmission over BLE advertising channels. Next is the Network Layer, responsible for message addressing and relaying. The Transport Layers manage message segmentation and end-to-end encryption. Finally, the Access Layer formats data for applications.
The true genius of the architecture lies in its application-level concepts, which ensure that devices from different manufacturers can work together seamlessly.
What is the role of Nodes, Elements, and Models in BLE Mesh?
Once a device is securely added to the network, it is called a Node. A single node can contain multiple independently addressable and controllable parts, known as Elements. For instance, a smart power strip is a single node, but each individual socket is a separate element.
The function of each element is defined by Models. A model is a standard description for a specific action. It includes States (data values like on/off or a temperature reading) and Messages (commands to get, set, or report a state).
This use of models is the key to making devices from different brands work together. Instead of just standardizing how to send data, BLE Mesh standardizes the meaning of the data. For example, any switch that uses the official “Generic OnOff Client” model can control any light that uses the “Generic OnOff Server” model, no matter who made them.
Publish-Subscribe (Pub/Sub)
Instead of direct device-to-device connections, BLE Mesh uses a publish-subscribe model. In this system:
- A node publishes (sends) a message to a specific address. This is typically a group address, like “Office Lights” or “Floor 2 Sensors”.
- Other nodes subscribe to one or more addresses. Any node subscribed to the “Office Lights” address will receive and process the message.
The main benefit of this system is that devices are not directly tied to each other. For example, the publishing node (like a light switch) doesn’t need to know the specific addresses or even how many subscribing nodes (such as light bulbs) exist. As a result, the network remains very flexible and easy to expand. If you want to add a new light to the office, you simply set up that node to subscribe to the “Office Lights” group, and you leave the other devices unchanged.
What is managed flooding in Mesh Networks?
Rather than using a complex routing system, Low-Power BLE Mesh uses a method called managed flooding to deliver these messages. When a node sends a message, it is broadcast to all the other nodes within its reach. Any nodes set up as relays will then re-broadcast the message. This allows the message to spread, or ‘flood’, throughout the entire network.
This method was chosen because it is simple and very reliable. The flooding approach creates multiple paths for a message to travel. This means a message can get to its destination through several different routes, which makes the network very robust. Even if one node fails, the message can still get through using another path, making the network self-healing. To keep this flooding from creating too much network traffic, two main control methods are used:
- Time-to-Live (TTL): Every message has a TTL number that goes down by one each time it is relayed. When the TTL gets to 1, the message is not relayed anymore. This stops messages from traveling forever in loops.
- Message Cache: Every node keeps a list of messages it has seen recently. If a node gets a message that is already in its list, it ignores it. This stops the same message from being re-sent over and over.
The designers made this practical choice for situations like building automation, where delivering group commands reliably matters more than saving bandwidth.
What are the different types of Nodes in Mesh Networks?
All nodes can send and receive messages, but the Bluetooth Mesh standard also defines four optional features. These features let nodes take on special roles to meet different network needs.
- Relay Nodes: These nodes are the backbone of the network. They retransmit messages they receive to extend the network’s range. Because they need to be listening all the time, Relay nodes are usually devices that are plugged into a wall outlet, like smart light bulbs or plugs.
- Proxy Nodes: These nodes are a bridge between the mesh network and standard BLE devices, like smartphones, that don’t have the full mesh software. A Proxy node can talk to the mesh network and also connect to a phone using a standard BLE connection, passing messages between the two.
- Low Power Nodes (LPNs): These are devices that run on batteries, like sensors, and are designed to use very little power. An LPN sleeps most of the time with its radio turned off. It cannot relay messages and only wakes up for short periods to send its own data or to check for new messages.
- Friend Nodes: To get messages, an LPN forms a Friendship with a mains-powered Friend node. The Friend node acts like a mailbox. It listens for messages addressed to the LPN, stores them, and then delivers them when the LPN wakes up and asks for them (a process called polling). This relationship is a very clever solution, as it moves the high-energy job of listening from the battery-powered sensor to a device with plenty of power.
What steps do you follow during the provisioning process?
The security of a mesh network starts with provisioning. This is the process of safely adding a new device to the network. This process is designed to be very secure to create a strong foundation of trust. It is managed by a provisioner, which is usually a smartphone app. The process has five main steps:
- Beaconing: The unprovisioned device advertises its presence.
- Invitation: The Provisioner invites the device to join the network.
- Public Key Exchange: The two devices use Elliptic Curve Diffie-Hellman (ECDH) to securely generate a shared secret without ever sending it over the air.
- Authentication: The device is authenticated, often using an Out-of-Band (OOB) method like scanning a QR code or entering a number, to protect against Man-in-the-Middle (MITM) attacks.
- Provisioning Data Distribution: The provisioner uses the secure channel to send the device its unicast address and the network keys, officially making it a node.
How can you implement BLE Mesh using the ESP32 platform?
The ESP32 system-on-a-chip (SoC) is a favorite among developers looking to build affordable Low-Power BLE Mesh projects. Most people work with Espressif’s IoT Development Framework (ESP-IDF), which comes packed with a complete, standards-compliant ESP-BLE-MESH stack right out of the box.
Espressif based its stack on the open-source Zephyr Project mesh stack, giving developers a solid and tested starting point. For an ESP32 project, enable mesh features with menuconfig, write code to handle mesh events, then compile and load it onto the chip. The code relies on ESP-IDF APIs to interact with the mesh network, such as sending messages or handling provisioning requests.
This framework translates the abstract concepts of the mesh specification into concrete, configurable options, thereby simplifying development.
|
Configuration Patch (idf.py menuconfig) |
Key Option | Purpose |
|---|---|---|
|
Component config -> Bluetooth -> Bluetooth Mesh |
Enable Bluetooth Mesh support
|
Top-level switch to include the entire ESP-BLE-MESH stack in the build |
|
Component config -> Bluetooth Mesh -> Support for BLE Mesh Feature |
Relay |
Enables the node to act as a Relay, retransmitting messages |
|
Component config -> Bluetooth Mesh -> Support for BLE Mesh Feature |
GATT Proxy |
Enables the node to act as a Relay, retransmitting messages |
|
Component config -> Bluetooth Mesh -> Support for BLE Mesh Feature |
Friend |
Enables the node to act as a Friend, caching messages for LPNs |
How to build own mesh device?
For a developer looking to build their own mesh device, the process typically starts by adapting one of the official examples provided within the ESP-IDF, such as the onoff_server example which implements a basic switchable node. After flashing the code, you turn a blank ESP32 into a functioning node in two steps: provisioning and configuration. First, a provisioner – usually a smartphone app like nRF Mesh – securely adds the device to the network, assigning it a unique unicast address and the shared Network Key. This makes it a member of the network.
The second phase of configuration is where the application – specific behavior is defined. The provisioner binds Application Keys to the models on the node (e.g., binding the “lighting AppKey” to the Generic OnOff Server model) and sets the publish and subscribe addresses that determine which messages the node sends and listens to. On the device side, the ESP32 application code is event-driven. Developers write callback functions, and the ESP-BLE-MESH stack calls these functions when specific events occur, such as when the device receives a message.
For instance, when a Generic OnOff Set message arrives, a registered callback function is triggered, which would contain the custom code to toggle a GPIO pin and turn an LED on or off. This powerful framework allows developers to focus on implementing their product’s features rather than the low-level details of the mesh protocol.
What have we learned and what is next for BLE Mesh?
Low-Power BLE Mesh is a major step forward for the Bluetooth standard, created specifically for the needs of the modern IoT. Its design successfully balances the need for large, reliable networks with the low-power needs of battery-powered devices. The technology can scale to thousands of nodes and uses multiple message paths for reliability. It requires multi-layer security and supports devices from different brands through a standardized model system. These strengths make it ideal for commercial smart lighting and drive its growth in building automation and industrial sensor networks.
Platforms like the ESP32 make development easier and cheaper. Gateways connect these local networks to the cloud for data analysis and remote management. As a result, Bluetooth Mesh is becoming an even more important part of our connected world. It has turned Bluetooth from a personal gadget technology into a real networking solution for large-scale and industrial use.
Ready to unlock the power of BLE Mesh Network for your next project? Get in touch with WizzDev to discuss how we can help turn your vision into reality.
