Bluetooth Mesh

Bluetooth Mesh Topologies and Applications

Common Bluetooth Classic and early Low Energy (LE) modes used point-to-point connections, while LE also supported broadcast communication. A smartphone (the master or Central) would connect directly to a headset (the slave or Peripheral), forming a simple, one-to-one link. A Central device could also connect to several Peripherals, creating a star network where application communication passed through the central hub. This model suited personal gadgets but had limitations in distributed Internet of Things (IoT) deployments.

In an office spanning several floors, a control panel may need to manage hundreds of lights, sensors, and thermostats. In a star network, each device must be within direct radio range of the central hub, which can be impractical because of distance, walls, and other obstructions. Relaying messages through other devices can extend communication beyond one direct radio link.

This challenge led to the development of Bluetooth Mesh, a networking standard adopted by the Bluetooth SIG in 2017 as Mesh Profile 1.0. Bluetooth Mesh uses the existing Bluetooth Low Energy physical layer and adds a specialized networking protocol stack. Mesh Profile 1.0 remains the name of the first profile release; later releases are named Mesh Protocol 1.1 and 1.1.1. Its purpose is to transform the traditional one-to-one communication model into a many-to-many (m:m) network. This topology can support device networks covering buildings, factories, and campuses, including applications such as smart lighting, building automation, and industrial sensor networks.

Managed Flooding

Bluetooth Mesh uses a communication principle known as managed flooding. Unlike traditional routed mesh networks where algorithms calculate a path for each message, flooding forwards a message through eligible relay nodes and may use multiple paths.

The Flooding Principle

In a pure flooding network, when a node wants to send a message, it broadcasts it to all of its immediate neighbors. Every node that receives the message broadcasts it again to its neighbors. This process can extend the message across multiple paths, but it cannot guarantee delivery when interference, unavailable nodes, or range limits intervene. Without controls it is also inefficient and can lead to an endless "broadcast storm" where messages circle the network.

Bluetooth Mesh refines this concept into managed flooding by adding two mechanisms to control the message flow:

Mesh Protocol 1.1 also adds Directed Forwarding. The source node can choose managed flooding or directed forwarding, in which only relay nodes on a selected path retransmit the message. The baseline Mesh Profile 1.0 description concerns managed flooding.

• Time to Live (TTL):Every message sent into the mesh network has a TTL value, which is a small number (e.g., 5 or 7). Each time a node retransmits, or "relays," the message, it decrements the TTL value by one. A node will not relay a message with a TTL of 1 or less. The field permits up to 126 relays and acts as a counter limiting the number of forwarding operations and the propagation distance.
• Message Cache: Every node in the mesh network maintains a small cache of recently processed Network PDUs. Before processing a received unit, a node checks its cache. If a corresponding unit is already present, the node discards the new copy. This limits repeated forwarding of the same Network PDU when it arrives from different neighbors and breaks broadcast-storm loops.

Together, the TTL and the message cache turn a chaotic flood into controlled, efficient, multipath communication without a central coordinator or routing tables. They increase the probability of delivery, while the result still depends on radio conditions and node availability.

The Mesh advertising bearer uses the advertising capabilities of Bluetooth Low Energy. Messages on this bearer are broadcast as LE advertising packets on the three primary advertising channels, so this transport is connectionless. A Proxy can expose the network through the GATT bearer. A relay operates at the network layer, while a Proxy provides a GATT connection for a client such as a smartphone. These roles are separate and depend on node configuration.

Node Types in a Bluetooth Mesh Network

A Bluetooth Mesh network consists of nodes that can provide different features. Each node can have one or more of four core features, and the configuration affects network range and power consumption. The enabled features determine whether a node relays messages, stores packets for an LPN, or provides a GATT path.

• Relay Nodes:

  A Relay node forwards messages when the Relay feature is enabled. After receiving a message that is not in its cache and has a TTL greater than 1, it retransmits the message to extend its range. Many mains-powered devices, such as smart light bulbs, smart plugs, and wall switches, can be configured as Relay nodes. Such a node maintains the reception required by Relay and participates in managed flooding, forming multi-hop paths. The node checks the Network PDU cache before forwarding and decrements TTL for each relay operation. Relay is optional, so mains power alone does not make a node a Relay.

• Low Power Nodes (LPNs):

  LPNs reduce power consumption by listening periodically. Small battery-powered sensors, such as a temperature sensor or a door contact sensor, do not keep the radio listening all the time because this would shorten battery life. An LPN spends most of its time in deep sleep, waking briefly to transmit a reading or check for messages. It can operate for years on a single coin-cell battery, but it cannot relay messages for other devices. The LPN uses friendship procedures to poll its Friend during receive windows, rather than keeping the receiver active.

