Bluetooth technology is focused on short-range wireless connectivity. Most of us know the Bluetooth standard as the way we connect a phone to our car or a headset for hands-free operation. But Bluetooth is much more than that. Originally designed as a replacement for wired serial connectivity such as RS-232C, Bluetooth now supports almost three dozen different profiles that include hands-free devices, human interface devices, phone book profile, and many more.

In 2010, a new version of Bluetooth (Bluetooth 4.0) was introduced, known as Bluetooth Low-Energy (BLE) or Bluetooth Smart. This variant is targeted at battery powered devices. Rather than using the typical device pairing found in what is now known as “classic” Bluetooth, BLE is more targeted at use as connectivity for the Internet of Things. Its potential use would be as a broadcast-type sensor (e.g., temperature, humidity, etc.) to devices that do not require pairing.

The network connection style used in classic Bluetooth is a traditional point-to-point connection that looks like the hub-and-spoke model known as a star topology. The central device, for example a smartphone, can be paired with a potentially unlimited number of devices, although typically only seven can be active at any point in time. Devices can only talk to the central controller and not directly to each other. Therefore, the hub must relay message traffic between devices if that is needed for the application.

BLE added a point-to-multipoint/ broadcast model that is useful for a short-range navigation beacon mode such as used in finding a particular store in a shopping center. With broadcast mode, it is possible to send one message to a large number of receivers simultaneously. An example would be to use a smartphone to turn on a set of Bluetooth-enabled lights and set their collective color and brightness without needing to address each light bulb individually.

Additional enhancements to the Bluetooth specification were released in 2016 with the introduction of Bluetooth 5. This brought additional speed and distance. Concurrent with the development of Bluetooth 5 was the development of a new connectivity model for BLE known as the Mesh Profile. This is a many-to-many style of communication with provisions for message relay from one device to another to create a flexible mesh topology with multiple potential paths between nodes to ensure message delivery.

Figure 1. Bluetooth mesh protocol differences. (Image courtesy of Nordic Semiconductor)

The Mesh Profile was released in mid-2017 and roughly corresponded to the availability of new Bluetooth 5 devices. Therefore, it was easy to assume that Bluetooth Mesh was an exclusive feature of Bluetooth 5. Fortunately, that is not the case. The mesh profile will work in conjunction with Bluetooth 4.2 compatible devices as well as Bluetooth 5 devices. At the time of this writing, the number of devices that support the mesh profile is still somewhat limited, but the number is growing steadily. Figure 1 illustrates how the Bluetooth Mesh model fits into the standard BLE protocol stack. The dark blue portion is standard BLE, where the light blue portions are the Bluetooth Mesh-specific extensions.

Mesh Model Specifics

The Bluetooth mesh profile is tailor-made for smart lighting. There are a number of standard generic models including a Generic OnOff Server (e.g., light on or off) and Generic Level Server (e.g., light brightness or light hue) that specifically target smart lighting. Several other predefined generic models can be combined to create more specialized solutions.

A node is a device that is provisioned to be part of a given network segment. This means that the device has had network-specific encryption keys loaded onto it so it can exchange messages with its peers. There are several different sets of encryption keys possible for each device.

A given device may have one or more elements associated with it. Elements can be thought of as features of the device. Each device has at least one element (the primary element) and may have many secondary elements. For example, a light bulb has a primary element that indicates if it is on or off. Bulbs with a dimmer function would have a secondary element that could represent the brightness. If the bulb supports different colors, then there may be three additional elements that represent the red, green, and blue values of the LED sources in the bulb.

The maximum number of nodes in any given Bluetooth mesh network is 32,767, with up to 4,096 subnets and 65,535 scenes. The subnets allow for segregation of the network into logical functions such as 5th floor vs. 4th floor. Scenes represent a collection of settings such as all of the lights being at the same brightness. One brightness scene might be for when the sun is shining through the windows, and another for a cloudy day.

Owing to the legacy of BLE operation, very low-power, battery-operated devices can be operated at a low duty cycle to preserve battery life. In this case, the device will spend a considerable amount of time in sleep state. In order to facilitate command and control of these types of nodes, there is a “friend” feature that is possible in designated devices. This implements a store-and-forward feature to buffer messages to the low-power node for delivery when the low-power node checks into the network again. So, the low-power device is essentially a “push” device that initiates message transfer and then receives any outstanding message traffic from the friend node at that time.

Figure 2. Mesh network device types. (Image courtesy of Ericsson)

There is also a “proxy” mode that exists to support provisioning of a network via an application on a smartphone or tablet. Many existing mobile devices do not yet support the mesh model and would therefore be unable to communicate with a mesh network in its normal operating mode. However, using one of the mesh nodes as a BLE <-> Mesh proxy, enables the application to talk to the network by relaying messages via the proxy node. This plays an important role in provisioning devices and in sending network control messages. The different nodes are depicted in Figure 2.

