Bond Management Service

Revision: v1.0.1
Revision Date: 2022-01-18
Group Prepared By: Medical Devices Working Group

Revision History

Revision Number	Date (yyyy-mm-dd)	Comments
V1.0.0	2014-Oct-21	Adopted by the Bluetooth SIG BoD
v1.0.1	2022-01-18	Adopted by the Bluetooth SIG Board of Directors.

Version History

Versions	Changes
v1.0.0 to v1.0.1	Incorporated errata E15767, E16242, E17148.

Acknowledgments

Name	Company
Wolfgang Heck	Roche Diagnostics
Rasmus Abildgren	Samsung Electronics
Leif-Alexandre Aschehoug	Nordic
Jordan Hartmann	Nonin Medical, Inc.
Nathaniel Hamming	University Health Network

Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.

Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”

Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.

Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.

Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.

Copyright © 2013–2022. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.

1. Introduction

1.1. Scope

Many Bluetooth devices have the ability to store bond information of the connection. Equally many Bluetooth enabled peripherals does not have a rich UI which can make debonding an unpleasant experience for end users with pushing and holding buttons. This service defines how a peer Bluetooth device can manage the storage of bond information, especially the deletion of it, on the Bluetooth device supporting this service. This enables that a Bluetooth device with a rich UI can be used for bond management of a Bluetooth device with a limited or even no UI.

1.2. Conformance

If conformance to this specification is claimed, all capabilities indicated as mandatory for this specification shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated.

1.3. Service Dependencies

This Service has no dependencies to other GATT-based services.

1.4. Bluetooth Specification Release Compatibility

This service is compatible with any Bluetooth core specification host that includes the Generic Attribute Profile (GATT).

1.5. GATT Sub-Procedure Requirements

Additional GATT Sub-Procedure requirements beyond those required by the GATT are indicated below.

GATT Sub-Procedure	Requirements
Write Characteristic Value	M
Write Long Characteristic Values	C1
Reliable Writes	O

Table 1.1. GATT Sub-Procedure Requirements

C1:: Mandatory if operand longer than MTU is requested, else optional

1.6. Transport Dependencies

This service may operate over LE and BR/EDR transports.

Where the term BR/EDR is used throughout this document, this also includes the optional use of AMP.

1.7. Error Codes

This service defines the following Attribute Protocol Error codes:

Name	Error Code	Description
Op Code not supported	0x80	Response if unsupported Op Code is received
Operation failed	0x81	Response if unable to complete a procedure for any reason

Table 1.2. Error Codes

1.8. Byte Transmission Order

All characteristics used with this service shall be transmitted with the least significant octet first (i.e., little endian). The least significant octet is identified in the characteristic definitions in [1].

2. Service Declaration

The Bond Management Service is recommended to be instantiated as a «Primary Service» and the service UUID shall be set to «Bond Management Service». The UUID value assigned to «Bond Management Service» is defined in [2].

3. Service Characteristics

The characteristic requirements in an instance of the Bond Management Service are shown in Table 3.1. Only one instance of each characteristic is permitted within this service.

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Bond Management Control Point	M	Write	Extended Properties (Reliable Write)	authentication required
Bond Management Feature	M	Read	Indicate C.1	authentication required

Characteristic Name

Requirement

Mandatory Properties

Optional Properties

Security Permissions

Bond Management Control Point

Write

Extended

Properties (Reliable Write)

authentication required

Bond Management Feature

Read

Indicate C.1

authentication required

Table 3.1. Bond Management Service characteristics

C.1:: The Indicate property shall be supported for the Bond Management Feature characteristic if the value of the Bond Management Feature characteristic can change over the lifetime of the device, otherwise Excluded for this service.
Notes:: Properties not listed as Mandatory or Optional are Excluded.

3.1. Bond Management Control Point

The Server shall evaluate a GATT Characteristic Value Write procedure or a GATT Characteristic Value Reliable Write procedure to the Bond Management Control Point and accept the request according to the rules specified in Section 3.1.2.1.

The Bond Management Control Point characteristic is identified using the UUID «Bond Management Control Point», as defined in [2].

The format of the Bond Management Control Point characteristic is defined in Table 3.2.

LSO		MSO
	Op Code (see Table 3.3)	Parameter (see Table 3.3)
Byte Order	N/A	LSO...MSO
Data type	UINT8	Variable
Size	1 octet	0 to 511 octets
Units	None	None

Table 3.2. Bond Management Control Point Characteristic Format

The Op Codes, the Parameters and the requirements for the User Control Point are defined in Section 3.1.1.

3.1.1. Bond Management Control Point Procedures

The table below shows the Bond Management Control Point (BMCP) procedures (Op Codes and Operands) in the context of this service:

