[nRF Connect SDK] Make ble connectable only for multiple paired(bonded) devices

[Tim Hwang]

Target nRF52832(nrf52dk_nrf52832)
SDK NCS v1.9.1

Base source
1. C:\Users\user\ncs\v1.9.1\nrf\samples\bluetooth\peripheral_hids_keyboard
2. C:\Users\user\ncs\v1.9.1\nrf\samples\bluetooth\peripheral_uart

My project require two mode(HID and NUS).
I made new project that support two mode.(User can select mode, and each mode will begin at boot time).

-----------------------------------------------------------------------------------------------------
My project used BT classic. So it can be acceptable for incoming connection regarding paired(bonded) device without discoverable option.
BLE protocol as peripheral role does not allow to accept incoming connection without advertise.
My question is following scenario is possible.

1. Make bonding with serveral other devices(Android, iOS or Windows). (CONFIG_BT_MAX_PAIRED=4)
2. Reboot BLE device(nordic)
3. BLE begin to advertise only for paired devices. (I found we could add paired list into advertise information)
4. Keep advertise until one of paired devices try to connect.
5. Accept incoming connection.
6. If BLE disconnected, BLE begin to advertise again. (Only for paired)
7. If BLE want to pair another device, BLE stop advertise and begin to advertise without paired list.
8. Make pairing for new device.

My customer use several our BLE product at the same time, so please review if my scenario is possible.
Thanks.

[Edvin]

Hello,

Yes, this is possible (and the common way to do things). 

I have not looked that much into this in NCS before, but it looks like the ble_adv_start() function found in NCS(v1.9.1)\nrf\subsys\caf\modules\ble_adv.c (caf - common application framework are just samples on how to use particular modules) is one way to do this. Look at how it uses ble_adv_start_directed() and ble_adv_start_undirected().

I don't see a way to temporary disable the whitelist, so you would need to clear the list if you want to advertise without a whitelist, and store the addresses and reapply them later.

I know that this is counterintuitive, but I would be surprised if it is not possible to make the bond manager handle this for you. I will have to look into it a bit more (but I wanted to answer you before too much time passed).

The list that you describe is very easy to do in the nRF5 SDK, so I would be surprised if there aren't any libraries that does this in NCS (I am just not aware of them yet). I would look into the peripheral_uart sample, and look at the settings module (BT_SETTINGS is the module handling bonding).

BR,

Edvin

[Tim Hwang]

Thanks for updating. I will test ble_adv_start_directed() then reply you.

[Update]

1. ble_adv_start_directed()
To use ble_adv_start_directed() in ble_adv.c, I have to call ble_adv_start() in ble_adv.c.
My base source(peripheral_hids_keyboard, peripheral_uart) never call ble_adv_start().
I cannot call ble_adv_start() in app level directly.

2. Similary peer list sample
"ncs/v1.9.1/nrf/samples/bluetooth/peripheral_nfc_pairing"
Above sample shows how I add peer list into adv param.
It works if peer is working, but if peer is turned off, That sample fail to connect and never start advertise again.
(I received connected but actually disconnected.

If I force to advertise again, BLE connected -> disconnect -> advertise -> connected -> ...)

C:\Users\user\ncs\v1.9.1\nrf\samples\bluetooth\peripheral_nfc_pairing\src\main.c

static void advertising_continue(void)
{
struct bt_le_adv_param adv_param;

bt_addr_le_t addr;

if (!k_msgq_get(&bonds_queue, &addr, K_NO_WAIT)) {
char addr_buf[BT_ADDR_LE_STR_LEN];

adv_param = *BT_LE_ADV_CONN_DIR(&addr);
adv_param.options |= BT_LE_ADV_OPT_DIR_ADDR_RPA;

int err = bt_le_adv_start(&adv_param, NULL, 0, NULL, 0);

if (err) {
printk("Directed advertising failed to start\n");
return;
}

bt_addr_le_to_str(&addr, addr_buf, BT_ADDR_LE_STR_LEN);
printk("Direct advertising to %s started\n", addr_buf);
}
...
}

So plesae let me have any sample. and tell me if my scenario is possible.

[Edvin]

Hello,

I found the advertising option that you should use. 

You can use BT_LE_ADV_OPT_DIR_ADDR_RPA, as this allows for resolvable private addresses. You may also use the option BT_LE_ADV_OPT_FILTER_CONN, which enables the filter accept list (former known as whitelist). And this option you can disable to allow new connections to be established. 

In order to stack options you just do like this:

adv_param.options |= BT_LE_ADV_OPT_DIR_ADDR_RPA;
adv_param.options |= BT_LE_ADV_OPT_FILTER_CONN;

For a list of all possible options, plesae see bluetooth.h line 329 (at least in NCSv1.9.1): /** Advertising options */.

Best regards,

Edvin

[Tim Hwang]

Thanks for reply.

00> advertising_continue bond(1)
00> Direct advertising to 00:16:7F:3A:FB:03 (public) started
00> Direct advertising to 00:16:7F:3A:FB:03 (public) timed out
00> advertising_continue bond(1)
00> Direct advertising to 00:16:7F:3A:FB:03 (public) started
00> Direct advertising to 00:16:7F:3A:FB:03 (public) timed out
00> advertising_continue bond(1)
00> Direct advertising to 00:16:7F:3A:FB:03 (public) started
00> Direct advertising to 00:16:7F:3A:FB:03 (public) timed out
00> advertising_continue bond(1)

