2. About this paper

The Bluetooth® Mesh Primer has been created to help technology professionals such as product designers and developers to quickly learn about Bluetooth Mesh technology before consulting the formal technical specifications and delving more deeply into the subject.

It is not the aim of this paper to reproduce or cover the same ground as the formal specifications or to the same depth. From time to time, brief extracts from the specifications may be included where it makes sense to do so. You should think of this paper as serving to orientate by introducing and explaining important Bluetooth Mesh concepts, pointing the way to other resources and specifications and hopefully, making the learning curve a little bit less steep.

3. Introduction

3.1 The Evolution of Bluetooth technology

Bluetooth technology has been around since the year 2000. Initially created to allow two devices to exchange data wirelessly without the need for any other intermediate networking equipment, it quickly found a role in products such as wireless mice and hands-free kits for cars. This first version of Bluetooth technology, used in those very first ever Bluetooth products is known formally as Bluetooth BR (Basic Rate) and operates at one million bits[1] per second (Mb/s) at the physical layer. It was followed by a faster version of the same technology which doubled the bit rate to 2 Mb/s called Bluetooth BR/EDR where EDR stands for Enhanced Data Rate.

Bluetooth Low Energy (LE) first appeared in version 4.0 of the Bluetooth Core Specification[2]. This was a new version of Bluetooth technology which rather than replace its predecessor, Bluetooth BR/EDR, sat alongside it as an alternative with capabilities and qualities that made it perfect for a new generation of products and the ability to meet new and challenging technical and functional requirements.

Bluetooth LE supports topologies other than point to point communication between two devices with a broadcast mode which allows one device to transmit data to an unlimited number of receivers simultaneously.

Bluetooth LE is also the foundation of Bluetooth Mesh networking which allows networks of tens of thousands of devices to be created, each one able to communicate with any other device in the network.

3.2 Bluetooth Mesh networking

Bluetooth Mesh networking was created to provide a secure, scalable and standardized wireless communication technology that can be applied to the problems and opportunities of commercial buildings.

Networked lighting control is a key application for Bluetooth Mesh and both manual and automated lighting control across physically large spaces is made possible.  An individual light or a group of lights can be acted upon in a single network operation.

Here are a few of the key things that are possible with networked lighting control based on a Bluetooth Mesh network.

• They can be switched on and off.
• Their brightness (more accurately termed lightness) can be controlled along a perceptually uniform scale that compensates for the varying sensitivity to light of the human eye.
• Color temperature, hue and saturation can be modified.
• Sensors can deliver information about more or less any measurable property of a room to relevant lights so that their state can be automatically adjusted in response to the environmental conditions. Note that Bluetooth Mesh does not require a centralized router to exchange messages between the sensors and lights.
• Arbitrary collections of certain state values known as scenes can be defined and lights can switch from one scene to another at a single request.
• Scene changes affecting groups of lights can be scheduled to take place automatically at specific points in time.
• Allows the automatic triggering of scenes based on room occupancy and the automatic transition to a standby state when there are no occupants. This helps in saving energy.
• Supports the ability to set predefined schedules for changing the states of lights.
• Supports the concept of vendor models which allow manufacturers to add additional features to their devices when needed.

Control over lights in a network is not limited by the range of direct wireless communication. A device like a switch or a sensor can exercise control over lights that are located in the far distant reaches of a building, perhaps tens of floors above.

Security was designed into Bluetooth Mesh technology from the start, and it addresses potential issues and threats including:

• safeguarding the confidentiality of information
• preventing devices from being tracked through device and network privacy mechanisms
• preventing the manipulation of network control messages
• constraining actions of devices to specific parts of the network only
• preventing replay attacks
• ensuring the addition of devices to the network is subject to a secure process
• ensuring devices can be securely removed from the network without any risk that discarded devices can be used to gain unauthorized access at a later time
• offering the ability to provide and revoke guest access to relevant functionalities in the network without compromising security of larger network.

Buildings that are equipped with a Bluetooth Mesh network and wireless networked lighting control enjoy a range of benefits.

• They become more energy efficient, with sensors delivering data about ambient light levels and room occupancy which can be automatically used to adjust lighting levels.
• Lighting can be reconfigured at the touch of a switch or smartphone application user interface (UI) to be optimized for a room’s current use, be it presentation or large company round-table meeting.
• Proactive maintenance is facilitated by the usage and device health data that Bluetooth Mesh devices can make available.
• Changes to physical layout and lighting requirements in a building are more easily brought about. It’s wireless!
• Bluetooth Mesh technology is defined by a series of standard specifications that span the full protocol stack and the behaviors, capabilities and interfaces to devices. This means that compliant products from any mix of manufacturers will be interoperable. Adopters of Bluetooth Mesh technology are not locked into a single manufacturer or small, closed group.

4. Key Features and Concepts

Understanding Bluetooth Mesh networking topology requires the reader to learn about a series of fundamental features, technical terms and concepts that are not found anywhere else in the world of Bluetooth LE. In this section, we’ll explore the most fundamental of these features, terms and concepts.

4.1 Bluetooth Operational Modes

Bluetooth LE defines a number of different ways which devices can communicate with each other. They are formally defined in the Bluetooth Core Specification and informally referred to as “operational modes” in this paper.

The various operational modes differ in a number of ways including the topology formed by the devices, the direction of communication which is possible and the underlying technicalities of the mode such as whether it is a connection-oriented or connectionless mode.

In connection-oriented communication the devices first exchange information which allows them to agree important aspects of the subsequent communication such as transmit and receive timing parameters. In connectionless communication, this does not happen and transmit and receive timings are not pre-agreed in the same way. In Bluetooth LE, connection-oriented communication always takes place between exactly two devices whereas connectionless communication can be used by one transmitting device to communicate with multiple receiver devices, with or without some degree of pre-agreed information about the parameters.

Topology is concerned with the cardinality of the relationships which may be formed between communicating devices. Three distinct topologies are recognized:

• one-to-one (1:1)
• one-to-many (1:m)
• many-to-many (m:n)

Some operational modes allow communication of application data in one direction only whereas others allow bidirectional communication.

Some modes use a precisely regular schedule for the transmission of packets and in other cases, it is irregular.

Seven operational modes are currently defined. They are as follows:

• LE Asynchronous Connection-oriented Logical transport (LE ACL)
• LE Advertising Broadcast (ADVB)
• LE Periodic Advertising (PADVB)
• LE Periodic Advertising with Responses (PAwR)
• Connected Isochronous Stream (CIS)
• Broadcast Isochronous Stream (BIS)
• Channel Sounding (CS)

The Bluetooth Core Specification defines each mode in detail.

Table 1 summarizes the key attributes of the seven operational modes for the purpose of comparison. Note that Channel Sounding (CS) is a special mode which is designed to support the secure calculation of the distance between two devices only and is not used for the transfer of application data.

Operational Mode	Connection-Oriented or Connectionless	Topology	Transmit Schedule	Direction of Application Data
LE ACL	connection-oriented	point-to-point	regular	bidirectional
ADVB	connectionless	one-to-many	irregular	unidirectional
PADVB	connectionless	one-to-many	regular	unidirectional
PAwR	connectionless	one-to-many	regular	bidirectional
CIS	connection-oriented	point-to-point	regular	bidirectional
BIS	connectionless	one-to-many	regular	unidirectional
CS	N/A	one-to-one	regular	N/A

Table 1 – Attributes of Bluetooth Operational Modes

Bluetooth Mesh technology is not an operational mode. It’s a protocol with a series of defined procedures, standard application-layer behaviors, and other features which make it possible to use Bluetooth LE as a wireless networking technology. It builds upon core capabilities of Bluetooth LE including several of the operational modes so that at times it is acting in a connectionless way and at other times using connection-oriented communication. In principle, the topology formed by a Bluetooth Mesh network is many-to-many since any device may potentially communicate with any other device and communication of application data can occur in either direction.

Communication is achieved using messages which are transported by Bluetooth LE in a suitable way using a mechanism called a bearer which is based upon one of the operational modes. Devices are able to relay messages to other devices right across the network so that the end-to-end communication range is extended far beyond the radio range of each individual mesh device.

4.2 Devices and Nodes

Devices which are part of a mesh network are called nodes and those which are not are called unprovisioned devices.

The process which transforms an unprovisioned device into a node is called provisioning.

