PAwR response delayed by one periodic interval

[droid]

Hello,

We are using 2 nRF5340-based devices running:

1. samples/bluetooth/periodic_adv_rsp
2. samples/bluetooth/periodic_sync_rsp

with the PAwR configuration (modified from the original samples):

• NUM_RSP_SLOTS = 1
• NUM_SUBEVENTS = 1

Each device is running Zephyr 4.3.0, and SoftDevice Controller based on NCS 3.2.0, configured for Periodic Advertising and PAwR.

We modified periodic_adv_rsp main.c to:

• display counter during request_cb (prior to counter++ increment, which is displayed as 'Subevent data set xx')
• display counter from the buffer in response_cb (which is the same as in the displayed Advertising data)

Here is a snippet of the output from periodic_adv_rsp:

Start Periodic Advertising
Start Extended Advertising
Scanning successfully started
request: counter 0
Subevent data set 1
Connected (err 0x00)
PAST sent
Discovery started
request: counter 1
Subevent data set 2
request: counter 2
Subevent data set 3
Discovery: attr 0x20005cb4
UUID 12345678-1234-5678-1234-56789abcdef1
Characteristic handle: 18
Write started
PAwR config written to sync 0, disconnecting
request: counter 3
Subevent data set 4
request: counter 4
Subevent data set 5
Response: subevent 0, slot 0
response: counter 3
 0xFF: 590003
Disconnected, reason 0x16 
Maximum numnber of syncs onboarded
request: counter 5
Subevent data set 6
Response: subevent 0, slot 0
response: counter 4
 0xFF: 590004
request: counter 6
Subevent data set 7
Response: subevent 0, slot 0
response: counter 5
 0xFF: 590005
request: counter 7
Subevent data set 8
Response: subevent 0, slot 0
response: counter 6
 0xFF: 590006

The response counter value lags the request counter value by one Periodic Advertising interval.

We tried modifying the PAwR parameters so as to increase slot_delay in an attempt to give the responder more time to generate a response. The results are the same.

This change also appeared to delay execution time of calls to bt_le_per_adv_set_subevent_data() and bt_le_per_adv_set_response_data() on each device.

Questions:

1. Is a delayed PAwR response of 1 Periodic Advertising interval expected?

2. If so, is there a way (e.g. by configuration or code changes) to avoid this?

Thank you.

[Vidar Berg]

Hello,

I have limited experience with PAwR so I forwarded this to our developers. Here is the response I got:

1. The sync is allowed to respond up to one periodic interval later. Which periodic interval it will respond in depends on the timing of the "LE Set Periodic Advertising Response Data" HCI command. If there is time to respond in the current subevent SDC will do that, if not the response will be one periodic interval delayed. In addition, SDC will enqueue the "LE Periodic Advertising Subevent Data Request" event when the AUX_SYNC_SUBEVENT_IND has been sent so it will be fetched by the host before the response events.
2. The way to make sure the sync can respond in the same subevent is to increase the response slot delay, like the customer tried. I dont know what values they tried. The data has to go through the zephyr host and HCI so there will be some delays here. They are using 53 so there are additional delays in IPC between app and net cores as well.

Best regards,

Vidar

Update: developer also tested the sample himself:

Ran the samples on 54L with modifications mentioned in the devzone post. With a sniffer I see the sync consistently responding in the same subevent (response slot delay is 10 ms in the sample, periodic interval is 318.75 ms): 

However, I see the same logs as the customer on the advertiser side:

So ideally they would use a sniffer to see if the sync is responding in the same periodic interval or not

I think there are two things confusing here:

• The controller raises the data request event right after sending the AUX_SYNC_SUBEVENT_IND, before any responses have been received. So the timeline is:
  • Controller sends AUX_SYNC_SUBEVENT_IND with counter=N, requests data for next subevent
  • App responds to data request, sets data with counter=N+1
  • Sync responds with counter=N
  • App receives the response with counter=N
• The sample prints "Subevent data set N" after it set data with counter=N-1. It is the "request: counter N-1" print that tells which counter value was set.

[droid]

Hello,

Thank you for the information (and Happy New Year!).

We were not able to capture any LE Periodic Advertising packets for some reason (Windows 11, Wireshark 4.6.2, nRF52840 Dongle with sniffer_nrf52dongle_nrf52840_4.1.1.zip) so could not verify the sniffer trace above, but have extended the slot_delay (up to 200ms in another application) which should be sufficient to set a subevent response in the LE Periodic Sync (with subevents) device in the same LE Periodic Advertising interval as the subevent request.

We greatly appreciate the Nordic developer reproducing our results. And, the following would then explain the results:

The controller raises the data request event right after sending the AUX_SYNC_SUBEVENT_IND, before any responses have been received. So the timeline is:

• Controller sends AUX_SYNC_SUBEVENT_IND with counter=N, requests data for next subevent
• App responds to data request, sets data with counter=N+1
• Sync responds with counter=N
• App receives the response with counter=N

This means the LE Periodic Advertising (with subevents) device will not  be able to send a request based on the previous subevent response from the LE Periodic Sync (with subevents) device in the next LE Periodic Advertising interval after the subevent response is received, but rather must wait for the following LE Periodic Advertising interval to do so.

Of course this guarantees sufficient time for SD scheduling the next LE Periodic Advertising interval transmission, but reduces the rate of such 'ping pong' transactions by 50%.

In the LE Periodic Advertising (with subevents) device, would it be at all possible to defer the request for data by the SD controller until after slot_delay time has passed? For sufficiently long LE Periodic Advertising intervals, that should supply sufficient time to process a request.

Thank you,

Carl

[Kenneth]

Hi Carl,

The nordic sniffer does not support PAwR so you will have to use something more powerful like an Ellisys or Frontline sniffer. 

The application does not have to respond directly in the callback from the host (request_cb in the sample). You can call bt_le_per_adv_set_subevent_data later after receiving the response from the sync. If you are too late the controller will respond with an error code (0x46 TOO_LATE).

Kenneth

[droid]

Hello,

Together with a timer (to handle the case of no response_cb in periodic_adv_rsp sample), this works well.

Thank you for the recommendation.

Carl