Bluetooth Mesh Node Communication: Designing Robust Mesh Networks

Building a reliable Bluetooth Mesh network starts with understanding how nodes exchange data. This article explores the core communication mechanisms, node architecture, and the models that enable interoperability across diverse devices.

Managed Flood – The Backbone of Mesh Messaging

Bluetooth Mesh delivers messages through a managed flood strategy. Unlike a naïve flood where every node repeats every packet, managed flood uses a cached message list and a Time‑to‑Live (TTL) field to avoid duplication and limit hops. Each node checks incoming packets against its cache; duplicates are discarded. The TTL, set on each message, decrements by one with every relay and caps at 126 hops, ensuring efficient and predictable delivery.

Publish‑Subscribe Communication

To keep the network scalable and prevent devices from processing irrelevant traffic, Bluetooth Mesh employs a publish‑and‑subscribe model. A publisher sends messages only to groups that have expressed interest, while subscribers receive only those addressed to their group. This model supports unicast, multicast, and broadcast, allowing fine‑grained control in scenarios such as room‑based lighting.

Figure 1 demonstrates a real‑world implementation using Cypress CYBT‑213043‑MESH evaluation kits. Switches act as publishers, and bulbs act as subscribers to the Dining and Kitchen groups. When Switch 1 publishes to the Dining group, the first three bulbs respond. Switch 2, publishing to the Kitchen group, controls only the third bulb.

Figure 1. Bluetooth Mesh Publish and Subscribe example for connected lighting. (Source: Cypress)

Node Architecture – Elements, Addresses, and Models

Each Mesh node contains one or more Elements, the functional building blocks that expose device capabilities. Every Element receives a unique unicast address, enabling independent control. A typical light bulb has a single Element for on/off and brightness. A dimmable bulb with an occupancy sensor would have two Elements: lighting and sensing.

Figure 2 illustrates nodes with one and two Elements, highlighting the address space and the relationship between Elements and Models.

Figure 2. Nodes with one and two Elements. (Source: Cypress)

Models – The Language of Mesh

Functionality is defined by Models, analogous to Bluetooth services. Models fall into three categories:

• Server Models expose state that can be read or modified by Clients (e.g., On/Off Server, Light Lightness Server).
• Client Models send requests or commands to Servers (e.g., On/Off Client used by switches).
• Control Models combine Client and Server logic with application code to act on messages.

Server Models can manage multiple states across one or more Elements. For example, a dimmable bulb may host both an On/Off Server and a Light Lightness Server. Client Models enable devices like switches or dimmers to query or change those states.

Models can extend each other. The Light Lightness Server extends the On/Off and Generic Level Servers, allowing a single On/Off command to affect any bulb type, regardless of its underlying model.

States – The Data Behind Each Element

Each Element maintains States, defined by the Bluetooth SIG. States hold values (e.g., ON/OFF) and behaviors. For instance, a sprinkler controller’s On/Off Server exposes a Generic OnOff state, which can be manipulated by any Client that understands that state.

Next Steps – Privacy and Security

In our next article, we’ll delve into Bluetooth Mesh’s robust privacy and security mechanisms, essential for protecting your network against eavesdropping and unauthorized control.

For deeper insights, watch our Learning More about Bluetooth Mesh video and begin designing your own mesh-enabled application.