Bluetooth Mesh Remote Provisioning: Verify Reachability Before Delegating Installation

Remote provisioning adds a reachable Mesh server between the commissioner and the unprovisioned device. Qualify both paths and track the provisioning transaction across them. A scan report from that server proves neither that a provisioning bearer can open nor that the new node has joined successfully.

Applicability: historical Bluetooth Mesh Protocol 1.1 PB-Remote for installing an unprovisioned device, with Zephyr 4.2.0 Remote Provisioning Client declarations as API examples. Device Key, address and composition refresh procedures for existing nodes are outside this workflow. No device was provisioned and all failure cases are proposed lab tests.

1. Map the three roles and two paths

The PB-Remote definition keeps the Provisioner in control of the provisioning protocol. Its PB-Remote Client communicates over the existing mesh with a node implementing the Remote Provisioning Server model. That server opens the final provisioning bearer to the unprovisioned device.

The last hop uses PB-ADV or PB-GATT as supported by the server. The device still needs to be within that server’s immediate radio reach. Remote provisioning extends the commissioner’s reach through the mesh; it does not make an unreachable last hop disappear.

Record commissioner build, selected server element address, subnet context, device UUID and attempt generation. Measure mesh-control failures separately from last-hop failures. A server that answers a configuration query may still be unable to hear the intended device.

The client/server model access security uses the server’s device key. Ensure the authorized commissioner has the required provisioning records and access. Do not equate ordinary application-model connectivity with permission to run remote provisioning.

2. Qualify scanning before reserving a long transaction

Query the server’s scan capabilities and current scan state. Choose a bounded single-device scan when the expected UUID is known, or a bounded multi-device scan for an authorized installation inventory.

Zephyr 4.2.0 rpr_cli.h exposes maximum scannable devices and active-scan capability, plus scan status and a scan-report callback. A request above server capability is rejected through the server’s scan status. In the exact implementation, bt_mesh_rpr_scan_start returns local send/wait status, while handle_scan_status copies the server result into the response structure. Check both the function return and returned status/state before declaring the scan active. A zero device limit means as many as supported, not unlimited memory.

In Mesh 1.1, a server reports devices it can provision through a supported last-hop bearer. Still treat reports as time-scoped observations. Save which server saw the UUID and when; a report from another location is not evidence for the server chosen later.

Extended scanning can supply requested additional advertising information. An empty result is distinct from a missing callback or a failed scan. Do not make a display name or RSSI the authorization check for installing a device.

Confirm the intended device through the approved provisioning identity and out-of-band procedure. Section 5.2.3 recommends an OOB public key for PB-Remote and advises against authentication without OOB. Do not weaken the authentication path merely because the commissioner is physically distant.

3. Allocate one link owner per server

A PB-Remote Server communicates with one PB-Remote Client and opens one supported provisioning bearer at a time. A Provisioner can use multiple client instances and servers for concurrency, but it must not assume one server provides arbitrary parallel installation slots.

Use a scheduler keyed by server instance. Keep an attempt’s owner, UUID and address reservation together. A second installation should wait or use another qualified server rather than overwriting a live link’s state.

Issue Link Open for the target UUID and distinguish method/message acknowledgment from the reported link state. The specification enumerates Idle, Link Opening, Link Active, Outbound Packet Transfer and Link Closing. Progress the provisioning engine only through its supported bearer-ready transition.

The PB-Remote link-open timeout is a last-hop operation limit. The client model’s response timeout is another limit. Zephyr exposes a client transmission timeout for waiting on the server; increasing that value does not by itself prove the server’s radio link can open.

4. Keep transport reports below provisioning completion

Once the bearer is open, the client runs the provisioning protocol while the server transports Provisioning PDUs. Remote Provisioning PDU Outbound Report describes the server’s send procedure; Remote Provisioning PDU Report carries an incoming provisioning PDU back toward the client.

Those reports are intermediate evidence. Completion requires the provisioning protocol’s result and consistent commissioner records. A successfully forwarded invite, capabilities message or encrypted data message is not the final installation state.

Let the selected stack own inbound/outbound PDU counts and duplicate handling. Log nonsecret event types, result codes and transaction context. Reimplementing retransmission by blindly resending application-level “provision” jobs can create overlapping attempts and confusing completion histories.

After successful provisioning, perform the required configuration and application-readiness checks separately. Model binding, subscriptions and publication settings are not established merely because network credentials were installed.

5. Treat late interruption as an uncertain outcome

Before sending provisioning data, reserve an address range according to the learned element count and persist the transaction intent through the commissioner’s supported database. Keep device keys and network material out of ordinary diagnostics.

If the server or mesh path disappears late in provisioning, the device may have accepted state while the commissioner missed the final response. Mark the attempt uncertain. Do not immediately recycle the reserved addresses or assume the device remains unprovisioned.

Reconcile through the authorized stack and inventory workflow: inspect link status when possible, check whether the expected new node can be contacted under the saved context, and determine whether controlled recovery is required. A repeated scan with no unprovisioned report is not sufficient proof of successful installation.

On cancellation, request supported link closure and preserve its result. If closure cannot be confirmed, keep the server unavailable to a conflicting job until its state is reconciled or the specified timeout/cleanup behavior is verified. Do not close another commissioner’s transaction as a convenience.

6. Inject faults at each boundary

• Keep the server reachable but remove the target from its radio range: expect scan or link-open failure, not a generic mesh outage.
• Lose the mesh route after a scan report: verify stale discovery does not advance the installation.
• Submit two jobs to one server: verify serialized ownership and no UUID mix-up.
• Interrupt a PDU transfer: verify protocol-owned retry and explicit failed or uncertain outcome.
• Restart the server after provisioning data delivery: verify address reservation and commissioner records remain reconciled.
• Complete provisioning but fail model configuration: verify “installed” and “application ready” remain separate.
• Reject the required OOB interaction: verify no silent fallback to weaker authentication.

Acceptance is a transaction map with accountable transitions: server reachable, target observed, bearer active, protocol complete, records durable and application configured. Every interruption should identify the affected boundary and leave a controlled next step.