BLE bonding

[Roei]

Hi,

As far as I understand, every connection establishment has to start with advertising.

Event if I have already connected and bonded to a peer, after disconnection I have to start advertising in order to connect to this peer again.

Am I right?

In that case - what is the meaning of bonding here? Shouldn't the peers connect automatically again without advertising/direct advertising? Do I have another option?

Thanks!

[Einar Thorsrud]

Hi,

As far as I understand, every connection establishment has to start with advertising.

Yes, that is correct. This is a key concept of the BLE protocol. The peripheral advertises regularly, and in case of connected advertising, it will switch the radio to Rx and listen for connection requests from a central in a short window after transmitting the advertising packet. This is how BLE connections are established.

Event if I have already connected and bonded to a peer, after disconnection I have to start advertising in order to connect to this peer again.

Am I right?

Yes pairing and bonding is independent of the connection mechanism.

In that case - what is the meaning of bonding here? Shouldn't the peers connect automatically again without advertising/direct advertising?

No, that would not be possible. When the peripheral is not advertising or in a connection it is typically in sleep, with the radio completely turned off. So there would be no way to connect to it. Pairing is a completely different concept, which is how devices exchange encryption keys (used both for encrypting the link and optionally randomizing the address to that it cannot be tracked even though it advertises). Bonding is the same thing, the only difference is that when bonding, the peers agree to store the keys to be used for later.

Do I have another option?

Not really. Dependign on your use case you may not need to bond, but there is no way around advertising to initiate a connection, regardless of if bonded or not.

[Roei]

Thanks for your answer!

I will be more specific. My use case is that I want to connect and bond my NRF device with my mobile. After turning off and on the device and mobile, I want them to connect again.

Until now, I did it with direct advertising. I saved the mobile's address after bonding when they first connected, so I will use it for direct advertising when my NRF device is turned on again.

The problem is that my mobile changes it's address. I read some articles about that privacy feature. Do you know that?

What can I do about that? How can I reconnect to a mobile which changed it's address?

Thanks!

[Einar Thorsrud]

Hi,

I see. You could start advertising normally, and then restart, or slightly adjust the advertising module.

The resone calling ble_advertising_restart_without_whitelistadvertising() did not work is that the module only supports restarting advertising in the same mode, and when advertising is not active the mode is IDLE. If you want to start advertising without whitelist you could expand the library with a ble_advertising_start_without_whitelist() function like this:

uint32_t ble_advertising_start_without_whitelist(ble_advertising_t * const p_advertising,
                                                 ble_adv_mode_t            advertising_mode)
{
    ret_code_t ret;

    p_advertising->whitelist_temporarily_disabled = true;
    p_advertising->whitelist_in_use               = false;
    p_advertising->adv_params.filter_policy       = BLE_GAP_ADV_FP_ANY;
    // Set correct flags.
    ret = flags_set(p_advertising, BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE);
    VERIFY_SUCCESS(ret);

    ret = ble_advertising_start(p_advertising, advertising_mode);
    if ((ret != NRF_SUCCESS) && (p_advertising->error_handler != NULL))
    {
        p_advertising->error_handler(ret);
    }

    return NRF_SUCCESS;
}

The only difference from the restart variant is that it does not stop advertising, and it uses the specified mode instead of the current mode. Calling this function instead of ble_advertising_start() will do the trick.

[Roei]

Thanks a lot!

One more question - 

I'm still confused about the difference between pm_whitelist_set and pm_device_identities_list_set. Can you please explain what does each of them do?

[Einar Thorsrud]

Hi,

The device identities list is a list of device IRK's (Identity resolution keys). So that is needed for whitelisting peers that use privacy (which include any modern phone). Whitelisting static MAC addresses only work with devices that do not use privacy. Therefore, you will need code for both to handle both cases, like it is done in the SDK examples.

[Roei]

Thanks, you helped me a lot!

I still don't understand how exactly the IRK works. Can you give me an example, how the first peer can recognize the second peer, using IRK, after the second one changed it's address?

[Einar Thorsrud]

The IRK is Identity Resolving Key, which gives a hint. When a device using a resolvable address changes the address, that is derived from the IRK. And it is also possible to do the reverse: check an address to see if it has been derived from a specific IRK, which is done by the peer that has the IRK after bonding. The exact details of how the resolution works is black magic to me (cryptography), but there is no need to understand the math in order to use it.