The first installment of this article series provided an overview of Bluetooth Mesh and the basic node and feature types supported by it. This installment covers how communication happens within the Bluetooth Mesh network and various concepts that are important to understand while designing an application with Bluetooth Mesh.
Communication from one node to another
Bluetooth Mesh uses a managed flood operation to transfer messages from one node to another. Managed flood is a multi-path implementation that includes just enough redundancy to ensure that a message reaches its destination.
In a basic flood implementation, every node blindly relays every message that it receives. The Bluetooth Mesh managed flood operation prevents Mesh devices from relaying previously received messages by adding all messages to a cached list. When a message is received, it is checked against the list and ignored if already present. Additionally, each message includes a Time-to-Live (TTL) value that limits the number of times a message can be relayed in the network. Each time a message is received and then relayed (up to a maximum of 126 times) by any device, the TTL value is decremented by 1.
Bluetooth mesh implements a Publish- and Subscription-Based Communication approach to ensure that different types of products can coexist in a network without being bothered by messages from devices they do not need to listen to. A Publisher Node sends messages to only nodes that have subscribed to the Publisher and will act on these messages. An example of this operation is use in different rooms within your home. Each room could subscribe to the messages from the specific light switches for that room. In addition, messages can be either unicast, multicast, and/or broadcast, meaning that a message can reach one, a few, or all nodes in the network.
Figure 1 shows an example of Bluetooth Mesh Publish-and Subscription-based communication implementation using the CYBT-213043-MESH Evaluation kits. The CYBT-213043-MESH kit uses the CYBT-213043-02 module to implement Bluetooth Mesh communication. In combination with the on-board user button and RGB LED, evaluation boards mimic Bluetooth Mesh Switch and Bluetooth Mesh Bulb respectively.
Figure 1. Bluetooth Mesh Publish and Subscribe example for connected lighting. (Source: Cypress)
As shown in the figure, the first switch from the left publishes the messages to the Dining room group. First and second bulbs from the right have subscribed only to Dining Room group. However, the third bulb has subscribed to the messages from the Dining Room and Kitchen groups. So, when Switch 1 publishes the messages, the first three bulbs (Dining room and Kitchen) can be controlled. However, when Switch 2 publishes the messages, only the third bulb (Kitchen) can be controlled.
Mesh Node Architecture
Now, as we have already discussed how messages are communicated among nodes, let’s look at the Bluetooth Mesh node architecture at the functional level and see what makes Bluetooth Mesh devices interoperable.
Elements define a node’s functionality. Every node has at least one Element called the “Primary Element”. For example, a light bulb generally has one Element. This Element exposes the On/Off and brightness control functionalities of the node. Another example is a dimmable light bulb with an integrated occupancy sensor. This node will have two Elements. The first element is used for the lighting function and the second for the sensor function. The Primary Element, in this case, would be the lighting function.
Every Element within a node has a unique address, known as a unicast address. This allows each Element to be addressed independently of other Elements within the same node. Figure 2 shows examples of both node types – the first with only one element and the other with two elements. Figure 2 also shows additional concepts that are discussed in the following sections and how they are related to each other in the Bluetooth Mesh implementation.
Figure 2. Nodes with one and two Elements. (Source: Cypress)
Every Bluetooth Mesh node uses one or more mesh Models that define the functionality of a given node. Models are analogous to Services in regular Bluetooth devices. There are three types of Mesh Models – Client Models, Server Models, and Control models (which implement both a Client and Server in a single model).
A Server Model can have one or more states spanning one or more Elements. The Server Model exposes device’s state of Elements that can be read or controlled by a Client node. For example, a Bluetooth Mesh light bulb uses a Server Model. In this application, either an On/Off Server or Light Lightness Server can be used. An On/Off Server model will expose the current state of the bulb and change the state based on the Client’s input to switch the state of the bulb between On and Off. If a Light Lightness Server is used, it will allow a Client to read the bulb’s current state, control its brightness, and switch it On or Off. Another application of the Server model would be a sensor node that only allows the Client to read the sensor state but does not allow its state to be changed.
A Client Model allows other nodes to send messages to request and/or change the state of a Server node. The most common example of an application with a Client Model is a Bluetooth Mesh Switch. A Bluetooth Mesh Switch may use the On/Off Client model. It can either request the current state of a Server device or send a message to change the state to On or Off. Another example would be a Bluetooth Mesh Dimmer that uses the Level Client. Beyond the capabilities of a switch, this model allows control of the level of the Server’s output, such as controlling the bulb’s brightness.
In most applications, Server and Client models need to be used along with some control code that acts based on the received messages or user input. A combination of Server and/or Client model and a control logic results in a Control Model.
Bluetooth Mesh Models can extend the functionality of other models. This capability allows Mesh nodes with different capabilities to be controlled by the same message.
Let’s take the example of lighting applications. A bulb that allows brightness to be controlled generally uses the Light Lightness Server model. Some bulbs may use the Generic Level Server Model to control the output power and hence brightness. A basic Bluetooth Mesh Bulb with only On/Off capabilities would likely use On/Off Server model. However, the Light Lightness Server model extends the functionality of the On/Off Server model and the Level Server model. That means that an On/Off message sent by an On/Off client will control the state of all three bulb types irrespective of the model used.
An Element’s conditions are stored in the States. Each State is a value of a certain type. In addition to the values, States have behaviors that are associated with that state. These States are defined by the Bluetooth SIG. For example, an On/Off Server in an On/Off bulb or a sprinkler controller will have a State called Generic OnOff that can have one of two values – ON and OFF. This is useful for devices like light bulbs or sprinkler controllers. The term ‘Generic’ is used to indicate that this state and its behaviors may be useful in different kinds of Mesh devices.
You can also watch Learning More about Bluetooth Mesh video for more information on Bluetooth Mesh communication and how to get started with a Bluetooth Mesh design.
In the next installment in this article series, we’ll explore the Privacy and Security features of Bluetooth Mesh.
Sachin Gupta is Product Marketing Manager at Cypress Semiconductor. He has more than 11-years of experience in product marketing and applications engineering roles. He has managed USB Type-C, Wi-Fi, Bluetooth, SoC and FPGA products in his product marketer roles. He can be reached at email@example.com.
Santhosh Vojjala is currently working as Principal Applications Engineer at Cypress Semiconductor. He has 11+ years’ experience in managing and developing world class connectivity (IoT), touch screen and embedded systems solutions for world wide customers. He can be reached at firstname.lastname@example.org