Q1) I manage to keep advertise. How can I increase timeout figure? Timeout is very short. it seems under 100ms. 

Q2) In my study, I can only one peer address for advertise, right?

[Edvin]

Tim Hwang said:

In my study, I can only one peer address for advertise, right?

No, the purpose of the whitelist (now called filter_accept_list) is that you can add multiple devices to that list, and then enable the whitelist using the adv_param.options |= BT_LE_ADV_OPT_FILTER_CONN;

Note that there is a difference between directed advertising and whitelisted advertising. Directed advertisements are usually used when you just disconnected from a device, usually due to noise or increased distance. Then you will advertise quite fast (short advertising interval) just to the device you disconnected from. I think the specification says that this kind of directed advertising only can go on for a given amount of time, which is quite short.

Whitelisted advertising, however, means that you will accept connection requests from any device in the whitelist (typically devices that you have connected to, and bonded with before. Based on your description, this is what you want to use, and not directed advertising. 

(I know I told you to look into the directed and undirected advertisements in nrf\subsys\caf\modules\ble_adv.c, but this was before I knew what I know now. I jus tsaw that they cleared the filter accept list, and then added addresses back in using bt_le_filter_accept_list_add(), but this was before I knew that you needed to enable the whitelist in your advertisements using the BT_LE_ADV_OPT_FILTER_CONN.

So to add devices to your whitelist, use bt_le_filter_accept_list_add(), and when you want to use the whitelist in your advertisements, you need to use the adv_param.options |= BT_LE_ADV_OPT_FILTER_CONN, and when you want to allow new connections, you don't use the option BT_LE_ADV_OPT_FILTER_CONN.

Best regards,

Edvin

[Tim Hwang]

Thank you for your kind reply.

1. What I'm expecting is..
Only bonded devices(>= 2) can see advertise. The others cannot find BLE device until ble device begin regular advertise(no peer list). One of them try to connect, it will be connected.(accepted)

2. Whitelist
I don't know Whitelist exactly. However from your comments, whitelist feature is allowed to incoming connection for specific central devices. And all central device can see advertise, right? Or please let me know.

3. In my product scenario..
If a user can see Nordic BLE but Android cannot connect it due to any policy, it will be more important issue. because they probably cannot understand such scenario.

My scenario looks like BT classic. My product have used BT classic chipset.
Last year my product replace it from BT classic to BLE device.
As you know, BT classic have connectable and discoverable properties.
Without discoverable, it can make connection unlikely BLE.

I'm wondering if BLE can do similar scenario. 

[Edvin]

Tim Hwang said:

1. What I'm expecting is..
Only bonded devices(>= 2) can see advertise. The others cannot find BLE device until ble device begin regular advertise(no peer list). One of them try to connect, it will be connected.(accepted)

Not exactly. All devices can see advertisements, but most central devices will ingore advertisements that are using a whitelist (it is a flag inside the advertisement), and the scanner is not known for the device.

Tim Hwang said:

2. Whitelist
I don't know Whitelist exactly. However from your comments, whitelist feature is allowed to incoming connection for specific central devices. And all central device can see advertise, right? Or please let me know.

Same on 1)

Tim Hwang said:

3. In my product scenario..
If a user can see Nordic BLE but Android cannot connect it due to any policy, it will be more important issue. because they probably cannot understand such scenario.

Phones will typically ignore devices which it knows it can't connect to (whitelist/directed advertisement). So for an end user this is typically not a problem.

Tim Hwang said:

My scenario looks like BT classic. My product have used BT classic chipset.
Last year my product replace it from BT classic to BLE device.
As you know, BT classic have connectable and discoverable properties.
Without discoverable, it can make connection unlikely BLE.

I am actually not that familiar with BT Classic. But if you mean that you can connect to different properties in Classic, that is not the case in BLE, but I am not sure I understood this question.

Best regards,

Edvin

[Tim Hwang]

Thanks for updating. I understand whitelist somehow.
I'll do whitelist API with Android and Windows PC. 

[Update]
I did whitelist test. I refered follwing case.
devzone.nordicsemi.com/.../ncs-zephyr-how-to-enable-whitelist

Changes:
1) Prj.conf
CONFIG_BT_FILTER_ACCEPT_LIST=y
2) Add whitelist when make bonding .
bt_le_whitelist_add(..)

#define BT_LE_ADV_WLIST_CONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE|BT_LE_ADV_OPT_FILTER_CONN, \
BT_GAP_ADV_FAST_INT_MIN_2, \
BT_GAP_ADV_FAST_INT_MAX_2, NULL)

err = bt_le_adv_start(discoverable ? BT_LE_ADV_CONN : BT_LE_ADV_WLIST_CONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));

Result
Adding whitelist is done. In case whitelist is enabled, Android can find BLE, but cannot make connection. Or it worked normally.(pairing&connecting)

Bluebird_ab:cd:a0: Nordic BLE
55:55:0f:28:d1:a4: Android

From this test, I would say BLE cannot advertise only for paired (bonded) devices only, right?
If yes, it is official announcement to our customers.

[Edvin]

Tim Hwang said:

From this test, I would say BLE cannot advertise only for paired (bonded) devices only, right?

What do you mean by this?

Advertisements are never encrypted, so it is not possible to advertise so that certain devices "doesn't see it". However, most devices will not display whitelisted/directed advertisements to the user if they are not bonded with the device. However, if you used nRF Connect for Android to connect to this device, it will show you all advertising devices. 

Did you see your device in the phone's bluetooth settings?

BR,

Edvin