Provisioning is a procedure which results in an unprovisioned device possessing a series of security keys, having a unicast address assigned to it and being listed in a database on a device known as the Provisioner. The Provisioner is typically a tablet or smartphone.

4.3 Elements

Some nodes have multiple constituent parts, each of which can be independently controlled. In Bluetooth Mesh terminology, these parts are called elements. Figure 1 shows an LED lighting product which if added to a Bluetooth Mesh network, would form a single node with three elements, one for each of the individual LED lights.

Figure 1 – Lighting node consisting of three elements

4.4 Messages

When a node needs to query the status of other nodes or needs to control other nodes in some way, it sends a message of a suitable type. If a node needs to report its status to other nodes, it sends a message. All communication in the mesh network is message-oriented and many message types are defined, each with its own unique opcode.

Messages fall within one of two broad categories:

• Acknowledged messages require a response from nodes that receive them. The response serves two purposes: it confirms that the message it relates to was received, and it returns data relating to the message recipient to the original message sender. The sender of an acknowledged message may resend the message if it does not receive the expected response(s) and therefore, acknowledged messages must be idempotent. This means that the effect of a given acknowledged message, arriving at a node multiple times, will be the same as if it had only been received once.
• Unacknowledged messages do not require a response.

Most Bluetooth Mesh scenarios involve the use of unacknowledged messages since this model of messaging scales very well. It is made reliable by configuring nodes to retransmit copies of messages multiple times in quick succession.

Messages that require acknowledgements to be returned work well when the target is a single device but do not scale well when targeting a group of multiple devices. Most messages that are involved in configuring a node or its elements use acknowledged messages.

A system known as relaying allows messages to be delivered beyond the immediate radio range. Relaying is explained in 4.19 Message Relaying.

4.5 Addresses

Messages must be sent from and to an address. Bluetooth Mesh defines three types of address.

A unicast address uniquely identifies a single element. A unicast addresses is assigned to a device during the provisioning process.

A group address is a multicast address. This address type allows more than one device to receive the same transmitted message through a process called publish and subscribe. Group addresses are either defined by the Bluetooth SIG and are known as Fixed Group Addresses or are assigned dynamically. Seven SIG Fixed Group Addresses have been defined. These are named all-nodes, all-relays, all-friends, all-proxies, all-directed-forwarding-proxies, all-ipt-nodes and all-ipt-border-routers. The terms Proxy, Friend and Relay will be explained later in this paper.

It is expected that dynamic group addresses will be established by the user via a configuration application and that they will reflect the physical configuration of a building, for example defining group addresses which correspond to each room in the building.

A virtual address is similar to a group address in that it allows a single transmitted message to be received by multiple devices through publish and subscribe. It takes the form of a 128-bit UUID value with which any element can be associated and is much like a label. For example, virtual addresses can be preconfigured at the point of manufacture and used for scenarios such as allowing the easy addressing of all meeting room projectors made by the manufacturer that are deployed in a mesh network.

4.6 Publish / Subscribe

The act of sending a message is known as publishing. Nodes are configured to receive only those messages that were sent to specific addresses for processing, and this is known as subscribing.

Typically, messages are addressed to group or virtual addresses. Group and virtual address names will have readily understood meaning to the end user, making them easy and intuitive to use when configuring devices.

In Figure 2, we can see that the node named Switch 1 is publishing to the group address Reception. Nodes Light 1, Light 2 and Light 3 each subscribe to the Reception address and therefore process messages published to this address. In other words, Light 1, Light 2 and Light 3 can be switched on or off using Switch 1.

Switch 2 publishes to the group address Accounts.  Light 3 alone subscribed to this address and so is the only light controlled by Switch 2. Note that this example also illustrates the fact that nodes may subscribe to messages addressed to more than one distinct address. This is both powerful and flexible.

Similarly, notice how both Switch 5 and Switch 6 publish to the same Underwriting address.

The use of group and virtual addresses with the publish/subscribe communication model has an additional benefit in that removing, replacing or adding new nodes to the network does not require reconfiguration of other nodes. Consider what would be involved in installing an additional light in the accounts department. The new device would be added to the network using the provisioning process and configured to subscribe to the Accounts address. No other nodes would be affected by this change to the network. Switch 2 would continue to publish messages to Accounts as before but now both Light 3 and the new light would respond.

Figure 2 – Publish and Subscribe

4.7 States and Properties

Elements can be in various conditions, and this is represented in Bluetooth Mesh by the concept of state values.

A state is a value of a certain type, contained within an element and one of its models – see below). States also have associated behaviors and may not be reused in other contexts.

As an example, consider a simple light which may either be on or off. Bluetooth Mesh defines a state called Generic OnOff. The light would possess this state and a value of On would correspond to and cause the light to be illuminated, whereas a Generic OnOff state value of Off would cause the light to be switched off.

The significance of the term Generic will be discussed later.

Properties are similar to states in that they contain values relating to an element.  But they are different to states in other ways.

Readers who are familiar with Bluetooth LE[3] will be aware of characteristics and recall that they are data types with no defined behaviors associated with them, making them reusable across different contexts such as within different GATT services. A mesh property provides the context for interpreting a characteristic in a Bluetooth Mesh device.

To appreciate the significance and use of contexts as they relate to properties, consider for example, the characteristic Temperature 8, an 8-bit temperature state type which has a number of associated properties, including Present Indoor Ambient Temperature and Present Outdoor Ambient Temperature. These two properties allow a sensor to publish sensor readings in a way that allows a receiving client to determine the context the temperature value has, making better sense of its true meaning.

4.8 States and Fundamental Operations

Messages are the mechanism by which operations that act upon mesh devices are invoked. A given message type defines an operation on a state or a collection of state values. All messages are of three broad types, reflecting the types of operation which Bluetooth Mesh supports. The shorthand names for the three types are GET, SET and STATUS.

GET messages request the value of a given state from one or more elements. A STATUS message is sent in response to a GET and contains the relevant state value.

SET messages change the value of a given state. An acknowledged SET message will result in a STATUS message being returned in response to the SET message whereas an unacknowledged SET message requires no response.

STATUS messages are sent in response to GET messages, acknowledged SET messages or independently of other messages, perhaps driven by a timer running on the element sending the message, for example.

Specific states referenced by messages are inferred from the message opcode. Properties on the other hand, are referenced explicitly in generic property related messages using a 16-bit property ID.

4.9 State Transitions

Changes from one state to another are called state transitions. Transitions may be instantaneous or execute over a period of time called the transition time. A state transition is likely to have an effect on the application layer behavior or appearance of a node.

4.10 Bound States

Relationships may exist between states whereby a change in one triggers a change in the other. Such a relationship is called a state binding. One state may be bound to several other states.

For example, consider a light controlled by a dimmer switch. The light could possess the two states, Generic OnOff and Generic Level with each bound to the other. Reducing the brightness of the light until Generic Level has a value of zero (fully dimmed) results in Generic OnOff transitioning from the On state to the Off state.

4.11 Models

Models pull the preceding concepts together and define combinations of state data and associated message types and functionality in much the way that a class or object does in object-oriented software development.

A model is typically either a server model or a client model.

• A server model defines a collection of states, state transitions, state bindings, and messages which the element containing the model may send or receive. It also defines behaviors relating to the supported messages, states and state transitions.
• A client model does not define any states. Instead, it defines the messages which it may send or receive in order to GET, SET or acquire the STATUS of states defined in the corresponding server model.

Models may be created by extending other models. A model which is not extended is called a root model.

Models are immutable, meaning that they may not be changed by adding or removing behaviors. The correct and only permissible approach to implementing new model requirements is to extend the existing model.

Foundation Models are those models that are required to configure and manage a mesh network. Other models are concerned with the specific types of functionality as might be required by certain classes of product.

4.12 Generics

It is recognized that many different types of device, often have semantically equivalent states, as exemplified by the simple idea of ON vs OFF. Consider lights, fans and power sockets, all of which can be switched on or turned off.

Consequently, the Bluetooth Mesh Model specification defines a series of reusable, generic states such as Generic OnOff and Generic Level.

Similarly, a series of generic messages that operate on the generic states are defined. Examples include Generic OnOff Get and Generic Level Set.

Generic states and generic messages are used in generalized models, both generic server models such as the Generic OnOff Server and generic client models such as the Generic Level Client.

Generics allow a wide range of device type to support Bluetooth Mesh without the need to create new models. Remember that models may be created by extending other models too. As such, generic models may form the basis for quickly creating models for new types of devices.

