I have a severe issue regarding controller-based-privacy which makes it impossible to re-connect to a bonded peripheral, which uses the Identity Address (IA) for connectable advertising.
But first, let me explain the scenario:
We have implemented the BLE central functionality on our RSL10 hardware (Its an ASHA streamer). So far connecting, bonding, disconnecting and reconnecting to a peripheral, which uses a private-resolvable address (PRA) works perfectly. Before a new peripheral is paired, GAPM_SCAN_ACTIVE is used to discover the new peripheral. Then we connect and start the bonding process. At this point the IRK and the IA parameters between both devices are exchanged and the peer information is then stored in the NVR2. In order to reconnect to the new bonded device, we use the controller’s Resolving List (GAPM_RAL_MGT_CMD to fill the Resolving List with the IRKs and IA information from NVR2). The Resolving List is updated each time we have a new valid bond or after system reset. In addition we use the GAPM_CONNECTION_AUTO command to add the bonded devices to the White List (and yes we have controller-based-privacy enabled with .addr_type = (GAPM_CFG_ADDR_CTNL_PRIVACY | GAPM_CFG_ADDR_PRIVATE). Now for peripherals, which use a PRA this procedure is very reliable and fast, since the host is not involved in the connection process. The controller is able to resolve the peers PRA and the connection can be established.
Now, last week I have tried to connect to a different BLE peripheral, which uses PRA (6B:BD:05:45:D1:9C) within the first 3 minutes, but the peripheral then switches to its IA (a global address 7C:A1:5D:88:DB:09). The pairing procedure completes without any issues (IRK and IA successfully exchanged) and also reconnection works within the first 3 minutes. However, when the peripheral uses the IA after 3 minutes, our central is not able to establish connection anymore. I double checked in the firmware and can ensure, that the peripheral’s IA is in the White List as well as in the Resolving List. But somehow the controller is not able to resolve a device, when it uses the IA instead of PRA. This is a strange behavior in my opinion , because a non-resolvable address should not be resolved anyway. I then manually cleared the Resolving List before connecting and … voila … the central succesfully connects!!. Do you have any explanation why this does not work when the device address is in the Resolving List??
We definitely want to use controller-based-privacy and clearing the Resolving List before any connection is not an option, as we would not be able to resolve PRAs anymore.
I spent quite some time studying the BLE Core 5.0 specification and I figured out that there are two types of privacy features: device privacy and network privacy. Here is an extract from Vol. 1 Part A. Section 5.4.5 Privacy Feature:
There are two modes of privacy: device privacy mode and network privacy
mode. A device in device privacy mode is only concerned about the privacy of
the device and will accept advertising packets from peer devices that contain
their identity address as well as ones that contain a private address, even if
the peer device has distributed its IRK in the past. In network privacy mode, a
device will only accept advertising packets from peer devices that contain
private addresses. By default, network privacy mode is used when private
addresses are resolved and generated by the Controller.
To me, it seems the RSL10 BLE RW stack only uses Network Privacy Mode, as the controller does not accept the IA. Am I right??
Do you have any suggestions, how to solve this issue? It would really help us.
According to BLE Core Specification 5.0 the HCI_LE_Set_Privacy_Mode allows to set the privacy mode (network or device privacy) for a specific device address. Does the RSL10 support this feature? Otherwise I assume that the device privacy mode, which would be necessary in this case, is not possible on the RSL10, as network privacy is used by default.
Thank you very much.