Bluetooth mesh models: The building blocks for interoperable products

Article By : Martin Woolley

Bluetooth technology is a wireless standard with agreed, formal specifications that support global interoperability between devices from different...

Bluetooth® technology is a wireless standard with agreed, formal specifications that support global interoperability between devices from different manufacturers. The same is true of Bluetooth mesh, which enables lights, sensors, switches, and other devices to work when installed in a state-of-the-art smart building.

Interoperability is a benefit of standardization across every layer of the entire communications stack — from the physical layer, dealing with the analogue world of radio at the bottom, to user level behaviors that products may exhibit at the top. The Bluetooth mesh specifications define those product behaviors in terms of granular, standard building blocks called models.

In part due to this interoperability, Bluetooth mesh has become the clear choice for large-scale device networks – from connected lighting to controlling complex smart building and industrial systems. In fact, Bluetooth mesh product qualifications (formal certifications) have doubled every six months for the last two years with no signs of slowing down. According to the 2020 Bluetooth Market Update, one billion networked smart devices will ship annually by 2024. As Bluetooth becomes the standard for device network connectivity, understanding how to use mesh models is important to any developer.

What is a Mesh Model?

According to the Bluetooth mesh glossary of terms, “a model defines a set of States, State Transitions, State Bindings, Messages, and other associated behaviors. An Element within a Node must support one or more models, and it is the model or models that define the functionality that an Element has. There are a number of models that are defined by the Bluetooth SIG, and many of them are deliberately positioned as “generic” models, having potential utility within a wide range of device types.”

In short, elements are addressable parts of a physical product, which itself is known as a ‘node.’ Models are specifications for standard software components that, when included in a product, determine what it can do as a mesh device. Models are self-contained components and products will incorporate several of them, which collectively make the device what it is.

Understanding States in Models

Models contain states, which are data items that indicate the condition of the device, such as on/off or high/low. States may be simple, containing only a single value, or composite, containing multiple fields, similar to a struct in programming languages like C. When there are relationships defined between state items, these are called state bindings. These specify that if one of the states in the relationship changes, then the other state needs to have its value recalculated.

Sometimes state bindings are conditional and may be enabled or disabled by some other states. In these instances, developers must implement the required logic for any state bindings that are defined for the models they are using and ensure that logic is executed. However, in instances where state bindings are not explicitly defined in the Bluetooth Mesh Model Specification, states must act independently.

Consider a rotary dimmer switch that is rotated to change the level of the lights in the room but can also be pressed to switch them on or off. You can rotate the control when the lights are off and nothing will appear to happen, but if you then press the switch, with it in the same rotated position, the lights will come on at the selected level of brightness. In this instance, if the generic on/off state indicates that a device is currently off, increasing the generic state level should have no user-discernible effect. Switching the device on by setting the generic on/off state to 1 not only switches the device on, but it also enables it to begin functioning at the level that has been set.

Model Classifications, Communication, and Behaviors

Models have two classifications – the first being clients, which do not contain state. The second are servers, which do contain states. Some of the server models have an associated ‘set-up model’ which contains configuration data. SetUp server models are similar to other server models in that they contain a state and they produce and consume particular types of messages. But their purpose is to allow a separation of a model’s configuration settings from the main model state items so that distinct access control policies can be applied, usually by a network administrator.

Models communicate with each other by sending and receiving messages. Messages are defined as part of the specification for each model so that it’s clear what types of message a model can produce and also receive and understand. Messages either communicate a state value to another device or they change a state value, eliciting an often-visible response from a device.

Models can have specified dependencies on other models. They may also extend another model, which is a process in which the first model adds states to the second model. A model may also require that a model which extends it be present. Models that do not extend other models are known as root models.

Object Oriented Approach in Bluetooth Mesh Models

When thinking about models, it’s helpful for software developers to consider model specifications through the lens of the object-oriented software engineering paradigm and model implementations in code inside a device as an instance of the model or object. The Bluetooth mesh specifications do not stipulate any particular approach to implementing models in code. This is left up to the developer, the programming language, and the APIs in use. However, models do lend themselves to an object-oriented approach.

There are a number of software developer kits (SDK) available for developing mesh firmware. No matter what SDK you use, however, the principles in implementing mesh firmware will be the same. The examples in this article relate to the Zephyr RTOS and its APIs.

The Role of Properties in Mesh Models

There are two forms that data can take in a Bluetooth mesh model – state and properties. State values are members of particular models and have a value based on a meaning as defined by the specification. However, they are not self-describing and the state a message relates to is inferred from the unique, identifying opcode of the message.

On the other hand, properties are data items whose permissible values, their meaning and other aspects of the data depends on the context of their use. Properties are explicitly identified by a property ID. In a model where a property is in use, the property ID and property value comprise the value of a state. For example, when looking at sensor data the state contains one or more pairs of property ID and a corresponding sensor value.

Properties allow the same model to be used with a wide range of data types. This is hugely advantageous in the case of models like the sensor server model since any type of sensor data can be handled and interpreted with respect to any context (provided a suitable property has been defined). Without this approach to describing and encapsulating data, many different types of sensor models would be required, or the sensor server model would need to have a large number of states for each of the different types of sensor data it might need to support.

Coding Models

One of the first steps a mesh firmware developer must take is to define their product’s mesh node composition. This means that the code defines how many elements the node has and what models each of the elements contains. The figure below shows the relationships between the node, its elements, the models contained within elements, and the items of state that each model contains.

Although details will vary across SDKs, using the Zephyr SDK node composition involves creating a series of arrays, each of which contains structs defined by macros that the SDK provides. This may look like the figure below that shows the four models belonging to the elements of a node.

(Source: Bluetooth SIG)

