-
Revision: v1.0.1
-
Revision Date: 2022-01-18
-
Group Prepared By: Medical Devices Working Group
Revision History
|
Revision Number |
Date |
Comments |
|---|---|---|
|
v1.0 |
2017-Dec-05 |
Adopted by the Bluetooth SIG Board of Directors. |
|
v1.0.1 |
2022-01-18 |
Adopted by the Bluetooth SIG Board of Directors. |
Version History
|
Versions |
Changes |
|---|---|
|
v1.0 to v1.0.1 |
Incorporated errata E15808, E16487. |
Acknowledgments
|
Name |
Company |
|---|---|
|
Wolfgang Heck |
F. Hoffmann-La Roche AG |
|
Felix Bootz |
F. Hoffmann-La Roche AG |
|
Leif-Alexandre Aschehoug |
Nordic Semiconductor |
|
Craig Carlson |
F. Hoffmann-La Roche AG |
|
Laurence Richardson |
Qualcomm Technologies International, Ltd. |
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 © 2015– 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
The Reconnection Configuration (RC) Profile allows a device like a CGM client to modify connection parameters for the current connection (and future connections of these devices), and when used with the Low Energy transport, it may modify the advertising parameters for future advertising events of a CGM server device. This profile also enables the client device to get information about the current connection parameter settings.
Along with modifications to connection parameters, this profile also introduces the following parameters for the timing of advertisements: Advertisement Count and Advertising Repetition Time.
These new advertising parameters allow devices to synchronize their communication efforts and thereby reduce messaging and power consumption.
 |
1.1. Profile dependencies
This profile is compatible with any Bluetooth Core Specification host that includes the Generic Attribute Profile (GATT).
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. Language
1.3.1. Language conventions
The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, is, and note in the development of specifications:
|
shall |
is required to – used to define requirements. |
|
must |
is a natural consequence of – used only to describe unavoidable situations. |
|
will |
it is true that – only used in statements of fact. |
|
should |
is recommended that – used to indicate that among several possibilities one is recommended as particularly suitable, but not required. |
|
may |
is permitted to – used to allow options. |
|
can |
is able to – used to relate statements in a causal manner. |
|
is |
is defined as – used to further explain elements that are previously required or allowed. |
|
note |
Used to indicate text that is included for informational purposes only and is not required in order to implement the specification. Informative text in a note continues to the end of the paragraph. |
For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.
Certain terms used in this specification have been updated and are no longer used by Bluetooth SIG. For a list of terms that have been updated and their replacement terms, see the Appropriate Language Mapping Table [5].
1.3.2. Reserved for Future Use
Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.
Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.
When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.
The acronym RFU is equivalent to Reserved for Future Use.
1.3.3. Prohibited
When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.
Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.
“Prohibited” is never abbreviated.
1.4. Bluetooth Core Specification release compatibility
This specification is compatible with any Bluetooth Core Specification that includes the Generic Attribute Profile (GATT) portion of the Core Specification. Nevertheless there are some optional features of this profile that require a higher version of the Bluetooth Core Specification. These requirements are described in the relevant section of this specification.
2. Configuration
2.1. Roles
The profile defines two roles: Reconnection Configuration Server and Reconnection Configuration Client. The Reconnection Configuration Server is the device whose communication parameters will be controlled by the Reconnection Configuration Client.
The Reconnection Configuration Server shall be a GATT Server.
The Reconnection Configuration Client shall be a GATT Client.
2.2. Service/profile role relationships
The following diagram shows the relationships between service and profile roles:
 |
