NewsEmbedded Provisioner for BLE Mesh Network

Embedded Provisioner for BLE Mesh Network

Category articles

Bluetooth Low Energy (BLE) is the wireless technology that is available on every smartphone currently. It offers a variety of advantages over other communication technologies such as low power consumption, security, and flexibility, and makes it an ideal option to connect with smart devices. The extension of one or even one several Bluetooth capabilities to many or many BLE mesh technologies is creating an exciting change to the IoT ecosystem. Smart devices that are connected to a BLE mesh networks can be controlled to build an intelligent home or smart office industry.

In order to make smart devices members of the mesh networks security credentials as well as configuration data must be made available to the devices. In general, a smart phone is used to secure transfer these details into the gadgets. A new approach is being developed to provide BLE Mesh networks without the need for a smartphone. The same BLE interface that is used to create these mesh devices is utilized for provisioning the nodes to lower the cost and eliminate the requirement for the use of a smart phone. This makes the mesh network easier to use by those who are not used to phones, like elderly or blind people.

BLE-Mesh can be described as an IoT (Internet of Things) application that connects to multiple BLE (Bluetooth low Energy) devices to Mesh networking. It lets Bluetooth enabled devices to become an efficient, integrated and range-extending Mesh network that enables authentic two-way communication. Multiple devices can be monitored and controlled within a secure network effectively through this technology.

Fig. 1. BLE Mesh Network

Provisioning is the procedure of authenticating and providing basic details of the BLE mesh network to devices. A device needs to be provided with the necessary information to become as a node. Once it has been provisioned, the node can send or receive messages within the BLE mesh network.

Fig. 2. Embedded Provisioner in BLE Mesh Network

Provisioner is a device that has the capability of integrating devices to mesh networks. It handles the allotment of addresses to ensure that there are there are no duplicate addresses allotted. Provisioner allows a device that is not provisioned to join a mesh network when it has been authenticatedand converting the device that is not provisioned to an mesh network. The device that is used to provision is usually an Android phone or another intelligent computing devices. Integrating the provisioning functionality into an embedded board made the entire system completely autonomous, and required only little involvement from users, and improved security at a lower costs.


Provisioning is the procedure of integrating the device in an existing network. It is an essential step in the creation of an Bluetooth Low Energy Mesh network.

When it comes to provisioning the provisioner secures distribution of an encrypted network key and unique address space to every device. Provisioning protocols use P-256’s Elliptic Curve and Diffie-Hellman Key Exchange to generate an encrypted temporary key that encrypts the network key as well as other data. This protects against a passive listening.

Provisioning employs a layered structure to provide Provisioning PDUs (Protocol Data Unit) through the Provisioning Protocol as shown in Figure. 3.

Fig. 3. Provisioning protocol stack

 A. Provisioning bearer

To enable a device to be provisioned a provisioning bearer has to establish a connection between a Provider and the device. Provisioner recognizes devices by its Device UUID, or any other additional information that is given. A provisioning bearer layer allows the transfer between provisioning PDUs (Protocol Data Unit) between the Provisioner and the unprovisioned device. Two bearers for provisioning are identified in the BLE Mesh standards:

* The PB-ADV bearer is that is used to provide an item over the advertising channels with Generic Provisioning PDUs. The mechanism for provisioning is based on a session. A session is created by this Link Establishment procedure.

* PB-GATT is a Provisioning bearer that is used to provision devices by with Proxy PDUs to store provisioning PDUs in the Mesh Provisioning Service. It makes use of data channels to transfer data between the two machines.

B.  Generic Provisioning Layer

Generic Provisioning layer is responsible for the transport the Generic Provisioning PDUs over an insecure connectionless provisioning bearer. This layer assures the reliability of packets that are part of the provisioning protocol that are based on specified Generic Provisioning PDUs. Generic Provisioning PDU format is comprised of an Generic Provisioning Control (GPC) field, followed by an adjustable length Generic Provisioning Payload.

C. Proxy Protocol

GATT bearer is used to allow devices that are not able to support the advertising bearer to take part in a mesh network similar to a mobile phones. The GATT bearer makes use of its Proxy protocol to send and also receive Proxy PDUs from two different devices using the GATT connection.

D.  Provisioning Protocol

Provisioning PDUs can be used to establish communication between the Provisioner and the unprovisioned device in the process of provisioning. The first octet in the Provisioning PDU is the Type field , which defines the structure for the parameter that are part of the Provisioning PDU as seen in Figure 4.

