BLE Transmit-Power Control: Interpret Path-Loss Reports Before Closing a Control Loop
Decode power and path-loss reports into a connection-scoped evidence ledger before allowing them to drive adaptation. A new callback does not necessarily contain a new radio measurement, and an unavailable value must never become a large numeric path loss. Establish controller ownership of power changes before adding another control loop.
Applicability: Bluetooth Core 6.1 connected LE ACL links and Zephyr v4.2.0 APIs. Controllers and peers must support the relevant features. The thresholds, replay sequence and policy below are hypothetical engineering fixtures, not RF measurements or recommended product thresholds. No vendor-specific transmit-power setter is assumed.
1. Identify what each report actually means
Under Core 6.1 Link Layer path-loss monitoring, path loss is remote transmit power minus average local RSSI. The averaging algorithm is unspecified. Thus a path-loss report is a controller-produced observation of the incoming link, not a direct distance measurement or evidence about both link directions.
For example, remote power of 0 dBm and average RSSI of −70 dBm imply 70 dB path loss. Raising remote power to 4 dBm while received strength becomes −66 dBm still implies 70 dB. This arithmetic illustrates why an RSSI increase alone cannot prove that propagation improved.
The controller can already manage power autonomously and through peer requests. Document that behavior and the exact implementation interface before designing host intervention. The reporting APIs do not themselves define a portable host command that sets an arbitrary connected-link transmit power.
2. Parse reason and validity before signed values
The HCI transmit-power event distinguishes local change, remote change and remote-read completion. Check Status for the completion reason; ignore it for the two change reasons. Preserve the reported PHY, which need not be the currently active PHY.
| Field value | Ledger interpretation |
|---|---|
| Transmit power 0x7E | Remote PHY power is not managed |
| Transmit power 0x7F | Power unavailable |
| Path loss 0xFF | Unavailable; ignore zone field |
| Ordinary valid power | Signed dBm, associated with its reported side and PHY |
Retain raw bytes beside decoded values in diagnostic traces. A generic signed-byte conversion is insufficient: 0x7F must not become a valid +127 dBm sample. Do not combine a local transmitter value with local receive RSSI to manufacture remote path loss.
A remote-power read can reuse information from a previous control exchange. Record command submission, command status and report arrival separately. “Arrived now” is not proof that the peer’s power was freshly measured now; leave RF observation time unknown when it is not exposed.
3. Create one ledger per connection generation
Use a new application generation whenever a connection is created. Key power records by generation, side and PHY. Include report reason, validity, arrival time, current connection parameters, requested monitoring parameters and their confirmed command outcomes.
Path-loss events do not carry their own PHY field. Retain the effective receive-PHY context and any pending PHY transition separately. If attribution around a change is ambiguous, mark the observation unsuitable for adaptation until the new configuration is established. Do not attach whichever transmit-power event happened to arrive most recently.
On disconnect, retire the generation and cancel its queued policy actions. Reuse of the numeric connection handle must not revive an earlier power recommendation. Keep rejected late callbacks visible in the diagnostic ledger without allowing them to mutate the replacement connection.
4. Configure a testable hysteresis model
In Zephyr v4.2.0, enable CONFIG_BT_PATH_LOSS_MONITORING and use bt_conn_le_set_path_loss_mon_param before bt_conn_le_set_path_loss_mon_enable. Check both returns. The parameter structure expresses min_time_spent in connection events, not milliseconds.
For a hypothetical fixture, choose low threshold 60 dB with hysteresis 3 dB, high threshold 80 dB with hysteresis 4 dB, and minimum residence of three connection events. The upward boundaries are 63 and 84 dB; downward boundaries are 57 and 76 dB.
These values satisfy the HCI ordering checks: 60≥3, 80+4≤255 and 60+3≤80−4. Starting in Middle, 83 dB does not cross upward; sustained 84 dB can enter High. Once High, 82 dB remains there; sustained 76 dB can return to Middle. Equality belongs to the crossing condition.
Replay that state model with controlled observations before testing RF. Separately verify controller event behavior on the target. Do not equate three connection events with three received packets or promise a fixed application response time; latency, subrating and scheduling affect useful observations.
Reconfiguration while monitoring is enabled can produce an immediate zone report when the new parameters change the zone, without waiting for the configured residence. Mark configuration revisions so the policy does not misclassify that report as sudden physical movement.
5. Bound the application reaction
Start with reporting only. Compare the ledger against controlled attenuation changes and application delivery outcomes. Confirm that invalid values, unsupported commands and absent reports are explicit states, rather than silently interpreted as a favorable link.
A proposed policy can require a valid current-generation zone, established PHY context, acceptable evidence age and no action already pending. Apply a product-defined dwell between actions. If a separately documented controller interface permits host power changes, bound its allowed settings and verify the resulting report before considering another adjustment.
Choose one owner for power policy. Do not have a fast host loop repeatedly oppose controller adaptation. An alternative application reaction is to select a previously qualified workload mode or display degraded-link status, without pretending that the monitoring command changed radio power.
Define behavior at a reported power limit. Repeated requests cannot create unavailable transmitter headroom. Preserve the delivery failure and fall back to an explicitly tested operating mode, or declare the link unable to meet the requirement.
6. Test the confusing transitions
- Inject unavailable and unmanaged values; verify no numeric control action.
- Complete a remote read using cached information; verify arrival time is not relabeled as measurement time.
- Change PHY and monitoring parameters; verify configuration-generated events remain distinguishable.
- Oscillate around each boundary and exercise equality; verify hysteresis and residence behavior.
- Disconnect with an action queued, then reuse the handle; verify generation rejection.
- Remove peer feature support; verify a bounded unsupported state rather than endless retries.
Acceptance requires a trace that explains every policy action from valid evidence, a confirmed implementation capability and the current connection generation. Keep the actual power, delivery and energy measurements separate. A correct event ledger makes a control experiment defensible; it does not by itself prove that the proposed adaptation improves the product.
