Bluetooth mesh - basic network components

In continuation of the topic about the bluetooth mesh network, about the announcement and the key components of which was written in this note , to understand its topology, we will consider the main set of technical terms and concepts that were previously absent in the world of Bluetooth LE.

Who cares, welcome ...

Most BLE devices exchange data with each other using a simple point-to-point network topology (p2p) that allows one-to-one communication, which is called piconet in the Bluetooth kernel specification .

Imagine a smartphone that has established a point-to-point connection with a heart rate monitor and receives data on the heart rate from the latter. Since the Bluetooth specification allows devices to establish several connections simultaneously, the same smartphone, already having a p2p connection with a heart rate monitor, can establish another connection of the same type with another device, for example, an activity tracker. In this case, the smartphone can communicate directly with each of these other devices, but the devices themselves cannot communicate directly with each other.

Unlike p2p, a mesh network allows each device to interact with any other device on the network. Communication is carried out by sending messages, and devices can send and relay these messages to other devices, thereby increasing the communication range far beyond the radio range of each individual node.

Devices and nodes

Let's say you purchased a chandelier with Bluetooth mesh support. In order to control it using switches that also use the Bluetooth mesh, the chandelier must first be made part of your mesh network, that is, “prepare”. In this context, new terms have appeared:

• "Node» (Node) - a device that is part of mesh-network.
• "Unprepared 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 fact that the device, by exchanging a certain set of encryption keys with a device that has the function of registering in the network, becomes 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 the 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 creating NetKey safely through the initialization process is the first and main 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 the terminology of a Bluetooth mesh network, these parts are called Elements. The figure on the left shows a LED chandelier, which, when added to the network, is a single unit 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 message-based, and many message types are already defined, each of which has its own unique opcode.

Messages are divided into 2 categories:

• acknowledged : messages implying a response from the nodes received by the message. Answering, the node confirms that the message has been received and returns some data to the sender. The sender of the acknowledged message can resend the message if he does not receive the expected response. That is, the value of the confirmed message arriving at the node several times will be the same as that which would be received when sending only once ( idempotent ).
• unacknowledged : messages that do not require a response.

Addresses

Messages must be sent from and to the address. There are three types of addresses defined on a Bluetooth network:

• unicast (unique address): uniquely identifies a single network element. This type is assigned to the device during the initialization process.
  
  
• multicast (multicast address): represents one or more network elements. Group addresses are defined by Bluetooth SIG under the name "SIG Fixed Group Addresses" or can be assigned dynamically. The Bluetooth SIG will be defined by 4 fixed address groups: All-proxies, All-friends, All-Relays and All-nodes. They will be described in more detail 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 groups of addresses corresponding to each room in the building can be defined.
  
  
• virtual address : an address that can be assigned to one or more elements covered by one or more nodes. It has a 128-bit unique identifier (UUID) value. Virtual addresses are likely to be generated during device production.

Publications and Subscriptions

Publishing is the action of sending a message.
Subscribe is the selection of specific messages for processing sent to specific addresses.

Typically, messages are addressed to an address group or virtual address.

In the figure above, we see that the “Switch 1” node is published for the “Kitchen” group address. 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 using “Switch 1”.

“Switch 2” is published for the Canteen group address. And only “Lamp 3” is subscribed to this address. 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 particular address. This is where network flexibility comes in. Please note how both nodes “Switch 5” and “Switch 6” are published for the same address: “Garden”.

The use of multicast and virtual addresses with the publisher-subscriber model has the additional advantage that the removal, replacement, or addition of new nodes to the network does not require reconfiguration of other nodes. Imagine what needs to be done when adding a new light source, for example, to the dining room: the new device will be added to the network using the preparation process and set up a subscription to the Canteen address, and these changes will not affect other nodes. “Switch 2”, as before, will publish messages for “Canteen”, but now both “Lamp 3” and a new lamp will respond to this.

States and Properties

Network elements 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 specific 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 status is “ Generic OnOff ”. A bulb having this state with the value “ On ” will light up, and in the state with the value “ Off ” it will not light naturally.

The propertiesare similar to states because they contain certain values ​​related to the element. But they differ significantly from states by other signs. Those who are familiar with BLE are aware of the concept of “service characteristic” (something representing data types in which some values ​​defining service metadata are presented). So the “ property ” provides a context for interpreting the characteristic.

To assess the importance of using context, consider, for example, the “Temperature 8” characteristic - an 8-bit type of temperature state that has a number of related properties, including the current internal ambient temperature and the existing outdoor ambient temperature. These two properties allow the sensor to publish readings in such a way that the receiving client can determine a context that has a temperature value.

Properties are divided into two categories:

• category of manufacturer (device): properties can only be read;
• admin category : properties have read and write access.

Messages, States, and Properties

Any particular type of message is an operation with a state or a set 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 to it, a message with the STATUS type is sent and contains the corresponding status value.
• SET messages change the value of a particular state. Sending an acknowledged message of this type requires a response message of type STATUS, while an unconfirmed message of type SET does not require a response.
• STATUS messages are sent in response to messages of the GET type, to acknowledged messages of the SET type 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 determines the functionality of an element on the network. 3 categories of models defined.