Fig. 4. Provisioning PDU format

Once the bearer is established for the provisioning, Provisioner starts provisioning procedure by sending Provisioning invite PDU to the device. Device acknowledges this by sending its approved ability to provision to.

Provisioner selects the capabilities of the device and then sends Provisioning Start PDU. Provisioner transmits Provisioning Public Key PDU in order to provide the public key that will be used in ECDH calculations.

Optionally, the device will send the Provisioning Input complete PDU once the user has completed the input procedure.

The device or the provider provides a Provisioning confirmation PDU the peer to verify the information exchanged to date including the authentication value as well as the random number that is not yet been exchanged. The device or the device will send a provisioning randomly PDU to allow peers to verify the confirmation. The Provisioner transmits the provisioning data PDU to send encrypted data for the provisioning device. The device then sends the complete provisioning PDU to confirm that it accepted and processed data for provisioning.

Various types of provisioning PDU types used in provisioning protocol are shown in Table 1.

  Provisioning PDU types
Type Name Description
1 0x00 Provisioning Invite Invites a device to join a mesh network
2 0x01 Provisioning Capabilities Indicates the capabilities of the device
3 0x02 Provisioning Start Indicates the provisioning method selected by the Provisioner based on the capabilities of the device
4 0x03 Provisioning Public Key Contains the Public Key of the device or the Provisioner
5 0x04 Provisioning Input Complete Indicates that the user has completed inputting a value
6 0x05 Provisioning Confirmation Contains the provisioning confirmation value of the device or the Provisioner
7 0x06 Provisioning Random Contains the provisioning random value of the device or the Provisioner
8 0x07 Provisioning Data Includes the assigned unicast address, a network key, NetKey Index, Flags and the IV Index
9 0x08 Provisioning Complete Indicates that provisioning is complete


Embedded provisioner is based on STMicroelectronics’s BLE Mesh solution called STSW-BNRG-Mesh. It has been developed to add devices in the mesh network, at which point they become nodes.

Provisioning is performed using a five-step process:

•             Beaconing

•             Invitation

•             Exchanging public keys

•             Authentication

•             Distribution of the provisioning data

as shown in Fig 5.

Fig. 5. Embedded Provisioning Procedure

A device that has PB-ADV support and has not yet been provisioned, or is not being provisioned, will display the Device Not Provisioned Beacon. A provisioner embedded in the device continuously scans BLE beacons to look for any device not provisioned within the range.

After obtaining the device UUIDs of all devices that were not provisioned, the embedded provider employed PB-ADV’s provisioning bearer to establish a link with a the generic provisioner layer.

Once the bearer for provisioning is established, the provisioning of the device begins with this protocol. Provisioner uses provisioning PDUs to connect with the device.

Provisioner invited the device to start the process of providing. After receiving the ability to provision it, Provisioner confirmed that the device is able to provide the device. It can send the security algorithm that is supported, the access to public keys using and OOB technology. It also determines the capability for this device to send an amount that is input by the user capability that this gadget permit the input of a value from the users, as well as also if the device is equipped with an array of OOB information that could be used to authenticate.

Because public keys weren’t available via an OOB technology Public keys could not be transferred between the two devices.

After you have the Public Key of the peer device is established, both device and the Provisioner utilized this calculated shared Diffie Hellman secret ECDHSecret and created the session key using the shared secret.

ECDHSecret is P-256(private key and peer key public)

The session key was used to decrypt and verify the provisioning information. The device was then authenticated by using data that is unique to the device. The two devices exchanged the confirmation with an undetermined number. The values for confirmation are an encrypted hash of the exchanged values as well as it is a random code. After the device has been validated, all provisioning info has been transmitted to the device, encrypted by the key that is derived from the shared secret.

After receiving an Provisioning PDU for Data from Provisioner it encrypted and authenticated the data used to provision. When the procedure was completed successfully, procedure for assigning addresses the device notified with the Provisioning Complete PDU to verify that it was provided. When it received the Provisioning Complete PDU from the device it was assumed that the Provisioner believed that the provisioning process has been successfully completed and that it is using the address of unicast.

Provisioner did not reuse unicast addresses assigned to a device, and then sent to the form of a Provisioning Data PDU, until Provisioner receives an unprovisioned Device beacon, or Services Data in the Mesh Provisioning Service from that identical device, identified by the Device UUID of the device.

