 |
nRF51 SDK
|
|
nRF51 SDK
|
Bonding is when two devices that connect and follow procedures that allow them to cache information inorder to avoid repeating certain set-up procedures on subsequent reconnection(s).
The caching of information can span across layers in the system, for example, keys needed to secure the link on reconnection, GATT Server Configuration. Information with respect to a bonded peer is expected to be retained on power cycle of the device, and is maintained persistently.
In contrast to bonding, the Bluetooth specification defines procedure needed to establish secure link for ongoing session only, called Pairing. No information is cached for paired devices. Please refer to Volume 3 Part H, Section 6.5 of Bluetooth Core Specification 4.0 for more information.
On nRF51 devices, the nRF51 SDK provides an example module called a Bond Manager that continually stores bond and GATT Server Configuration information for a bonded peer device.
When using Bluetooth low energy, a Central device and a Peripheral device can exchange security and identification information, which can be stored and will remain after a disconnect or power cycle (for example, non-volatile memory). Known as a bond, this information is used to establish a secure link or to verify a device's identity, so when the devices reconnect they do not have to go through the initial stages like performing service discovery, configuring the descriptors again.
The Bluetooth Core Specification 4.0 states that the GATT Server configuration shall be stored for bonded devices. The Bond Manager distinguishes information that is related to bonding, Bonding Information, from the related information for the bond, System Attributes.
The Bond Manager provides whitelist maintenance which can be used to limit connections from bonded devices. The nRF51 SDK examples provide information about where using a whitelist is beneficial (such as the HID Keyboard).
The S110 SoftDevice handles the BLE on-air transactions necessary to establish a new bond (bonding procedure) or to use a previous bond (security re-establishment) when it reconnects to a bonded Central device. It is, however, up to the application layer to memorize the security and identification information between connections and power cycles and to return them to the S110 stack when it detects a reconnection from a previously bonded Central device.
In the SDK, this security and identification information is known as Bonding Information in the Bond Manager and services and profile examples that use Bond Manager.
Applications that use the bond manager can rely on it to maintain the needed information. Bonding information is added as soon as a new bond is established. On disconnect, the application should use the Bond Manager API call ble_bondmngr_bonded_centrals_store to write the latest Bonding Information and System Attributes to flash memory.
An application is provided with API needed to delete the bond or all bonds if necessary. The maximum number of bonds that the bond manager can maintain for an application is limited to BLE_BONDMNGR_MAX_BONDED_CENTRALS. The optimal number of bonds required to be maintained are very specific to use case and system requirements, therefore, BLE_BONDMNGR_MAX_BONDED_CENTRALS is a configurable define. Application developers should identify their typical or optimal number of bonded devices and configure this define accordingly.
If the application acts as a GATT server, it stores a set of persistent attributes related to bonding with a Central device. On reconnection with the bonded Central device, the application should restore the related attributes to the last known state to the S110 SoftDevice. These attributes mainly include the Client Characteristic Configuration Descriptor states.
The SDK and Bond Manager refer to these GATT attributes as System Attributes. An application using the bond manager can rely on it to maintain the System Attributes. The application can request storing the System attributes before disconnection once during a connection using ble_bondmngr_sys_attr_store API. Upon disconnection, the application should use the Bond Manager API call ble_bondmngr_bonded_centrals_store to write the latest Bonding Information and System Attributes to flash memory.
System Attributes are not restored upon connection with a bonded peer because link security needs to be established first. Once needed security is established, these attributes are restored by the bond manager.
The application is responsible for sending a bonded peer's GATT notifications, so it is important that the link is secure (encrypted) when the application begins a data transfer using GATT notifications. The application can use ble_bondmngr_is_link_encrypted to determine the encryption status and it is also notified of a BLE_BONDMNGR_EVT_ENCRYPTED event when encryption is established.
If a peer device loses its bonding information, the System Attributes are reset by the Bond Manager.
An application can use the Bonds Manager module (bond manager) included in the nRF51 SDK to handle most of the operations related to the Bonding Information and System Attributes by interfacing with the bond manager. The bond manager provides:
The bond manager notifies the application when it connects to a new bonded device or to a previously bonded device through the Asynchronous Event Notification callback. This callback is registered by the application with bond manager when initializing the module. The application can use the Bond Manager API to store or load the Bonding Information and System Attributes. The bond manager identifies all the devices the application is bonded to and restores their respective Bonding Information and System Attributes to the SoftDevice.
The bond manager automatically writes the Bonding Information to flash memory when the bonding procedure with a new device is successfully completed. On disconnect, the application should use the Bond Manager API call ble_bondmngr_bonded_centrals_store to write the latest Bonding Information and System Attributes to flash memory.
The bond manager provides the API call ble_bondmngr_sys_attr_store to allow the application to write the System Attributes to flash while in a connection. The application should call this API call when it considers that all CCCDs and other persistent attributes are in a stable state. In case all attributes are already stored, this API will return an error code indicating the same and no forced updated will be performed. This is to reduce flash access and any resulting impact on the radio.
For detailed description of the Bond Manager Application Interface please refer to section Bonds Manager.
1.8.3.1 
