Bluetooth Channel Sounding: Define the Product’s Ranging Evidence Contract
A product distance result should be a qualified estimate with provenance, not a floating-point number detached from its radio evidence. Establish supported roles and modes, collect matching results from both peers, preserve incomplete and aborted outcomes, and identify the estimator and calibration that produced the estimate.
Applicability: Bluetooth Core 6.1 Channel Sounding and the Zephyr v4.2.0 result structures and sample documentation. This is an integration and qualification procedure for a deliberately selected CS-capable controller pair. No particular board has been tested here, and no accuracy, range or attack-resistance measurement is claimed.
1. Define the product decision first
Specify what the distance estimate will influence: a display, a search hint, a power-state suggestion or an access decision. Give the consuming application an explicit invalid/unknown outcome. A missing estimate must not silently become zero distance, because that can resemble the strongest possible proximity evidence.
Define maximum acceptable age, required availability and the consequences of a wrong result. Keep those product requirements separate from the estimator’s observed performance. A requirement such as “show a fresh estimate within a chosen interval” is a target until a test establishes it.
The Bluetooth SIG feature explanation distinguishes phase-based ranging and round-trip timing, and explicitly states that Channel Sounding does not prescribe a distance-estimation algorithm. Successful protocol operation therefore does not establish the accuracy of an independently chosen estimator.
2. Save a capability snapshot from both ends
Record controller manufacturer, silicon revision, firmware identity, host release, build configuration and board/antenna revision. Read local and remote CS capabilities and retain the actual responses. Compare the requested initiator/reflector roles, modes, timing options and antenna-path arrangement against that pair’s support.
The Core HCI capability and procedure interfaces expose supported configurations and selected procedure parameters. Save selected values after successful setup rather than copying requested values into the evidence record. Treat rejection as an unsupported configuration, not as a failed distance measurement.
Keep connection role distinct from sounding role. Under the Core Link Layer model, either Central or Peripheral can be the CS initiator or reflector. The ACL must be encrypted before CS use. Record successful security and configuration stages; merely having a connected link is insufficient.
Use the selected controller’s release documentation to establish actual support. A Bluetooth version label alone is too broad to qualify a particular combination. If that documentation or a runtime capability response is missing, leave that operating point unqualified.
3. Preserve result identity and completeness
Build a bounded assembly record keyed by application session, connection generation, configuration identity and procedure counter. Add the subevent identity or ordered position required by the implementation. Counter wrap and reconnection must not merge two physically different observations.
Core HCI can split a subevent across an initial result and continuation events. Preserve procedure and subevent completion states, abort reasons, step modes, channels and antenna-path information. Do not pass a first fragment directly to an estimator that assumes a complete observation.
The Zephyr v4.2.0 result structure includes procedure count, status, abort information, reported-step count and a step-data buffer. Its abort_step distinguishes completed steps from an aborted suffix. Keep the source representation alongside the normalized estimator input so a decoder error can be traced.
Set independent limits for assembled bytes, pending procedures and assembly age. On overflow, missing continuation or mismatched peer data, emit a specific rejected outcome and release the assembly. Do not append late data to whichever procedure happens to be current.
4. Match peer evidence before estimation
The tagged Zephyr sample documentation explains that its distance estimation needs data from both devices and exchanges results through a simple GATT characteristic. It assumes one subevent per procedure and limits the amount processed at once. Those are sample boundaries, not a general product transport contract.
For a product, version the peer-result envelope. Include session and procedure identity, declared length, completeness, configuration revision and integrity checks appropriate to the authenticated connection. Reject stale, duplicated or incompatible envelopes before pairing them with local results.
A hypothetical fixture can pair local procedure 41 with remote procedure 41, then deliberately substitute remote procedure 40. The first may proceed if all other gates pass; the second must be rejected as mismatched. This checks association logic without pretending to measure radio accuracy.
Do not infer observation time from the arrival of the peer envelope. Transport delay is additional age. Preserve local observation timing, remote timing semantics and receive time separately; if clocks are not synchronized, do not subtract their raw timestamps as though they shared an epoch.
5. Make estimator and calibration provenance explicit
Record estimator name/version, parameter set, accepted/rejected sample counts, antenna mapping and calibration identifier. The Core RTT description requires compensation for known internal antenna-to-measurement delays. Establish what the controller already compensates and what the chosen estimator expects before adding application corrections.
Do not double-correct a delay because both a vendor library and application worksheet mention it. Store the correction’s owner, units, reference plane and validity conditions. Revisit calibration after a relevant board, antenna, enclosure or firmware change.
| Result field | Required meaning |
|---|---|
| status and reason | Accepted, rejected, unsupported or stale, with cause |
| distance and units | Present only for an accepted estimate |
| observation identity and age | Which paired procedure produced it and how fresh it is |
| quality/uncertainty | Named metric and calibration basis, or explicitly unknown |
| provenance | Hardware, configuration, estimator and calibration revisions |
A vendor quality score is not automatically a confidence probability or an error bound. If its relation to error has not been validated for the product, retain the score under its own name and leave uncertainty unknown.
6. Qualify failure behavior and accuracy separately
First replay complete, partial, aborted, duplicated, delayed and cross-session result sets through the pipeline. Verify exactly which gate rejects each case. Then run controlled physical measurements against independently measured ground truth.
Use a matrix covering separation, orientation, obstruction, reflective surroundings, motion and the supported environmental conditions. Keep a fixed reference setup while varying one factor. Report attempted procedures, accepted estimates, rejected outcomes, age distribution and signed distance error.
Analyze error on accepted estimates alongside availability. An estimator that rejects difficult cases can look accurate if its missing results disappear from the denominator. Report both, with the tested conditions and sample counts.
For security-sensitive decisions, retain a separate threat model and adversarial qualification. Encryption and a successful sounding procedure do not replace that work. Release only a product policy whose invalid-result behavior, evidence freshness and measured operating limits are explicit.