Unlike traditional IP-based networks, Bluetooth Mesh uses a managed flood routing model for forwarding messages from one node to another. In this model, messages are broadcast to each node in the vicinity and a time-to-live (TTL) is used to address the potential of a routing loop. By decrementing the TTL as the message transits each node, if the TTL should reach zero, the message will be dropped at that node. The maximum TTL supported in Bluetooth Mesh is 126.

The control model used by the mesh is a client/server architecture with the following types of elements: (1) a server model that represents one or more states that may span one or more elements inside the device; (2) a client model that defines a set of messages used by the client to get, set, or request status for the various states of a server; and (3) a control model that adds control logic for interactions between the client and server models.

Bluetooth mesh communicates via messages. These messages can support up to a twenty-nine-byte payload. Based on the payload size, we can see that most of the payload is likely oriented to transferring states of the elements. This is supported through a publish/subscribe paradigm, where the device is the server and the client is the actor that is either getting, setting, or requesting status from the elements in the servers. However, unlike traditional publish/subscribe models, there is no message broker in the system because of the managed flooding message routing approach. All servers will eventually see the message and the client will get the responses from all servers in the network segment. Using the subnet mechanism allows users to minimize unwanted interruptions from unrelated systems by segmenting traffic.

Provisioning Devices and Security

Probably the most involved process in Bluetooth mesh is the provisioning of new devices. Provisioning is the process of enabling a device to join the network by adding security keys, setting subnets, etc. Provisioning can be performed by another node on the network or via a proxy such as a mobile device running a provisioning application.

The overall flow of the provisioning process is: (1) beaconing (periodic broadcast), (2) invitation, (3) exchange of public keys, (4) authentication, and finally (5) distribution of provisioning data. The new device will send out a beacon looking for an invitation to join a network. Once it receives the invitation, the device will send a capabilities protocol data unit (PDU) that informs the provisioner of the number of elements on the device, the set of security algorithms the device supports, the availability of its public key using out-of-band (OOB) technology such as a QR or bar code, the ability for this device to output a value to the user, and the ability of the device to allow input from the user. With this information, the provisioner can determine how to exchange security keys with the device.

In Bluetooth mesh, security is mandatory. All messages are encrypted and authenticated. If the device supports it, it will use Elliptic Curve Diffie-Hellman (ECDH) to establish a shared secret with the provisioner for further key exchange. Otherwise, the initial public key can be established via an OOB mechanism such as using the provisioning device's ability to scan a bar code from the unprovisioned device's packaging. Once the initial shared secret is established, all subsequent traffic will be encrypted via the AES-128 symmetric cipher.

Authentication is handled via the secure exchange of random numbers known as “nonces.” Depending on the capabilities of the unprovisioned device, the nonce can be generated by the provisioning device and acknowledged on the unprovisioned device or vice versa or both. Confirmations are then exchanged to verify that the nonces are correct. Once the authentication is complete, the actual provisioning data can be sent to the new device and the device is now known as a network node. This provisioning data includes the overall network encryption key, the unique per-device key, some bookkeeping data, and a unicast address that will be the network address for the primary element on the new node. At this point, the node is provisioned and can start communicating on the network.

Even the best of devices will eventually fail and need to be replaced. When this happens, the node may be completely non-responsive, thereby preventing the removal of the network key. In order to prevent a potential “trash can” attack where an attacker somehow manages to extract the network key from the node, the node can be blacklisted. This will prevent it from being able to establish connections with other nodes on the network. Then, the provisioner can initiate a Key Refresh procedure where a new network key is generated and distributed throughout the network.

To further enhance cybersecurity, each PDU contains a sequence number and initialization vector (IV) index fields. Nodes will reject any message with a sequence number less than the last properly received good message sequence number. The IV index must also match that of the last good IV that was received. This precludes the typical replay attacks that can be used to reset node states.


The addition of mesh networks adds an important communication paradigm to BLE devices. With the use of managed flood routing, the network size and scope can easily be expanded as new features are required.

One of Bluetooth mesh's many strengths is its security focus. Since security is mandatory, all Bluetooth mesh devices support message encryption/decryption and the encryption keys are securely provisioned before the device can communicate on the network.

Finally, while the Bluetooth mesh model seems to be best suited for smart building applications, we are sure to see new use cases as the protocol matures and users get an opportunity to see how it performs. The increasing number of available protocol stack implementations will also help to expand Bluetooth mesh's use in the industry. So, while the jury is still out on how successful Bluetooth mesh will be, the future does look bright for this new technology.

This article was written by Mike Anderson, CTO and Chief Scientist for The PTR Group, Inc. (Ashburn, VA). For more information, visit here.