Device Manager

Device Manager Application Interface Abstraction.. More...

Modules
	Device Manager Sequence Charts
	Service/Protocol Types
	Describes the possible types of Service/Protocol Contexts for a bonded/peer device.
	Device Manager Events
	This section describes the device manager events to that are notified to the application.
	Device Manager Data Types
	Device Module APIs
	This section describes APIs exposed by the module.
	Device Manager Configuration
	Defines application specific configuration for Device Manager.

Detailed Description

Device Manager Application Interface Abstraction..

Device Manager Active and Bond Peers. Management of peer includes book keeping of contextual information book keeping like the Security Keys, GATT configuration and any application specific information.

Active Peers are devices which connected, and may or may not be bonded. Bonded Peers are devices which bonded, and may or may not be Active (Connected). Therefore, Active Bonded Peer refers to a device which is connected as well as bonded. Paired Devices or refers to peer devices that are connected and have necessary context establishment/exchange for the current connection session, however, on disconnection all contextual information is flushed. For example, SMP Information Exchanged during pairing, GATT Configuration etc is not retained on disconnection.

It should be noted that this module allows management of contextual information but not does provide an interface for connection management. Therefore, entering connectable mode, or connection establishment or disconnection of a link with peer is not in scope of this module.

For bonded peers, the contextual information is required to be retained on disconnection and on power cycle, persistent storage of contextual information is handled by the module. This module categorizes the contextual information into 3 categories:

• Bonding Information This information is the information exchanged between local and peer device to establish a bond. This information also includes peer identification information, like the peer address or the IRK or both. From here on this category of information is referred to as Device Context.
• Service/Protocol Information This information is the information retained for the peer to save on one-time procedures like the GATT Service Discovery procedures, Service Configurations etc, allowing devices to resume data exchange on subsequent reconnection without having to perform initial set-up procedures each time. From here on this category is referred to as Service Context.
• Application Information This information is the context that the application would like to associate with each of the bonded device. For example, if application chooses to rank its peers in order to manage them better the rank information could be treated as Application Information. This provision is provided to save the application from maintaining a mapping table with each Device Instance and Application Information. However, if application have no use case to make use of this, it is possible to not use or employ this at compile time. From here on this category of information is referred to as Application Context.