Figure 3 – Generic Models

4.13 Scenes

A scene is a stored collection of states which may be recalled and made current in response to receiving a special type of message or at a specified scheduled time. Scenes are identified by a 16-bit Scene Number, which is unique within the mesh network.

Scenes allow a series of nodes to be set to a given collection of previously stored, complimentary states in one coordinated action.

Imagine that in the morning you like the temperature in your reception area to be 20 degrees Celsius, the LED lights to be at a certain brightness level and the lamp on the receptionist’s desk set to a nice warm yellow hue. Having manually set the various nodes in this example scenario to these states, you can store them as a scene using a configuration application and recall the scene later on, either on demand by sending an appropriate, scene-related mesh message or automatically at a scheduled time.

4.14 Networks and Subnets

A Bluetooth Mesh network is defined by a set of four common resources – address space, network keys and application keys, and IV index. A Bluetooth Mesh network can be subdivided into a series of subnets. Unlike networks based on protocols such as TCP/IP, belonging to a particular network does not relate in any way to the address of the device. Instead, Bluetooth Mesh network and subnet membership is achieved largely through issuing a node with a network key (see 4.15 Keys). An element can be issued with multiple network keys and therefore be a member of more than one subnet. Subnets can be completely separate from each other, or they may overlap or be fully contained within another subnet.

Subnets have a number of uses including:

• Adding security to the network by isolating one group of devices from other, unrelated devices.
• Radio spectrum use can be made more efficient by preventing the flow of messages beyond the boundary of the subnet.
• Making network management easier. For example, a “guest device” can be given temporary access to a small part of the network using a subnet and its network key.

Figure 4 depicts subnets used for each guest room in a hotel.

One subnet is designated the primary subnet. Devices that are expected to be permanent members of the network are made members of the primary subnet.

Figure 4 – an example of subnets being used to isolate devices in each room in a hotel

4.15 Keys

The Bluetooth Mesh Protocol specification defines several types of security key.

• Each node has a unique device key (DevKey). Only the device to which it is issued and the Provisioner know this key value. This key is used to make the configuration process secure.
• A device is issued with at least one shared network key (NetKey). This type of key secures communication at the network layer. Possession of a particular NetKey makes a node part of the associated network or subnet. A special key called the primary NetKey relates to the primary mesh network.
• A mesh network has at least one application key (AppKey). Examples of applications that the network supports might include lighting, air conditioning, or heating. An AppKey is used to secure communication at the Upper Transport Layer and has the effect of partitioning messaging between different applications from a security perspective.

A device key and the primary network key are provided to each node during the provisioning process (see 4.16 Provisioning). Application keys and if required, further network keys corresponding to subnets are issued to a device during configuration (see 4.17 Configuration).

4.16 Provisioning

Provisioning is the process by which a device joins the mesh network and becomes a node. It involves several stages, results in various security keys being generated and is itself a secure process.

Provisioning is usually accomplished using an application on a device such as a smartphone or tablet. Other architectures (e.g. cloud-based provisioning) are possible. In this capacity, the device used to drive the provisioning process is referred to as the Provisioner and the device being provisioned, the Provisionee.

A Provisioner can provision a device that is in direct radio range. An optional feature known as Remote Provisioning makes it possible to provision a device that is located anywhere within the network, at any distance from the Provisioner.

4.16.1 Direct Provisioning

The direct provisioning process progresses through five steps, and these are described next.

Step 1. Beaconing

An unprovisioned device indicates its availability to be provisioned by broadcasting an Unprovisioned Device beacon. This is indicated by the inclusion of a Mesh Beacon advertising data (AD) type in the advertising packet payload field.

The user might need to start a new device advertising in this way by pressing a button, for example.

Step 2. Invitation

In this step, the Provisioner sends an invitation to the Provisionee, in the form of a Provisioning Invite PDU. The beaconing Provisionee device responds with information about itself in a Provisioning Capabilities PDU.

Step 3. Exchanging Public Keys

The Provisioner and the Provisionee, exchange their public keys, which may be static or ephemeral, either directly or using an out-of-band (OOB) method.

If supported, X.509 certificates can be used for authentication of public keys. See 4.16.3 Certificate-Based Provisioning.

Step 4. Authentication

During this step, the Provisioner and Provisionee perform certain actions to authenticate. For example, the Provisionee could output a random, single or multi-digit number to the user in some form, using an action appropriate to its capabilities. For example, it might display a multiple digit numeric value. The user then enters the digits output by the new device into the Provisioner and a cryptographic exchange takes place between the two devices, involving the random number, to complete the authentication of each of the two devices to the other. Equally, the Provisioner could output a value which must be input to the Provisionee. A variety of authentication methods are possible, depending in part on the input/output capabilities of the devices.

Step 5. Distribution of the Provisioning Data

After authentication has successfully completed, a session key is derived by each of the two devices from their private keys and the exchanged, peer public keys. The session key is then used to secure the subsequent distribution of the data required to complete the provisioning process, including a security key known as the network key (NetKey) and a device-specific key called the device key (DevKey). Critically, the device key is calculated independently by Provisioner and Provisionee and so never transmitted over the air.

After provisioning has completed, the provisioned device possesses a DevKey, the network’s NetKey, a mesh security parameter known as the IV Index and a Unicast Address, allocated by the Provisioner. It is now known as a node.

4.16.2 Remote Provisioning

Using remote provisioning (RPR), the Provisioner and unprovisioned device may be in any location, provided a communication path across the network between the two devices can be formed. This offers a more practical approach to provisioning for many real-world situations.

Figure 5 – Remote Provisioning

4.16.3 Certificate-Based Provisioning

The provisioning process includes an authentication step. Authentication can be achieved in a number of ways, including for example, displaying a multiple-digit number. Generally, authentication requires the device being provisioned to be in sight of the person performing provisioning so that (e.g.) the number of flashes of an LED can be counted. This is not always practical, however. In particular, if remote provisioning is in use, the device to be provisioned may be completely out of sight, perhaps on the far side of the building.

X.509 certificates are a digital, public key certificates that have a standard format. Bluetooth Mesh supports the use of X.509 certificates during provisioning. Devices provisioned using X.509 certificates do not need to be in sight and therefore compliment remote provisioning very well.

4.17 Configuration

Each node supports a standard set of configuration states which are implemented within the standard Configuration Server Model and accessed using the Configuration Client Model. Configuration state data is concerned with the node’s composition and those capabilities that are independent of any specific application or device type behaviors (these are governed by other models implemented on the device).

The Composition Data state is divided into pages and contains information about the node, including its elements and the models that it supports. The Large Composition Data Server model compliments this state and provides support for devices that have a complex composition and large number of components. DALI (Digital Addressable Lighting Interface) devices are a prime example of such devices.

DALI devices are built around a communication bus, into which up to 128 components (known as bus units in DALI terminology) may be plugged or unplugged easily. When part of a mesh network, a DALI component becomes an element in a complex mesh node which represents the DALI device as a whole. If device firmware detects changes to the components plugged into the bus, its composition data can be automatically updated, providing a plug-and-play capability.

The features supported by a node (see 4.18 Features) are indicated by Configuration Server states. The addresses to which a node has subscribed are stored in the Subscription List state. The network and subnet keys indicating the networks the node is a member of are stored in the NetKey List state and application keys are stored in the AppKey List state.

A series of configuration messages allow the Configuration Client Model and Configuration Server Model to support GET, SET and STATUS operations on the Configuration Server Model states.

4.18 Features

All nodes can transmit and receive mesh messages but there are a number of optional features which a node may possess, giving it additional, special capabilities. There are four such optional features: the Relay, Proxy, Friend and Low Power features. A supported feature may be enabled or disabled at a given time.

4.18.1 Relay Nodes

Nodes which support the Relay feature are known as Relay nodes and are able to retransmit received messages. Relaying is the mechanism by which a message can traverse the entire mesh network, making multiple hops between devices by being relayed.

Mesh network PDUs include a field called TTL (Time to Live). It takes an integer value and is used to limit the number of hops a message will make across the network. Setting TTL to 3, for example, will result in the message being relayed a maximum of two times. Setting it to 0 will result in it not being relayed at all, only travelling a single hop from the originating device directly to the destination device. A TTL value of 1 means that the message has already been relayed some number of times and should not be relayed again. Messages sent with TTL = 1, do not leave the device and therefore can only be used for local communication on the node via loopback.

