For Bluetooth technology, the establishment of the Mesh specification symbolizes a transformation in form, and its vast impact makes it a paradigm shift.
Since its launch in 2000, Bluetooth has actively pursued growth, initially aiming to replace wired technologies, but quickly became an important standard for wireless audio and computer peripherals, such as wireless mice and keyboards.
In 2010, the advent of low-energy Bluetooth marked a significant step forward for Bluetooth technology. Its influence is both deep and broad, with applications covering smartphones and tablets, medical and fitness devices, smart homes, and the wearable device market. A wireless communication system built on a Mesh network topology has proven to effectively provide extensive coverage, not only extending the coverage range but also being quite stable and reliable. However, prior to this, such networks were built on special technologies that were incompatible with most consumer computers, smartphones, and peripherals, and were not suitable for enterprise use.
The establishment of the Bluetooth Mesh technology specification is the result of the joint efforts of 120 member companies of the Bluetooth Special Interest Group, far exceeding the normal scale, thus meeting the global demand for Bluetooth mesh network industry standards. For Bluetooth technology, the establishment of the Mesh specification symbolizes a transformation in form, and its vast impact makes it a paradigm shift. This article is divided into two parts; the first part describes the applications and characteristics of Bluetooth Mesh, while the second part describes the technology and design architecture of Bluetooth Mesh.
Bluetooth Mesh for Smart Buildings
Imagine this: on a winter morning before dawn, you drive to work, and after passing through the company’s security system, a parking space is automatically assigned to you (Figure 1). The number above the parking space lights up automatically, guiding you to park your car easily. Then, the parking allocation system immediately marks this space as occupied.
Figure 1: Bluetooth Mesh network covers the entire office and parking lot
As you enter the building, a presence sensor detects your presence and immediately identifies you through your wearable device. You get into the elevator and go to the second floor, then exit the elevator. As usual, you are the first one to enter the office. When the elevator door opens, the lights automatically turn on along the path from the elevator to your office and the kitchen, while the coffee, an essential part of your company, is there waiting for you. To save energy, other areas remain dark.
You enter the office, and the door behind you closes automatically. The ceiling lights and the desk lamp have been turned on for you and adjusted to the brightness you find most comfortable. You notice that the temperature in the room seems to be slightly warmer than the rest of the office, which happens to be your favorite temperature. As soon as you sit down, your computer automatically logs you in.
Your day starts smoothly, as the building automatically responds to your needs, even accommodating your preferences. How is all this achieved efficiently?
A few months ago, the company installed a Bluetooth Mesh network, starting with a Mesh lighting system; later, presence sensors, environmental sensors, wireless heating and air conditioning, and parking management systems were gradually added to the Mesh network. As a result, the company saved a significant amount on electricity and heating costs, and the working environment became more humane, greatly improving individual work efficiency. Moreover, maintenance costs were reduced because the company no longer needed to go through the hassle of wiring to add new lighting switches, saving both expensive costs and avoiding interference with normal operations.
Meanwhile, the building management team can understand the status of the entire building and various services through various data, keeping track of people’s usage patterns, and then using this data to adjust the systems to optimal conditions.
The Bluetooth Mesh network allows you to easily and economically manage all services in the building and control and set automated behaviors wirelessly. Looking back, you really can’t imagine how you managed without this advanced system before.
Basic Concepts of Bluetooth Mesh Technology
To understand the Bluetooth Mesh network topology, one must first be familiar with some latest technological terms and concepts beyond Bluetooth. This section will introduce some fundamental terms and concepts.
▼
§ “Mesh Network” vs. “Point-to-Point”
Most low-energy Bluetooth devices communicate with other devices via a simple “point-to-point” network topology (one-to-one communication), which is referred to as a “Piconet” in the core specifications of Bluetooth.
Imagine a smartphone establishing a point-to-point connection with a heart rate monitor and transmitting data to the phone. One of Bluetooth’s great features is that devices can establish multiple connections, so this smartphone can also establish a point-to-point connection with another activity tracker. Although this smartphone can communicate directly with two external devices simultaneously, the external devices cannot communicate directly with each other.
In contrast, a mesh network is a “many-to-many” network topology (Figure 2), where each device in the mesh network can communicate with any other device. This will be explained in detail in subsequent articles. Communication between devices occurs through messages, and each device can forward messages, allowing the communication distance to exceed the range of individual node radio frequency power.
Figure 2: A many-to-many network topology using a message forwarding architecture
§ Devices and Nodes
Each device in the mesh network is a node, while devices that have not yet joined are referred to as “unprovisioned devices.” Therefore, the process of an unprovisioned device becoming a network node is called “provisioning.” Imagine a scenario where a user buys a Bluetooth Mesh-enabled light fixture and installs it at home; to add it to the Bluetooth Mesh network, the light fixture must first be provisioned to be operable through existing Bluetooth lighting switches or dimmers.
Provisioning is a secure process, during which the unprovisioned device receives a series of encryption keys and registers with a “provisioner” device (usually a tablet or smartphone). One of these keys is the “network key,” abbreviated as NetKey.
All nodes in the Mesh network will have at least one network key, and it is because of possessing this key that the device can be considered a member of that network and referred to as a node. However, nodes must meet several conditions before they can function; the most basic requirement is to obtain a network key through a secure provisioning process.
§ Elements
Some nodes may have multiple components, each of which can be controlled independently. In Bluetooth Mesh terminology, these components are called “elements” (Element). Figure 3 shows an LED fixture that, when added to the Bluetooth Mesh network, becomes a single node with three elements, each corresponding to a different LED light.
Figure 3: A lighting node with three “elements”
§ Messages
When a node needs to query the status of other nodes or control them, it must send a certain type of message; if a node needs to report its own status to others, it also does so by sending messages.
All communication in the mesh network is achieved via “messages.” Bluetooth Mesh technology has defined many types of messages, each with its unique code (Opcode).
Messages are primarily divided into two major categories: “Acknowledged” and “Unacknowledged.” Acknowledged messages require a response from the receiving node, which serves two purposes: first, to confirm that the message was received; second, to send back data from the receiving end to the sender.
If the sender of an acknowledged message does not receive the expected response, it can resend the message, thus acknowledged messages must possess the idempotent property. In other words, when a node receives the same acknowledged message multiple times, the effect is the same as receiving it once; unacknowledged messages do not require a response.
§ Addresses
The transmission of messages must occur from one address to another, and Bluetooth Mesh technology defines three types of addresses. Unicast addresses correspond to single element addressing, and during provisioning, a unicast address is assigned to the device.
Group addresses are multicast addresses that can correspond to one or more elements. Group addresses can be defined by the Bluetooth Special Interest Group or dynamically assigned; the former is known as “SIG Fixed Group Addresses.” Currently, four SIG fixed group addresses are defined, including All-proxies, All-friends, All-relays, and All-nodes. This article will further explain the meanings of terms like proxy, friend, and relay.
Dynamic group addresses are intended to allow users to establish and correspond to the physical configuration of a building through a configuration setup program.
For example, each room in a building has a corresponding group address, and virtual addresses are used to correspond to one or more element addresses and can cover multiple nodes. The format is a 128-bit universally unique identifier (UUID) that can correspond to any element, similar to the function of a label.
§ Publish/Subscribe
“Publish” refers to the act of sending messages, while setting nodes to receive specific messages from certain addresses is called “subscribing.” Generally, messages are sent to group addresses or virtual addresses. The names of groups and virtual addresses usually make their purpose clear to users, making them convenient and intuitive to use.
As shown in Figure 4, we see that the “Switch 1” node publishes messages to the “Kitchen” group address. The nodes “Bulb 1,” “Bulb 2,” and “Bulb 3” subscribe to the “Kitchen” address, so they will receive and process messages published to that address. In other words, “Bulb 1,” “Bulb 2,” and “Bulb 3” can be controlled through “Switch 1.”
Figure 4: Publish/Subscribe scenario illustration
“Switch 2” will publish messages to the “Dining Room” address. In the figure, only “Bulb 3” subscribes to the messages from that address, so “Switch 2” can only control this bulb. Please note that this example also demonstrates that nodes can subscribe to messages from more than one address, making the design both powerful and flexible.
Similarly, please note that both “Switch 5” and “Switch 6” can publish messages to the “Garden” address. Another great advantage of using group and virtual addresses along with the publish/subscribe communication mechanism is that when nodes are removed, replaced, or added to the network, other nodes do not need to be reconfigured.
Imagine the processes required if a new light needs to be added to the dining room. First, the new device must go through the provisioning process to join the network and be set to subscribe to the “Dining Room” address messages; however, other nodes will not be affected by these changes. “Switch 2” will still publish messages to the “Dining Room” as before, but now both “Bulb 3” and the new bulb will respond.
§ Status and Attributes
Elements can have multiple statuses, and in Bluetooth Mesh technology, this concept is represented through status values. “Status” refers to a type of value within an element (see the “Server” model section at the end of this article). In addition to values, statuses have corresponding behaviors and cannot be reused in other contexts.
For example, a simple light bulb can either be “on” or “off.” Bluetooth Mesh technology defines a status called “Generic OnOff.” The bulb has this status, so the value “On” corresponds to the bulb being on or illuminating.
Conversely, a value of “Off” for the Generic OnOff status corresponds to the bulb being off or extinguished.
Later, we will discuss the importance of generic definitions. Attributes, like statuses, contain values about a specific element; in this respect, the two are similar, but they differ in other aspects. For readers familiar with low-energy Bluetooth, this may remind you of characteristics, which are data types without corresponding behavior definitions and can be applied in various contexts. Attributes provide context for interpreting a characteristic.
To demonstrate the importance and usage of context for attributes, this article uses “Temperature 8” as an example. This is an 8-bit temperature status type, and it has some corresponding attributes, including Present Indoor Ambient Temperature and Present Outdoor Ambient Temperature.
These two attributes allow sensors to publish sensor readings so that receiving devices can interpret temperature values more accurately based on the context of the temperature. Attributes are mainly divided into two categories: Manufacturer attributes are read-only attributes, while Admin attributes are read/write attributes.
§ Messages/Status/Attributes
Messages are the mechanism used to trigger operations of Mesh network devices. Formally, message types represent operations on individual or group status values. All messages can be categorized into three major types, reflecting the types of operations supported by Bluetooth Mesh technology: GET, SET, and STATUS.
GET messages are used to retrieve the status values of one or more nodes. STATUS messages are used to respond to GET messages and contain corresponding status values. SET messages are used to change the value of a status. Acknowledged SET messages will ultimately produce a STATUS message in response; unacknowledged SET messages do not require a response. STATUS messages are used to respond to GET messages, acknowledged SET messages, or can be used independently for other unrelated messages, such as a status message triggered by a timer on an element.
Individual statuses referenced by messages must derive their meaning from the message’s code; attributes do not. In generic attribute-related messages, they are directly represented by a 16-bit attribute identifier (ID).
§ State Transitions
A transition from one state to another is called a “state transition.” State transitions can be instantaneous or take a certain period to complete; this period is referred to as “transition time.” State transitions can significantly affect the behavior of nodes at the application layer.
§ State Binding
States may exist in a relationship with each other, so changing one state may also affect another state. This relationship is called “state binding.” One state can bind to multiple other states. For example, a light bulb controlled by a dimmer may have two states: Generic OnOff and Generic Level, which are interrelated. If the brightness is adjusted to a value of “zero” (which means fully dimmed), it causes the Generic OnOff state to transition from “On” to “Off.”
§ Models
Models combine the concepts introduced earlier to define some or all functions of an element in the mesh network. Models are essentially divided into three types.
The first type is the “Server” model, which defines certain statuses, state transitions, state bindings, and the messages that elements within this model may send or receive. Additionally, the server model defines the behaviors corresponding to messages, statuses, and state transitions.
The second type is the “Client” model, which does not define any statuses but defines the messages it may send or receive to “read” or “set” statuses or receive the “status” messages defined in its corresponding server model.
The third type is the “Control” model, which combines both the “Server” model (able to communicate with other Client models) and the “Client” model (able to communicate with server models).
Of course, models can also be established by extending other models, and unextended models are referred to as root models. Once a model is defined, it cannot be changed; in other words, behaviors cannot be added or removed to change the model. To meet new requirements, the only correct and allowed way is to extend existing models.
§ Generic Definitions
There are many different types of devices, each having some states that are fundamentally the same. The simplest are the two states: “On” and “Off,” such as bulbs, fans, and outlets, all of which can switch between “On” or “Off.”
Thus, the Bluetooth Mesh model specifications define a series of reusable and generic states, such as Generic OnOff and Generic Level. Similarly, a series of generic messages acting on generic states are defined, such as: Generic OnOff Get and Generic Level Set.
Generic states and generic messages are fundamentally used for generic models, such as the Generic OnOff Server model and the Generic Level Client model (Figure 5). These generic definitions allow many types of devices to easily support Bluetooth Mesh technology without having to establish their own models, and they can also create models by extending other models. Therefore, when new types of devices need support, they can quickly establish models by extending generic models.
Figure 5: Generic Model
§ Scenes
A “scene” refers to a set of states that can be applied to the current state when receiving a certain type of message or at a specified time. Scenes are represented by a unique 16-bit scene number (Scene Number) in the Mesh.
With scenes, a group of nodes can be uniformly set to previously stored and coordinated states. Imagine that when night falls, you may want the temperature in your living room to be around 20 degrees Celsius, and the six LED bulbs on the ceiling to maintain a specific brightness, while the lamp on the corner table is set to a comfortable warm yellow. After manually setting all devices to the desired states, you can save these states as a scene through a configuration application, allowing you to send a scene Mesh message in the future or automatically apply this set of settings at a scheduled time.
§ Provisioning
“Provisioning” is the process that allows a device to join the mesh network and become one of its nodes. This process involves several stages and generates several security keys, and provisioning itself is also a secure process. Provisioning needs to be completed through an application on a device (such as a tablet), which acts as the guide for the entire provisioning process, hence referred to as the “provisioner.”
There are five steps in the provisioning process, detailed as follows::
▶ Signal Emission
To support various Bluetooth Mesh functionalities, including but not limited to the provisioning process, Bluetooth introduces some new GAP broadcast types in the specifications, one of which is the “Mesh Beacon” broadcast type.
An unconfigured device must use the “Mesh Beacon” broadcast type in its advertising packet to let the network know of its existence. The user may need to power on the new device and enter this state to send the advertising packet, such as pressing certain buttons simultaneously or holding down a button for a period.
▶ Invitation
When entering this step, the provisioner sends an invitation to the device being provisioned, known as “Provisioning Invite PDU.” Then, the device that emitted the signal in the previous step must respond with a “Provisioning Capabilities PDU” to provide some information about itself.
▶ Exchange Public Keys
Next, the provisioner and the device being provisioned exchange public keys, which can be either permanent or temporary, and the exchange can be done directly or via out-of-band (OOB) methods.
▶ Authentication
In the authentication step, the device being provisioned must send a random single or multiple-digit number to the user based on its capabilities. For instance, the provisioning device may cause an LED to blink several times. At this point, the user must input the number sent by the provisioning device into the provisioner. The two devices will use this random number to perform a series of encrypted data exchanges to authenticate each other.
▶ Send Provisioning Data
Once authentication is successful, both devices will use their private keys along with the public key provided by the other party to generate a session key. This session key will be used to protect the data that needs to be sent during the subsequent provisioning process, such as the aforementioned NetKey network key.
Upon completion of the provisioning process, the provisioned device will have the network key of the mesh network, a security parameter called “IV Index,” and a unicast address assigned by the provisioner, thus officially becoming a node.
§ Optional Features
All nodes can send and receive mesh network messages, but nodes may also have some optional special features. Currently, there are four optional features: Relay, Proxy, Friend, and Low Power; a node can decide whether to support these features or support multiple optional features, and any optional feature can be enabled or disabled at any time.
§ Relay Nodes
Nodes that support the “Relay” feature are called relay nodes, and these nodes can forward the messages they receive. Through the relay mechanism, messages can traverse the entire mesh network, passing through multiple hops along the way.
The protocol data unit (PDU) of the Mesh network contains a field called TTL (Time To Live). This is an integer value used to limit the number of hops a message can take in the network. For instance, if the TTL is set to “3,” the message can be relayed a maximum of three times.
If it is set to “0,” the message cannot be relayed and must be sent directly to the destination. Nodes in the Mesh network can enhance the efficiency of the mesh network using the TTL field by having a basic understanding of the topology configuration and the members on the network.
§ Low Power Nodes and Friend Nodes
Some types of nodes have limited power capabilities and must conserve energy as much as possible. Additionally, these devices may spend most of their time sending messages but still need to receive some messages occasionally.
For example, a temperature sensor may be powered by a small button battery. When the temperature exceeds or falls below a preset upper or lower threshold, it will send temperature readings once every minute. If the temperature remains between the upper and lower thresholds, it will not send messages. This operation is easy to achieve and does not consume too much power.
However, the problem arises when users need to send messages to the sensor to set new threshold values. Although this situation is infrequent, the sensor must be able to support it. However, the need to receive messages increases the load on the device, thus consuming power; if the device is always in a standby state, it will not miss any temperature threshold setting messages but will consume a lot of power; if the device is in a low-power standby state, it can save power but may miss some setting messages.
To solve this dilemma, the answer lies in the concept of “Friend” nodes and “Friendship.” Using the aforementioned temperature sensor as an example, we can set the sensor as a “Low Power Node” (LPN) by adding a functional flag in the sensor’s setup data.
The LPN requires the cooperation of another node with no power limitations (for example, a node that is always plugged in), which is referred to as a “Friend” node. The friend node is responsible for storing messages sent to the LPN, and the LPN periodically polls the friend node to check for any “pending messages.”
As long as the polling frequency of the LPN to the friend node is not too high, it can balance the need to save power and receive messages in a timely manner. Whenever the LPN polls the friend node, the friend node will send all the messages it has stored to the LPN one by one and indicate to the LPN that there are more messages waiting to be sent with a MD (More Data) flag.
The relationship between the LPN and the friend node is called “Friendship.” For nodes with limited power that must receive messages, the concept of friendship is crucial, allowing them to continue operating within the Bluetooth Mesh network while being energy efficient.
§ Proxy Nodes
There is a vast number of devices supporting low-energy Bluetooth worldwide, and most smartphones and tablets are examples.
However, when the Bluetooth Mesh network is officially adopted, existing Bluetooth devices in the market do not support Bluetooth Mesh technology. However, they can support low-energy Bluetooth, thus connecting and interacting with other devices via the Generic Attribute Profile (GATT).
The role of “Proxy” nodes is to provide a GATT interface for low-energy Bluetooth devices to interact with the Mesh network. Bluetooth defines a “Proxy Protocol” communication protocol for connection-oriented bearer devices (like GATT) to use; GATT devices will read and write Proxy Protocol PDUs from Proxy nodes, which will convert these PDUs into Mesh PDUs, and vice versa (Figure 6).
Figure 6: Mobile phone communicating via Mesh proxy node, P= Proxy function enabled
In short, Proxy nodes allow low-energy Bluetooth devices that do not possess Bluetooth Mesh technology to interact with nodes in the Mesh network.
§ Node Configuration
Each node supports a standard set of configuration states, which are executed in the Configuration Server Model and accessed through the Configuration Client Model. Configuration state data pertains to the capabilities and behaviors of nodes within the Mesh network but does not relate to the behaviors of individual applications or device types.
For example, the functionalities supported by a node, regardless of whether it is a proxy node, relay node, etc., are indicated through the configuration server states. The addresses subscribed by a node are stored in the Subscription List, and network and subnet keys indicate the network to which the node belongs and are listed in the Configuration Block. The application keys held by the node are also listed there. Bluetooth Mesh network defines a series of configuration messages to allow the configuration client model and configuration server model to perform read, set, and status operations under the configuration server model’s state.
Analysis of Bluetooth Mesh Network Architecture
This section will delve into the architecture of Bluetooth Mesh networks and the roles of its various layers. It will also explain the relationship between the Mesh architecture (Figure 1) and the core architecture of low-energy Bluetooth.
At the lowest level of the Mesh network architecture is called “low-energy Bluetooth.” However, this is not merely one layer of the Mesh architecture but refers to the entire low-energy Bluetooth technology, which provides the basic wireless communication capabilities needed for the Mesh architecture above it to operate.
Clearly, the Bluetooth Mesh system must operate in the presence of low-energy Bluetooth technology. Next, we will explain each layer of the Mesh architecture starting from the lowest level.
▼ Bearer Layer
The messages in the Mesh network require a communication system to transmit and receive. This is the role of the “Bearer Layer,” which defines how the communication system should handle Mesh PDUs. Currently, Bluetooth Mesh technology only defines two bearers: Advertising Bearer and GATT Bearer.
The Advertising Bearer will use the low-energy Bluetooth GAP broadcasting and scanning features to send and receive Mesh PDUs. The GATT Bearer allows devices that do not support the Advertising Bearer to communicate indirectly with nodes in the Mesh network that support the Advertising Bearer using the aforementioned “Proxy Protocol.”
The Proxy Protocol is encapsulated within the GATT operation, achieved through specially defined GATT characteristics. The proxy nodes in the Mesh network will execute GATT characteristics and support both GATT Bearer and Advertising Bearer, thus able to convert and forward messages between the two bearers.
▼ Network Layer
The “Network Layer” defines various message address types and network message formats, allowing the Bearer Layer to transmit transport layer PDUs. This layer can support multiple bearers, each with multiple network interfaces, including local interfaces that allow multiple elements within the same node to communicate with each other.
The Network Layer determines which network interface a message should be output through. Messages from the Bearer Layer will pass through an input filter to determine whether to pass the message to the Network Layer for further processing. Similarly, output messages will pass through an output filter to determine whether to discard the message or send it to the Bearer Layer. The relay and proxy functions can also be executed through the Network Layer.
▼ Lower Transport Layer
The “Lower Transport Layer” receives PDUs from the upper transport layer and then transmits them to the lower transport layer of another device; if necessary, this layer will also segment and reassemble the PDUs. When the PDUs are too long to fit into a single Transport PDU, the Lower Transport Layer will segment the PDU into multiple Transport PDUs. The Lower Transport Layer of the receiving device will then reassemble these segmented PDUs into a single Upper Transport Layer PDU and pass it to the upper layer.
▼ Upper Transport Layer
The “Upper Transport Layer” is responsible for encrypting, decrypting, and authenticating application data coming from and going to the Access Layer. Additionally, this layer also handles message transmission and control, with messages generated internally from the Upper Transport Layer of each node and exchanged with each other, including messages related to “Friendship” and “Heartbeat.”
▼ Access Layer
The “Access Layer” defines how various applications should access the Upper Transport Layer, including:
• Defining application data formats.
• Defining and controlling the encryption and decryption processes executed by the Upper Transport Layer.
• Ensuring that data received from the Upper Transport Layer is sent to the correct network before passing it to the next layer.
▼ Foundation Models Layer
The “Foundation Models Layer” is responsible for executing models related to the configuration and management of the Mesh network.
▼ Models Layer
The “Models Layer” is responsible for executing models and their related behaviors, messages, statuses, state bindings, etc., according to model specifications.
▼ Mandatory Security Mechanisms for Bluetooth Mesh Networks
Low-energy Bluetooth offers various security mechanisms for designers of specifications to choose from, such as different pairing methods or individual security requirements for each characteristic, etc. However, security is entirely an optional feature, so it is possible to create completely open devices without any security protections or restrictions.
Device designers or manufacturers must analyze the threats they face and then determine their product’s security needs and solutions (Figure 2). However, for Bluetooth Mesh networks, security is mandatory. Whether it is the network itself or individual applications and devices, all have security mechanisms in place that cannot be turned off or weakened in any way.
▼ Basic Security Principles of Bluetooth Mesh Networks
Bluetooth Mesh networks have the following basic security principles:
• All Mesh messages are encrypted and authenticated.
• Network security, application security, and device security are independently separated.
• Security keys can be changed during the lifecycle of a Mesh network through a “Key Refresh” process.
• Message header encoding makes it difficult to trace messages transmitted within the network, providing a privacy mechanism that makes nodes untraceable.
• The security mechanisms of Bluetooth Mesh can prevent replay attacks.
• The process of adding devices to the Mesh network to become nodes is secure.
• Nodes can be securely removed from the network and can prevent “trashcan” attacks.
▼ Isolation Based on Different Security Considerations
The core of the Bluetooth Mesh security mechanism consists of three types of keys. These keys protect different parts of the Mesh network and separate different security considerations.
To understand this design and its importance, let’s look at a case of a Mesh light bulb that can act as a relay node. When the bulb acts as a relay, it may handle some messages related to the building’s access control system. However, a bulb should not have permission to read and process the content of such messages but must forward the messages to other nodes.
To resolve this conflict, Bluetooth Mesh technology employs different security keys that protect the transmission of messages at the network layer and the application-related data (such as lighting, security, heating, etc.).
All nodes in the Mesh network have a network key (NetKey). In fact, it is because they hold a common key that nodes can become members of that network. This network key can also derive a network encryption key and a private key.
The network key held by a node can only decrypt and verify communications at the network layer, allowing the node to forward messages but not to decrypt application-related data. The network may also be further divided into multiple subnets, each with its own dedicated network key, which only members of that subnet possess. The network key can be used to isolate physical spaces, such as each room in a hotel.
To decrypt application-related data, a node must possess the corresponding application key (AppKey). Among all nodes in the Mesh network, there may be many different application keys, but usually, each application key will only be held by a few types of nodes that can participate in that application. For example, light bulbs and lighting switches will have the application key for lighting but will not have the application key for heating systems; the latter is usually held by temperature control switches, radiator control valves, and other nodes.
The upper transport layer will use the application key to encrypt and authenticate messages before passing them to the access layer. Multiple application keys may correspond to a single network key.
This relationship is called “key binding,” indicating that certain applications must hold application keys and can only operate within a specific network, but one network can accommodate multiple independent and secure applications.
The last key is the device key (DevKey), a special type of application key. Each node has a unique device key known only to the provisioning device. The device key is used during the provisioning process to ensure the security of communications between the provisioner and the node.
▼ Enhancing Security with Node Removal/Key Update
As mentioned earlier, nodes hold various security keys for the Mesh. If a node fails and must be removed, or if the owner decides to sell it to someone else, it is crucial to ensure that the device cannot be used to attack its original network.
To this end, Bluetooth Mesh technology defines a process for removing network nodes. Users can use the provisioning application to blacklist a node and initiate the “Key Update” process.
The key update process causes all nodes on the network (except for the blacklisted node) to receive new network keys, application keys, and all related derived data. In other words, the entire set of security keys responsible for ensuring the security of the network and applications will be replaced. This way, the network keys and application keys held by the removed node become invalid, and the node will no longer be a member of the network, thus posing no threat.
▼ Privacy
The private key derived from the network key is used to encode the header data of the network PDU, such as the source address. Encoding ensures that eavesdroppers cannot easily trace the movements of devices and their users. Furthermore, it makes it difficult for some traffic analysis attacks to succeed. This technique’s security level indeed matches its purpose.
▼ Replay Attacks
In the field of network security, a “replay attack” refers to an attacker intercepting and capturing one or more messages from the network and retransmitting them, aiming to deceive the receiving end into executing actions that the attacker’s device does not have permission to perform. A common example is a car keyless entry system, where hackers capture the authentication messages between the owner and the vehicle and replay these messages to unlock the doors and steal the car.
Bluetooth Mesh networks have built-in mechanisms to prevent replay attacks. Essentially, this is accomplished using two fields in the network PDU: Sequence Number (SEQ) and IV Index.
When an element publishes a message, it increments the SEQ value. When a node receives a message from an element, if its SEQ value is less than or equal to the last valid message’s SEQ, that message will be discarded, as it is likely a result of a replay attack.
The IV Index is another field used in conjunction with SEQ. Messages from the same element must contain an IV Index that is equal to or greater than the last valid message’s value from that element.
▼ Bluetooth Mesh Networks Use Managed Flooding Mechanism
Wi-Fi networks operate around a central node (the router), with all network traffic passing through it. If the router fails, the entire network stops functioning.
In contrast, Bluetooth Mesh networks employ a message delivery technique called “managed flooding.” Once a message is published by a node, it is broadcasted across the network rather than routed to one or more specific nodes.
All nodes within radio frequency range will receive the message and can forward it (if configured to do so). The so-called forwarding means rebroadcasting the received message so that nodes farther away from the original sending node can receive it.
Furthermore, Bluetooth technology’s use of managed flooding has another significant meaning: messages can reach their destination through multiple paths within the network. This creates a very stable and reliable network, which is why the design of Bluetooth Mesh networks chose to use a flooding method of delivery rather than a routing approach.
▼ Characteristics of Managed Flooding Mechanism
Bluetooth Mesh networks effectively utilize the advantages of flooding methods and optimize them to achieve both stability and efficiency, reflecting the meaning represented by the “managed flooding mechanism.” These methods include:
▼ Heartbeat
Nodes periodically emit “heartbeat” messages. Each heartbeat message informs other nodes in the network that it is still functioning normally. Additionally, heartbeat messages contain data that allows receiving nodes to determine the distance from the sender, i.e., how many hops it takes to reach them, which can be effectively used in the TTL field.
▼ TTL
TTL (Time To Live) is a field that all Bluetooth Mesh PDUs possess. This field is used to control the maximum number of hops during the message forwarding process. By setting the TTL, nodes can control the forwarding of messages and achieve energy savings, avoiding unnecessary excessive forwarding of messages. Heartbeat messages allow nodes to determine the maximum TTL setting for each published message.
▼ Message Cache
All nodes must implement message caching, which includes all messages recently received by the node. When a node receives a message, it can compare it against the cache to see if the same message is already present. If so, it indicates that the message has already been accepted and processed, and it can be immediately discarded.
▼ Friend Nodes
The important optimization mechanism in Bluetooth Mesh networks is the combination of “Friend” nodes and “Low Power” nodes. As mentioned, friend nodes can provide message storage functions and subsequently forward messages to relevant low-power nodes. This allows low-power nodes to achieve excellent energy efficiency. The internal transmission of messages occurs when a node receives a message, sending it from the lowest layer of low-energy Bluetooth up layer by layer (from the bearer layer to the network layer). Then, the network layer performs various checks to determine whether to forward the message to the upper layer or discard it.
▼ Internal Message Transmission
When a node receives a message, it will transmit the message from the lowest layer of low-energy Bluetooth up layer by layer (from the bearer layer to the network layer). The network layer will then perform various checks to determine whether to pass the message to the upper layer or discard it.
Additionally, the PDU contains a network identifier (Network ID) field that can be used to quickly determine the network key used by the message. If the receiving node’s network layer cannot identify the network key, it means that the receiving device is not a member of that network, and the PDU will be discarded. There is also a message integrity check (MIC) field. The node will identify the network key corresponding to the PDU’s network identifier; if the check fails, the message will be discarded. All nodes within the signal range of the sending node will receive the emitted message, while messages unrelated to the receiving device will be quickly discarded, such as messages from different networks or subnets.
The same principle applies to the upper transport layer. However, this layer checks the application key of the message, which is the application identifier (AID) field in the PDU. If the receiving node cannot identify the application identifier in the PDU, the upper transport layer will discard the PDU directly. Additionally, if the integrity check of the transmitted message (TransMIC) fails, the message will also be discarded.
Through this article, it is believed that you should have a basic understanding of Bluetooth Mesh technology, its functions, concepts, and terminology. Although Bluetooth technology differs somewhat from what we know, it is a Bluetooth technology that allows devices to communicate with each other through a new topology; most importantly, this technology enables widely used low-energy Bluetooth wireless technology to explore new fields and industries.
The strongest science popularization from CCTV, how are chips manufactured?
Linux thinking organized, the outline you lack is well organized!
Newcomers come in! How to quickly get started with embedded development?
In 10 minutes, can you explain what the Internet of Things is?
5000 words of dry goods, understand the memory of embedded operating systems.