Editor’s Note: Part 1 of this two-part series detailed the architecture and capabilities of the Bluetooth mesh 1.0 protocol. Here, Part 2 describes how to integrate Bluetooth mesh into Bluetooth low energy designs using chips and development kits.
Bluetooth mesh brings the notable advantages of networking to the popular short-range protocol. These were discussed in detail in Part 1. However, the specification also brings new design challenges, particularly when it comes to implementing its models.
The key to overcoming these challenges is leveraging upgraded development tools to gain greater familiarity with Bluetooth mesh. This article describes how to use a selection of Bluetooth hardware and software, development kits (DKs) and software development kits (SDKs) to set-up and build Bluetooth mesh applications.
The Bluetooth mesh stack comprises a completely new host layer that shares some concepts with the BLE host layer, but is not compatible with it. Early versions of the Bluetooth mesh stack are now becoming available for engineering development, typically as part of an SDK.
Because Bluetooth mesh is a complementary specification to the Bluetooth Core Specification, there is no requirement for vendors to update their Bluetooth low energy (BLE) physical layers (PHY) or software stacks to support it. However, adding Bluetooth mesh requires vendors to introduce their own implementations of the stack for their customers.
For example, BLE vendor Nordic Semiconductor has introduced the nRF5 SDK for Mesh. The kit includes a Bluetooth mesh stack, selection of drivers, libraries, and examples for mesh applications. The SDK operates on several integrated development environments (IDEs) and compilers including SEGGER Embedded Studio from Segger Microcontroller Systems and CMake.
Because Bluetooth mesh is compatible with all versions of BLE (i.e.: 4.0, 4.1, 4.2 and 5), Nordic’s mesh SDK will eventually work with all its BLE chips. The current version, however, works only with the company’s latest nRF52 Series BLE solutions such as the mid-range Bluetooth 5-compliant nRF52832 chip.
Because there is no change to the BLE PHY or software stack, Bluetooth mesh development work can be performed on an existing DK incorporating the target device. The DK recommended for the nRF52832 is the nRF52 DK (Figure 1).
Figure 1: Nordic Semiconductor’s mesh SDK will work with the nRF52 DK which incorporates an nRF52832 SoC target device. (Image source: Nordic Semiconductor)
Mesh development demands at least three (and preferably more) devices to communicate and simulate a mesh environment. Ideally, several DKs could be employed to represent the nodes in a mesh, but this has the drawback of significantly increasing development hardware costs. An alternative approach is to use one DK and purchase tested and verified BLE modules (based on the target device) to form the additional nodes. For development with the Nordic nRF52832, Rigado’s BMD-300 or Laird’s BL652-SA-01-T/R are good module options.
Cypress Semiconductor has adopted a similar approach to Nordic. The company offers Bluetooth mesh SDK for its BCM92073X WICED Smart DK which is based on Cypress’ BCM20736S Bluetooth v4.1 PHY. Suitable BLE modules for mesh development work based on this PHY include Inventek’s ISM20736S.
The hardware, software and development tools from Nordic and Cypress come complete with examples and tutorials to guide the developers through the steps of building a simple Bluetooth mesh application. But before embarking on a first design, it helps to run through the associated tutorials to understand the unique characteristics of Bluetooth mesh’s architecture because it has a major bearing on the design process.
Such tutorials highlight that while Bluetooth mesh nodes come in four generic types (see Part 1 of this two-part article series), the capabilities of each is determined by its model(s). Understanding models is the key to making the most of Bluetooth mesh’s capabilities.
Bluetooth mesh offers the flexibility required to build novel mesh applications because developers can build models which will enable devices with many custom behaviors. A model defines the required states, the messages that act upon those states, and the associated behavior. All communication across a mesh network is facilitated by messages.
A state is a value representing a condition of an element. An element is an addressable entity of a device or node. Each device has at least one (primary) element and may have one or more secondary elements. The number and structure of elements does not change throughout the node’s lifetime. An element ‘exposing’ a state is called a server. An element ‘accessing’ a state is referred to as a client.
Importantly, models come in three types; server, client and control. A server model is composed of one or more states spanning one or more elements. It defines a set of mandatory messages that it can transmit or receive, the element behavior when it transmits and receives the messages, and any additional behavior that occurs after messages are transmitted or received.
A client model defines a set of messages that a client uses to request, change, or ‘consume’ corresponding server states, as defined by a server model. The client model does not have states.
A control model can combine client model functionality (to communicate with other server models) and server model functionality (to communicate with other client models). A control model may also contain control logic - a set of rules and behaviors that coordinate the control model’s interactions between other models to which the control model connects (Figure 2).
Figure 2: Shown is the element model structure of a Bluetooth mesh device that implements a control model. Device C can communicate with server models (within Devices A and B) as a client (messages X, Y, and Z and messages R, S, and T respectively), and client models (within Device D) as a server (supporting messages A, B, and C). (Image source: Bluetooth SIG)
To illustrate the use of models in a practical example, consider a power strip comprising two independent power sockets, each capable of controlling the power output, and integrating a BLE radio, allowing the strip to connect to a Bluetooth mesh.
The device (the power strip) features two elements that represent each of the two power sockets. The functionality of each element is defined by the Generic Power Level Server model which defines a set of states on a server, as well as a set of messages that operate on the states. A Generic Power Level Set message may be sent to the device to control the output power. The message is addressed to one of the socket’s elements.
The sockets can also be controlled by a generic device, such as a dimmer, that implements the Generic Level Client model. This model sets a desired level to zero, a maximum value, or a value in between. Power to the sockets is controlled through state binding. In each power socket, the Generic Power Actual state is bound to the Generic Level state. A Generic Level Client sends Generic Level messages to the Generic Level Server. The Generic Level state is changed, which in turn (via the defined binding) changes the Generic Power Actual state that controls the power output.
Because elements can report states, each socket may report power level as well as the energy consumption of a device plugged into the socket. Energy consumption is reported using messages defined by the Sensor Server model.
Assuming the developer has gained some familiarity with both the architecture of Bluetooth mesh and BLE development (see Digi-Key article: “Bluetooth 4.1, 4.2 and 5 Compatible Bluetooth Low Energy SoCs and Tools Meet IoT Challenges” for more on general BLE design), and is armed with a Bluetooth mesh SDK, host SDK, DK and additional modules or DKs to set up a network, a developer can relatively easily configure a Bluetooth mesh implementation.
The first step is to build the mesh stack. In Nordic’s case the stack is built using the selected IDE. For example, with SEGGER Embedded Studio, the stack is built by using one of the examples included with the Bluetooth mesh SDK (such as the “light switch” example) and compiling using the IDE.
The target PHY on the DK is then erased and reprogrammed with both the compiled Bluetooth mesh stack and BLE stack. Once the stacks are programmed and verified, the SDK can be used to set-up and build mesh networks.
Provisioning: Nordic’s development tools include a provisioning application programming interface (API) that is used to add new devices to the mesh network. Provisioning is handled by provisioners (devices already connected to the network and previously configured for the provisioning task) used to provide new devices with the information they need to join a mesh network. Initially, the device is supplied with a network key, an address, and a device key for establishing a secure channel for configuration after provisioning.
The API allows the developer to start listening for the unprovisioned (or provisionee - the device to be added to the network) node’s broadcast beacon sent on one of BLE’s three advertising channels. Bluetooth mesh transmits and receives messages using BLE’s advertising channels, rather than the 37 full-bandwidth data channels. Incoming link requests on the channel will be automatically accepted by the provisioner.
When the link has been established, it is authenticated using an out-of-band (OOB) method to ensure that the device joining the network is the intended target. The use of OOB methods reduce the chance of “man-in-the-middle” attacks from devices listening on BLE’s spectrum allocation. An API event then provides the provisioning data and the device key for the device.
Configuration: Nordic’s “light switch” application (included with the SDK) shows how to develop applications with both provisioner and provisionee roles. In the demo, a light switch client model (the switch) is the provisioner and the light switch server model (the bulb) is the provisionee.
Nordic’s example makes the most of the fact that the simplest server in the Bluetooth mesh specification is a Generic OnOff Server, representing that the server is either on or off. For example, the simplest client is a Generic OnOff Client that’s able to control a Generic OnOff Server via messages defined by the Generic OnOff Model.
When this server model receives a GET or (reliable) SET message from a client model, it sends the current value of the OnOff state as a response. This keeps the client up-to-date about the server state (Figure 3).
Figure 3: Messages and ATT opcodes supported by Generic OnOff Model. (Image source: Nordic Semiconductor)
The configuration server is used to represent a mesh network configuration of a device and is a mandatory requirement for Bluetooth mesh nodes. The configuration server handles the communication with, and instructions from the configuration client (controlled by the provisioner).
Configuration starts after completion of provisioning. The provisioner reads the composition data of the provisionee to identify the metadata of the device and which models are bound to what element in the device. Next the application and/or network key(s) are added and bound to the different models (Figure 4).
Figure 4: Provisioning and configuration flowchart from nRF5 SDK for Mesh. “nrf_mesh…” call-outs are API functions. (Image source: Nordic Semiconductor)
Adding more devices to the network is simply a case of repeating the provisioning and configuration process for each new node.
Publishing and subscribing: The final stage of setting up and building an initial application is to configure the publication state of the models. For example, the address used to publish state events, with what key, using what “Time-To-Live” (TTL) value, and set subscriptions.
Messages are sent when they are published from each model’s publish address. Publication is used, for example, by a sensor node periodically reporting data. Messages can be published just once or repeated, and are sent to either a unicast, group, or virtual address (see Part 1 of this article). Publication is also used by client models to send messages to server models.
Configuration of publication related states is generally controlled by a provisioner via the configuration model.
When using the Nordic SDK, messages are published using the “access_model_publish()” API function, which will publish a message according to the publication settings (interval, destination) of the publishing model.
Subscriptions allow models to listen for incoming messages from specific addresses. This can be used to listen to, for example, the periodic messages published from sensor nodes. The Nordic SDK enables models to subscribe to an address by allocating a subscription list using the “access_model_subscription_list_alloc()” API function.
Note that when using a client model, it is not required to subscribe to the address from which messages are being sent in order to receive replies to those messages. Subscriptions are only used to receive unsolicited messages from nodes.
During the development process it might be advantageous to connect a non-Bluetooth mesh enabled device to the Bluetooth mesh. An example might be a smartphone which the developer wishes to use to control a prototype smart lighting mesh application. Interaction between the mobile and the mesh is achieved via the smartphone’s and node device’s Generic Attribute Profile (GATT) interface in the Bluetooth stack, rather than the Bluetooth mesh stack.
Bluetooth mesh adds new capabilities to BLE applications. However, because it wasn’t included as part of the original Core Specification, the adoption of mesh has introduced some compromises and added some complexity to the design process. Developers familiar with designing using the Bluetooth protocol stack will be at an advantage to those with no knowledge, but even for experienced engineers, implementing Bluetooth mesh does require learning a new architecture and understanding its nuances such as states, elements and models.
The design challenge can be eased by partnering with a vendor such as Nordic Semiconductor or Cypress Semiconductor. These vendors have now released Bluetooth mesh stacks to complement their mature BLE solutions. The stacks are accompanied by purpose-designed SDKs which allow the developer to use chips, firmware and design tools with which they are familiar to accelerate the learning process of designing Bluetooth mesh applications.