For the most efficient use of the network and radio spectrum, an optional feature called Directed Forwarding can be used. Directed Forwarding uses relaying in an informed and more efficient way.

See 4.19 Message Relaying for more information on how relaying works.

4.18.2 Low Power Nodes and Friend Nodes

Some types of nodes have a limited power source and need to conserve energy as much as possible. Devices of this type may be predominantly concerned with sending messages but still have a need to occasionally receive messages.

Consider a temperature sensor which is powered by a small coin cell battery. It sends a temperature reading once per minute whenever the temperate is above or below configured upper and lower thresholds. If the temperature stays within those thresholds, it sends no messages. These behaviors are easily implemented with no particular issues relating to power consumption arising.

However, the user is also able to send messages to the sensor, which change the temperature threshold state values. This is a relatively rare event, but the sensor must support it. The need to receive messages has implications for duty cycle and as such power consumption. A 100% receive (RX) duty cycle would ensure that the sensor did not miss any temperature threshold configuration messages but use a prohibitive amount of power. A low duty cycle would conserve energy but risk the sensor missing configuration messages.

The answer to this apparent conundrum is the Friend node and the concept of friendship.

Nodes like the temperature sensor in the example may be designated Low Power nodes (LPNs) and a feature flag in the sensor’s configuration data set to indicate this.

LPNs work in tandem with another node, one which is not power-constrained (e.g. it has a permanent AC power source). This device is termed a Friend node. The Friend stores messages addressed to the LPN and delivers them whenever the LPN polls the Friend node for waiting messages. The LPN may poll the Friend relatively infrequently so that it can balance its need to conserve power with the timeliness with which it needs to receive and process messages. When it does poll, all messages stored by the Friend are forwarded to the LPN, one after another, with a flag known as MD (More Data) indicating to the LPN whether there are further messages to be sent from the Friend node.

The relationship between the LPN and the Friend node is known as friendship. Friendship is key to allowing very power constrained nodes which need to receive messages, to function efficiently in a Bluetooth Mesh network.

4.18.3 Proxy Nodes

4.18.3.1 About Proxy Nodes

There are an enormous number of devices in the world that support Bluetooth LE including most smartphones and tablets. Typically, such devices do include the Bluetooth Mesh networking stack, but they do have the ability to connect to other devices and interact with them using procedures defined by GATT, the Generic Attribute Profile.

Proxy nodes implement a GATT service and several characteristics which other Bluetooth LE devices may use to send messages into and receive messages from a Bluetooth Mesh network. The Proxy node acts as the GATT server and the other device is the GATT client.

A protocol called the Proxy protocol is defined. GATT devices read and write Proxy protocol PDUs from within GATT characteristics implemented by the Proxy node. The Proxy node transforms these PDUs to or from mesh network PDUs. With respect to the use of the Proxy protocol, the Proxy node is deemed the Proxy server and the other device the Proxy client.

Proxy client devices must first be provisioned, just like any other device that is a member of the network.

Proxy nodes allow Bluetooth LE devices that do not possess a full Bluetooth Mesh networking stack to interact with nodes in a mesh network. In practice this means that powerful devices that have a full operating system and high-resolution display can be equipped with applications that provide the user with a graphical user interface (GUI) via which to interact with devices such as lights in the network.

Figure 6 – Smartphone communicating via a mesh proxy node

4.18.3.2 Proxy Discovery

Proxy nodes operate in one of two modes, enabling them to be discovered and engaged with by a Proxy client such as a smartphone application in one of two ways.

4.18.3.2.1 Continuous Advertising Mode

In this mode, the Proxy node broadcasts advertising packets at intervals irrespective of whether a Proxy client device is present. The broadcast packets contain an advertising data item called Service Data which includes the UUID identifier of the GATT Mesh Proxy Service and other service data. The presence of the Mesh Proxy Service UUID identifies the advertising device as a Proxy node. A Proxy client can discover the Proxy node by scanning for advertising packets that contain the Mesh Proxy Service UUID, connect to the Proxy node and then exchange Proxy PDUs over the connection. The Proxy node relays PDUs to and from the mesh network using the advertising bearer.

The indiscriminate, more or less permanent advertising used in this approach is sub-optimal and makes wasteful use of the Bluetooth advertising channels. The advertising bearer, used by the greater majority of nodes in the mesh network is dependent on these channels being available.

4.18.3.2.2 On-Demand Private Proxy Mode

A second, more efficient approach that involves a technique called solicitation is defined. It is called the On-Demand Private GATT Proxy, support for which is optional.

In this approach, advertising does not start until the Proxy server has become aware that a Proxy client is present and in need of its services.

A Proxy client that supports the On-Demand Proxy feature indicates that it needs the services of a Proxy node by advertising. The advertising packets that it transmits contain a PDU called a Solicitation PDU. This contains the UUID of the Mesh Proxy Solicitation Service and other information.

The Proxy server node carries out a form of scanning called passive scanning. Passive scanning does not involve the transmission of any packets and therefore has no impact on radio channels. On receiving and authenticating a Solicitation PDU from a Proxy client, the Proxy node starts advertising so that the Proxy client can connect to it and start the exchange of Proxy PDUs over the established connection in the standard way.

The On-Demand Private GATT Proxy makes efficient use of advertising channels by only advertising when a Proxy client has indicated that it should do so. It also offers improved privacy due to its use of Mesh private beacons. See 7.7 Privacy.

4.19 Message Relaying

4.19.1 Multi-hop Message Delivery

A Bluetooth Mesh network may span a large area and nodes in one part of a building will often be out of direct radio range of other nodes. To enable message-based communication between all nodes, regardless of how far apart an originating node is from the destination node(s) to which its messages are sent, Bluetooth Mesh uses a system which involves messages being retransmitted by certain nodes so that they hop from node to node across the network until they arrive at their destination.

In general terms, the process of retransmitting messages is called relaying, and this is the function of the Relay node.

Relaying can function in one of two different ways. The first approach is called managed flooding and the second, directed forwarding.

4.19.2 Managed Flooding

A Relay node uses the simpler managed flooding approach by default. Managed flooding involves messages received by the Relay being retransmitted.

Certain conditions will cause a Relay to not retransmit however, and this helps improve radio spectrum efficiency. Examples include:

• PDUs contain a field called Time to Live (TTL). The sender sets this field to an integer value which limits the number of times a message will be relayed. This stops messages from being relayed right across the network for no good reason.
• Details of messages received are cached by relays. The cache is checked before relaying. If the message is found in the cache it is assumed that the message has been received before and retransmitted in which case the new copy of the message is discarded.

4.19.3 Directed Forwarding

The directed forwarding approach is more sophisticated than managed flooding and makes more efficient use of radio spectrum. When using directed forwarding:

• The Relay node only retransmits a message if it knows it is a member of a sequence of nodes via which the message can travel to reach its destination. If the destination cannot be reached via this node, the message is discarded. Radio transmissions are thus reduced, and spectrum use is more efficient, leaving more capacity for messaging in the network and reducing the probability of collisions occurring.
• The sequences of nodes along which delivery to a destination is possible is either created manually during configuration or is automatically created and maintained by various system procedures.

Section 6.4 Relaying explores directed forwarding further.

For a deeper explanation of directed forwarding, see Bluetooth Mesh Directed Forwarding.

4.20 Device Firmware Updates

4.20.1 About Firmware

The low-level software which implements a device’s functionality and controls the hardware is usually called firmware. Bluetooth Mesh devices run firmware which implements the Bluetooth Mesh protocol and the models that the device supports.

Typically, firmware needs to be updated during its lifetime. Reasons for updating a Bluetooth Mesh device’s firmware include:

• to upgrade the version of the Bluetooth Mesh protocol that the device supports
• to add new functionality through support for further mesh models
• to fix bugs

4.20.2 Practical Issues

Devices in a Bluetooth Mesh network are often installed in locations that are physically difficult to reach (e.g. mounted on ceilings). From a practical point of view, any firmware update procedure that relies on physical, wired connectivity is likely to be problematic. Even a wireless update mechanism that relies on direct communication with the device to be updated is sub-optimal, especially in a large building.

Bluetooth Mesh defines a set of procedures which allow the firmware on devices to be updated from across the network, allowing updates to any node to be initiated from any physical location.

