Identity address in connection complete event

[ebmmy]

Dear Nordic DevZone,

I'm encountering pairing issues with mobile devices and a nRF54 DevKit flashed with HCI over UART firmware. After initial pairing, deleting the bonding information and attempting to pair again results in a failure.

After analyzing the HCI trace, I've observed that during the initial pairing, the connection complete event reports the mobile device's resolvable address. However, during the subsequent pairing attempt, the connection complete event reports the mobile device's identity address. We have address resolution enabled in the controller.

Based on my understanding of the Bluetooth specification, I wouldn't expect the controller to resolve the address and provide the identity address within the standard connection complete event. My interpretation of the specification is that address resolution and the provision of the identity address should only occur in the enhanced connection complete event. This event includes explicit address type information that indicates when such resolution has taken place.

My question is: When address resolution is enabled in the controller, should the standard connection complete event ever report the identity address, or should it always report the address that was used for the connection establishment?

Thank you in advance for any insights you can provide!

Have a nice day and best regards

[Sigurd]

Hi ebmmy,

Core 6.B.4.7 v6.0 says:

 "If the Link Layer is using the Resolving List and the peer device has been resolved, the Address returned to the Host is the peer device’s Identity Address."

---

The identity address is also a device address. RPA resolution will occur if configured, even without advertising extensions (see own_address_type and peer_address_type in LE Create Connection. To differentiate between the RPA and identity address in the legacy event, it's enough to look at the bit pattern using for instance BT_ADDR_IS_STATIC()

When you delete the bond you should delete corresponding entry from the resolving list as well since IRK considered to be not valid any longer. Then controller will not be able to resolve it and will report address as it was so subsequent pairing will succeed.

[Emil Lenngren]

Please see the definitions for the two different connection complete events:

LE Connection Complete event, Peer_Address_Type:

• 0x00: Peer is using a Public Device Address
• 0x01: Peer is using a Random Device Address

LE Enhanced Connection Complete event,

Peer_Address_Type:

• 0x00: Public Device Address (default)
• 0x01: Random Device Address
• 0x02: Public Identity Address (Corresponds to a resolved RPA)
• 0x03: Random (Static) Identity Address (Corresponds to a resolved RPA)

Peer_Resolvable_Private_Address:

• 0xXXXXXXXXXXXX: Resolvable Private Address being used by the peer device for this connection. This is only valid for Peer_Address_Type 0x02 and 0x03. For other Peer_Address_Type values, the Controller shall return all zeros.

Note that the LE Advertising Report, LE Directed Advertising Report, LE Extended Advertising Report, LE Scan Request Received, LE Periodic Advertising Sync Transfer Received and LE Monitored Advertisers Report events all have the same definition for the peer's address type as LE Enhanced Connection Complete event (except for LE Extended Advertising Report event which additionally has a "No address provided" option).

My interpretation of the text "If the Link Layer is using the Resolving List and the peer device has been resolved, the Address returned to the Host is the peer device’s Identity Address." in the Link Layer chapter is just briefly describing how the HCI events work for those seven different events that include resolving list functionality, i.e. that an Identity Address can be returned in the peer address field, and in that case, the 0x02 or 0x03 type option will be used, which explicitly state that these are for Identity Addresses. I don't think it is meant as a definition or requirement for the LE Connection Complete event, which apparently doesn't even list Identity Addresses as any of the options, as opposed to all other commands and events which actually support Identity Addresses.

When the Resolving List feature was added to the Bluetooth Core specification, the spec writers apparently didn't want to modify the LE Connection Complete event (maybe due to backwards compatibility), as that one is left as is, without any explicit Identity Address support. Since the text is left unmodified, I would assume the intention was to also leave the semantics unmodified, i.e. to return the raw address from the ADV_IND packet. If you read carefully through the HCI documentation, including LE commands and LE events, you can also see that the term that an address is being "used" seems to refer to the particular addresses in the actual Link Layer packets, e.g. ADV_IND and CONNECT_IND. See also how this terminology is used in the LE Connection Complete event. That terminology is not used in the Peer_Address_Type in the LE Enhanced Connection Complete event, but it is used in the Peer_Resolvable_Private_Address (which contains the address actually used in the ADV_IND packet).

Please also compare with the LE Extended Create Connection command, Peer_Address_Type:

• 0x00: Public Device Address or Public Identity Address
• 0x01: Random Device Address or Random (static) Identity Address

Also here there is a clear distinction between a "Device Address" and an "Identity Address".

During pairing, the Security Manager uses the functions f5, f6 and c1, which all take the two devices' device address used for the connection (i.e. the raw address from the ADV_IND/CONNECT_IND packets). That means that the hosts need to be aware of the address used. If the LE Connection Complete event wouldn't provide this address, but instead a resolved Identity Address, pairing cannot be performed since it is lacking this information. This could for example happen if the peripheral has removed the bond while the central has not, and the user now wants to pair these devices again. Alternatively, assume two bonded devices connect and now need to perform pairing again (e.g. if no device requested MITM protection previously, but now they do, then per GAP Figure 10.1, pairing shall be performed).

Due to all the items and hints above, I believe that it is intended and makes most sense that the LE Connection Complete event shall always return the raw address used in the ADV_IND packet and never an Identity Address corresponding to a resolved RPA.

We can see in the open-source Zephyr BLE controller that the in my opinion "wrong" semantics is being used here: https://github.com/nrfconnect/sdk-zephyr/blob/d07064e0c1c9f6b8f5c52d1ae9280b2b13894c99/subsys/bluetooth/controller/ll_sw/ull_central.c#L719 and https://github.com/nrfconnect/sdk-zephyr/blob/d07064e0c1c9f6b8f5c52d1ae9280b2b13894c99/subsys/bluetooth/controller/hci/hci.c#L8488, i.e., it will emit the Identity Address corresponding to a resolved RPA rather than the raw address used.

FYI, Nordic Semiconductor AI says "The recommended workaround is to mask the address type to use only the least significant bit, but this does not address the underlying issue of which address is reported. The correct, standards-compliant behavior is to report the raw address from the advertising packet, not the resolved identity address".