• 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 determine any states, but defines messages that can be sent or received.
  
  
• Management model : combines a server model 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 expanding 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 requirements to the model is to expand 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 generic states, such as, for example, “ Generic OnOff ” and “ Generic Level ”. A number of generalized messages that work with such states are defined similarly, for example: " Generic OnOff Get " and " Generic Level Set ". Generalizations allow you to use a wide range of device types without the need to create new models.

Scenes

A scene is a stored 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 , 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, the 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 manually set the nodes to these states, you can save these states as a scene using the configuration application and later call this scene upon request by sending a corresponding message related to the scene or call it automatically at the scheduled time.

Initialization

Initialization (provisioning), as mentioned earlier, is the process by which a device connects to a mesh network and becomes a node. The process includes several steps, leads to the creation of various security keys and is itself a secure process. Initialization is carried out using the 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.

1. " I am a lighthouse " (Beaconing). To support various functions of the bluetooth network, new types of GAP profile reversing (GAP AD) have been added, in particular the Mesh Beacon type AD. An unprepared device indicates its availability on the air, using this type in the packages of invertising. 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.
   
   
2. The invitation (Invitation). At this point, the device used to control the initialization process sends an invitation. The Mayak device, in response to an invitation, sends information about itself.
   
   
3. Exchange of public keys . Both devices exchange their public keys either directly or using the OOB (out-of-band) method.
   
   
4. 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 the mutual authentication of the two devices.
   
   
5. Distribution of data provided . After authentication is complete, a session key is created that is used to secure the subsequent exchange of data necessary to complete the initialization process, including generating the NetKey security key. After initialization is complete, the prepared device becomes the owner
   
   • network key "NetKey";
   • a network security setting called an “IV Index”;
   • unicast address, dedicated control device.
   
   

After which the device becomes a node.

Features

All nodes in a network can send and receive messages on a given network, but there are a number of additional functions that a node may have. The node may not support, support some or all of these additional functions, and any supported function may be enabled or disabled at some point in time.
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 travel across the network, making several “hops” between devices by relaying. The network PDU includes a field called TTL (Time To Live). It takes an integer value and is used to limit the number of jumps. For example, if the TTL is 3, then a message will be sent using 3 “hops” from the source node. Setting TTL to 0 means that the value will not be relayed, but will move in the area of ​​one jump. In this way, nodes can use the TTL field to make better use of the mesh network.
  
  
• Low power: Low power nodes. Some nodes with power restrictions should save energy as much as possible. In addition, devices of this type can be mainly associated with sending messages, but sometimes they have to receive messages. Take a temperature sensor that is powered by a coin-sized battery. It sends temperature readings once a minute, in case the temperature exceeds the set upper and lower thresholds. If the temperature remains within these thresholds, the sensor does not send any messages. This behavior is easy to implement without any problems associated with energy consumption. At the same time, the user can send a message to this sensor, which changes the threshold state values. Such an event can occur very rarely, but the sensor must support it. If the sensor does not skip a single message, it will have increased power consumption, and when saving energy, you can skip configuration messages. For such cases, there is a concept of friendship and a node function called “Friend”. Nodes, such as the temperature sensor in this example, can be designated as Low Energy Consumption (LPN) nodes, and a function flag will appear in the sensor configuration, indicating the node as such. An LPN node works in tandem with another node that does not have power limitations (for example, having a constant AC power supply). This device is called the Friend node. For such cases, there is a concept of friendship and a node function called “Friend”. Nodes, such as the temperature sensor in this example, can be designated as Low Energy Consumption (LPN) nodes, and a function flag will appear in the sensor configuration, indicating the node as such. An LPN node works in tandem with another node that does not have power limitations (for example, having a constant AC power supply). This device is called the Friend node. For such cases, there is a concept of friendship and a node function called “Friend”. Nodes, such as the temperature sensor in this example, can be designated as Low Energy Consumption (LPN) nodes, and a function flag will appear in the sensor configuration, indicating the node as such. An LPN node works in tandem with another node that does not have power limitations (for example, having a constant AC power supply). This device is called the Friend node.
  
  
• Friend : Friend Node. A node with this function stores messages addressed to the LPN and delivers them to the LPN whenever the LPN asks a friend about “waiting messages”. LPN can interrogate a friend relatively rarely, but in such a way as to balance the amount of energy consumed and the frequency of receiving and processing configuration messages. When executing the request, all messages stored with a friend are forwarded to LPN with the “MD” (More Data) flag, indicating to the LPN whether there are additional messages to send from the Friend node. The relationship between the LPN and the Friend 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 the stack of this network. 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 the 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 in that network.

The figure below shows the interaction with the mesh node through the proxy node of this network.


System architecture, network security and a description of its operation in action, we will consider in the final part.

Thanks for attention.