Is it possible to nRF52 to direct advertise without bonding?

[Matthew K]

Hi guys. I read this thread answered by Einar Thorsrud.
devzone.nordicsemi.com/.../direct-advertising-example

"HID mouse example uses direct advertising, but only when it is bonded. In a normal use case, direct advertising only makes sense when bonded, since then you know which device you should advertise directed to."

Suppose I have an iOS/Android/nRF52 Central device and a nRF52840 board running the ble_app_hid_mouse example.
Let's assume the nRF52840 mouse knows the Central device's public address that wasn't bonded before.

(EX: I checked from iOS/Android system settings and the value is DC:37:14:36:6C:7A)

[Q] In this case, can I make the nRF52840 mouse directly advertise to DC:37:14:36:6C:7A, even though it hasn't bonded previously?

Or is this not possible to direct advertise with the nRF52 mouse since it hasn't bonded/used the whitelist, which is against the Bluetooth 5 Spec?

[Q] I heard directed advertising usually comes with high duty cycle with interval fix at 3.75ms.
Also, I heard directed advertising shouldn't be going more than a minute to comply with the Bluetooth SIG.
Is this true? Which side of the Bluetooth Core Spec defines these items?

Thanks for your help!

[Einar Thorsrud]

Hi,

Suppose I have an iOS/Android/nRF52 Central device and a nRF52840 board running the ble_app_hid_mouse example.
Let's assume the nRF52840 mouse knows the Central device's public address that wasn't bonded before.

(EX: I checked from iOS/Android system settings and the value is DC:37:14:36:6C:7A)

[Q] In this case, can I make the nRF52840 mouse directly advertise to DC:37:14:36:6C:7A, even though it hasn't bonded previously?

Or is this not possible to direct advertise with the nRF52 mouse since it hasn't bonded/used the whitelist, which is against the Bluetooth 5 Spec?

If the central does not use privacy / resolvable random address, then you can advertise directly to the device even without being bonded. However, both iOS and Android always use privacy, so in this case it will not work. The only way you can get the identity resolution key (IRK) that you need for this, is by bonding. Also, note that Apple's Accessory Design Guidelines explicitly states that:

ADV_DIRECT_IND should not be used. See the Bluetooth 4.0 specification, Volume 6, Part B, Section 2.3.1.

See more about advertising types that are recommended under 41.3 Advertising PDU on page 186 in the R18 release (currently the latest).

[Q] I heard directed advertising usually comes with high duty cycle with interval fix at 3.75ms.
Also, I heard directed advertising shouldn't be going more than a minute to comply with the Bluetooth SIG.
Is this true? Which side of the Bluetooth Core Spec defines these items?

It is possible to advertise both which high and low duty cycle, and the definition of high duty cycle is <= 3.75 ms (see page 2450 in the Bluetooth 5.3 core specification). The specification dictates that this can be used for a maximum of 1.28 seconds (see page 2464 in the Bluetooth 5.3 core specification).

[Matthew K]

Thanks Einar!

Einar Thorsrud said:

The specification dictates that this can be used for a maximum of 1.28 seconds (see page 2464 in the Bluetooth 5.3 core specification).

Does this mean nRF52's SoftDevice makes the direct advertising stop after 1.28 seconds?
Or is this the user firmware's job to stop it using the APP TIMER?

I'm asking this so I want to force the nRF52840 to direct advertise several minutes for experimental reasons (like capture more ADV_DIRECT_IND packets from the sniffer)

Einar Thorsrud said:

If the central does not use privacy / resolvable random address, then you can advertise directly to the device even without being bonded.

Then how about two nRF52840 devices where both using public addresses?
In this case, can the Peripheral nRF52840 do a direct advertising to the Central nRF52840, even though both devices never bonded?

About the example using two nRF52840 boards, may I ask some follow-up questions:
[Q] When the nRF52 peripheral is doing the direct advertisng to the nRF52 Central, can other nearby central devices request connection to the nRF52 peripheral?
In other words, can other central devices scan this nRF52 peripheral?

I want the nRF52 Peripheral reject other devices' connection request, except the specific nRF52 Central, during the direct advertising.

[Q] When the nRF52 Central is using the public address, is whitelist feature not needed because the nRF52 Peripheral doesn't need to resolve the address?

[Q] Suppose both nRF52 Peripheral anc Central used their public address during bonding.
If either nRF52 device starts advertising with a resolvable Bluetooth address, is the previous bonded data not usable since the address has changed?

Thank you so much!

[Einar Thorsrud]

Matthew K said:

Does this mean nRF52's SoftDevice makes the direct advertising stop after 1.28 seconds?
Or is this the user firmware's job to stop it using the APP TIMER?

Both. The application specified the timeout, but the SoftDevice checks if the parameters are valid. If you try to use high duty cycle directed advertising with a timeout larger than 1.28 seconds (BLE_GAP_ADV_TIMEOUT_HIGH_DUTY_MAX), you will get an NRF_ERROR_INVALID_PARAM error from the SoftDevice.

Matthew K said:

Then how about two nRF52840 devices where both using public addresses?
In this case, can the Peripheral nRF52840 do a direct advertising to the Central nRF52840, even though both devices never bonded?

Yes, in this case that will work without any problems.

Matthew K said:

[Q] When the nRF52 peripheral is doing the direct advertisng to the nRF52 Central, can other nearby central devices request connection to the nRF52 peripheral?
In other words, can other central devices scan this nRF52 peripheral?

Other BLE devices shall ignore directed advertising packets that are not meant for themselves. They are sent on air though, so a sniffer or malicious device or similar will still be able to pick up the advertising, but it cannot connect.

Matthew K said:

[Q] Suppose both nRF52 Peripheral anc Central used their public address during bonding.
If either nRF52 device starts advertising with a resolvable Bluetooth address, is the previous bonded data not usable since the address has changed?

The bond is still useful, as long as the devices exchanged IRKs during bonding. With this, the addresses can be resolved. You can see a simple explanation under Privacy in BLE here.

[Matthew K]

Thank you so much! About my previous point:

I want to force the nRF52840 to direct advertise several minutes for experimental reasons (like capture more ADV_DIRECT_IND packets from the sniffer)

Will this be possible?

Also, my whitelist question wasn't answered:

Matthew K said:

[Q] When the nRF52 Central is using the public address, is whitelist feature not needed because the nRF52 Peripheral doesn't need to resolve the address?

I want to check when whitelisting is mandatory for bonding and direct advertising.

After these, let's close this ticket. Thank you!

[Einar Thorsrud]

Hi,

Matthew K said:

I want to force the nRF52840 to direct advertise several minutes for experimental reasons (like capture more ADV_DIRECT_IND packets from the sniffer)

Will this be possible?

Yes, you can do slow directed advertising indefinitely.

Matthew K said:

[Q] When the nRF52 Central is using the public address, is whitelist feature not needed because the nRF52 Peripheral doesn't need to resolve the address?

I want to check when whitelisting is mandatory for bonding and direct advertising.

Whitelisting is never mandatory, but it is a method that prevents other centrals than those in the whitelist to connect. It is technically not relevant when using directed advertising, as in that case you advertise only to a specific peer.

Note that in other cases, whitelisting cab be equally useful when using a resolvable random (privacy) address as other address types. The technical details are a bit different, as when using privacy, the IRK is what is used in the whitelist, and in other cases the address is whitelisted directly. But the result is the same (only whitelisted peers are allowed to connect).