Note
Note: Profile roles are represented by blue boxes, and the service roles are represented by gray boxes.
The Reconnection Configuration Profile is a generic profile that is intended to be referenced by another (higher level) profile specification (in Figure 2.1, the dependency of the higher level profile specification is illustrated as an example with two other services, named Other Service 1 and Other Service 2.).
2.3. Concurrency limitations/restrictions
There are no concurrency limitations or restrictions for the Reconnection Configuration Client or Reconnection Configuration Server roles imposed by this profile.
2.4. Topology limitations/restrictions
There are no topology limitations or restrictions when the profile is used over the LE transport.
2.5. Transport dependencies
This version of profile shall operate over an LE transport only. The functionalities specified are mostly dependent on the Link Layer and therefore a different handling is required when using BR/EDR transport.
3. Reconnection Configuration Server Role requirements
The following table describes support of the Reconnection Configuration Server, which shall instantiate one and only one instance of the Reconnection Configuration Service.
|
Service |
<server role> |
|---|---|
|
Reconnection Configuration Service |
M |
|
Bond Management Service |
C.1 |
- M:
-
Mandatory
- C.1:
-
Mandatory if Upgrade to LESC is supported or Next Pairing OOB is supported, otherwise Optional.
3.1. Incremental Reconnection Configuration Service requirements
3.1.1. Additional requirements for Low Energy transport
3.1.1.1. Service UUIDs AD Type
While in a GAP Discoverable Mode for initial connection to a Reconnection Configuration Client, the Reconnection Configuration Server may include the Reconnection Configuration Service UUID defined in [3] in the Service UUIDs AD type field of the Advertising Data or Scan Response Data.
3.2. Incremental Bond Management Service requirements
The table below shows the requirements defined in the Bond Management Service.
|
Bond Management Service Characteristic |
Requirement |
|---|---|
|
Bond Management Control Point |
M |
|
Bond Management Features |
M |
- M:
-
Mandatory
4. Reconnection Configuration Client role requirements
The following table describes support of the Reconnection Configuration Client requirements:
|
Service |
Reconnection Configuration Client |
|---|---|
|
Reconnection Configuration Service [1] |
M |
|
Bond Management Service [4] |
C.1 |
- M:
-
Mandatory
- C.1:
-
Mandatory if Upgrade to LESC is supported or Next Pairing OOB is supported.
Table 4.2 describes the procedure requirements for a Reconnection Configuration Client.
|
Profile Requirement |
Section |
Support in <client role> |
|---|---|---|
|
Service Discovery |
M |
|
|
M |
|
|
C.1 |
|
|
Characteristic Discovery |
M |
|
|
M |
|
|
C.1 |
|
|
RC Feature |
M |
|
|
RC Settings |
M |
|
|
RCCP |
M |
|
|
Bond Management Control Point |
C.1 |
|
|
Bond Management Feature |
C.1 |
- M:
-
Mandatory
- C.1:
-
Mandatory if Upgrade to LESC is supported or Next Pairing OOB is supported.
4.1. GATT sub-procedure requirements
Requirements in this section represent a minimum set of requirements for a client. Other GATT sub‑procedures may be used if supported by both the client and the server.
The table below summarizes additional GATT sub-procedure requirements beyond those required by all GATT Clients.
|
GATT Sub-Procedure |
<client role> Requirements |
|---|---|
|
Discover All Primary Services |
C.1 |
|
Discover Primary Services by Service UUID |
C.1 |
|
Discover All Characteristics of a Service |
C.2 |
|
Discover Characteristics by UUID |
C.2 |
|
Discover All Characteristic Descriptors |
M |
|
Notifications |
C.3 |
|
Indications |
C.4 |
|
Read Characteristic Value |
M |
|
Write Characteristic Value |
M |
|
Reliable Writes |
C.5 |
|
Write Long Characteristic Values |
C.5 |
|
Read Characteristic Descriptors |
M |
|
Write Characteristic Descriptors |
M |
- M:
-
Mandatory
- C.1:
-
Mandatory to support at least one of these service discovery sub-procedures.
- C.2:
-
Mandatory to support at least one of these characteristic discovery sub-procedures.
- C.3:
-
Mandatory if Ready for Disconnect Supported, otherwise Optional.
- C.4:
-
Mandatory if any RCCP procedure is supported, otherwise Optional.
- C.5:
-
Mandatory if Bond Management Service is supported.
4.2. Service discovery
When using the Low Energy transport, the Reconnection Configuration Client shall perform primary service discovery using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure.
4.2.1. Reconnection Configuration Service discovery
The Reconnection Configuration Client shall discover the Reconnection Configuration Service.
4.2.2. Bond Management Service discovery
The Reconnection Configuration Client may discover the Bond Management Service.
4.3. Characteristic discovery
As required by GATT, the Reconnection Configuration Client must be tolerant of additional optional characteristics in the service records of services used with this profile.
4.3.1. Reconnection Configuration Service characteristic discovery
The Reconnection Configuration Client shall perform either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure in order to discover the characteristics of the service.
The Reconnection Configuration client shall perform the GATT Discover All Characteristic Descriptors sub-procedure in order to discover the characteristic descriptors described in the following sections.
4.3.1.1. RC Feature characteristic
The Reconnection Configuration Client shall discover the RC Feature characteristic.
If the RC Feature characteristic supports indications, the Reconnection Configuration Client shall discover the Client Characteristic Configuration descriptor of the RC Feature characteristic.
4.3.1.2. RC Settings characteristic
The Reconnection Configuration Client shall discover the RC Settings characteristic.
The Reconnection Configuration Client shall discover the Client Characteristic Configuration descriptor of the RC Settings characteristic.
4.3.1.3. RCCP characteristic
The Reconnection Configuration Client shall discover the RCCP characteristic.
The Reconnection Configuration Client shall discover the Client Characteristic Configuration descriptor of the RC Settings characteristic.
4.3.2. Bond Management Service characteristics discovery
In order for the Reconnection Configuration Client to discover the characteristics of the Bond Management Service, it may use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure to discover all characteristics of the service.
4.3.2.1. Bond Management Control Point characteristic
The Reconnection Configuration Client may discover the Bond Management Control Point characteristic of the Bond Management Service.
4.3.2.2. Bond Management Features characteristic
The Reconnection Configuration Client may discover the Bond Management Feature characteristic of the Bond Management Service.
After successful discovery of the Bond Management Feature characteristic, the Reconnection Configuration Client shall discover the Client Characteristic Configuration descriptor of the Bond Management Feature characteristic.
4.4. RC Feature characteristic behavior
The Reconnection Configuration Client shall read the RC Feature characteristic to determine the supported features of the Reconnection Configuration Server in order to interpret the supported functionalities and operate more efficiently.
If the Reconnection Configuration Server supports indications of the RC Feature characteristic, the Client may configure this characteristic for indications. When the Client receives an indication of the RC Feature characteristic, the Client shall use the indicated value to determine the supported functionalities again. Alternatively, the Client may read the RC Feature characteristic each time after connecting with the Reconnection Configuration Server. A Client shall enable indications of the RC Feature characteristic, or it shall read the RC Feature characteristic on each connection.
If the E2E-CRC Supported bit is set to 1 (True), all characteristics contain a CRC-field the Reconnection Configuration Client shall calculate when writing to the characteristic and may verify CRC when reading. Otherwise the CRC-calculation is not supported and the fields are not included except in the RC Feature characteristic.
Note
Note: The Reconnection Configuration Client receives a value of 0xFFFF in the E2E-CRC-field of the RC Feature characteristic when E2E-CRC Supported bit is set to 0 (False).
If the Enable Disconnect Supported bit is set to 1 (True), the Reconnection Configuration Client may request a disconnection of the link using the corresponding procedure of the RCCP. Otherwise the Reconnection Configuration Client shall assume that the server does not support this RCCP procedure.
If the Ready for Disconnect Supported bit is set to 0 (False), the Reconnection Configuration Client should ignore the Ready for Disconnect bit in the RC Settings characteristic. Otherwise, if the Reconnection Configuration Client receives a notification of the RC Settings characteristic and the Ready for Disconnect Supported bit is set to 1 (True), the Reconnection Configuration Client shall proceed as described in Section 4.5.3.
If the Propose Reconnection Timeout Supported bit is set to 0 (False), the Reconnection Configuration Server does not support the configuration of the timeout. Otherwise the Reconnection Configuration Client may configure the Reconnection Timeout with the corresponding procedure of the RCCP characteristic.
If the Propose Connection Interval Supported bit is set to 0 (False), Reconnection Configuration Server does not support the configuration of the Connection Interval. Otherwise the Reconnection Configuration Client may configure the Connection Interval with the corresponding procedure of the RCCP characteristic.
If the Propose Peripheral Latency Supported bit is set to 0 (False), the Reconnection Configuration Server does not support the configuration of the Peripheral Latency. Otherwise the Reconnection Configuration Client may configure the Peripheral Latency with the corresponding procedure of the RCCP characteristic.
If the Propose Supervision Timeout Supported bit is set to 0 (False), the Reconnection Configuration Server does not support the configuration of the Supervision Timeout. Otherwise the Reconnection Configuration Client may configure the Supervision Timeout with the corresponding procedure of the RCCP characteristic.
If the Propose Advertisement Interval Supported bit is set to 0 (False), the Reconnection Configuration Server does not support the configuration of the Advertisement Interval. Otherwise the Reconnection Configuration Client may configure the Advertisement Interval with the corresponding procedure of the RCCP characteristic.
If the Propose Advertisement Count Supported bit is set to 0 (False), the Reconnection Configuration Server does not support the configuration of the Advertisement Count. Otherwise the Reconnection Configuration Client may configure the Advertisement Count with the corresponding procedure of the RCCP characteristic.
If the Propose Advertisement Repetition Time Supported bit is set to 0 (False), the Reconnection Configuration Server does not support the configuration of the Advertisement Repetition Time. Otherwise the Reconnection Configuration Client may configure the Advertisement Repetition Time with the corresponding procedure of the RCCP characteristic.
If the Advertisement Configuration 1 Supported bit is set to 0 (False the Reconnection Configuration Server doesn´t support Connectable Undirected Advertising. Otherwise the Reconnection Configuration Client may configure the Reconnection Configuration Server to use ADV_IND advertising by writing the corresponding bit(s) of the RC Settings characteristic.
If the Advertisement Configuration 2 Supported bit is set to 0 (False the Reconnection Configuration Server does not support Scannable Undirected Advertising. Otherwise the Reconnection Configuration Client may configure the Reconnection Configuration Server to use ADV_SCAN_IND advertising by writing the corresponding bit(s) of the RC Settings characteristic.
If the Advertisement Configuration 3 Supported bit is set to 0 (False), the Reconnection Configuration Server does not support Non Connectable Undirected Advertising. Otherwise the Reconnection Configuration Client may configure the Reconnection Configuration Server to use ADV_NONCONN_IND advertising by writing the corresponding bit(s) of the RC Settings characteristic.
If the Advertisement Configuration 4 Supported bit is set to 0 (False that the Reconnection Configuration Server does not support Connectable Low Duty Cycle Directed Advertising. Otherwise the Reconnection Configuration Client may configure the Reconnection Configuration Server to use ADV_DIRECT_IND, low duty cycle advertising by writing the corresponding bit(s) of the RC Settings characteristic.
If the Upgrade to LESC Only Supported bit is set to 0 (False), the Reconnection Configuration Server does not support LESC Only. Otherwise the Reconnection Configuration Client may configure the Reconnection Configuration Server to use LESC Only for next pairing by writing the corresponding bit of the RC Settings characteristic.
If the Next Pairing OOB Supported bit is set to 0 (False), Reconnection Configuration Server does not support OOB pairing. Otherwise the Reconnection Configuration Client may configure the Reconnection Configuration Server to use OOB for next pairing by writing the corresponding bit of the RC Settings characteristic.
If the Use of Filter Accept List Supported bit is set to 0 (False), the Reconnection Configuration Server does not support the use of the Filter Accept List Timer. Otherwise the Reconnection Configuration Client may get or set the Filter Accept List Timer with the corresponding procedures of the RCCP characteristic.
If the Limited Access Supported (for other Reconnection Configuration Clients) bit is set to 0 (False), Reconnection Configuration Server does not support disabling the service for other Reconnection Configuration Clients. Otherwise the Reconnection Configuration Client may disable the service for other Reconnection Configuration Clients by writing the corresponding bit of the RC Settings characteristic.
4.5. RC Settings characteristic behavior
If the Ready for Disconnect Supported bit is set to 1 (True) in the features of the Reconnection Configuration Server, the Reconnection Configuration Client shall configure the RC Settings characteristic for notifications (i.e. via the Client Characteristic Configuration descriptor).
The Reconnection Configuration Client shall be able to receive multiple notifications of the RC Settings characteristic.
The Reconnection Configuration Client should read the RC Settings characteristic to know the current settings of the server.
If the Reconnection Configuration Client receives a notification of the RC Settings characteristic with bits or values that are designated as Reserved for Future Use (RFU), it shall ignore those bits and continue to process the RC Settings characteristic in the same way as if all the RFU bits had been zero.
When the implementation receives an RC Setting characteristic with additional unrecognized octets, the Reconnection Configuration Client behavior shall be identical to behavior when only recognized octets are received. The Reconnection Configuration Client shall ignore the additional unrecognized octets.
Note
Note: This is to enable compatibility with future Reconnection Configuration Service updates for the case where available octets in the characteristic are specified for optional use.
When a Reconnection Configuration Client requires a connection to a Reconnection Configuration Server, it shall follow the connection procedures described in Section 5.
4.5.1. Upgrade to LE Secure Connections Only mode
The Reconnection Configuration Client shall use the procedure of Section 4.6.11 to set the bit Upgrade to LESC Only to 1 (True) in the RC Settings characteristic when Security Mode 1, Level 4 shall be used.
The Reconnection Configuration Client then shall use the Bond Management Service (BMS) to delete the bond of the current connection or all bonds, depending on the use case to delete the bond(s) and terminate the connection.
The Reconnection Configuration Client then shall reconnect to the Reconnection Configuration Server again, now being requested to use Security Mode 1, Level 4.
The Reconnection Configuration Client should be aware that the Reconnection Configuration Server may have a timeout in which the connection using the Security Mode 1, Level 4 pairing shall be reestablished. If the Reconnection Configuration Client misses the time slot for that reconnection, it shall use the default security level for the next pairing.
The Reconnection Configuration Client may reset the bit Upgrade to LESC Only to 0 (False) in the RC Settings characteristic using the procedure of Section 4.6.11. This enables future connections to other Reconnection Configuration Clients not to use Security Mode 1, Level 4; otherwise, all future connections are forced to use Security Mode 1, Level 4.
4.5.2. Switch to OOB Pairing Only mode
The Reconnection Configuration Client shall use the procedure of Section 4.6.12 to set the bit Use OOB Pairing to 1 (True).
The Reconnection Configuration Client then shall use the BMS to delete the bond of the current connection or all bonds, depending on the use case to delete the bond(s) and terminate the connection.
The Reconnection Configuration Client then shall reconnect to the Reconnection Configuration Server again, now being requested to use an OOB pairing mechanism.
The Reconnection Configuration Client should be aware that the Reconnection Configuration Server may have a timeout in which the connection using the OOB pairing mechanism shall be reestablished. If the Reconnection Configuration Client misses the time slot for that reconnection, it shall use the default pairing mechanism for the next pairing.
The Reconnection Configuration Client may reset the bit Use OOB Pairing to 0 (False) using the procedure of Section 4.6.12. This enables future connections to other Reconnection Configuration Clients not to use the OOB pairing mechanism; otherwise, all future connections are forced to use the OOB pairing mechanism.
4.5.3. Ready for Disconnect behavior
When the Reconnection Configuration Client receives a notification of the RC Settings characteristic with the bit Ready for Disconnect set to 1 (True), the Client shall disconnect immediately if it has received all the data that it needs from the Server. The Reconnection Configuration Client must determine when to disconnect; however, to reduce the energy consumption of the server, consider disconnecting as soon as possible.
4.5.4. Limited Access behavior
The Reconnection Configuration Client shall use the procedure of Section 4.6.13 to set the bit Limited Access to 1 (True) in the RC Settings characteristic when other Reconnection Configuration Clients shall be prohibited from modifying communication parameters. Only the Reconnection Configuration Client that sets this bit can control communication parameters of the Reconnection Configuration Server. In this case the Client will detect the bit Access Permitted set to 1.
One exception is the Enable Disconnect procedure can always be triggered by any Reconnection Configuration Client.
Use the Limited Access procedure carefully so as not to exclude other Reconnection Configuration Clients from further reconnections. This feature is designed to enable use case scenarios where energy consumption of the Reconnection Configuration Server is very critical and a change of the communication parameters would interfere with the specific use case.
When a Reconnection Configuration Client (re)connects to a Reconnection Configuration Server and the bit Limited Access is set to 1 (True) and the Reconnection Configuration Client itself has not set this bit, it will not to be able to change the connection parameters. In this case the Client will detect the bit Access Permitted set to 0.
4.5.5. Advertisement Configuration behavior
The following table shows the four configurations of advertisements from which a Reconnection Configuration Client can select:
|
Advertisement Configuration |
Configuration Details |
|---|---|
|
1 |
Connectable undirected advertising (default) |
|
2 |
Scannable undirected advertising |
|
3 |
Non connectable undirected advertising |
|
4 |
Connectable low duty cycle directed advertising |
The Reconnection Configuration Client shall read the RC Features characteristic first before setting an advertisement configuration to determine the supported modes of the Reconnection Configuration Server.
The change of the advertisement modes shall be handled with care; a wrong setting might make the Reconnection Configuration Server non-connectable.
4.6. RCCP characteristic behavior
The Reconnection Configuration Client may configure the RCCP characteristic for indications (i.e. via the Client Characteristic Configuration descriptor) to receive any change of the communication parameters, even if no Reconnection Configuration Control Point procedure is supported.
Before performing a Reconnection Configuration Control Point procedure, the Reconnection Configuration Client shall configure the RCCP characteristic for indications (i.e. via the Client Characteristic Configuration descriptor).
The Reconnection Configuration Client may perform a write to the RCCP characteristic to request a desired procedure. A procedure begins when the Reconnection Configuration Client writes the RCCP to perform some desired action and ends when a Procedure Response indication is sent by the Reconnection Configuration Server.
Table 4.5 shows the requirements for the RCCP procedures (opcodes) in the context of this profile:
|
Procedure (Opcode) |
Requirement |
|---|---|
|
Enable Disconnect |
C.1 |
|
Get Actual Communication Parameters |
C.2 |
|
Propose Settings |
C.2 |
|
Activate Stored Settings |
C.2 |
|
Get Max Values |
C.3 |
|
Get Min Values |
C.3 |
|
Get Stored Values |
C.2 |
|
Set Filter Accept List Timer |
C.4 |
|
Get Filter Accept List Timer |
C.4 |
|
Set Advertisement Configuration |
C.5 |
|
Upgrade to LESC Only |
C.6 |
|
Switch OOB Pairing |
C.7 |
|
Limited Access |
C.8 |
|
Procedure Response |
C.9 |
|
Communication Parameter Response |
C.2 |
|
Filter Accept List Timer Response |
C.4 |
|
Client Parameter Indication |
M |
- M:
-
Mandatory
- C.1:
-
Mandatory if device supports “Enable Disconnect” feature, otherwise Excluded.
- C.2:
-
Mandatory if device supports one or more of the following features: “Propose Reconnection Timeout”, “Propose Connection Interval”, “Propose Peripheral Latency”, “Propose Supervision Timeout”, “Propose Advertisement Interval”, “Propose Advertisement Count”, “Propose Advertisement Repetition Time”, otherwise Excluded.
- C.3:
-
Optional if device supports one or more of the following features: “Propose Reconnection Timeout”, “Propose Connection Interval”, “Propose Peripheral Latency”, “Propose Supervision Timeout”, “Propose Advertisement Interval”, “Propose Advertisement Count”, “Propose Advertisement Repetition Time”, otherwise Excluded.
- C.4:
-
Mandatory if device supports “Use of Filter Accept List” feature, otherwise Excluded.
- C.5:
-
Mandatory if device supports “Advertisement Configuration”, otherwise Excluded.
- C.6:
-
Mandatory if device supports “Upgrade to LESC Only”, otherwise Excluded.
- C.7:
-
Mandatory if device supports “Switch OOB Pairing”, otherwise Excluded.
- C.8:
-
Mandatory if device supports “Limited Access”, otherwise Excluded.
- C.9:
-
Mandatory if any RCCP procedure is supported.
4.6.1. Enable Disconnect procedure
If the Enable Disconnect Supported bit of the Reconnection Configuration Feature characteristic is set to 1 (True), then this procedure is supported by the Reconnection Configuration Server.
The Reconnection Configuration Client shall write the Enable Disconnect opcode to the RCCP and wait for the Procedure Response opcode indication with Result Code Value set to Success indicating success of the operation or an error value as described in Section 4.6.14.
4.6.2. Get Actual Communication Parameters procedure
To get the actual values of the communication parameters used in the current connection, the Reconnection Configuration Client shall write the Get Actual Communication Parameters opcode to the control point and wait for the indication of the Client Parameter Indication opcode with the values for the current communication parameters or an error value as described in Section 4.6.14.
4.6.3. Propose Settings procedure
To request a change of the communication parameters the Reconnection Configuration Client shall use the Propose Settings procedure. There are two different behaviors due to the effect of the parameter change.
|
Group A: (Parameters that influence advertising) |
Group B: (Parameters that influence connection) |
|---|---|
|
Reconnection Timeout |
Minimum Connection Interval |
|
Advertisement Interval |
Maximum Connection Interval |
|
Advertisement Count |
Peripheral Latency |
|
Advertisement Repetition Time |
Supervision Timeout |
4.6.3.1. Behavior for Group A Only changes
This section describes the behavior if only parameters of Group A are changed.
-
The Reconnection Configuration Client shall write the Propose Settings opcode followed by an operand containing the desired communication parameters. The operand always contains both groups of parameters; the Reconnection Configuration Client should set the parameters not to be changed to the wildcard value (0xFFFF).
Note
Note: If the server can accept at least one of the proposed values, the Client will receive Proposal Accepted, but if the Server cannot support anything in the request, the Client receives an error response with the Result Code Value set to Communication Parameters Rejected.
-
The Reconnection Configuration Client shall receive:
-
An indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to Success.
-
Or, in case of an error, an indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
-
4.6.3.2. Behavior for Group B changes
This section describes the behavior if parameters of Group B or Group B and Group A are changed.
-
The Reconnection Configuration Client shall write the Propose Settings opcode followed by an operand containing the desired communication parameters. The operand always contains both groups of parameters; the Reconnection Configuration Client should set the parameters not to be changed to the values the wildcard value (0xFFFF).
Note
Note: If the Server can accept at least one of the proposed values, the Client will receive Proposal Accepted but if the Server cannot support anything in the request the Client receives an error response with the Result Code Value set to Communication Parameters rejected.
-
The Reconnection Configuration Client shall receive:
-
An indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to Proposal Accepted. This is necessary to determine that the requested communication parameters are accepted by the server.
-
Or an indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14. In this case the next steps are skipped.
-
-
The Link Layer of the peer device should initiate a procedure to modify the connection parameters with the new communication parameters already sent to the server and react on this as defined in the Core Specification [2].
-
The Reconnection Configuration Client shall receive:
-
An indication of the RCCP with a Client Parameter Indication opcode and an operand set to Client Parameters. The values within Client Parameters might be different from the request.
-
Or, in case of a rejection of the communication parameters, an indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to Communication Parameters rejected.
-
4.6.4. Activate Stored Settings procedure
To request a change of the communication parameters the Reconnection Configuration Client shall use the Activate Stored Settings procedure with an operand containing the desired parameter set number.
The behavior follows the same parameter definitions as described in Table 4.6.
4.6.4.1. Behavior for Group A Only changes
This section describes the behavior if only parameters of Group A are changed.
-
The Reconnection Configuration Client shall write the Activate Stored Settings opcode followed by an operand containing the desired parameters set number.
-
The Reconnection Configuration Client shall receive:
-
An indication of the RCCP with a Client Parameter opcode.
-
Or, in case of an error, an indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
-
4.6.4.2. Behavior for Group B changes
This section describes the behavior if parameters of Group B or Group B and Group A are changed.
-
The Reconnection Configuration Client shall write the Activate Stored Settings opcode followed by an operand containing the desired communication parameters..
-
The Reconnection Configuration Client shall receive:
-
An indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to Request Accepted.
-
Or an indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14. In this case the next steps are skipped.
-
-
The Link Layer of the peer device should initiate a procedure to modify the connection parameters with the new communication parameters already sent to the server and react on this as defined in the Core Specification [2].
-
The Reconnection Configuration Client shall receive:
-
An indication of the RCCP with a Client Parameter Indication opcode and an operand set to Client Parameters. The values within Client Parameters might be different from the request.
-
Or, in case of a rejection of the communication parameters, an indication of the RCCP with a Procedure Response opcode and Result Code Value in the operand set to Communication Parameters rejected.
-
4.6.5. Get Max Values procedure
To get the maximum values of the communication parameters supported by the server, the Reconnection Configuration Client shall write the Get Max Values opcode to the control point and wait for an indication of the RCCP with a Communication Parameter Response opcode, an operand containing the Request opcode and the maximum values for the communication parameters.
If the operation results in an error, the Reconnection Configuration Client will get an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
4.6.6. Get Min Values procedure
To get the minimum values of the communication parameters supported by the server, the Reconnection Configuration Client shall write the Get Min Values opcode to the control point and wait for an indication of the RCCP with a Communication Parameter Response opcode, an operand containing the Request opcode and the minimum values for the communication parameters.
If the operation results in an error, the Reconnection Configuration Client will get an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
4.6.7. Get Stored Settings procedure
To get the stored values of the communication parameters of a parameter set of the server, the Reconnection Configuration Client shall write the Get Stored Values opcode to the control point followed by an operand containing the desired parameters set number. The Reconnection Configuration Client will get an indication of the RCCP with a Communication Parameter Response OP Code, an operand containing the Request opcode and the stored values for the communication parameters.
If the operation results in an error, the Reconnection Configuration Client will get an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
4.6.8. Set Filter Accept List Timer procedure
To set the value of the Filter Accept List Timer of the server, the Reconnection Configuration Client shall write the Set Filter Accept List Timer opcode to the control point followed by an operand containing the desired value of the Filter Accept List Timer and wait for the Procedure Response opcode indication with Result Code Value set to Success indicating success of the operation.
If the operation results in an error, the Reconnection Configuration Client will get an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
4.6.9. Get Filter Accept List Timer procedure
To get the values of the Filter Accept List Timer of the server, the Reconnection Configuration Client shall write the Get Filter Accept List Timer opcode to the control point. The Reconnection Configuration Client shall wait for the Filter Accept List Timer Response indication with the values of the Filter Accept List Timer or an error response as described in in Section 4.6.14.
The values of the Filter Accept List Timer consists of a uint32 containing the currently used Filter Accept List Time in seconds, a uint32 for minimum acceptable value and a uint32 for maximum acceptable value.
4.6.10. Set Advertisement Configuration procedure
To set the Advertisement Configuration of the server, the Reconnection Configuration Client shall write the Set Advertisement Configuration opcode to the control point followed by an operand containing the desired value for the Advertisement Configuration and wait for the Procedure Response opcode indication with Result Code Value set to Success indicating success of the operation.
If the operation results in an error, the Reconnection Configuration Client will get an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
4.6.11. Upgrade to LESC Only procedure
To upgrade to LESC Only, the Reconnection Configuration Client shall write the Upgrade to LESC Only opcode to the control point followed by an operand containing 0xFF for enabling LESC Only or 0x00 for disabling LESC Only and wait for the Procedure Response opcode indication with Result Code Value set to Success indicating success of the operation.
The Reconnection Configuration Client should be aware that the Reconnection Configuration Server may have a timeout in which the connection using the Security Mode 1, level 4 pairing will be reestablished. If the Reconnection Configuration Client misses the time slot for that reconnection, it shall be able to handle the next pairing with the default security level.
To access the GATT database in LESC Only mode, the Reconnection Configuration Client shall first upgrade to LESC Only. Then it may use the BMS to delete the bond of the current connection or all bonds, depending on the use case, to delete the bond(s).
To enable other Reconnection Configuration Clients, not supporting LESC Only, a connection to the server, the Reconnection Configuration Client may disable LESC Only using the procedure above.
If the operation results in an error, the Reconnection Configuration Client will get an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
4.6.12. Switch OOB Pairing procedure
To switch to OOB Pairing, the Reconnection Configuration Client shall write the Switch OOB Pairing opcode to the control point followed by an operand containing 0xFF for enabling OOB pairing or 0x00 for disabling OOB pairing and wait for the Procedure Response opcode indication with Result Code Value set to Success indicating success of the operation.
The Reconnection Configuration Client should be aware that the Reconnection Configuration Server may have a timeout in which the connection using the OOB pairing will be reestablished. If the Reconnection Configuration Client misses the time slot for that reconnection, it shall be able to handle the next pairing with default behavior.
To create a connection based on OOB pairing the Reconnection Configuration Client shall first enable OOB pairing. Then it shall use the BMS to delete the bond of the current connection or all bonds, depending on the use case, to delete the bond(s) and terminate the connection. The Reconnection Configuration Client then shall reconnect to the Reconnection Configuration Server again, now being requested to use OOB pairing.
To enable other Reconnection Configuration Clients, not supporting OOB, a connection to the server, the Reconnection Configuration Client may disable OOB pairing using the procedure above.
If the operation results in an error, the Reconnection Configuration Client will get an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
4.6.13. Set Limited Access procedure
To enable “Limited Access”, the Reconnection Configuration Client shall write the Limited Access opcode to the control point followed by an operand containing 0xFF for setting Limited Access or 0x00 for resetting Limited Access and wait for the Procedure Response opcode indication with Result Code Value set to Success indicating success of the operation.
If the operation results in an error, the Reconnection Configuration Client will get an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to the error value as described in Section 4.6.14.
4.6.14. General error handling procedures
If the Reconnection Configuration Client attempts to request any defined RC Control Point procedure before it has configured the Client Characteristic Configuration descriptor for indications, the Reconnection Configuration Client shall get an error response with the Attribute Protocol Application Error Code set to Client Characteristic Configuration Descriptor Improperly Configured. In this case the Reconnection Configuration Client shall configure the Control Point for indications and repeat the procedure.
If the Reconnection Configuration Client writes an opcode to the RC Control Point characteristic that is unsupported by the Server, the Reconnection Configuration Client shall be able to handle an indication of the Control Point with a Procedure Response opcode and Result Code Value in the operand set to Opcode Not Supported.
If the Reconnection Configuration Client writes an opcode to the RC Control Point characteristic with an operand that is invalid, the Reconnection Configuration Client shall be able to handle an indication of the Control Point with a Procedure Response opcode and Result Code Value in the operand set to Invalid Operand.
If the Reconnection Configuration Client attempts to perform any defined RC Control Point procedure before a previous procedure is complete it shall be able to handle an error response with the Attribute Protocol Application Error Code set to Procedure Already In Progress.
It the Reconnection Configuration Client attempts to disconnect the connection and the server is busy for instance if a measurement is pending, it shall be able to handle an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to Device Busy.
If the Reconnection Configuration Client writes an opcode to the RC Control Point characteristic with an operand containing a parameter value which is out of the supported range it shall be able to handle an indication of the control point with a Procedure Response opcode and Result Code Value in the operand set to Communication Parameter out of Range.
If for any reason a procedure cannot be completed on the server, the Reconnection Configuration Client shall be able to handle an indication of the Control Point with a Procedure Response opcode and Result Code Value in the operand set to Operation failed.
If the Reconnection Configuration Client writes to a Control Point characteristic where a CRC value is expected and does not append the E2E-CRC field, it shall be able to handle an ATT Application Error Response with the error code set to Missing CRC.
If the Reconnection Configuration Client writes to a Control Point characteristic where a CRC value is expected and puts a wrong value in the E2E-CRC field, it shall be able to handle an ATT Application Error Response with the error code set to Invalid CRC.
4.7. Bond Management Service characteristics behavior
The Reconnection Configuration Client may write to the Bond Management Control Point to control the bond(s).
The Reconnection Configuration Client may perform a write to the Bond Management Control Point (BMCP) to request a desired procedure. A procedure begins when the Reconnection Configuration Client writes the BMCP to perform some desired action and ends when the ATT Write Response is received by the Reconnection Configuration Client.
The Reconnection Configuration Client shall determine the Bond Management features supported by the Reconnection Configuration Server by reading the Bond Management Feature characteristic before starting any Bond Management Control Point procedure.
4.7.1. Delete Bond of Requesting Device procedures
If the Delete Bond of Requesting Device Procedure Supported bit of the Bond Management Feature characteristic is set to 1 (True), then the procedure(s) are supported by the Reconnection Configuration Server.
The Reconnection Configuration Server may allow the Reconnection Configuration Client to request the deletion of the bond information of the requested device’s transport from its database. In this case the Reconnection Configuration Client shall write the opcode related to the requested transport to the BMCP. If an authorization code is required, as determined by the Bond Management Feature characteristic (see Section 4.7.5), the opcode shall be followed by a parameter representing the authorization code. The Reconnection Configuration Client will get the ATT Write response of the Reconnection Configuration Server for successful operation or an ATT Error Code describing the error.
If the operation is successful, the Reconnection Configuration Client shall delete the corresponding bond information in its database after the requested transport(s) are no longer active.
4.7.2. Delete all Bonds procedures
If the Delete all Bonds Procedure Supported bit of the Bond Management Feature characteristic is set to 1 (True), then the procedure(s) are supported by the Reconnection Configuration Server.
The Reconnection Configuration Server may allow the Reconnection Configuration Client to request the deletion of the bond information of the requested device’s transport from its database. In this case the Reconnection Configuration Client shall write the opcode related to the requested transport to the BMCP. If an authorization code is required, as determined by the Bond Management Feature characteristic (see Section 4.7.5), the opcode shall be followed by a parameter representing the authorization code. The Reconnection Configuration Client will get the ATT Write response of the Reconnection Configuration Server for successful operation or an ATT Error Code describing the error.
If the operation is successful, the Reconnection Configuration Client shall delete all bond information of the requested transport(s) in its database after the requested transport(s) are no longer active.
4.7.3. Delete Bond of all except the requesting device procedures
If the Delete Bond of all except the requesting device Procedure Supported bit of the Bond Management Feature characteristic is set to 1 (True), then the procedure(s) are supported by the Reconnection Configuration Server.
The Reconnection Configuration Server may allow the Reconnection Configuration Client to request the deletion of the bond information of all but the requested device’s transport from its database. In this case the Reconnection Configuration Client shall write the opcode related to the requested transport to the BMCP. If an authorization code is required, as determined by the Bond Management Feature characteristic (see Section 4.7.5), the opcode shall be followed by a parameter representing the authorization code. The Reconnection Configuration Client will get the ATT Write response of the Reconnection Configuration Server for successful operation or an ATT Error Code describing the error.
If the operation is successful, the Reconnection Configuration Client shall delete all bond information of the requested transport(s) in its database, except the bond information of the requesting device’s transport after the requested transport(s) are no longer active.
4.7.4. Bond Management Control Point error handling
If the Reconnection Configuration Client writes an operand to the Bond Management Control Point characteristic that is invalid, it will receive an ATT Error Response with the Attribute Protocol Error Code set to Insufficient Authorization.
If the Reconnection Configuration Client writes an opcode that does not fit the transportation requirements (e.g. an opcode valid only for BR/EDR transport is written to a single mode LE device) or the opcode is not supported on the Reconnection Configuration Server, it will receive an ATT Error Response with the Attribute Application Error Code set to Opcode Not Supported.
What the Reconnection Configuration Client does when receiving one of these error codes is left to the implementation.
If the Reconnection Configuration Client receives an ATT Error Response with the Attribute Application Error Code set to Operation Failed, the procedure on the Reconnection Configuration Server was not successful and the Reconnection Configuration Client shall not assume that the bond information will be deleted after the requested transport(s) are no longer active.
4.7.5. Bond Management Feature characteristic behavior
The Reconnection Configuration Client shall read the Bond Management Feature characteristic to determine the supported procedures of the BMCP.
If the Reconnection Configuration Server supports indications of the Bond Management Feature characteristic and the Reconnection Configuration Client has discovered this characteristic, the Reconnection Configuration Client may configure this characteristic for indications. When the Client receives an indication of the Bond Management Feature characteristic, the Client shall use the indicated value to determine the supported procedures again. Alternatively, the Reconnection Configuration Client may read the Bond Management Feature characteristic each time after connecting with the Reconnection Configuration Server. A Reconnection Configuration Client shall enable indications of the Bond Management Feature characteristic, or it shall read the Bond Management Feature characteristic on each connection.
The following table describes the relationship between Bond Management (BM) feature bits, transport(s) and authorization requirements:
|
Bit |
Octet |
BM Feature Bit Description |
BR/EDR Transport* |
LE Transport |
Authorization Required |
|---|---|---|---|---|---|
|
0 |
0 |
Delete bond of requesting device (BR/EDR and LE) |
X |
X |
|
|
1 |
0 |
Delete bond of requesting device (BR/EDR and LE) with authorization code |
X |
X |
X |
|
2 |
0 |
Delete bond of requesting device (BR/EDR transport only) |
X |
||
|
3 |
0 |
Delete bond of requesting device (BR/EDR transport only) with authorization code |
X |
X |
|
|
4 |
0 |
Delete bond of requesting device (LE transport only) |
X |
||
|
5 |
0 |
Delete bond of requesting device (LE transport only) with authorization code |
X |
X |
|
|
6 |
0 |
Delete all bonds on server (BR/EDR and LE) |
X |
X |
|
|
7 |
0 |
Delete all bonds on server (BR/EDR and LE) with authorization code |
X |
X |
X |
|
0 |
1 |
Delete all bonds on server (BR/EDR transport only) |
X |
||
|
1 |
1 |
Delete all bonds on server (BR/EDR transport only) with authorization code |
X |
X |
|
|
2 |
1 |
Delete all bonds on server (LE transport only) |
X |
||
|
3 |
1 |
Delete all bonds on server (LE transport only) with authorization code |
X |
X |
|
|
4 |
1 |
Delete bond of all except the requesting device on the server (BR/EDR and LE) |
X |
X |
|
|
5 |
1 |
Delete bond of all except the requesting device on the server (BR/EDR and LE) with authorization code |
X |
X |
X |
|
6 |
1 |
Delete bond of all except the requesting device on the server (BR/EDR transport only) |
X |
||
|
7 |
1 |
Delete bond of all except the requesting device on the server (BR/EDR transport only) with authorization code |
X |
X |
|
|
0 |
2 |
Delete bond of all except the requesting device on the server (LE transport only) |
X |
||
|
1 |
2 |
Delete bond of all except the requesting device on the server (LE transport only) with authorization code |
X |
X |
Note
*Note: This version of the profile does not support BR/EDR; ignore values in this column.
If the Reconnection Configuration Client reads the Bond Management Feature characteristic bits that are set and any of these bits are designated as Reserved for Future Use (RFU) in [4], it shall ignore those bits and continue to operate normally as if the bits were not set.
5. Connection establishment procedures
The Reconnection Configuration Profile is a generic profile which is intended to be referenced by another higher-level profile specification. The connection establishment procedures specified by the higher-level profile specification shall be followed.
6. Security considerations
6.1. Reconnection Configuration Server security considerations for Low Energy
This section describes the security requirements for the Reconnection Configuration Server for an LE transport.
The characteristics of the Reconnection Configuration Server should be set to the same security mode and level as the characteristics referred by the higher layer specification.
6.2. Reconnection Configuration Client security considerations for Low Energy
This section describes the security requirements for the Reconnection Configuration Client for an LE transport.
The Reconnection Configuration Client may bond with the Reconnection Configuration Server.
The Reconnection Configuration Client shall accept any request by the Reconnection Configuration Server for LE Security Mode 1 and Security Level 1 or higher.
7. Acronyms and abbreviations
The following alphabetized list of abbreviations and acronyms are used in this specification. Acronyms and abbreviations used but not defined in this specification (including the table below) have the meanings given to them in the Bluetooth Core Specification.
|
Abbreviation or Acronym |
Meaning |
|---|---|
|
BM |
Bond Management |
|
BMS |
Bond Management Service |
|
BMCP |
Bond Management Control Point |
|
BR/EDR |
Basic Rate / Enhanced Data Rate |
|
CGM |
Continuous Glucose Monitoring |
|
E2E-CRC |
End-to-End Cyclic Redundancy Check |
|
LE |
Low Energy |
|
LESC |
Low Energy Secure Connections |
|
RC |
Reconnection Configuration |
|
RCCP |
Reconnection Configuration Control Point |
|
RCS |
Reconnection Configuration Service |
|
N/A |
Not Applicable |
8. References
Bibliography
[1] Reconnection Configuration Service
[2] Bluetooth Core Specification, v4.0 or later
[3] Service UUIDs, Characteristic, and Descriptor descriptions accessible via the Bluetooth SIG Assigned Numbers
[4] Bond Management Service
[5] Appropriate Language Mapping Table, https://www.bluetooth.com/language-mapping/Appropriate-Language-Mapping-Table