External Bonding Database#

External Bonding Database.

Receive and respond to requests related to managing an external bonding database. When the application uses the bluetooth_feature_external_bonding_database feature, the Bluetooth stack and the application use the commands and events in this class to store and retrieve data from the persistent bonding storage.

When this feature is used, the built-in bonding database (bluetooth_feature_builtin_bonding_database) and the address resolving in the Bluetooth stack are excluded. The user application and external bonding database are responsible for the following functionalities:

• The external bonding database must be able to reliably and permanently store the bonding data and type tuples that are provided by the stack in the sl_bt_evt_external_bondingdb_data_request event. Data types sl_bt_external_bondingdb_data_remote_address and sl_bt_external_bondingdb_data_remote_address_type can be used by the application to identify the device, but they are not used by the stack and hence the stack will not ask for their values. Other data types in sl_bt_external_bondingdb_data_t are needed by the Bluetooth Security Manager or GATT Server. The Long Term Keys (LTK) and Identity Resolving Keys (IRK) must be stored securely. When the database is on a separate host device, they must be securely transmitted between the host and target over the NCP transport. The application also needs to manage the bondings in the storage, e.g., delete a bonding when requested by the business logic.

• Manage a local RAM-based bookkeeping to keep track of open connections. At a minimum, the remote Bluetooth address address and address type must be stored in the bookkeeping when a sl_bt_evt_connection_opened event is received. If the remote Bluetooth device address is a resolvable private random (RPA) address, the application may perform address resolving using the IRK keys of the remote devices stored in the bonding database. Address resolving is required for identifying a connected device using an RPA address. When the scanner or periodic advertising synchronization feature is used, RPA addresses in advertisement report or sync events may need to be resolved if required by the business requirements.

• When the Bluetooth stack requires bonding data, it will send an sl_bt_evt_external_bondingdb_data_request event. The application must respond to the request by sending the data value using the sl_bt_external_bondingdb_set_data command. The GATT server will pend the requests from the remote GATT client and encryption or bonding is not possible until all requested bonding data has been sent to the stack. The stack will send sl_bt_evt_external_bondingdb_data_ready when it has received all the necessary bonding data from the application.

In this configuration, the value of bonding parameter in sl_bt_evt_advertiser_scan_request, sl_bt_evt_connection_opened, sl_bt_evt_sm_bonded, sl_bt_evt_scanner_legacy_advertisement_report, sl_bt_evt_scanner_extended_advertisement_report, sl_bt_evt_periodic_sync_opened, sl_bt_evt_pawr_sync_opened, sl_bt_evt_periodic_sync_transfer_received, and sl_bt_evt_pawr_sync_transfer_received is always SL_BT_INVALID_BONDING_HANDLE (0xff). Resolving the bonding handle is the responsibility of the external bonding database. Additionally, the following BGAPI commands are not available and will return the SL_STATUS_NOT_AVAILABLE error:

• sl_bt_sm_delete_bonding

• sl_bt_sm_get_bonding_handles

• sl_bt_sm_get_bonding_details

• sl_bt_sm_find_bonding_by_address

• sl_bt_sm_resolve_rpa

Modules#

sl_bt_evt_external_bondingdb_data_request

sl_bt_evt_external_bondingdb_data

sl_bt_evt_external_bondingdb_data_ready

0x005c0020

0x005c0020