• Friend Nodes:

  An LPN spends most of its time asleep, so a Friend receives messages for it. A Friend is usually mains-powered and may also support the Relay feature; it maintains the relationship with the LPN and queues messages addressed to that node. When the LPN wakes periodically, it polls the Friend, which delivers the stored messages. The battery-powered node therefore remains addressable without continuous listening. The friendship identifies the served LPN and defines the queue used for its messages.

• Proxy Nodes:

  The advertising bearer is the primary mesh transport, but devices that do not support the full Bluetooth Mesh standard, such as most smartphones or laptops, can use a Proxy. A Proxy node mediates between Mesh messages and a standard Bluetooth LE GATT connection, the GATT bearer. A smartphone with a compatible app can connect to the Proxy and then communicate with, configure, and control the mesh network. This path lets an application exchange mesh messages and configuration data through GATT.

Publish-Subscribe Communication Model

Instead of direct one-to-one addressing, where a sender must know the unique address of every receiver, Mesh uses a model known as Publish-Subscribe (Pub/Sub). This separates device configuration and supports group communication.

How Pub/Sub Works in Bluetooth Mesh

The system is based on group addresses and virtual addresses. Half of the address space is allocated to group addresses, while a virtual address uses a 128-bit Label UUID and its hash. Devices are configured to send messages to these addresses (publish) or receive messages addressed to subscribed groups.

• Publishing:A device that wants to send information, such as a wall switch, is configured to "publish" its messages to a specific group address. For example, a switch in the living room might be set to publish an "On/Off" command to the "Living Room Lights" address. The switch does not need to know how many light bulbs are in that group or what their individual addresses are. It simply shouts its command into the network, addressed to the group.
• Subscribing:Devices that should act on information, such as smart light bulbs, are configured to "subscribe" to one or more group addresses. All the light bulbs in the living room can subscribe to the "Living Room Lights" address and receive messages addressed to that group. When the switch publishes its "On/Off" command, each bulb processes it according to its own reception schedule and responds to the command.

The Advantages of the Pub/Sub Model

This model supports group control in smart buildings:

• Scalability and Flexibility:Adding a new light bulb to the living room is simple. You just configure the new bulb to subscribe to the "Living Room Lights" group address. The original switch does not need to be reconfigured or even be aware that a new bulb exists. It continues to publish to the same address, and the new bulb will now respond.
• Group Control: It makes controlling large groups of devices simple and efficient. A single message from one switch can control dozens or hundreds of lights, depending on range, configuration, and node processing time.
• Complex Scenes and Automation:The model allows for complex interactions. A single "Movie Mode" button could publish a command to a "Movie Scene" group. The ceiling lights might subscribe to this group to dim to 10%, the smart blinds might subscribe to close, and the smart TV might subscribe to turn on. All these devices from different manufacturers react to a single, simple command.

Bluetooth Mesh Security Model

Security is part of the Bluetooth Mesh specification. In a network where messages may be relayed by thousands of devices, the security model addresses privacy, authenticity, and access control. Bluetooth Mesh uses a layered model in which each message is encrypted and authenticated.

The security architecture is built on a "separation of concerns" principle, using a set of different security keys for different purposes. Message encryption and authentication use AES-128-CCM, while network and application keys protect separate layers:

1. Device Key (DevKey): Each node added to the mesh network has its own unique Device Key. This key is used primarily during the initial setup process, called provisioning, to establish a secure one-to-one communication channel between the device being added and the Provisioner (e.g., a smartphone app).
2. Network Key (NetKey): Each subnet has its own NetKey, and a node can belong to more than one subnet. The network layer of a Mesh packet is encrypted and authenticated with the NetKey for that subnet. This ensures that only trusted devices belonging to the subnet can relay messages and participate in managed flooding. It protects the network infrastructure from unauthorized access and replay attacks.
3. Application Key (AppKey):This key provides a second layer of security on top of the network layer. The actual payload of a message, such as a "turn on" command, is encrypted with an Application Key bound to the relevant NetKey. Different AppKeys can be used for different applications or functions within the same physical network. For example, all the lights and light switches in a building might share an "Lighting AppKey," while the heating, ventilation, and air conditioning (HVAC) system might use a separate "HVAC AppKey." Light switches can then control the lights without accessing HVAC commands. This separation provides fine-grained access control for building automation.

Dual-layer encryption, at the network level with NetKey and at the application level with AppKey, means that Relay nodes process the network layer to read TTL and handle the cache without accessing application data unless they also possess the correct AppKey. The architecture requires message encryption and authentication, replay protection, key refresh, and subnet separation.