Bluetooth LE: Add feature to allow profiles to change ADV data at RPA updates

[Casper-Bonde-Bose]

Problem An upcoming Bluetooth (GATT based) specifications require that the data advertised is updated at the same time as the Resolvable Private Address updates.

Feature This request covers adding a mechanism for a profile to update the advertisement data and scan response data between updating the address and re-enabling advertisements.

Requirements It is important that:

• not a single advertisement is sent with the new address and the old data
• not a single advertisement is sent with the old address and the new data
• the implementation ensures that actions performed by the profile during the update of the data do not trigger a new RPA update. The current advertisement API supports only a single user (advertisement instance), hence the solution could support only a single advertisement instance, but should be prepared for supporting multiple instances.

The reason for the strict alignment is privacy, and there is a qualification test that validates this.

Solutions I see two different solutions:

1. Generic Address_changing() call-back - when we get adv-ext it would include the identity-reference. It will be called with states set in a way that allows new adv data to be set using the existing API's, but the callback can be used to perform any action.
2. Adv data update only call-back such as address_change_update_data(pointers to same arguments as bt_le_adv_update_data). This will allow only to update the adv data - the call-back can perform other actions, but the BT-interface cannot be called(to protect against state changes during a state change).

There are two cases that needs to be handled:

1. Host handling RPA update - this should be trivial as everything can be handled within the host stack.
2. Controller handling RPA update - This seems impossible with the current HCI interface - Please provide input for this.

[Casper-Bonde-Bose]

@joerchan I see you have a commit for advertisement extensions - do you have comments on this topic?

[joerchan]

@Casper-Bonde-Bose I'm not sure if you are aware of this, but somebody already created a PR for the address callback solution which was closed since we couldn't solve all the issues with that. You have already outlined the controller RPA update issue. https://github.com/zephyrproject-rtos/zephyr/pull/22524

Your second solution might be better suited. Since the undirected advertiser uses the host RPA, and the scanner/initiator use the controller RPA. Directed advertiser use the controller RPA, but has no data.

Is this something that has to be exposed to the application, or can we keep it inside the host itself?

Regarding Advertising Extension, maybe the duration parameter of the advertiser could be used in some way. I'm still working on how to handle privacy together with the use of the duration parameter. If the duration parameter was to be set to the same as the RPA timeout. Then advertising data could be updated in the stopped event, and the advertiser started again.

[Casper-Bonde-Bose]

@joerchan I was not aware of #22524, thanks for the reference.

I believe it is limited to the profiles in the host stack - in the future there might be a need to call from the profile to the application to get parts of the advertisements data but currently I do not see a need for this.

I was not aware that a mix of host and controller RPA handling was used - this means we do not need to handle controller RPA updates - as only undirected advertisements are needed for this feature. And if that is true also for advertisement ext. then we do not need to do any coordination between duration and RPA timeout as a consequence of this feature.

If you suggest to replace this feature with using adv-ext + period < RPA timeout, that is also an option. It would require the RPA timeout is per advertisement instance, and that the RPA timer is started when the advertisement instance is enabled - and that a new address is generated at each call to enable. (the enable API could have an option to instruct the stack to generate a new RPA.

[joerchan]

If you suggest to replace this feature with using adv-ext + period < RPA timeout, that is also an option. It would require the RPA timeout is per advertisement instance, and that the RPA timer is started when the advertisement instance is enabled - and that a new address is generated at each call to enable. (the enable API could have an option to instruct the stack to generate a new RPA.

That was my suggestion yes. Except it is duration, there is a period parameter as well. Using the Privacy feature together with advertising duration would mean that we could set the duration equal to the RPA timeout, and update advertising data and re-start the advertiser in the advertiser stopped callback. I think that is the best solution.

[joerchan]

CC: @Vudentz @jhedberg Any comments to the suggested solution? It wouldn't require any changes to the proposed API of Advertising Extension since we can use the duration parameter and the stopped callback.

[jhedberg]

@joerchan no other comments except that it sounds like a good plan forward