This Device Firmware Update (DFU) feature is described next.

4.20.3 The DFU Capability

The Bluetooth Mesh DFU feature allows firmware update files (often known as binary images) to be wirelessly distributed across the network to sets of one or more target devices in a single operation. It is a convenient tool for keeping firmware up to date and works in a way which makes efficient use of human, network and radio resources.

4.20.3.1 DFU Models and Roles

The Bluetooth Mesh DFU feature involves three pairs of client and server models.

• The BLOB Transfer models provide a generalised mechanism for transferring Binary Large Objects (BLOBs) between nodes. A firmware update file is an example of a BLOB.
• The Firmware Distribution models support procedures which distribute firmware update files to the nodes that are to be updated. The firmware distribution procedures make use of the BLOB Transfer models.
• The Firmware Update models support procedures for applying updates to device firmware.

A number of DFU roles are defined:

Role	Description	Models
Target	A node which receives firmware updates. A Target is able to report the version of firmware it is running and the location from which updates can be obtained.	Firmware Update Server BLOB Transfer Server
Initiator	Usually runs on a device that both supports Bluetooth Mesh and has internet connectivity. Examples of such devices include smartphones and gateway devices. Periodically or on request, an Initiator checks manufacturers’ websites for new firmware releases. It then downloads update files and sends them to a Distributor node.	Firmware Distribution Client Firmware Update Client BLOB Transfer Client
Distributor	Receives firmware update files from an Initiator and sends them to Target nodes for installation. Acts as an intermediary for the Initiator which means the Initiator does not need to be in range of the mesh network for the full duration of the distribution and update procedures.	Firmware Distribution Server Firmware Update Client BLOB Transfer Client BLOB Transfer Server
Standalone Updater	A Stand-alone Updater fulfils the role of a combined Initiator and Distributor, acquiring firmware updates and sending them directly to Updating Nodes without the need for an intermediate Distributor.	Firmware Update Client BLOB Transfer Client

 

4.20.3.2 The Firmware Update Process[4]

4.20.3.2.1 Obtaining Firmware Updates

The Mesh DFU model specification defines the Firmware Check Over HTTPS procedure. This procedure is invoked by an Initiator (or Standalone Updater) and typically involves:

1. Receiving a list of Target nodes from the application layer
2. For each Target node on the list
   1. Retrieving information about the firmware currently installed such as the version number and the Uniform Resource Identifier (URI) of the location from which updates may be obtained.
   2. Sending a HTTP GET request to the URI and if a firmware update is available, downloading a firmware description file in the response.

A firmware description file is a JSON format file which provides information such as the number of files that a firmware update is partitioned into and the total size of the update in bytes.

The Firmware Retrieval over HTTPS procedure is then used to obtain the firmware update file(s) using the HTTPS protocol. Either the Initiator can do this, or it can instruct a Distributor to obtain the firmware updates.

Note that the specification also allows firmware updates to be checked for and retrieved using vendor-specific approaches.

4.20.3.2.2 Distributing Firmware Updates

The Initiator uses the Firmware Distribution Client model which is backed by the BLOB Transfer Client model to send firmware updates and target node details to a Distributor. The Distributor then uses the Firmware Update Client model and BLOB Transfer Client model to send updates to each of the Target nodes.

4.20.3.2.3 Firmware Installation

Targets use vendor-specific procedures to verify and install updates. Progress information is available to the Distributor.

4.20.3.2.4 DFU Security

There are security risks associated with acquiring firmware from remote sources and then installing it on nodes in the Bluetooth Mesh network. There needs to be a way of verifying that the remote source is trustworthy and that firmware update files have not been tampered with.

The DFU specification mandates the use of the secure HTTPS protocol for downloads from remote servers within the standard Firmware Check and Firmware Retrieval procedures. This ensure that downloads are encrypted and cannot be tampered with in-flight without detection. HTTPS also requires the remote server to have a digital certificate by which its identity can be authenticated.

The Firmware Check Over HTTPS and Firmware Retrieval Over HTTPS procedures address the primary security issues. The vendor-specific installation procedure used by a device offers other opportunities for further security checks.

5. System Architecture

5.1 Introduction

In this section we’ll take a closer look at the Bluetooth Mesh architecture, the layers of the mesh networking stack and the technical specifications which define the technology.

5.2 The Bluetooth Mesh Specifications

Bluetooth Mesh is defined by a collection of specifications.

• The Mesh Protocol specification defines the architecture, protocols, procedures, foundation models and other core concepts of Bluetooth Mesh technology.
• The Mesh Models specification defines additional models that provide functionality beyond that which is defined by the foundation models.
• The device firmware update and BLOB transfer capabilities each have dedicated specifications in which their respective models are defined.
• A collection of profile specifications define additional requirements and implementation details that further standardize particular classes of products, improving interoperability as a result.

5.3 The Bluetooth Mesh Stacks

Figure 7 shows the architecture of Bluetooth Mesh in terms of its layers and dependencies on parts of the Bluetooth Core Specification. There are two stacks. The mesh networking stack enables communication between nodes in a Bluetooth Mesh network. The mesh provisioning stack enables the provisioning of devices.

Figure 7 – The Bluetooth Mesh architecture

At Figure 7, there is a component labeled Bluetooth Core Specification (LE Physical Transport). This represents the set of core Bluetooth LE features that are leveraged by Bluetooth Mesh.

A Bluetooth LE system consists of a controller and a host. These are often physically separate components that are connected in some way (e.g. UART) and which communicate using a set of standard commands and events known as the Host Controller Interface (HCI). The layers of the mesh networking stack are all resident in the host component. The mesh networking stack is dependent on parts of the Bluetooth LE stack that run in the controller such as the link layer and the physical layer. See The Bluetooth Low Energy Primer for more information on these layers and the basic architecture of Bluetooth LE.

We’ll now review each layer of the mesh architecture, working our way up from the bottom layer.

5.4 Bearer Layer

Mesh messages require an underlying communications system for their transmission. The bearer layer defines how mesh PDUs will be handled by a given communications system. Two main bearers that are used for general messaging purposes are defined and these are called the advertising bearer and the GATT bearer.

The advertising bearer leverages Bluetooth LE advertising and scanning features to transmit and receive mesh PDUs.

The GATT bearer allows a device which does not support the advertising bearer to communicate indirectly with nodes of a mesh network using a protocol known as the Proxy protocol. The Proxy protocol is encapsulated within GATT operations involving a GATT service called the Mesh Proxy Service which includes two GATT characteristics named Mesh Proxy Data In and Mesh Proxy Data Out.

A Proxy node implements the Mesh Proxy Service and its characteristics. It supports both the GATT bearer and the advertising bearer, and this allows it to convert and relay messages over the two types of bearer.

The GATT bearer may also be supported by nodes that do not support the Proxy feature.

5.5 Network Layer

The network layer defines the various message address types and a network message format that allows transport layer PDUs to be handled by the bearer layer.

It can support multiple bearers, each of which may have multiple network interfaces, including the local interface which is used for communication between elements that are part of the same node.

The network layer determines which network interface(s) to output messages over. An input filter is applied to messages arriving from the bearer layer, to determine whether they should be delivered to the network layer for further processing. Output messages are subject to an output filter to control whether they are dropped or delivered to the bearer layer.

The Relay and Proxy features may be implemented by the network layer.

5.6 Lower Transport Layer

The lower transport layer takes PDUs from the upper transport Layer and sends them to the lower transport layer on a peer device. Where required, it performs segmentation and reassembly of PDUs. For longer packets, which will not fit into a single transport PDU, the lower transport layer will perform segmentation, splitting the PDU into multiple transport PDUs. The receiving lower transport layer on the other device, will reassemble the segments into a single upper transport layer PDU and pass this up the stack.

5.7 Upper Transport Layer

The upper transport layer is responsible for the encryption, decryption and authentication of application data passing to and from the access layer. It also has responsibility for transport control messages, which are internally generated and sent between the upper transport layers on different peer nodes. These include messages related to friendship, directed forwarding and heartbeats.

5.8 Access Layer

The access layer is responsible for defining how models make use of the upper transport layer. This includes:

• Defining the format of message data.
• Defining and controlling the encryption and decryption process which is performed in the upper transport layer.
• Verifying that data received from the upper transport layer is for the right network and model, before forwarding the data up the stack.

5.9 Foundation Model Layer

