Experimental: Peer Manager

The BLE Peer Manager can be used by applications to manage BLE security (encryption, pairing, and bonding). It uses flash storage to persistently store bonding information and GATT data for each peer device that it is bonded with. The Peer Manager handles the different BLE security procedures as required by the Bluetooth Specification, which makes it easy to create compliant applications.

The Peer Manager replaces the existing BLE Device Manager. The main functionality is the same, but the following major improvements make it profitable to switch to the Peer Manager:

• Support for multiple roles: The Device Manager supports both the central and the peripheral role, but the role must be decided at compile time. The Peer Manager is role-agnostic and supports the central and the peripheral role simultaneously.
• Flash Data Storage: The Peer Manager uses the Experimental: Flash Data Storage (FDS) module instead of the Persistent Storage Manager. FDS is less prone to data corruption and focuses on minimal write and delete operations. These improvement are most significant for the nRF52 IC.
• Autonomy: The Peer Manager works more autonomously than the Device Manager; for example, it automatically responds to security requests and has an in-built error recovery process. If the SoftDevice or the FDS reports a temporary failure, the Peer Manager will retry the calls and will report only permanent failures.
• Ease of use: Because of the high degree of autonomy, the Peer Manager API is easy to use and less susceptible to small user errors.
• Modularity: The Peer Manager is designed in a modular way. This modularization makes it easy to maintain, test, and extend with new features.
• Caching of GATT attributes: In addition to storing the CCCD values for all bonded peers (as all GATT servers are required to by the Bluetooth Specification), the Peer Manager can also cache GATT attribute information of remote GATT servers. Caching the remote database reduces the required packet exchange and therefore conserves energy.
• Distribution of service changed indications: When a GATT database changes, the Peer Manager can distribute the service changed indication to all bonded peers. The application must notify the Peer Manager every time it changes its database.
• Resolution of random device addresses: The Peer Manager includes functionality to resolve random resolvable private addresses using Identity Resolving Keys (IRKs).

Note

The Peer Manager is currently in experimental state and should therefore not be used in production. However, if you currently use the Device Manager in an application, you should consider switching to the Peer Manager. The Peer Manager will replace the Device Manager in the future, and new features will be added only to the Peer Manager. If you have suggestions and feedback about the experimental implementation, post them on the Nordic Developer Zone.

See Architecture for an overview of the different modules that make up the Peer Manager. Functionality explains the API functions that are available, and Usage presents code examples and shows how to use the Peer Manager in an application. Migrating to Peer Manager points you to detailed instructions for updating your application that uses the Device Manager to use the Peer Manager.