Continuing the topic of the bluetooth mesh network, the announcement and key components of which was written
in this article , to understand its topology, we will look at the main set of technical terms and concepts that were previously absent in the world of Bluetooth LE.
Who cares, welcome ...
Most BLE devices communicate with each other using a simple point-to-point (p2p) network topology that allows one-to-one communication, which in the Bluetooth core specification is called
“piconet” .
Imagine a smartphone that has established a point-to-point connection with a heart rate monitor and receives heart rate data from the latter. Since the Bluetooth specification allows devices to establish several connections at the same time, the same smartphone, already having a p2p connection with a heart rate monitor, can establish another connection of the same type with another device, such as an activity tracker. In this case, the smartphone can directly communicate with each of these other devices, but the devices themselves cannot directly communicate with each other.
')
Unlike p2p, a mesh network allows each device to communicate with any other device on the network. Communication is carried out by sending messages, and the devices can both transmit and relay these messages to other devices, thus increasing the communication range far beyond the radio range of each individual node.
Devices and nodes
Suppose you have purchased a Bluetooth mesh chandelier. In order to control it using switches that also use a Bluetooth mesh, the chandelier must first be made part of your mesh network, that is, “prepare”. In this context, new terms have appeared:
- A Node is a device that is part of a mesh network.
- Unprovisioned device (Unprovisioned device) - a device that is not part of the network.
- “ Provisioning” is the process of entering an unprepared device into the network, after which the device will become a node. These are certain actions in the context of network security, which lead to the device, exchanging a certain set of encryption keys with a device that has the function of registration in the network, to become a member of the network. A device with network registration is usually a tablet or smartphone. One of the encryption keys is called a “network key” or, briefly, “NetKey” .
All nodes of a mesh network have at least one “NetKey” and the presence of such a key makes the device a member of the network, that is, a node. There are other requirements that must be met before the node becomes useful, but the secure creation of a “NetKey” using the initialization process is the first and basic step. The initialization process will be discussed in more detail below.
Items