The foundation model layer is responsible for the implementation of those models concerned with the configuration and management of a mesh network.

5.10 Model Layer

The model layer is concerned with the implementation of models and as such, the implementation of behaviors, messages, states and state bindings as defined in one or more model specifications.

6. Messaging

This section explores aspects of how messaging in a Bluetooth Mesh network works and brings together some of the key concepts explained in section 4. Key Features and Concepts.

6.1 Message Publication and Delivery

A network which uses Wi-Fi is based around a central network node called an access point, and all network traffic passes through it. If the router is unavailable, the whole network becomes unavailable.

In contrast, Bluetooth Mesh delivers messages directly to nodes that are within radio range or via relay nodes when they are further away. When published by a node, messages are broadcast rather than being routed directly to a specific node. All nodes receive all messages from nodes that are in direct radio range. If configured to do so, a node will then use either managed flooding or directed forwarding and relay received messages.

6.2 Multipath Delivery

An important consequence of the use of broadcast communication and relaying is that messages can arrive at their destination via multiple paths through the network. This contributes to Bluetooth Mesh being a highly reliable network technology.

6.3 Traversing the Stack

Receiving a message starts with a packet being received by the link layer of the Bluetooth LE controller[5]. Its payload is then passed to the Bluetooth Mesh bearer layer in the Host and from there to the mesh network layer.

The network layer applies various checks to decide whether to pass the message higher up the stack or to discard it.

In addition, PDUs have a Network ID field, which provides a fast way to determine which NetKey the message was encrypted with. If the Network ID is not recognized by the network layer on the receiving node, this indicates it does not possess the corresponding NetKey and is not a member of that subnet and therefore the PDU is discarded. There is also a network message integrity check (MIC) field. If the MIC check fails, then the message is discarded.

Messages are received by all nodes in range of the originator, but many will be quickly discarded when it becomes apparent they are not relevant to this node due to the network or subnet(s) it belongs to.

The same principle is applied higher up the stack in the upper transport layer. Here though, the check is against the AppKey associated with the message and identified by an application identifier (AID) field in the PDU. If the AID is unrecognized by this node, the PDU is discarded by the upper transport layer. If the transport message integrity check (TransMIC) fails, the message is discarded.

The upper transport layer passes messages to the access layer. From there, the model layer is used to invoke appropriate model functions based on the type of message received.

6.4 Relaying

The basic concept of relaying was introduced in section 4.19 Message Relaying. The directed forwarding method is more complex than the managed flooding method and is explained further in this section.

6.4.1 Directed Forwarding

6.4.1.1 Comparison with Managed Flooding

When managed flooding is used, Relay nodes retransmit all messages that they receive apart from in limited circumstances such as when the maximum number of hops indicated by the TTL field has already been taken. This is a simple and effective mechanism but is not the most efficient with respect to use of radio spectrum. Messages are propagated across the network in all directions, irrespective of whether any of the destination nodes are located in a given direction, relative to the Relay node.

Consider Figure 8 and Figure 9 which depict a large conference hall that is equipped with a Bluetooth Mesh network and includes a switch that controls the lighting over the stage. Messages need to be relayed by a single hop to reach all of them.

There are two Relay nodes in range of the switch. When the stage lighting switch is used, a message is transmitted, received by both relays and retransmitted, so that the message travels through the network both towards the target lights and away from them. 

Figure 8 – The light switch broadcasts an on/off message

Figure 9 – Two relays receive the message and both retransmit

This is sub-optimal. The Relay node furthest from the stage can make no contribution in delivering the on/off control messages from the switch to the stage lighting.

Directed forwarding differs from managed flooding in that relaying only takes place if the Relay node’s state data indicates that it lies on a path to one or more of the nodes addressed by the message. A Relay node that can use directed forwarding is called a Directed Relay node.

Figure 10 shows the effect of directed forwarding when used by the conference hall light switch and Relay nodes. Propagation of the on/off message from the light switch takes place towards the lights on the stage only and not into other parts of the network.

Figure 10 – The effect of directed forwarding

The concept of path is a formally defined aspect of directed forwarding.

6.4.1.2 Paths and Lanes

Directed forwarding involves the definition or discovery of sequences of Directed Relay nodes that are capable of delivering a message from a given source address to a particular destination address. Such node sequences are called paths.

In a path definition, the source address is always a unicast address, but the destination address may be of any type, including a group address. When a destination address corresponds to more than one node, it is more accurate to describe a directed forwarding path as a set of sequences of Directed Relay nodes.

A state data item called the Forwarding Table on a Directed Relay node indicates the paths that the relay can service. It consists of a list of pairs of source and destination addresses. On receiving a message, the Directed Relay consults the Forwarding Table and if it contains an entry with the source and destination address of the message, the message is relayed. Otherwise, the message is discarded.

There may exist more than one sequence of Directed Relay nodes that a message could be relayed by to reach a particular target node. This can be taken advantage of by creating multi-lane paths. A lane is a sequence of Directed Relay nodes and in that respect is the same as a path. When multiple alternate sequences of nodes are available for the delivery of a message from one source node to one destination node though, the term lane is used for the sequence and path for the collection of all lanes. Multi-lane paths have the benefit of offering greater redundancy so that messages are more likely to be delivered even when one of the sequences of Directed Relay nodes has a break in it due to one of those nodes currently being unavailable for some reason. 

6.4.1.3 Path Creation and Maintenance

Paths are either created manually using a Configuration Manager tool or are discovered and established dynamically through the execution of a series of automated procedures.

When automatic path creation is in use, the process executes over a number of stages. For those source and destination address pairs for which a path is required, special messages are used to explore the network with the goal of finding Relay node sequences that can deliver a message from the source to the destination. During this process a measurement called the path metric is established so that a comparison can be made between alternative sequences and the best be selected for use. The path metric is simply a count of the number of hops it takes to get from the source node to the destination via a given sequence of relays. A path that consists of fewer hops is better than one which requires more.

When the shortest sequence of nodes that can act as a path for a source/destination address pair has been discovered, the nodes in that sequence are updated using control messages so that their Forwarding Table indicates that they are part of that path.

7. Security

7.1 Security in Bluetooth Mesh is Mandatory

Bluetooth LE allows the profile designer to exploit a range of different security mechanisms.  This includes the various ways in which the pairing of two devices can work, the use of private device addresses in advertising packets and the security rules attached to GATT characteristics. But security is totally optional, and it is permissible to have a device which is completely open, with no security protections or constraints in place. In those cases where a Bluetooth SIG specification does not apply (for example when dealing with a custom profile or service), the device designer or manufacturer is responsible for analyzing threats and determining the security requirements and for deciding how to use the security features of Bluetooth LE to meet those requirements.

In contrast, in Bluetooth Mesh security is mandatory. The network, devices and individual applications are all secure and security cannot be switched off or reduced.

7.2 Security Fundamentals

The following fundamental security statements apply to all Bluetooth Mesh networks:

1. All mesh messages are encrypted and authenticated.
2. Network security, application security and device security are addressed independently. See 7.3 Separation of Concerns and Security Keys below.
3. Security keys can be changed during the life of the mesh network using the Key Refresh procedure and Node Provisioning Protocol Interface procedures.
4. Message obfuscation provides a privacy mechanism that makes it difficult to track nodes.
5. Mesh Private beacons ensure that no static information which could be used for device tracking is broadcast by a node.
6. Mesh security protects the network against replay attacks.
7. The provisioning process by which devices are added to the mesh network to become nodes is a secure process and includes support for X.509 digital certificates.
8. Nodes can be removed from the network securely, in a way which prevents trashcan attack[6].

7.3 Separation of Concerns and Security Keys

At the heart of Bluetooth Mesh security are three types of security key. Between them, these keys provide security to different aspects of the network. The use of different types of security key in the design of Bluetooth Mesh security is an example of an important principle known as separation of concerns.

To understand this and appreciate its significance, consider a mesh light which can act as a Relay node. In its capacity as a Relay node, it may find itself handling messages relating to the building’s Bluetooth Mesh door and window security system. A light has no justifiable reason to be able to access and process the data in such messages but does need to relay them to other nodes.

To deal with this potential conflict of interest, Bluetooth Mesh uses different security keys for providing security at the network layer from those used to secure data relating to specific applications such as lighting, physical security, heating and so on.

All nodes in a mesh network possess at least one network key (NetKey). It is possession of this shared key which makes a node a member of the network. A network encryption key and a privacy key are derived directly from the NetKey.