The embedded provisioner application runs on top of the BLE stack, along with BLE Mesh application. To enable embedded provisioner applications running on the same chip of nodes with only a limited amount of memory on the device, an the optimized coding method is employed.

In the embedded provisioner application A state machine is employed to manage the different states of the process of provisioning. It starts by scan of BLE beacons. BLE beacons state. The provisioner scans the device that is not provisioned beacon, establishes a link with the selected device to perform the procedure of provisioning and assigns the device’s address and save device data in the memory flash. This state machine works in a cycles to provide multiple unprovisioned devices within the range as illustrated in Fig 6.

Fig. 6. Embedded Provisioner State Machine


After turning onto the embed provisioner for its first time it establishes the credentials for network, including the application key, network key IV Index etc. needed to send as well as receive data messages on a mesh networks.

An interface for serial communication is accessible to communicate with the node that is a provisioner. After the successful creation of network credentials, a message is displayed in the interface, indicating the node as a provisioner as illustrated in Fig 7.

Fig. 7. Provisioner Node Initialization

In BLE Mesh the unprovisioned device beacons are utilized by devices that are not provisioned so that they can be identified by a provisioner. Devices broadcast their unique Device UUID that allows for their identification.

To verify the existence of devices that are not provisioned the provisioner node must scan beacons that are available. Scanning is activated by sending out a scan command via the serial terminal that is defined by ATEP SCAN. The embedded provisioner begins scans the BLE channels for advertising beacons that are the available Unprovisioned beacons for devices.

As a response in response to the command the provisioner node displays the list of Device UUIDs for all devices that are unprovisioned in the terminal serial. The scan Command Response for Two Provisioned Devices that are accessible in the range of the provisioner identified with their Device UUIDs can be seen in Fig 8.

Fig. 8. Scan Command to get Device UUIDs

This data can be utilized to select one of the unprovisioned devices available to be provisioned. To start the provisioning process of selected node, a command, namely ATEP PRVNXX can be sent by the serial terminal. This command indicates the device’s location on the device’s unprovisioned in the scan stage. It is a zero-based offset, which means that when provisioning the first device it becomes the number 00.

When the provisioning command is issued the provisioner node creates an PB-ADV link provisioning bearer to the device identified with the device UUID. Through that link are all messages for the provisioning protocol have been communicated by using PDUs for Provisioning.

Generic Provisioning layer guarantees reliability of the provisioning messages by using Generic Provisioning PDUs that are connected to an unreliable provisioning bearer that is not connected.

After the successful installation of the device the provisioner produces a successful provisioning message together with the device key that was calculated by the node. The device key information as well as the allocated unicast address for the each node, which is unique to every node in the mesh network have been stored to flash memory provisioner to be used as network information. It can then be later used for setting up the network or the node.

Then, after receiving the complete and successful provisioning message from the device’s provisioner shuts down the link established as illustrated in Fig 9.

Fig. 9. Provisioning Command

The application for embedded provisioning is designed with the intention to run with the exact same chips that used to create nodes. This required a specially optimized programming approach that can allow the complete Embedded Provisioner application within the limited memory of the device. A modified coding strategy is utilized, which only requires three megabytes in flash memory combination with BLE Mesh applications to enable the Embedded Provisioner feature.


With the expanding market for IoT devices increasing numbers of devices are being integrated into the mesh network to allow remote control and monitoring. With the increasing quantity of smart devices on mesh networks, Embedded Provisioner is an excellent option that can save time and money.

In a massive mesh network that has thousands of gadgets, it can be a huge problem to manage the provisioning of every device. The embedded provisioner is able to solve this issue by provisioning nodes using an automation script that is small.

Additionally, it can be integrated in embedded systems such as smart TVs, smart speakers to aid in the creation of the network mesh, provide and control of the mesh nodes. With the advancement of technology, increasing numbers of different kinds of devices are able to be included to the mesh networks with ease.


[1]          Mesh Profile Bluetooth Specification, Revision: v1.0, Revision Date: 2017-Jul-13, pp. 227-259

[2]          Mesh Model Bluetooth Specification, Revision: v1.0, Revision Date: 2017-Jul-13

[3]          Bluetooth Core Specification, Version 4.2, Publication Date: 2014-Dec-02

[4]          Website –

[5]          Website –

[6]          Website –

Michal Pukala
Electronics and Telecommunications engineer with Electro-energetics Master degree graduation. Lightning designer experienced engineer. Currently working in IT industry.