Op-code	Requirement	Definition	Parameter Value	Description
0x00	N/A	Reserved for future use	N/A	N/A
0x01	C.1	Delete bond of requesting device (BR/EDR and LE)	Authorization Code (optional)	Initiates the procedure to delete bonds of requesting device on BR/EDR and LE transports. The optional Authorization Code is sent as parameter to this op code.
0x02	C.2	Delete bond of requesting device (BR/EDR transport only)	Authorization Code (optional)	Initiates the procedure to delete bond of requesting device on BR/EDR transport. The optional Authorization Code is sent as parameter to this op code.
0x03	C.3	Delete bond of requesting device (LE transport only)	Authorization Code (optional)	Initiates the procedure to delete bond of requesting device on LE transport. The optional Authorization Code for that is sent as parameter to this op code.
0x04	C.4	Delete all bonds on server (BR/EDR and LE)	Authorization Code (optional)	Initiates the procedure to delete all bonds of the device on BR/EDR and LE transport. The optional Authorization Code is sent as parameter to this op code.
0x05	C.5	Delete all bonds on server (BR/EDR transport only)	Authorization Code (optional)	Initiates the procedure to delete all bonds of the device on BR/EDR transport. The optional Authorization Code is sent as parameter to this op code.
0x06	C.6	Delete all bonds on server (LE transport only)	Authorization Code (optional)	Initiates the procedure to delete all bonds of the device on LE transport. The optional Authorization Code is sent as parameter to this op code.
0x07	C.4	Delete all but the active bond on server (BR/EDR and LE)	Authorization Code (optional)	Initiates the procedure to delete all bonds but the requesting device on BR/EDR and LE transport. The optional Authorization Code is sent as parameter to this op code.
0x08	C.5	Delete all but the active bond on server (BR/EDR transport only)	Authorization Code (optional)	Initiates the procedure to delete all bonds but the requesting device on BR/EDR transport. The optional Authorization Code is sent as parameter to this op code.
0x09	C.6	Delete all but the active bond on server (LE transport only)	Authorization Code (optional)	Initiates the procedure to delete all bonds but the requesting device on LE transport. The optional Authorization Code is sent as parameter to this op code.
0x0A - 0xFF	N/A	Reserved for future use	N/A	N/A

Table 3.3. BMCP Procedure Requirements

C.1:: If device supports transport over BR/EDR and LE (dual mode) to the same device, this Op code is mandatory otherwise excluded
C.2:: If device supports transport over BR/EDR this Op Code is mandatory otherwise excluded
C.3:: If device supports transport over LE this Op Code is mandatory otherwise excluded.
C.4:: If device supports transport over BR/EDR and LE (dual mode), this Op code is optional otherwise excluded
C.5:: If device supports transport over BR/EDR this Op Code is optional otherwise excluded
C.6:: If device supports transport over LE this Op Code is optional otherwise excluded.

3.1.2. Bond Management Control Point Behavioral Description

When the Bond Management Control Point characteristic is written using the allowed GATT Characteristic Value Write sub-procedures with one of the supported op codes (???), the server shall evaluate request according to Section 3.1.2.1.

The implementation may additionally require an authorization code for execution.

The support of the procedure and the required authorization is defined in the Bond Management Features characteristic in Section 3.2.

Where used, the format of the Authorization Code value is an UTF-8 string of variable size up to a length of 511, where each character represents one digit of the Authorization Code.

3.1.2.1. General Procedure Evaluation Criteria

When the Server receives an op code with a procedure request, the request shall be evaluated before the ATT Write Response is sent. The response with success shall be sent only if the requested control point procedure criteria are met. Otherwise, an ATT Error Response should be send where the error code returned should be with the following priority:

If the Op Code doesn’t fit the transportation requirements (e.g. an Op Code valid for BR/EDR transport is written to a single mode LE device) or the Op Code is not supported on the device, the Server shall return an error response with the Attribute Application Error Code set to "Op Code not supported" as defined in Section 1.7.
The Server may request an additional authorization code and/or confirmation on its UI (if present). The authorization code is supplied as an operand to the op code, and the Server shall compare it with the required authorization string. If the operand doesn’t match the required authorization string and/or a negative confirmation from the UI is received, the Server shall return an error response with the Attribute Protocol Error Code set to "Insufficient Authorization".If for any other reason the control point procedure will not be successful the Server shall return an error response with the Attribute Application Error Code set to "Operation Failed" as defined in Section 1.7.

If the evaluation is successful the server shall perform the requested procedure.

3.1.2.2. Delete Bond of Requesting Device Procedures

When one of the "Delete bond of requesting device" Op Codes is written to the Bond Management Control Point, the Server shall delete the bond information of the requested device's transport(s) from its database after the requested transport no longer are active to the requesting device.