When implementing models, here is some of the functionality that is typically necessary:

1. RX Message Handler Functions

The opcodes of messages associated with each model and which the node might receive (RX) must be registered and the functions for handling those message types must be implemented. An example of what this looks like in Zephyr code is below.

(Source: Bluetooth SIG)

When messages are received by a model, it either changes a state value (set) or requests that the current value of a particular state be reported in a status message (get). Set messages come in two forms – those that do not require a response (unacknowledged) and those that require the new state value to be sent back in a status message. Sometimes the term “set” can be used to mean either of those two variations.

When developers are handling state changes produced by set messages, it’s important to ensure that any defined and active state bindings are processed and other dependent state values are recalculated as required.

2. TX Message Producer Functions

Functions that formulate mesh messages and use the appropriate API to send messages need to be written so that their execution is triggered by suitable events or device interactions – like when a user presses buttons or turns knobs.

Developers will be largely concerned with the parts of mesh messages that relate to the top layer of the stack, known as the “access layer” (though there can be exceptions).

When implementing models, it is important to respect the fact that client models and server models must know nothing about each other’s implementation details. For example, a server should not need to know or choose to exploit knowledge of the specific values that a client might be able to send. Each is a black box to the other.


Security in Bluetooth mesh devices is mandatory. When a new device is first set up, it is put through a process called Provisioning and Configuration, typically using a smartphone application. Provisioning equips the new device with a series of security keys of various types. Possession of the network key makes the device a member of that particular network and is used to secure data related to lower layers of the mesh stack. Application keys are associated through the configuration process with specific models in particular elements of the new node and are used to secure data relating to higher layers of the stack. Separation of network and application layer data security allows nodes in the network to process messages they are not the ultimate recipient of (e.g. when relaying a message), without needing to or being able to decrypt application related parts of the message.


Arm IoT Solution Overview – Deliver Secure IoT Systems to Market Quickly and Efficiently

The stack will ensure that all messages are encrypted and can be authenticated, using the provisioned network key and appropriate application key. Message headers are also obfuscated, which is a defence against network pattern analysis attacks. Protocol data unit (PDUs) contain the SEQ field, which should be incremented each time a node sends a message. The purpose of the SEQ field is to allow replay attacks to be identified. Messages received which have a SEQ value less than or equal to the last received will be ignored.

Overview of Mesh Models

There are four groups of models defined by the Bluetooth SIG: generic models, models for sensors, models for lighting, and models concerned with time and a mesh automation feature called the scene. In the image below you’ll notice that every client model has a corresponding server model and vice versa. In some cases, server models have a corresponding setup server model too.

(Source: Bluetooth SIG)

Overview of Foundation Models

While models are generally optional and developers implement models that equip their products with the mesh capabilities they need, there are two models whose inclusion is mandatory. These foundation models are concerned with enabling the configuration and management of the Bluetooth mesh network and the devices it contains.

All devices need to be configurable and so the configuration server model is mandatory for all devices. It provides the device with the ability to be configured. The model contains a significant number of states that allow various aspects of a device to be configured. A device’s overall composition is held within a state called the Composition Data state. The destination address to use when sending messages and other parameters relating to periodic message publication, the addresses subscribed to and which, if any of various special mesh network roles a device may play, are all part of the configuration model’s data.

Typically, developers only need to ensure the configuration server model is part of their device’s firmware. However, sometimes developers explicitly perform part of the device’s configuration from within their code.

The Health model is another mandatory foundation model and is concerned with fault reporting and diagnostics.The primary element of all nodes in a Bluetooth mesh network must include a health server model, although other elements may inform this model of faults as well. In a health server model, a series of fault-related states are defined for the health server model. Faults are represented by single octet codes.

Models in Action – Lighting

Bluetooth mesh models are essential in meeting the complex requirements of lighting in smart buildings. Lighting models allow control over the on/off state of lights, their lightness, color temperature, and hue color. Notably, they also provide a highly sophisticated software-based lighting controller that can enable smart lighting automation scenarios.

When considering a lighting model, it’s important to think about the nature of lights and the various ways they can be controlled. Lights are often controlled manually by pressing buttons, turning knobs or pushing sliders. But they can also be controlled by sensors—for instance, indicating to the lights that there is someone in the room. Timers can also be used to control lights. Lights can have more attributes than their on/off state or their lightness that we might wish to control. For smart buildings, the Bluetooth mesh lighting models include a particularly special set of models, like the Light LC models that provide sophisticated, automated control of lights.

Collectively, the lighting control (LC) models form a lighting controller: a software component that allows sophisticated, sensor and user-driven lighting control to be set up. Occupancy and ambient light sensors are catered for so that techniques like daylight harvesting can be employed. As the state of the lighting controller changes, the  lightness state of the light under control progresses through a series of levels, with the transition from one to another governed by configurable timing parameters so that changes are not abrupt and feel natural to building users.

Bluetooth mesh lighting control is entirely software based and supports a superior, decentralized controller architecture with the controller embedded in the lights rather than in physically separate hardware devices. There are cost advantages and significant performance advantages to this approach.

The Business Case for Bluetooth Mesh

Bluetooth mesh networking is quickly being adopted as the wireless communications platform of choice in a number of sectors. Bluetooth mesh enables the automation of a building’s essential systems to harness energy savings, reduce operating costs, and improve a building’s core systems. Bluetooth mesh networks can provide the basis for a distributed platform which could potentially support advanced smart building services, such as wayfinding and asset tracking.

Regardless of the particulars of your industry, mesh models are the building blocks critical to Bluetooth mesh interoperability.

— Martin Woolley is the Technical Programme Manager at Bluetooth SIG

Leave a comment