Bluetooth® mesh, you can create large-scale networks capable of supporting secure, reliable communication between tens, hundreds, or thousands of devices. In part 1 of The Fundamental Concepts of Bluetooth Mesh Networking, we explored some of the basic concepts of a Bluetooth mesh network, including nodes, elements, models, and states. In this article, we examine addressing, messages, publications, subscriptions, and lists, and detail how these core concepts interweave to make a Bluetooth mesh network.
The Bluetooth Mesh Architecture
Bluetooth® mesh runs on top of the Bluetooth Low Energy (LE) stack. Figure 1 below outlines the Bluetooth mesh stack and defines the functionality of each layer.
Figure 1 – Bluetooth mesh architecture.
As we discussed in part 1, nodes—such as light fixtures, temperature regulation equipment, manufacturing equipment, and electronic gates—are devices capable of sending, receiving, and/or relaying information within the Bluetooth mesh network. Messages are used to transfer data between nodes, and addresses are used to define where the messages come from (source) and go to (destination).
There are four types of addresses; three of these types are used in messaging: unicast, virtual, and group addresses. The fourth is known as an unassigned address. Addresses are 16 bits in length and are encoded as defined below (Figure 2).
Figure 2 – Mesh address encoding.
- Unassigned Address – Unconfigured elements, or elements without designated addresses, have an unassigned address. Given these elements do not have a unique address, they may not be used in messaging.
- Unicast Address – During provisioning, a provisioner allocates a unicast address to each element in a node for the lifetime of that node on the network. Unicast addresses may appear in the source address field and/or the destination address field of a message. Messages sent to unicast addresses are only processed by one element.
- Virtual Address – Virtual addresses are a set of elements associated with a specific Label UUID; these addresses may be published or subscribed to. The Label UUID is a 128-bit value associated with multiple elements that may come from one or more nodes.
For virtual addresses, bits 15 and 14 are set to 1 and 0 respectively (Figure 2); bits 13 – 0 are set to a hash value (providing 16,384 hash values). The hash is derived from the Label UUID. Checking the full 128-bit UUID with a subscribing element is inefficient, especially as the UUID may span more than one message segment. The hash values provide a more efficient way of determining which messages go to which elements.
- Group Address – Group addresses are another type of multicast address found in Bluetooth mesh networking. Representing multiple elements from one or more nodes, there are two types of group addresses:
- Dynamically assigned -> 0xC000-0xFEFF
- Fixed addresses – Assigned by Bluetooth SIG and divided into five segments:
- Reserved for Future Use (RFU) –> 0xFF00-0xFFFB
- All-proxies -> 0xFFFC
- Sent to all nodes with proxy functionality enabled.
- All-friends -> 0xFFFD
- Sent to all nodes with friend functionality enabled.
- All-relays -> 0xFFFE
- Sent to all nodes with relay functionality enabled.
- All-nodes -> 0xFFFF
- Sent to all nodes.
- All messages sent to fixed nodes are processed by the primary element of the node.
Bluetooth® mesh networks communicate via messages. A message may be termed a control message or an access message.
- Control Messages – Messages concerned with the operation of the Bluetooth mesh network. Examples include heartbeat and friend request messages.
- Access Messages – Allow client models to retrieve or set the value of state values in server models, or they are used to report state values by the server.
Models implement and define the functionality of nodes. Elements are uniquely addressable entities within nodes containing one or more models and states define the status of elements. For every state, there is set of messages that a server model supports. Examples include a client model requesting the value of a state or requesting to change a state and a server model sending messages about states and/or a state change.
Messages are identified by opcodes and have associated parameters. An opcode identifies the operation of the message. Examples include:
- Generic OnOff Get – Used to identify the state; OnOff state for a generic model.
- There are no parameters for Generic OnOff Get.
- Generic OnOff Set is used to set the OnOff state of a generic model.
- OnOff – The target value (on or off).
- TID – Transaction Identifier – Is the message new or a re-transmission.
- Transition Time – How long an element should take to transition from one state to another.
- Delay – Message execution delay.
There are two categories of access message, acknowledged and unacknowledged. Acknowledged messages are transmitted to and acknowledged by each receiving element. The response is typically a status message. No response is sent to an unacknowledged message. Bluetooth mesh network status messages are an example of unacknowledged messages.
Every Bluetooth® mesh network message is secured using NetKeys and AppKeys to encrypt and authenticate messages. NetKeys are used for the network layer communication. Assuming a Bluetooth mesh network has no subnets, all communication within that mesh network uses the same network key.
AppKeys are used for application data. Some nodes within the network may have specific applications and, within these applications, potentially sensitive data requiring limited access. Such nodes have a specific AppKey and are associated with specific applications. Examples of areas that may use different AppKeys include security (building access control, equipment room access, and CEO office access), lighting (manufacturing floor, exterior building lights, and walkways), and HVAC systems.
Relay nodes, such as light bulbs or wall switches, typically have valid NetKey and can relay sensitive messages within the network. However, they would not have access to the specific AppKeys for the various restricted areas, such as building control or HVAC Systems, and couldn’t decrypt the application data.
Bluetooth® mesh networking uses a publish/subscribe model for message transport. Nodes generating messages are said to publish messages. Nodes interested in receiving messages subscribe to addresses they are interested in. Messages may be published to unicast, group, or virtual addresses.
Messages may be sent as replies to other messages, or they may be unsolicited messages. When a model sends a reply message, it uses the message originator’s source address as the destination address. When sending an unsolicited message, it uses the model’s publish address as the destination address. Every model in a node has a single publish address.
When receiving messages, each instance of a model within a node (there may be multiple models in a node) may subscribe to receive messages from one or more group or virtual addresses.
Models subscribing to messages use a model’s subscription lists to define valid addresses that they can receive messages from. When messages are received by a model, the model checks its subscription list. It’s considered a match when the address on the subscription list is set to the model’s element unicast address or a fixed group address that belongs to the node. Figure 3 shows valid source and destination addresses for access messages.
Figure 3 – Valid source and destination addresses for access messages.
As Bluetooth® mesh entities publish the status of various nodes, systems throughout the whole Bluetooth mesh network can subscribe to this data regardless of proximity to a transmitting node’s location. This allows equipment on one side of the network to talk to administrators elsewhere in the facility via low-power wireless messages, regardless of distance.
Learn More About Mesh
Bluetooth® mesh combines the proven, global interoperability and mature, trusted ecosystem associated with Bluetooth technology to support the creation of industrial-grade device networks. Now that you have a basic understanding of the fundamental concepts behind Bluetooth mesh networking, you’re ready to take a deeper dive into the intricacies of the topology. For an in-depth look at Bluetooth mesh, download the Bluetooth Mesh Technical Overview. Later, we’ll explore Bluetooth mesh security, provisioning, proxy nodes, and more.
Bluetooth Mesh Models: A Technical Overview
In this detailed technical paper, Martin Woolley provides a guided tour of the Bluetooth mesh models, taking an in-depth look at building blocks critical to Bluetooth mesh interoperability.
Maintaining Lighting Control Means More Than Managing Lighting
When someone mentions control in terms of lighting, chances are the listener thinks of…
New Five-Year Forecasts for Bluetooth Device NetworksBluetoothデバイスネットワークにおける今後5年間の最新予測
From networked lighting control to monitoring systems to electronic shelf labels (ESL), Bluetooth® Device…
How Bluetooth Mesh and DALI Form a Digital Highway for Lighting Control and Data CollectionBluetooth MeshとDALIが形成する 照明制御とデータ収集の高速データ通信網
Bluetooth® technology and DALI® already have a long history of working together. But as…
Bluetooth Mesh Empowers Innovation for Intelligent Delta Electronics Lighting SystemsBluetooth meshが支えるデルタ電子のインテリジェント照明システムイノベーション
In recent years, intelligent lighting solutions have gained increasing attention from the industry as…