Being in possession of the NetKey allows a node to decrypt and authenticate up to the network layer so that network functions such as relaying, can be carried out. It does not allow application data to be decrypted.

Application data for a specific application can only be decrypted by nodes which possess the right application key (AppKey). Across the nodes in a mesh network, there may be many distinct AppKeys, but typically, each AppKey will only be possessed by a small subset of the nodes, namely those of a type which can participate in a given application. For example, lights and light switches would possess the lighting application’s AppKey but not the AppKey for the heating system, which would only be possessed by thermostats, valves on radiators and so on.

AppKeys are used by the upper transport layer to decrypt and authenticate messages before passing them up to the access layer.

AppKeys are associated with only one NetKey. This association is termed key binding and means that specific applications, as defined by possession of a given AppKey, can only work on one specific network, whereas a network can host multiple, independently secure applications.

The final key type is the device key (DevKey). This is a special type of application key. Each node has a unique DevKey known to the Provisioner device and no other. The DevKey is used to secure communication during the configuration process.

Figure 11 – Security keys in Bluetooth Mesh

7.4 Subnets and Subnet Bridging

The network may be subdivided into subnets. Each subnet has its own NetKey, which is possessed only by those nodes which are members of that subnet. This might be used for example, to isolate and secure distinct physical areas such as each guest room in a hotel. In this case, this would ensure that devices like the lights in a particular guest room can only be controlled by other devices that are in the same room and on the same subnet.

There are cases where communication between devices in different subnets is required. It might be the case that hotel management staff need to be able to centrally control all devices in all hotel rooms but at the same time, it remains imperative that a device in one guest’s room cannot be used to control a device in another guest’s room, and that transmissions from a device in one room cannot be intercepted and decrypted by a device in another. Bluetooth Mesh has a feature called subnet bridging that makes this possible.

The subnet bridging feature allows network planners to use subnets for area isolation but to also selectively allow communication between specific devices in different, adjacent subnets without compromising on security. This involves setting up one or more nodes to act as subnet bridges. These are nodes that possess the NetKey of each of the subnets to be bridged as well as a model called the Bridge Configuration Server model and its various states.

Subnet bridging is enabled via a state called Subnet Bridge. A further state called the Bridging Table contains entries which enable communication between a specific source address and a particular destination address. In addition, a Bridging Table entry indicates the NetKey for the first subnet and the NetKey of the second subnet.

It is the information in the Bridging Table state that allows messages from one subnet, encrypted with the first NetKey, to be decrypted by the node acting as subnet bridge and re-encrypted with the NetKey for the second subnet and for this action to be restricted to messages with the specified source and destination address.

7.5 Node Removal, Key Refresh and Trashcan Attacks

Nodes contain various mesh security keys. Should a node become faulty and need to be disposed of or if the owner decides to sell the node to another owner, it is important that the device and the keys it contains cannot be used to mount an attack on the network that the node was taken from.

A procedure for removing a node from a network is defined. The Provisioner application is used to add the node to a reject list and then a process called the Key Refresh procedure is initiated.

The Key Refresh procedure results in all nodes in the network, except for those which are members of the reject list, from being issued with new network keys, application keys and all related, derived data. In other words, the entire set of security keys which form the basis for network and application security are replaced.

Consequently, the node that was removed from the network, and which contains an old NetKey and an old set of AppKeys, is no longer a member of the network and poses no threat.

7.6 Replay Attacks

A replay attack is a technique whereby an eavesdropper intercepts and captures one or more messages and retransmits them later, with the goal of tricking the recipient into carrying out something which the attacking device is not authorized to do.

7.6.1 IV Index and Sequence Numbers

Bluetooth Mesh has protection against replay attacks. The basis for this protection is the use of two data items called the Sequence Number (SEQ) and IV Index. Elements increment the SEQ value every time they publish a message. A node receiving a message from an element which contains a SEQ value less than or equal to the value that was in the last valid message will discard it, since it is likely that it relates to a replay attack.

IV Index is a network shared resource that is checked in conjunction with the SEQ and source address values when messages are received. The combined values of the SEQ, IV Index and SRC (source address) fields are always unique for every mesh message that an element sends.

The network uses one IV Index value at a time except for when the IV Update procedure is in progress during which time two different values are in use until the procedure has completed and a new value has been assigned to the whole network.

7.6.2 The IV Update procedure

Sequence numbers are 24 bits in length. Through repeated incrementing of the SEQ field, a node may eventually exhaust its supply of sequence number values. To avoid this happening, a network procedure called IV Update can be initiated by a node that finds itself in this situation. This causes a new IV Index value to be calculated by incrementing the old value, assigned it across the whole network and for elements in affected nodes to reset their sequence number to zero.

For security reasons, only nodes that are members of the primary subnet are permitted to initiate the IV Update procedure. Guest devices that are members of non-primary subnets only cannot initiate IV Update. This affords protection to this important shared network resource.

7.7 Privacy

A privacy key, derived from the NetKey is used to obfuscate network PDU header values, such as the source address. Obfuscation ensures that casual, passive eavesdropping cannot be used to track devices and the people that use them. It also makes attacks based upon traffic analysis difficult.

A number of the Bluetooth Mesh procedures including the Key Refresh procedure and the IV Update procedure use beaconing to broadcast data to other devices in the network to indicate their presence and state. Beaconing is a technique which leverages Bluetooth advertising.

The transmission of static, unchanging information can constitute a security risk since it may become possible to track the device as it moves around the network and deduce information about the device, the user of the device and perhaps the network as a whole. To address this risk, Bluetooth Mesh includes a capability called Mesh Private beacons.

Mesh Private beacon transmissions do not contain static information. Their use improves network privacy by eliminating the possibility of devices being tracked using the data contained within beacon messages.

8. Scalability

Bluetooth Mesh networking is proven to scale. Out in the real world there are commercial deployments with as many as six thousand nodes.

The theoretical maximum number of addressable elements in a Bluetooth Mesh network is 32,767. This is due to the fact that a unicast address used to identify an element is 15 bits in length. That said, considering scalability in terms of the number of nodes a network can accommodate is not a particularly useful way of viewing the topic. It’s more appropriate to think in terms of the amount of work that the network can support or to put it another way, the volume and rate of network operations that it can accommodate.

Scalability and other performance measures are issues that the network planner (see 10.1 The Planner) takes into account when designing the network. The placement and configuration of nodes can have a significant effect on how well the network performs and how easily it will scale to the largest required number of nodes in the future.

Scalability in wireless networks tends to be limited by a number of factors, including how efficiently the shared radio spectrum is used. Collisions occur when two devices transmit on the same radio channel at the same time, and this can become a limiting factor in the scalability of a network. Avoiding or reducing the probability of message loss due to collisions is, therefore, a key strategy in the design of Bluetooth Mesh and the design work undertaken by the network planner.

Not all networks are the same. A small network with relatively few nodes may be harder to scale than a larger network if the nodes in the small network are placed physically close together and the nodes transmit messages frequently. In other words, concepts such as network density and node verbosity are important. It’s not just about the absolute number of nodes that the network contains.

Bluetooth Mesh was designed with scalability in mind from the outset. PDUs are small (at most 29 octets in length) and this reduces the airtime used by transmissions and therefore, the probability of collisions taking place.

Typically, copies of messages are transmitted on three different channels. This increases network capacity and lessens the probability of message loss due to collisions.

The relaying process both with and without the sophistication of the directed forwarding feature establishes multiple paths for messages, increasing the probability of delivery, especially in busy networks.

Unacknowledged messages reduce network traffic, especially in multicast scenarios where one device seeks to control a group of other devices in a single operation, a very typical situation in a Bluetooth Mesh network.

A decentralized design philosophy is fundamental to important aspects of how Bluetooth Mesh works. This supports higher levels of scalability and differentiates it from other comparable technologies too. For example, sensors communicate directly with lights without the need for intermediate lighting controllers.

The Bluetooth SIG website contains an article which provides a more thorough exploration of the subject of scalability in Bluetooth Mesh networks.

9. Bluetooth Networked Lighting Control (NLC)

One of the primary applications for which Bluetooth Mesh was designed is for the control of networked lighting devices in large buildings.

Lights (sometimes known more formally as luminaires) can be complex, with multiple independently controllable lamps, support for brightness and color control and the ability to be controlled both manually by human-operated switches or by environmental measurements delivered by remote, wireless sensors.

