PAwR Response Slots: Decide Whether Scheduled Sensor Replies Fit the Product

PAwR fits a sensor product only when three budgets agree: each device owns a defined response opportunity, its packet fits that opportunity, and the host supplies the response before the controller’s deadline. A schedule with enough numbered slots is necessary but does not establish reliable reporting or application freshness.

Applicability: this analysis pins Bluetooth Core 6.1 and Zephyr v4.2.0 host interfaces. These are explicit historical baselines, not latest-version or qualification claims. The advertiser and responding devices require controllers supporting their respective PAwR roles. All timings, sensor counts and qualification cases below are hypothetical; no radio or host-latency measurements were performed.

1. Qualify both roles before counting sensors

The exact Zephyr advertiser sample requires the PAwR Advertiser controller feature; its synchronization partner requires the PAwR Scanner feature. A generic Bluetooth LE support statement is insufficient. Record host release, controller firmware, supported roles, PHY, simultaneous radio activities and relevant resource limits.

The samples also make subevent and response-slot assignment application-specific. Their example uses a connection and GATT characteristic to distribute assignments. That is one provisioning approach, not a rule that PAwR itself allocates unique sensor identities or resolves competing claims.

Create an assignment table containing logical sensor identity, train generation, subevent, slot, payload schema and activation condition. Prevent two active sensors from believing they own the same slot in the same subevent. Include replacement devices and an advertiser restart; a clean initial assignment is not enough.

2. Calculate slot starts from the correct anchor

Core 6.1, Volume 6, Part B, section 4.4.2.2.4 anchors response-slot delay at the start of AUX_SYNC_SUBEVENT_IND. It is not measured from that packet’s end. Adjacent slot starts are separated by response-slot spacing.

Let a hypothetical train repeat every 200 ms with four subevents spaced 25 ms apart. Give each subevent eight response slots, a 5 ms response delay and 2 ms slot spacing. Subevent starts are 0, 25, 50 and 75 ms. Within the first subevent, response-slot starts are 5, 7, 9, 11, 13, 15, 17 and 19 ms.

The specification requires spacing no greater than (subevent interval−response delay)/slot count. Here the bound is (25−5)/8=2.5 ms, so 2 ms satisfies that timing inequality. Delay plus eight spacing units is 21 ms, inside the 25 ms subevent. This is a schedule check, not a measured airtime margin.

The Zephyr parameter fields encode periodic interval, subevent interval and delay in 1.25 ms units, and spacing in 0.125 ms units. The example therefore uses 160, 20, 4 and 16 respectively. Preserve both encoded values and physical units in the configuration record.

3. Prove packet fit separately

The same Link Layer clause requires the indication duration to be less than response delay minus 150 microseconds, and the response duration to be less than slot spacing minus 150 microseconds. For this example those limits are 4.85 ms and 1.85 ms. Include the complete on-air packet and selected PHY, not just the sensor-value bytes.

Choose a concrete application schema before testing capacity. For example, reserve fields for schema version, assignment generation, sample sequence, sample age and measurement bytes. Count the advertising-data framing and any protection overhead as well. An eight-byte measurement does not necessarily create an eight-byte radio payload.

Core 6.1 HCI section 7.8.126 allows a Response_Data_Length field up to 251 octets, but that is not a promise that 251 octets fit every slot. The controller rejects data exceeding its slot-time capacity with Packet Too Long (0x45). For that check on LE Coded PHY, the specified assumption is S=8.

Submit boundary payload lengths in the qualification build and retain the controller status. A smaller host buffer or implementation limit can reject a request earlier. Record the limiting layer rather than labeling every failure an RF problem.

4. Budget the host-to-controller deadline

The response API carries request event, request subevent, response subevent and response slot. Preserve those fields from the relevant request context. A new measurement must not be attached to stale event bookkeeping merely because the same slot number recurs.

Trace indication receipt, host callback entry, response preparation, submission and controller command status. Include sensor conversion, queue delay and HCI transport service where applicable. For a same-subevent response, the usable preparation interval is shorter than the start-anchored delay because receiving the indication already consumes time.

The HCI contract discards a response submitted after its identified slot and returns Too Late (0x46). Treat this as a deadline failure, distinct from Packet Too Long. It also specifies one transmission for the submitted response data; a successful command is not an acknowledgement that the advertiser application consumed the measurement.

Prefer a prepared recent sample when the product permits it, carrying its actual sample age. If the requirement demands a new conversion after every request, demonstrate that complete conversion and submission path under worst supported load before accepting the schedule.

5. Turn opportunities into a reporting policy

Four subevents with eight uniquely assigned slots provide 32 scheduled opportunities per 200 ms event. If each sensor owns one, the nominal reporting cadence is five opportunities per second per sensor. These are allocation arithmetic, not delivered-packet counts or supported-product capacity.

Define the missed-slot behavior explicitly. The hypothetical policy discards an expired response request, records the reason and offers the newest eligible sample at a later valid request. It does not transmit spontaneously into a neighbor’s slot or relabel an old sample as newly measured.

At the advertiser, classify absent response, malformed response, duplicate sequence and over-age measurement separately. Mark the sensor’s value stale according to the product requirement. If acknowledgement or retry is required, design that application exchange explicitly and include its opportunities in the schedule budget.

6. Test admission, overload and reassignment

1. Start with one assigned responder and verify request identity, slot selection, payload and received application sequence.
2. Add all proposed responders with distinct assignments; measure delivery and age distributions with an explicit expected-opportunity denominator.
3. Delay response preparation until it crosses the submission boundary. Require a deadline-failure record, without an unsafe late retry.
4. Increase payload until a documented host or controller limit rejects it; retain the exact status and selected PHY.
5. Introduce duplicate slot ownership in a controlled fixture, then verify the assignment manager detects and repairs its own configuration error.
6. Restart the advertiser and replace one sensor. Reject stale assignment generations before admitting the replacement.

Keep synchronization acquisition and loss tests separate from these response-admission tests. Accept PAwR when the chosen hardware supports both roles, every payload and deadline fits, and the measured missing-report behavior satisfies the declared product policy. Otherwise change the schedule, sampling contract or transport rather than presenting slot count as a reliability guarantee.