3.1.2.3. Delete all Bonds Procedures

When one of the "Delete all bonds" Op Codes is written to the Bond Management Control Point, the Server shall delete the bond information of all devices of the requested transport(s) from its database after the requested transport(s) no longer are active to the requested devices.

3.1.2.4. Delete Bond of All Except the Requesting Device Procedures

When one of the "Delete Bond of All Except the Requesting Device " Op Codes is written to the Bond Management Control Point, the Server shall delete the bond information of all except the requesting device of the requested transport(s) from its database after the requested transport(s) no longer are active to the requested devices.

3.2. Bond Management Feature

The Bond Management Feature characteristic shall be used to indicate the supported features of the server. If the service claim support for the corresponding procedure, it shall set the supported bit. The format of the Bond Management Feature characteristic is defined in Table 3.4.

LSO	MSO
	Feature (see Table 3.5)
Byte Order	LSO...MSO
Data type	Bit Field
Size	Variable
Units	None

Table 3.4. Bond Management Feature Characteristic Format

The characteristic value is a bit field where every bit shall be set according to Table 3.5.

The BM Feature characteristic shall be static during a connection.

Bit	Octet	BM Feature Bit Description
0	0	Delete bond of requesting device (BR/EDR and LE)
1	0	Delete bond of requesting device (BR/EDR and LE) with authorization code
2	0	Delete bond of requesting device (BR/EDR transport only)
3	0	Delete bond of requesting device (BR/EDR transport only) with authorization code
4	0	Delete bond of requesting device (LE transport only)
5	0	Delete bond of requesting device (LE transport only) with authorization code
6	0	Delete all bonds on server (BR/EDR and LE)
7	0	Delete all bonds on server (BR/EDR and LE) with authorization code
0	1	Delete all bonds on server (BR/EDR transport only)
1	1	Delete all bonds on server (BR/EDR transport only) with authorization code
2	1	Delete all bonds on server (LE transport only)
3	1	Delete all bonds on server (LE transport only) with authorization code
4	1	Delete bond of all except the requesting device on the server (BR/EDR and LE)
5	1	Delete bond of all except the requesting device on the server (BR/EDR and LE) with authorization code
6	1	Delete bond of all except the requesting device on the server (BR/EDR transport only)
7	1	Delete bond of all except the requesting device on the server (BR/EDR transport only) with authorization code
0	2	Delete bond of all except the requesting device on the server (LE transport only)
1	2	Delete bond of all except the requesting device on the server (LE transport only) with authorization code
Any other bit	N/A	Reserved for future use

Table 3.5. Bond Management Feature Bit Allocation and their static requirements

Reserved for future use (RFU) bits in the Bond Management Feature characteristic value shall set be to 0.

3.2.1. Bond Management Feature Characteristic Behavior

When read or indicated, the BM Feature characteristic gives a value that is used by a client to determine the supported features of the server. The server shall only include the number of octets needed for returning the highest set feature bit. I.e., if the supported bit 0 octet 0 and bit 1 octet 2 is set, the server shall return the 3 first octets. The client will be prepared to receive a value larger than the current 3 octets defined and will ignore bits it does not understand.

When the Client Characteristic Configuration descriptor is configured for indications and the supported features of the server have changed, the Bond Management Feature characteristic shall be indicated to any bonded Collectors after reconnection.

Example:

If a device supports the "Delete all bonds on server (LE transport only)" feature, bit 2 octet 1 of the Bond Management Feature characteristic shall be set to 1, otherwise bit 2 octet 1 of the Bond Management Feature characteristic shall be set to 0.

4. SDP Interoperability

If this service is exposed over BR/EDR, then it shall have the following SDP record.

Item	Definition	Type	Value	Status
Service Class ID List				M
Service Class #0		UUID	«Bond Management Service»	M
Protocol Descriptor List				M
Protocol #0		UUID	L2CAP	M
Parameter #0 for Protocol #0	PSM	Uint16	PSM = ATT	M
Protocol #1		UUID	ATT	M
BrowseGroupList				M

Table 4.1. SDP Record

5. Acronyms and Abbreviations

Abbreviation or Acronym	Meaning
BM	Bond Management
BMCP	Bond Management Control Point
BR/EDR	Basic Rate / Enhanced Data Rate
PSM	Protocol Service Multiplex

Table 5.1. Example Abbreviations and Acronyms

6. References

This section provides references for all documents mentioned within the specification, including complete title, author/publisher, date, and document number (where applicable). References are numbered in the form [1], and referenced from the text using hyperlinks. It is allowed use undated references if explanatory notes are provided (e.g., “version 1.1 or later,” “latest version applies”).