The Bluetooth Mesh model specifications define standardized functional blocks which a device such as a light implements to gain certain capabilities in the network such as the ability to be switched on or off. The modular nature of models supports the creation of innovative, multi-function products. Individual models are often sophisticated, with numerous parameters available to govern their state and behavior. This further adds to the flexibility and versatility of Bluetooth Mesh as a technology for networked lighting control.

Various important aspects of Bluetooth Mesh are optional. This includes the list of bearers supported, the ways in which a device can be provisioned, the node features (i.e. Proxy, Relay, LPN and Friend) that are supported and so on. There are often dependencies between different parts of the Bluetooth Mesh specifications.

The flexible nature of Bluetooth Mesh technology is of considerable benefit. But this must be balanced against the goal of achieving interoperability between products from different manufacturers through standardization. The more configurable and variable a technology is, the more difficult it can sometimes become to safeguard interoperability. Due to this, a series of Bluetooth Mesh NLC device profile specifications define standard configurations and other application layer requirements and recommendations for devices of various types. Compliance with the relevant profiles will result in the product being interoperable with other products that implement the same profile.

NLC profile specifications for the following product types have been defined.

• Ambient Light Sensor NLC profile
• Basic Lightness Controller NLC profile
• Basic Scene Selector NLC profile
• Dimming Control NLC profile
• Energy Monitor NLC profile
• Occupancy Sensor NLC profile

In defining all layers of a device from the physical layer all the way up to the application layer, Bluetooth Mesh is the first full-stack standard for wireless lighting control.

10. Bluetooth Mesh Stakeholders

An understanding of the main stakeholders and their roles helps build an appreciation of how Bluetooth Mesh networks are planned, created, maintained and managed. A number of standard roles are identified and explained in this section.

10.1 The Planner

The planner has a broad set of responsibilities, all concerned with defining the network to be created. It is useful to consider these responsibilities as falling into three sub-categories:

• Physical planning
• Functional planning
• Network planning

The same person might be responsible for all sub-categories, or they may be distributed amongst specialists.

Physical planning concerns defining the physical placement of devices in a building. Architects, interior designers or industrial designers are commonly concerned with physical planning.

Functional planning concerns defining the functional characteristics of devices and their functional relationships with other devices in the network. Functional planning may influence physical planning.

Network planning is concerned with determining the required configuration of devices such that the required functionality and reliability will be achieved. It is this role that will determine which devices are configured to act as friend nodes, low power nodes, relay nodes or proxy nodes for example. The network planner influences the physical planning.

10.2 The Installer

The installer physically installs devices in a building. This will typically involve drilling holes, climbing ladders, using a screwdriver and connecting electrical power.

10.3 The Commissioner

After devices have been physically installed by the installer in accordance with the design created by the planner, this role will make devices part of the new Bluetooth Mesh network by provisioning them. After provisioning, the commissioner will configure each new node so that it has the functionality and configuration specified by the functional and network planning work. Typically, provisioning and configuration are carried out at the same time and using the same tool, which is often a smartphone application.

10.4 The Building Maintenance Role

The building maintenance role is another broad role, involving aspects of the planner, installer and commissioner roles but with responsibility for an existing network in a building rather than the creation of a new one. Examples of tasks the building maintenance role will undertake include replacing devices (requiring installation, provisioning and configuration), diagnosing and solving problems, and securely disposing of devices that are no longer needed.

10.5 The Building Owner

The building owner owns the building and is concerned that the network functions as required, is secure and delivers the expected return on investment (ROI).

11. Conclusion

This paper should have provided the reader with an introduction to Bluetooth Mesh, its key capabilities, concepts and terminology. It’s Bluetooth but not as we know it. It’s a Bluetooth technology that supports a new way for devices to communicate using a new topology.

Most of all, it’s Bluetooth that makes this most pervasive of low power wireless technologies, a perfect fit for a whole new collection of use cases and industry sectors.

12. Additional Resources

This section lists other resources which support learning about Bluetooth LE from various perspectives.

Resource	Description	Location
Bluetooth Mesh Protocol Specification	This specification defines the Bluetooth Mesh architecture and its protocols and procedures.	https://www.bluetooth.com/specifications/specs/mesh-protocol/
Mesh Models	Defines the full set of standard Bluetooth Mesh models.	https://www.bluetooth.com/specifications/specs/mesh-model-1-1/
Bluetooth Core Specification	Defines all layers of the Bluetooth stack and associated protocols and procedures. Covers both Bluetooth LE and Bluetooth BR/EDR.	https://www.bluetooth.com/specifications/specs/
Profile and service specifications	A service specification defines a single GATT service along with the characteristics and descriptors that it contains. The behaviors to be exhibited by the GATT server device hosting the service in response to various conditions and state data values are defined in the service specification.   Profile specifications define the roles that related devices assume and in particular, define the behavior of the client device and the data on the connected server that it should work with.	https://www.bluetooth.com/specifications/specs/
The Bluetooth Low Energy Primer	The Bluetooth Low Energy (LE) Primer explains every layer of the Bluetooth LE stack, starting with the physical layer at the bottom and ending with the generic access profile at the top. Topics related to the layered architecture of the stack, such as security, are covered too. This is the place to start if you’re new to Bluetooth LE and want to learn about the technology from a technical perspective.	https://www.bluetooth.com/bluetooth-resources/the-bluetooth-low-energy-primer/
Bluetooth Mesh 1.1 – Feature Summary	Version 1.1 of the Bluetooth Mesh protocol specification introduced several substantial new features. This paper summarizes the changes at a high level and provides links to papers that provide greater detail on each of the new features.	https://www.bluetooth.com/mesh-feature-enhancements-summary/
Study Guide – An Introduction to Bluetooth Low Energy Development	An educational resource for developers wishing to learn about software development for connection-oriented scenarios involving smartphones and peripheral devices. Includes a series of hands-on projects with solutions.	https://www.bluetooth.com/bluetooth-resources/bluetooth-le-developer-starter-kit/
Study Guide – An Introduction to Bluetooth Mesh Software Development	An educational resource for developers wishing to learn about Bluetooth Mesh and about the implementation of mesh models in microcontrollers. Includes a series of hands-on projects with solutions.	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-developer-study-guide/
Study Guide – An Introduction to the Bluetooth Mesh Proxy Function	An educational resource for developers wishing to learn how to create GUI applications for devices such as smartphones which allow interaction with nodes in a Bluetooth Mesh network. Includes a series of hands-on projects with solutions.	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-proxy-kit/
Paper – Bluetooth Mesh Networking – An Introduction for Developers	An educational resource for anyone interested in learning about the key concepts and capabilities of Bluetooth Mesh.	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-networking-an-introduction-for-developers/
Paper – Bluetooth Mesh Models – A Technical Overview	An educational resource for anyone interested in better understanding the standard models available for use in Bluetooth Mesh products.	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-models/
Study Guide – Understanding  Bluetooth LE Security	An educational resource which explains and illustrates all aspects of security in Bluetooth LE (excluding Bluetooth Mesh). Suitable for both complete beginners to the subject of security and those with prior experience. Includes a series of hands-on projects with solutions.	https://www.bluetooth.com/bluetooth-resources/le-security-study-guide/
Paper – Bluetooth Security and Privacy Best Practices Guide	A guide which is intended to help implementers better understand why certain available security and privacy choices are better or worse than others for specific applications, and what risks and pitfalls remain in the specifications.	https://www.bluetooth.com/bluetooth-resources/bluetooth-security-and-privacy-best-practices-guide/
Article – Scalability in Bluetooth Mesh networks	A blog post which examines the question of scalability, offers a definition and explores the factors that govern the issue in larger networks.	https://www.bluetooth.com/blog/mesh-in-large-scale-networks/

[1] When discussing radio transmission rates it is more common to use symbols per second rather than bits. There is a 1:1 correspondence between digital bits and analogue symbols in Bluetooth, however.

[2] The Bluetooth specifications are introduced in section 5. System Architecture.

[3] The Bluetooth LE Primer is recommended reading as an introduction to LE in general

[4] The Standalone Updater role can be substituted for references to Initiator or Distributor in this section.

[5] See 6.3 The Bluetooth Mesh Stacks

[6] A trashcan attack involves the recovery of a discarded device and the recovery and malicious use of the security keys it contains