Some nodes can consist of several parts, each of which can be controlled independently. In Bluetooth mesh terminology, these parts are called Elements. The figure on the left shows the LED chandelier, which, when added to the network, is a single
node with three
elements and each of the elements is an individual light source.
Messages
If a node needs to request the status of other nodes or, in some way, manage other nodes, it sends a message of a certain type. If a node must communicate its status to other nodes, it also sends a message. Thus, the mesh network is based on messages, and many types of messages have already been defined, each of which has its own unique opcode.
Messages are divided into 2 categories:
- Confirmed : messages that imply a response from the nodes, received messages. Answering, the node confirms that the message was received and returns some data to the sender. The sender of the acknowledged message can re-send the message if it does not receive the expected response. That is, the value of a confirmed message arriving at a node several times will be the same as the one that would have been received when sent only once ( idempotent ).
- unconfirmed : messages that do not require a response.
Addresses
Messages must be sent from and to the address. The Bluetooth network has three types of addresses:
- unicast (individual address): uniquely identifies a single network element. This type is assigned to the device during the initialization process.
- multicast : represents one or more network elements. Group addresses are defined by a Bluetooth SIG called “SIG Fixed Group Addresses” or can be assigned dynamically. The Bluetooth SIG will identify 4 fixed address groups: “All-proxies”, “All-friends”, “All-Relays” and “All-nodes”. More will be described below. Dynamic group addresses can be set by the user using the configuration application. If, for example, dynamic group addresses reflect the physical configuration of a building, then you can define groups of addresses that correspond to each room in the building.
- virtual address : an address that can be assigned to one or more elements covered by one or several nodes. It has a 128-bit unique identifier (UUID). Virtual addresses are likely to be generated during device production.
Publications and Subscriptions
Publish is the action to send a message.
Subscribe is the selection of specific messages for processing sent to specific addresses.
As a rule, messages are addressed to a group of addresses or a virtual address.
In the figure above, we see that the node "Switch 1" is published for the group address "Kitchen". Each of the nodes "Lamp 1", "Lamp 2" and "Lamp 3" is subscribed to the address "Kitchen" and, therefore, receive and process messages published for this address. In other words, "Lamp 1", "Lamp 2" and "Lamp 3" can be turned on or off with the help of "Switch 1".
“Switch 2” is published for the dining room group address. And at this address is only signed "Lamp 3". It is the only one controlled by Switch 2. This example illustrates the fact that nodes can subscribe to messages addressed to more than one individual address. It shows the flexibility of the network. Notice how both nodes "Switch 5" and "Switch 6" are published for the same address: "Garden".
Using group and virtual addresses with the publisher-subscriber model has the added advantage that removing, replacing, or adding new nodes to the network does not require reconfiguration of other nodes. Imagine what to do when adding a new light source, say, to the dining room: a new device will be added to the network using the preparation process and will set up a subscription to the Dining Room address, and these changes will not affect other nodes. "Switch 2" as before, will publish messages for the "Dining Room", but now it will react as "Lamp 3", and the new lamp.
States and Properties
Elements of the network can be in different states and these states are represented in the network by the concept of “state value”.
A state is a value of a certain type contained within an element (within the server model - see below). As an example, consider a light bulb that can be turned on or off. In the bluetooth network, the state "
Generic OnOff " is
defined . A lamp with this status with the value “
On ” will be on, and in the state with the value “
Off ” it will not naturally burn.
Properties are similar to states, as they contain certain values ​​related to the element. But they are significantly different from the states of other signs. Those who are familiar with BLE are aware of the concept of a “characteristic of a service” (something that represents data types in which some values ​​define the service metadata). So the "
property " provides the context for interpreting the characteristic.
To appreciate the importance of using the context, consider, for example, the “Temperature 8” characteristic — an 8-bit type of temperature state that has a number of properties associated with it, including the current internal ambient temperature and the existing outdoor ambient temperature. These two properties allow the sensor to publish readings so that the receiving client can determine the context that has a temperature value.
Properties are divided into two categories:
- category of manufacturer (device): properties can only be read;
- administrator category : properties have read and write access.
Messages, statuses and properties
Any particular type of message is an operation with a state or a collection of several state values. All messages have three main types, reflecting the types of operations supported by the Bluetooth network:
- GET messages request the value of the current state from one or more nodes. In response, a message is sent with the STATUS type and contains the corresponding status value.
- SET messages change the value of a particular state. Sending a confirmed message of this type requires a response message with the STATUS type, whereas an unconfirmed SET message does not require a response.
- STATUS messages are sent in response to GET messages, confirmed SET messages, or independently of other messages, for example, controlled by a timer running inside the element that sends the message.
Models
A model is a combination of concepts that defines the functionality of an element that is in a network. Identified 3 categories of models.
- Server model : defines a set of states, state transitions, state bindings, and messages that an element containing this model can send or receive. This model also defines the behavior associated with messages, states and state transitions.
- Client model : does not define any states, but defines messages that can be sent or received.
- Management Model : combines a server model in itself that allows you to exchange data with other client models with a client model that allows you to communicate with server models.
Models can be created by extending other models. Models are immutable, which means that they cannot be changed by adding or removing behavior. The correct and only acceptable approach to adding new model requirements is to extend the existing one.
Generalizations
Many different types of devices often have similar states, an example of which is the simple idea of ​​“On” - “Off”, that is, devices that can be turned on or off. Therefore, the bluetooth network specification defines a set of generalized states, such as "
Generic OnOff " and "
Generic Level ". Similarly, a number of generalized messages are defined that work with such states, for example: "
Generic OnOff Get " and "
Generic Level Set ". Generalizations allow the use of a wide range of device types without the need to create new models.

