BLE Connection Subrating: Prove the Transition Between Idle and Interactive Operation

Prove two different transitions: additional activity permitted by continuation events, and a negotiated change of subrate parameters. Neither should be inferred from a successful request call. Record the effective factor and completion status, then measure the first useful application response from several arrival phases in the idle schedule.

Applicability: Bluetooth Core 6.1 and Zephyr v4.2.0, a controlled LE ACL connection with one serialized subrate-policy owner. Controller and peer support remain explicit requirements. All parameter sets and tests below are hypothetical. No phone compatibility, battery saving or measured command-latency result is claimed.

1. Verify capability and host participation

The Core feature definitions distinguish Connection Subrating from Connection Subrating (Host Support). A supporting controller does not by itself prove that the peer host participates. Capture local and remote feature evidence, role, firmware versions and the configuration that enables the host interface.

In Zephyr, the connection header gates subrating APIs and callbacks through CONFIG_BT_SUBRATING. The default-setting API additionally requires the central role. A compiled declaration is not proof that the selected controller accepts the corresponding command.

Test this matrix with controlled peers before making claims about phones. An operating-system API may not expose the control required by the product even when its radio implements the underlying feature.

2. Keep the underlying interval visible

Subrating selects a reduced set of connection events from an underlying interval; it does not simply replace that interval with a larger one. Core section 4.5.1 defines the selected events using the subrate factor and base-event phase. Continuation events can provide additional underlying events after nonempty Link Layer traffic.

For a hypothetical connection with underlying interval 15 ms, factor eight and zero peripheral latency, regular subrated opportunities are 120 ms apart. Choose continuation number two for the idle policy. Traffic at an eligible event can create subsequent continuation opportunities; it does not automatically report a negotiated factor change to one.

The first command after a quiet period still needs an eligible exchange. A local application queue becoming nonempty is not evidence that the remote device is already listening at every underlying anchor. Separate the initial wait from the burst’s later command spacing.

Do not label the 120 ms spacing an end-to-end latency guarantee. Host queues, scheduling conflicts, retransmissions and the peer application remain outside that simple arithmetic. The product’s response criterion must end at a meaningful acknowledgement, not at enqueue.

3. Validate the complete requested tuple

The HCI Subrate Request contract checks factor range, latency, continuation and supervision timeout together. For the proposed idle request, set minimum and maximum factor to eight, maximum latency to zero, continuation to two and timeout to two seconds.

Its timeout must exceed 2×15 ms×8×(0+1)=240 ms; two seconds passes this inequality. The factor-times-latency expression is eight, within the specified maximum 500, and continuation two is less than maximum factor eight. These checks do not establish radio performance.

For an interactive request fixed at factor one, set continuation to zero. Reusing the idle value two would violate the continuation constraint. Record timeout in the API’s 10 ms units: the hypothetical two-second value is 200, not 2000.

The tagged host implementation validates common parameters and sends the subrate request through the synchronous HCI command path. That synchronous command exchange is still distinct from the Link Layer procedure completing and the effective connection state being reported.

4. Own desired, pending and effective state separately

Maintain desired policy, pending request and last confirmed effective parameters for each connection generation. Only one owner sends requests. New interactive work changes the desired policy immediately, but it does not overwrite the effective factor while a procedure is pending.

In the HCI lifecycle, Subrate Request receives Command Status; LE Subrate Change reports the completed update. Zephyr exposes subrate_changed with a status and resulting parameters. Its callback contract says effective parameters remain unchanged on unsuccessful status. Retain the known state and reason instead of copying the requested tuple as success.

Changing defaults is not an active-link transition. bt_conn_le_subrate_set_defaults affects future connections where the local controller is central; it does not update an existing connection. Use the per-connection request for the current link.

Also observe ordinary connection-parameter updates. The Core resets subrate factor to one and continuation to zero when the underlying interval changes; the HCI subrate-change event is not issued for changes made through the Connection Update procedure. A state cache driven only by subrate_changed can therefore become stale. Reconcile both update paths.

5. Sweep the first-command arrival phase

Build an application echo or bounded control acknowledgement with sequence numbers. For each trial, confirm the idle effective tuple, allow the traffic to become quiet, then issue one command at a selected offset relative to observed subrated opportunities.

Use offsets near an opportunity, halfway between opportunities and just after one. Add a multi-command burst. Record application enqueue, request submission, command status, effective update notification and remote acknowledgement using compatible time references. If separate clocks are used, establish their correlation instead of subtracting unrelated timestamps.

Compare three controlled cases: factor-one baseline, factor-eight with continuation disabled, and factor-eight with continuation two. Then test the explicit transition to factor one. This distinguishes a faster burst caused by continuation from an actual parameter update.

Report first-command delay separately from later burst spacing. Include rejected requests and trials without acknowledgement before the product deadline. Excluding failed trials can make an unsuitable idle policy appear responsive.

6. Exercise rollback and competing updates

1. Use a peer without required host support and verify the documented fallback, without rapid repeated requests.
2. Submit the factor-one request with an invalid nonzero continuation in an isolated negative test; retain the rejection and unchanged effective state.
3. Introduce packet loss during transition and verify that pending state is not mistaken for completed negotiation.
4. Change the underlying interval through the ordinary update path and verify the subrate cache is reconciled.
5. Disconnect during a pending request, reconnect and ensure an old completion cannot update the new connection generation.
6. Deliver new work while an idle transition is pending; serialize the resulting policy change rather than sending competing updates.

Accept the design only when capability evidence, observed effective state and first-command latency satisfy the same product requirement. Keep energy qualification separate until the actual board and workload are measured; a sparse schedule alone does not establish a battery-life gain.