Scenes
A scene is a saved collection of states that can be called or made current when a special type of message is received or at a specific time. Scenes are identified using the 16-bit scene number "
Scene Number ", which is unique in the mesh network. Scenes allow you to set a number of nodes in a given set of previously saved, complementary states in one coordinated action.
Imagine: You want the temperature in the room to be 23 degrees in the evening, six lamps in the chandelier shine with a certain brightness, and the lamp on the table was set to a pleasant warm yellow hue. After you have manually set the nodes to these states, you can save these states as a scene using the configuration application and later invoke this scene upon request by sending an appropriate message associated with the scene or invoke it automatically at a scheduled time.
Initialization
Provisioning, as mentioned earlier, is the process by which a device connects to a mesh network and becomes a node. The process involves several steps, leads to the creation of various security keys and is in itself a secure process. Initialization is carried out using an application on the device, such as, for example, a tablet. The device used to control the initialization process is called the "
Provisioner ". The preparation process consists of five steps, described below.
- " I am a beacon " (Beaconing). To support various functions of the bluetooth network, new types of GAP profile (GAP AD) advertizing have been added, in particular the “Mesh Beacon” type AD. An unprepared device indicates its availability on the air using this type in advertizing packets. In order for the device to start transmitting such data, the user may need to force the device into this mode, for example, by pressing a combination of buttons or holding the button for a certain period of time.
- Invitation . At this stage, the device used to control the initialization process sends an invitation. The Beacon device, in response to an invitation, sends information about itself.
- Exchange of public keys . Both devices exchange their public keys either directly or using the out-of-band method.
- Authentication . At this stage, the device that is supposed to enter the network in one form or another displays a random number to the user. The user enters this number into the control device, after which a certain exchange of encrypted data takes place between the two devices. The result of this exchange is a mutual confirmation of the authenticity of the two devices.
- Submission of the data provided . After authentication is completed, a session key is created that is used to secure the subsequent exchange of data necessary to complete the initialization process, including the generation of the “NetKey” security key. After completion of the initialization, the prepared device becomes the owner
- network key "NetKey";
- network security parameter, referred to as the “IV index” (IV Index);
- address unicast, dedicated control device.
After which the device becomes a node.
Special features
All network nodes can transmit and receive messages from this network, but there are a number of additional functions that a node may have. A node may not support, support some or all of these additional functions, and any supported function may at some point be turned on or off.
We list these functions:
- Relay : Relay nodes. Nodes that support the relay function, called relay nodes, can retransmit received messages. Relaying is a mechanism by which a message can move across the entire network, making several “hops” between devices by means of relay. The network PDU includes a field called TTL (Time To Live). It takes an integer value and is used to limit the number of hops. For example, if the TTL is 3, then a message will be transmitted using 3 “hops” from the source node. Setting the TTL to 0 will result in the value not being retransmitted, but moving in the area of ​​one hop. Thus, nodes can use the TTL field to more efficiently use the mesh network.
- Low Power : Low power nodes. Some nodes that have power limitations should save energy as much as possible. In addition, devices of this type can be mainly related to sending messages, but sometimes they have to receive messages. Take a temperature sensor that is powered by a battery the size of a coin. It sends temperature readings once per minute, in case the temperature exceeds the set upper and lower thresholds. If the temperature remains within these thresholds, then the sensor does not send any messages. This behavior is easily implemented without any special problems associated with energy consumption. At the same time, the user can send a message to this sensor, which changes the state values ​​of the thresholds. Such an event can occur very rarely, but the sensor must support it. If the sensor does not skip any messages, it will have increased power consumption, and you can skip configuration messages while saving energy. For such cases, there is the concept of friendship and the function of a site called “Friend”. Nodes, such as a temperature sensor in this example, can be labeled as low energy consuming (LPN) nodes, and in the sensor configuration there will be a function flag denoting the node as such. An LPN node operates in tandem with another node that does not have power limitations (for example, having a constant AC power source). This device is called the “Friend” node.
- Friend : Node is a friend. A node with this function stores messages addressed to the LPN node and delivers them to the LPN whenever the LPN polls a friend about "waiting messages". An LPN may ask a friend relatively rarely, but so as to balance the amount of energy consumed and the frequency of receiving and processing configuration messages. When executing a request, all messages stored by a friend are sent to the LPN with the “MD” (More Data) flag (additional data) indicating to the LPN node whether there are additional messages to be sent from the “Friend” node. The relationship between the LPN node and the Friend node is called Frienfship.
- Proxy : Proxy nodes. There are a huge number of devices that support BLE in the world, including most smartphones and tablets, but devices released before the Bluetooth mesh network was announced do not support this network stack. And since they have a BLE stack, these devices have the ability to connect to other devices and interact with them using the GATT (Generic Attribute Profile) profile. Proxy nodes provide a GATT interface that can be used to interact with a network. The protocol, called the proxy protocol, is used with GATT and, with its help, the proxy node converts these device PDUs to / from the network PDUs. Thus, proxy nodes allow BLE devices that do not have a mesh network stack to communicate with nodes of this network.
The figure below shows the interaction with the mesh node through a proxy node of this network.
System architecture, network security and a description of its work in action, we will look at the final part.
Thanks for attention.