• Revision: v1.0

  • Revision Date: 2020-08-11

  • Group Prepared By: Discovery of Things Working Group

Revision History

Revision Number

Date

Comments

v1.0

2020-08-11

Adopted by the Bluetooth SIG Board of Directors.

Contributors

Name

Company

Minsoo Lee

LG Electronics Inc.

Norman Geilhardt

Assystem Germany GmbH

Robert D. Hughes

Intel Corporation

Dominik Sollfrank

Assystem Germany GmbH

Christopher Church

Qualcomm, Inc.

Jaeho Lee

LG Electronics Inc.

Jingu Choi

LG Electronics Inc.

Masahiko Seki

Sony Corporation

Ash Kapur

Broadcom Corporation

Smith Kennedy

HP Inc.

HJ Lee

LG Electronics Inc.

Siegfried Lehmann

Apple, Inc.

Scott Walsh

Plantronics Inc.

Andre Eisenbach

Google Inc.

Robert Hulvey

Cypress Semiconductor

Doug Young

Bose Corporation

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. Each option identified in the specification 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 © 2017-2020. 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

This Bluetooth profile uses the Transport Discovery Service (TDS) [1] to expose data via advertising, and optionally the Generic Attribute Profile (GATT), which can be used to facilitate a connection handover from the Bluetooth Low Energy (LE) [2] transport to the Basic Rate/Enhanced Data Rate (BR/EDR) [2] transport.

This profile defines the role of a Provider, which provides information to facilitate a handover to a BR/EDR transport either via TDS or via advertising data (AD), and a Seeker, which acts as a client to retrieve the provided information to access the BR/EDR transport. The Provider exposes Bluetooth BR/EDR services in advertising packets within the Transport Discovery Data (TDD) AD Type. The Seeker can use this information to decide whether or not to request a connection handover to the BR/EDR transport, or, if the Provider has indicated its BR/EDR transport is already available, to begin connection establishment procedures on that transport.

1.2. Profile dependencies

This profile requires GATT and TDS.

1.3. 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 to all optional and conditional capabilities for which support is indicated.

1.4. Bluetooth specification release compatibility

This specification is compatible with Bluetooth Core Specification 4.2 [2] or later.

1.5. Language

1.5.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 used to express:

a natural consequence of a previously stated mandatory requirement.

OR

an indisputable statement of fact (one that is always true regardless of the circumstances).

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. Each note is clearly designated as a “Note” and set off in a separate paragraph.

For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.

1.5.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.5.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.

2. Profile overview

This Bluetooth profile uses TDS [1] to expose data via advertising, and optionally GATT, which can be used to facilitate a connection handover from the Bluetooth LE transport to the BR/EDR transport.

2.1. Protocol stack

The following diagram shows the relationships between service and profile roles.

Relationship between service and profile roles
Figure 2.1. Relationship between service and profile roles

Note:

Profile roles (Provider and Seeker) are represented by yellow boxes and services (in this case, TDS) are represented by orange boxes.

For Provider and Seeker role dependencies, refer to Sections 3 and 3.3.1 respectively.

2.2. Configurations, roles, and modes

2.2.1. Roles

This profile specifies the requirements of two roles: Provider and Seeker.

  • The Provider shall be a GATT Server if it instantiates TDS.

  • The Seeker shall be a GATT Client.

2.2.2. Concurrency limitations and restrictions

There are no concurrency limitations or restrictions for the Seeker or Provider imposed by this profile. A device may act as a Seeker and Provider simultaneously.

A device that initiates a BR/EDR connection should support the Seeker role and a device that accepts an incoming BR/EDR connection should support the Provider role. Because most BR/EDR devices both initiate and accept incoming BR/EDR connections, BR/EDR Connection Handover Profile (CHP) devices should support both Seeker and Provider roles, however, this is not required.

2.2.3. Topology limitations and restrictions

The Provider shall use either the Generic Access Profile (GAP) Peripheral or the GAP Broadcaster role.

The Seeker shall use the GAP Central role.

2.3. Profile data

This profile uses the length-type-value (LTV) structures defined in Section 5 of TDS [1].

3. Provider role requirements

If the Provider supports TDS [1], it shall support the GAP Peripheral role. If the Provider does not support TDS, then it shall support the TDS AD Data.

Service

Provider

Transport Discovery Service

C.1
Table 3.1. Service requirements for Provider

C.1:

If the BD_ADDR LTV is not present in AD and the BD_ADDR of the BR/EDR device being represented by the Connection Handover Profile is not the same as the Public Address of the advertiser, then mandatory; otherwise optional.

Due to the potential differences between the values of the Provider’s Bluetooth LE device address and the BD_ADDR of the device being represented by the Connection Handover Profile:

  • If a Provider includes TDS profile data in AD and the Provider is not using a Public Address that is equal to the BD_ADDR of the BR/EDR device being served and the Provider does not provide the BD_ADDR via the BR-EDR Handover Data characteristic, then the Provider must include the BD_ADDR LTV in the TDS profile data in AD.

  • If a Seeker finds TDS profile data in AD, but the BD_ADDR LTV is not present, and a Public Address is being used by the advertiser of the TDS profile data, then the Seeker must use the Public Address of the Provider as the BD_ADDR for the BR/EDR device.

  • If the advertising is non-connectable, then the BD_ADDR LTV must be present in the TDD AD Type.

Providers supporting TDS should not include the BD_ADDR LTV in the TDS AD, because it constitutes a persistent unique identifier that could allow the Provider’s location to be tracked over time. Similarly, while LE Peripherals should support Resolvable Private Addresses (RPAs) in their advertising packets, including the TDS BD_ADDR LTV would negate the benefit of using RPAs.

Section 5.1 contains additional Provider requirements that are not otherwise defined in this section.

3.1. Additional TDS requirements

This section describes additional Provider requirements beyond those defined in TDS.

3.1.1. Additional GATT characteristic requirements

If the Provider instantiates TDS, it shall support the TDS Control Point.

3.1.2. Additional GATT sub-procedure requirements

If the Provider instantiates TDS, the requirements in this section apply.

In addition to the GATT sub-procedure requirements in TDS, the Provider shall also support the GATT sub-procedure requirements shown in Table 3.2.

GATT Sub-Procedure

Provider Requirements

Write Characteristic Value

M

Indications

M

Read Characteristic Descriptors

M

Write Characteristic Descriptors

M
Table 3.2. Additional GATT sub-procedure requirements for Provider

M:

Mandatory

3.2. Additional Provider requirements for BR/EDR connection handover

Providers shall follow the additional requirements defined in this section in order to support a connection handover to the BR/EDR transport.

3.2.1. Additional advertising requirements

The following additional requirements apply to the TDD AD Type. This configuration enables a Seeker to determine whether the Provider can establish a connection handover to BR/EDR and that more data may be available in the GATT database.

The Provider shall include the TDD AD Type in its Advertising packet in order to advertise its supported services. A Provider may include multiple Transport Blocks in the TDD AD Type with multiple Organization IDs; however, only one shall include the Bluetooth SIG Organization ID (0x01).

3.2.1.1. Organization ID field

The Provider shall set the Organization ID field value to 0x01 (Bluetooth SIG).

3.2.1.2. TDS Flags field

The Provider shall set the Role bits to 0b10 (Provider Only).

The Provider shall set the Transport Data Incomplete bit to 1 (True) if the Transport Block data is incomplete and the full data can be found in the Complete BR-EDR Transport Block Data descriptor from the GATT database. Otherwise, it shall be set to 0.

The Provider shall set the value of the Transport State bits to an appropriate value depending upon whether the BR/EDR transport is currently Off, On, or Temporarily Unavailable. If the value is On or Temporarily Unavailable, a TDS control point operation may not be required to enable the BR/EDR transport. If the value is Off, a successful write to the TDS control point with the Activate Transport Opcode is required to allow a BR/EDR connection to be established by the Seeker.

If the Transport State bits are set to Temporarily Unavailable, refer to additional requirements in Section 3.2.1.4.

3.2.1.3. Transport Data Length field

The Provider shall set the value of the Transport Data Length field to the appropriate value representing the length of the transport data.

3.2.1.4. Transport Data field

This field shall contain only LTV structures allowed in [1] and may be in any order.

The Service UUID List LTV defined in [1] shall be present. This structure allows Seekers to determine the list of supported BR/EDR services and other information to aid in a connection. Where multiple Service UUIDs are listed, the Provider should list these in order of descending priority or preference (e.g., perhaps a use case requires an immediate service, but also another service that is of lower priority). The UUID closest to the least significant octet (LSO) should be the higher priority service and the UUID closest to the most significant octet (MSO) should be the lower priority service.

If the Transport State bits are set to ‘Temporarily Unavailable’, the Availability Offset LTV defined in [1] may be present. This structure allows Seekers to determine the estimated number of seconds before the BR/EDR transport will become available.

This value should decrease accordingly towards zero as the estimate of availability approaches the time when the Provider will update the Transport State.

Additional LTV structures like BR/EDR Local Name and BR/EDR Class of Device may be included in the Transport Data field. These structures correspond to fields often included in a device’s BR/EDR Extended Inquiry Response (EIR) data, which can facilitate a more user-friendly pairing or connection experience. Including both the LE Local Name AD Type and the TDS BR/EDR Local Name field may not make sense for many devices; if the TDS BR/EDR Local Name is excluded from the Provider’s Transport Data field, a Seeker should use the Provider’s Local Name as appropriate.

3.2.1.5. LE General / Limited Discoverable flags

When in the LE Peripheral role, Providers must configure the LE Limited Discoverable Mode flag and the LE General Discoverable Mode flag as outlined in the Core Specification Volume 3, Part C, Sections 9.2.3.2 and 9.2.4.2 [2]. When these flags are not set, it indicates that the Provider is not bondable, which means that an unbonded Seeker will be unable to connect and initiate pairing in order to read the BR/EDR Handover Data characteristic, which requires encryption. Seekers may therefore decide to wait to initiate an LE connection with an unbonded Provider until either the LE General Discoverable Mode flag or the Limited Discoverable Mode flag is set in the Provider’s advertising packet.

3.2.1.6. Additional advertising recommendations
3.2.1.6.1. LE address during BR/EDR-discoverable mode

A Seeker attempting to connect to a Provider that is advertising using LE RPAs and is simultaneously BR/EDR-discoverable may find it challenging to correlate the LE advertisement of the Provider with the Provider’s BR/EDR inquiry response. Therefore, a Provider using LE RPAs should switch to using its Public Address for LE advertising when it is also BR/EDR-discoverable.

3.2.1.6.2. TX Power Level AD Type

Providers should consider placing a TX Power Level AD Type in their LE advertising packets. This allows Seekers to correct for the LE transmit power level of Providers when using LE RSSI to estimate the proximity of devices.

3.2.2. Additional TDS Control Point requirements

The following additional requirements apply for the use of the TDS Control Point in the context of this specification. These additional requirements enable a Provider to connect to a Seeker over the BR/EDR transport for use with a specific service by using the TDS Control Point.

Upon receiving the Activate Transport opcode (0x01) with the Organization ID set to Bluetooth SIG (0x01), and zero or more Service UUIDs listed in the Parameter field, the Provider can determine if it can support a BR/EDR Connection Handover to support any requested service(s).

When the Provider receives an incoming BR/EDR connection, it may verify that the BD_ADDR received in that connection request matches the Seeker Address LTV value (BD_ADDR) written to the TDS Control Point (see Section 5.3 in [1]).

If the Provider supports any of the requested services, it shall turn on the BR/EDR radio, enter the connectable mode, and start Page Scanning. Once this is complete, the Provider shall send a TDS Control Point Indication containing the Requested opcode (0x01), the Result Code ‘Success’ (0x00), and a Response Parameter that contains the Organization ID (0x01 – Bluetooth SIG), followed by any requested Service Discovery UUID LTVs describing the services that it is ready to support and other allowed LTVs. The Provider shall then wait for a Page Request from the Seeker. Once a Page Request is received, the Provider shall follow normal BR/EDR connection procedures described in the Core Specification (if supported, for devices paired over the Bluetooth LE transport, cross-transport key derivation, defined in Core Specification Volume 3, Part C, Section 14.1 [2], avoids the requirement to additionally pair over the BR/EDR transport when connecting). For a good user experience, the Provider should perform Interlaced Page Scanning at a high duty cycle for at least a few seconds.

If the parameter written to the control point does not meet the requirements of the service, the Provider shall send a TDS Control Point Indication containing the Requested opcode (0x01), Result Code for Invalid Parameter and, optionally, a Response Parameter field.

The Provider shall send a TDS Control Point Indication within a maximum of 10 seconds, see Section 4.5.1.2.

3.3. Additional characteristic and descriptor requirements

The Provider shall conform with the characteristic and descriptor definitions in Section 5 of TDS [1].

3.3.1. Examples for parsing profile data

Figure 3.1 includes examples containing dissimilar LTV structures in the Transport Data and Parameter fields. The Transport Data field contains one LTV structure (Type 0x01 = 16-bit Service UUID list) containing two 16-bit Service UUIDs, and one LTV structure (Type 0x02 = 32-bit Service UUID list) containing two 32-bit Service UUIDs. Any remaining Transport Data is omitted for clarity, but follows the same LTV format.

Parsing the Transport Data field of the TDD AD
Figure 3.1. Parsing the Transport Data field of the TDD AD

In Figure 3.2, the Parameter field of the TDS Control Point contains one LTV structure (Type 0x01 = 16-bit Service UUID list) containing two 16-bit Service UUIDs, and one LTV structure (Type 0x05 = Seeker Address) containing the Seeker BD_ADDR. Any remaining Parameter data is omitted for clarity, but follows the same LTV format.

Parsing the Parameter field in a TDS Control Point write request
Figure 3.2. Parsing the Parameter field in a TDS Control Point write request

In Figure 3.3, the Response Parameter field of the TDS Control Point contains the one-octet Organization ID value, followed by one LTV structure (Type 0x01 = 16-bit Service UUID list) containing two 16-bit Service UUIDs, and one LTV structure (Type 0x02 = 32-bit Service UUID list) containing two 32-bit Service UUIDs. Any remaining Response Parameter data is omitted for clarity, but follows the same LTV format.

Parsing the Response Parameter field in a TDS Control Point Indication
Figure 3.3. Parsing the Response Parameter field in a TDS Control Point Indication

4. Seeker role requirements

The Seeker shall act as a Client of TDS [1].

Table 4.1 describes the discovery requirements for a Seeker. Table 4.2 describes profile requirements for the Seeker.

Discovery Requirement

Section

Support in Seeker

Transport Discovery Service Discovery

4.2

M

Transport Discovery Service Characteristic Discovery

4.3.1

M
Table 4.1. Discovery requirements for a Seeker

M:

Mandatory

Profile Requirement

Section

Support in Seeker

TDS Control Point

4.5.1

M

BR-EDR Handover Data

4.5.2

M

Bluetooth SIG Data

4.5.3

O

Complete BR-EDR Transport Block Data descriptor

4.5.3.1

C.1
Table 4.2. Profile requirements for Seeker

C.1:

Optional if the Bluetooth SIG Data characteristic is supported, otherwise excluded.

M:

Mandatory

O:

Optional

Section 5.2 contains additional Seeker requirements that are not otherwise defined in this section.

4.1. GATT sub-procedure requirements

Requirements in this section represent a minimum set of requirements for a Seeker. Other GATT sub-procedures may be used if supported by both Seeker and Provider.

Table 4.3 summarizes additional GATT sub-procedures required beyond those required by all GATT Clients.

GATT Sub-Procedure

Seeker Requirements
(GATT Client)

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

Read Characteristic Value

M

Read Characteristic Descriptors

M

Write Characteristic Descriptors

M

Indications

M
Table 4.3. Additional GATT sub-procedure requirements for Seeker

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.

M:

Mandatory

4.2. Service discovery

The Seeker shall discover TDS.

When using the Bluetooth LE transport and performing primary service discovery, the Seeker shall use either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure.

When using the BR/EDR transport, the Seeker shall initiate service discovery by retrieving the Service Discovery Protocol (SDP) record of TDS as defined in [1].

4.3. Characteristic discovery

As required by GATT, the Seeker shall be tolerant of additional optional characteristics in the service records of services used with this profile.

Where a characteristic is discovered that can be indicated (i.e., the TDS Control Point characteristic), the Seeker shall also discover the associated Client Characteristic Configuration descriptor.

4.3.1. Transport Discovery Service characteristic discovery

The Seeker shall use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure to discover the characteristics of the service.

The Seeker shall use the GATT Discover All Characteristic Descriptors sub-procedure to discover the characteristic descriptors.

4.4. Scanning requirements

The Seeker shall scan for advertisements from compatible Providers. When the Seeker detects Provider advertisements, it shall parse the data in the TDD AD Type to determine if it has discovered a Provider that supports a required service as described in Section 4.4.1 through 4.4.4.

The Seeker should cache data from previously received Provider advertisements and GATT-based connections to reduce the need for future transactions and potentially reduce connection times.

4.4.1. Organization ID field

The Seeker shall use the contents of this field to determine if the contents within the Transport Block are potentially applicable to this profile. For example, if the value is other than 0x01, the Seeker might choose not to parse the remaining data in the Transport Block. Seekers should be aware that multiple Transport Blocks might be present in the TDD AD Type (see Section 3.1.2 in [1]).

4.4.2. TDS Flags field

The Seeker shall use the contents of this field to determine more about the contents of the Transport Block.

The Seeker shall parse the value of the Role bits to determine if the advertising device is a Provider.

The Seeker shall parse the value of the Transport Data Incomplete bit to determine if there is additional Block data in the GATT database.

The Seeker should use the contents of the Transport State bits to determine whether the BR/EDR radio is currently Off, On, or Temporarily Unavailable. This information can be used by Seekers to determine if a GATT connection is required in order to initiate a connection handover. For example, if the BR/EDR transport is set to On and the Seeker has previous knowledge of how to connect to the Provider over BR/EDR (either through caching previously acquired data or through other means), it may proceed to connect over BR/EDR without forming a Bluetooth LE connection. Alternately, if the BR/EDR transport is set to Temporarily Unavailable, the Seeker should not proceed to attempt a connection, but should continue to monitor the contents of the successive advertisements to determine if the state has changed to On before attempting any connection. In order to connect to the Provider over BR/EDR, with the Provider’s BR/EDR transport set to Off, the Seeker shall proceed to form an LE connection in order to activate the BR/EDR transport. The use of the TDS Control Point and related characteristics is described in Section 4.5.

4.4.3. Transport Data Length field

The Seeker shall parse the value of the Transport Data Length field to determine the length of the Transport Data.

4.4.4. Transport Data field

The Seeker shall parse the Transport Data field as described in [1] to determine Service UUIDs and/or Availability Offset values supported by the Provider.

4.5. Characteristic requirements

This section describes Seeker requirements for the TDS Control Point and other characteristics related to this profile.

4.5.1. TDS Control Point

The TDS Control Point characteristic can be used by the Seeker to request the Provider to activate the BR/EDR transport. Additional opcodes may be added by the Bluetooth SIG for future use.

Before writing to the TDS Control Point, the Seeker shall configure the TDS Control Point characteristic for indications (i.e., via the Client Characteristic Configuration descriptor).

The Seeker may perform a write to the TDS Control Point to request a desired opcode. The Provider normally responds to each successful write with an indication that includes the Requested opcode, a Result Code, and may also include a Response Parameter as defined in [1]. The TDS Control Point timeout process is specified in Section 4.5.1.2.

See Section 4.6 for general error handling requirements associated with this control point.

4.5.1.1. TDS Control Point opcode requirements

Table 4.4 shows the requirements for the TDS Control Point opcodes in the context of this profile:

TDS Control Point opcode

Requirement

Activate Transport

Mandatory
Table 4.4. TDS Control Point opcode requirements

4.5.1.1.1. Activate Transport opcode

To activate (i.e., enable Page Scanning and prepare for a connection) the BR/EDR transport of the Provider, the Seeker shall use the Activate Transport opcode value 0x01.

4.5.1.1.2. Organization ID

The Seeker shall set the Organization ID value to 0x01 (Bluetooth SIG).

4.5.1.1.3. Parameter

When writing to the TDS Control Point, the Parameter field shall contain only LTV structures allowed in [1], which may be listed in any order.

The Seeker shall populate the Parameter field value with LTV structure(s) representing the Service UUIDs of the desired services. Where multiple Service UUIDs are listed, the Seeker should list these in order of descending priority or preference (e.g., perhaps a use case requires an immediate service, but also another service that is of lower priority). The UUID closest to the LSO should be the higher priority service, and the UUID closest to the MSO should be the lower priority service. The Seeker shall include the Seeker Address LTV structure to inform the Provider of the BD_ADDR that the Seeker will use this structure for BR/EDR connection establishment (Paging).

The Seeker shall wait for the TDS Control Point Response Indication or for the operation to time out according to the process described in Section 4.5.1.2.

Upon receiving a TDS Control Point Indication from the Provider that contains the Requested opcode (0x01), the Result Code ‘Success’ (0x00), and a Response Parameter that includes the Organization ID (0x01 - Bluetooth SIG) followed by the Service Discovery UUID LTVs describing the services that the Provider can currently support, the Seeker shall initiate normal BR/EDR connection establishment procedures described in the Core Specification. For a good user experience, the Seeker should perform the paging procedure for a period not less than 5.1 seconds by configuring a Page_Timeout value on the Host Controller Interface (HCI) as appropriate.

4.5.1.2. TDS Control Point timeout process

A TDS Control Point operation is started when the ATT Write Response is sent from the Provider as a result of the Seeker writing an opcode to a control point to perform some desired action. The control point operation ends when the Provider sends an indication to the Seeker.

A TDS Control Point operation is not considered to have started, and correspondingly is not queued in the Provider, when a write request to a control point results in an ATT Error Response.

The Seeker shall start a timer with the value set to 10 seconds after the ATT Write Response is received from the Provider. The timer shall be stopped when a control point indication is received. If the timer expires, then the operation shall be considered to have timed out.

If a TDS Control Point operation times out, the Seeker may choose to disconnect the physical link.

4.5.2. BR-EDR Handover Data

The Seeker shall read the BR-EDR Handover Data characteristic to access information that will assist with a low latency connection to the BR/EDR transport when required.

4.5.2.1. BR-EDR Features field

All bits of the BR-EDR Features field are RFU.

4.5.2.2. BD_ADDR field

The Seeker shall use the BD_ADDR field to determine the BD_ADDR of the remote BR/EDR device.

4.5.2.3. Class of Device field

The Seeker may use the value of the Class of Device field to help the user (e.g., via a graphical icon or text in a user interface) understand the classification of the Provider device.

4.5.3. Bluetooth SIG data

4.5.3.1. Complete BR-EDR Transport Block data descriptor

The Seeker may read the Complete BR-EDR Transport Block Data descriptor to access the value of the Transport Block for the case where the Seeker and Provider are already connected over the Bluetooth LE transport (perhaps for a reason unrelated to this profile). In some cases, it may be more efficient for the Seeker to access this information via GATT rather than via the advertising packet.

4.6. General error handling

The Seeker shall be tolerant and behave appropriately (i.e., the Seeker shall be able to continue to process commands and/or receive data normally) when receiving the Result Codes, ATT Application Error Codes, and ATT Error Codes defined in TDS [1].

If a Service Changed indication is received from the Provider, then this indicates not only that the Seeker must re-perform Service and Characteristic discovery (as defined in GATT in Vol. 3, Part G, Section 7 in [2]) within the handle range specified, but also that the cached values for characteristics and descriptors may no longer be valid and the Seeker shall refresh these cached values.

If the Seeker receives AD or reads characteristic/descriptor values with RFU bits that are non-zero (i.e., RFU bits in the TDS Flags field of the TDD AD Type), it shall ignore those bits and continue to process the advertising packet or characteristic/descriptor as if the RFU bits had been 0.

Similarly, if the Seeker receives AD or reads characteristic/descriptor values with an enumerated value that is RFU (i.e., RFU values in the Organization ID field of the TDD AD Type), it shall ignore that value and continue to process commands and operate normally.

If the Seeker receives AD or reads characteristic/descriptor values with a non-zero value in the Length field (i.e., for the case where the profile is extended to include Transport Data), it shall ignore the unknown octets in the Transport Data field and continue to process commands and operate normally.

If the Seeker receives a TDS Control Point opcode with a Parameter that includes additional unknown octets, it shall ignore the unknown octets and continue to process commands and operate normally.

5. Connection establishment procedures

This section describes the connection establishment and connection termination procedures used by a Provider and Seeker in typical scenarios.

The figures in this section show examples of communication and data flow for the cases where the BR/EDR transport of the Provider is Off (see Figure 5.1) and where the BR/EDR transport of the Provider is On (see Figure 5.2).

Service overview - Provider Transport Off
Figure 5.1. Service overview - Provider Transport Off

Service overview - Provider Transport On
Figure 5.2. Service overview - Provider Transport On

5.1. Provider connection establishment

This section describes connection procedures that a Provider should follow to allow a connection with a Seeker using a Bluetooth LE transport.

  • Section 5.1.1 describes the connection procedure when the Provider does not support bonding or if the Provider supports bonding but is not bonded with any Seekers.

  • Section 5.1.2 describes the connection procedure when the Provider is bonded with one or more Seekers.

The Provider shall use connectable advertisements.

When a Provider receives a Connect Request from a Seeker matching the Provider’s advertising filter policy, it shall form an LE Connection as required by the Core Specification [2].

Once an LE Connection is formed, the Provider may perform GATT operations as required. The use of characteristics and descriptors to respond to actions (e.g., a connection handover to another transport) is defined in Section 3.2.2.

If an LE connection is formed and the connection is no longer required, the Provider may disconnect at any time.

5.1.1. Connectable Mode for unbonded devices

This procedure is used for connection establishment when the Provider is not bonded with any Seekers and ready for connection (e.g., when the Provider has data to send or when commanded by the user).

If a connection is not initiated within TGAP(adv_fast_period), the Provider may either continue sending background advertising to reduce power consumption as long as it chooses or stop advertising. The advertising interval and time to perform advertising are implementation-specific and should be configured with consideration for user expectations of connection establishment time by using the GAP timers defined in Core Specification Volume 3, Part C, Section 9.3.11 [2].

If a connection is not established within a time limit defined by the Provider, the Provider may exit the GAP Connectable Mode.

Table 5.1 summarizes the recommended procedure if the Provider is not bonded to any Seekers.

Recommended
GAP Modes

Recommended
Filter Policy

Remarks

General or Limited Discoverable Modes

Undirected Connectable Mode

Bondable Mode

Allow a connection from any Seekers.

None
Table 5.1. Recommended connection procedure for unbonded devices

When a bond is created, refer to recommendations in Section 5.1.2.

When the Provider no longer requires a connection, it should perform the GAP Terminate Connection procedure.

If the Provider has no data to transfer (or no further data to transfer) and the connection is idle, the Provider should wait at least longer than the maximum connection interval (e.g., 5 seconds) before performing the GAP Terminate Connection procedure. This allows the Seeker to perform any additional required actions (e.g., read characteristics). For devices that support man-in-the-middle (MITM) protection, this duration may need to be longer to allow completion of the pairing sequence.

5.1.2. Connectable Mode for bonded devices

Table 5.2 summarizes the recommended procedure if the Provider is bonded with one or more Seekers.

Recommended
Time

Recommended
GAP Modes

Recommended
Filter Policy

Remarks

First 10 seconds

Non-Discoverable Mode

Undirected Connectable Mode

Allow connection from only bonded Seekers in Filter Accept List.

The Filter Accept List should be used in order to accept connection requests only from the relevant bonded Seeker.

After 10 seconds

General or Limited Discoverable Modes

Undirected Connectable Mode

Bondable Mode

Allow Connection from any Seekers.

This allows bonding with a new Seeker.

Unbonded procedure is described in Section 5.1.1.
Table 5.2. Recommended connection procedure for bonded devices

If a connection is not initiated within TGAP(adv_fast_period), the Provider may either continue sending background advertising to reduce power consumption as long as it chooses, or stop advertising.

The advertising interval and time to perform advertising are implementation-specific and should be configured with consideration for user expectations of connection establishment time by using the GAP timers defined in Core Specification Volume 3, Part C, Section 9.3.11 [2].

If a connection is not established within a time limit defined by the Provider, the Provider may exit the GAP Connectable Mode.

When the Provider is disconnected and the Provider is ready for reconnection (e.g., when the Provider has new data to send or when commanded by the user), the Provider should reinitiate the connection procedure (i.e., start advertising).

If, in a connection, the Provider has no data to transfer (or no further data to transfer) and the connection is idle, the Provider should wait 5 seconds (idle connection timeout) before performing the GAP Terminate Connection procedure. This allows the Seeker additional time to perform any additional required actions (e.g., read characteristics).

5.2. Seeker connection establishment

This section describes the connection procedures a Seeker should follow to initiate a connection with a Provider using a Bluetooth LE transport.

The Seeker should use the GAP General Discovery procedure to discover a Provider. If a Seeker uses the GAP Limited Discovery procedure, it will only be able to detect Providers that are in the GAP Limited Discoverable Mode.

If the Seeker finds a compatible Provider and requires a GATT connection (e.g., to access additional GATT characteristics and descriptors in the GATT database or to write to the TDS Control Point to initiate an action), it may send a Connect Request to the Provider to form an LE Connection.

A Seeker may use one of the GAP Connection procedures based on its connectivity requirements as described in Table 5.3.

GAP Connection Procedure

Unbonded Seeker

Bonded Seeker

General Connection Establishment

Allowed

Allowed

Direct Connection Establishment

Allowed

Allowed

Auto Connection Establishment

Allowed

Allowed

Selective Connection Establishment

Allowed

Allowed
Table 5.3. Allowed GAP connection procedures

If a connection is not initiated within TGAP(adv_fast_period), the Seeker may either continue background scanning to reduce power consumption or stop scanning.

Once an LE Connection is formed, the Seeker may perform GATT operations as required. The use of characteristics and descriptors to initiate actions (e.g., a connection handover to another transport) is defined in Section 4.5.1.1.

If an LE connection is formed and the connection is no longer required, the Seeker may disconnect.

The connection interval, scan interval, scan window, and time to perform scanning are implementation-specific and should be configured with consideration for user expectations of connection establishment time using the GAP timers defined in Volume 3, Part C, Section 9.3.11 [2].

If a connection is not established within a time limit defined by the Seeker, the Seeker may exit the connection establishment procedure.

When the connection is established, the Seeker may bond with the Provider.

When the Seeker is disconnected, the Seeker may continue scanning for advertisements from Providers and may initiate a new connection.

5.2.1. Link loss reconnection procedure

When a connection is terminated due to link loss, the Seeker should attempt to reconnect to the Provider by using any of the GAP Connection procedures that use the connection establishment timing parameters defined in Core Specification Volume 3, Part C (GAP), Section 9.3.11 [2] and the connection interval timing parameters defined in Core Specification Volume 3, Part C (GAP), Section 9.3.12.

6. Profile dependencies

6.1. Concurrency limitations and restrictions

There are no concurrency limitations or restrictions for the Seeker or Provider imposed by this profile. A device may act as a Seeker and Provider simultaneously.

6.2. Transport dependencies

This specification requires features that are only available when using the Bluetooth LE transport. This includes requirements related to the use of advertising and scanning. Since the target transport for connection handover is BR/EDR, the BR/EDR transport is also required.

7. Security considerations

Encryption shall be enabled to read the BR/EDR Handover Data Characteristic value. There are no other security requirements for the Provider and Seeker.

8. Acronyms and abbreviations

Any abbreviation or acronym used in the document, but not defined in a referenced specification (e.g., Volume 1 Part B of the Core Specification), is defined here.

Abbreviation or Acronym

Meaning

AD

advertising data

ATT

Attribute Protocol

BD_ADDR

Bluetooth Device Address

BR/EDR

Basic Rate/Enhanced Data Rate

EIR

Extended Inquiry Response

GAP

Generic Access Profile

GATT

Generic Attribute Profile

HCI

Host Controller Interface

LE

Low Energy

LSO

least significant octet

LTV

length-type-value

MITM

man-in-the-middle

MSO

most significant octet

MTU

maximum transmission unit

PDU

Protocol Data Unit

RFU

Reserved for Future Use

RPA

Resolvable Private Address

SDP

Service Discovery Protocol

TDD

Transport Discovery Data

TDS

Transport Discovery Service

UI

user interface

UUID

universally unique identifier
Table 8.1. Acronyms and abbreviations

9. References

Bibliography

[1] Bluetooth Transport Discovery Service, Version 1.1 or later

[2] Bluetooth Core Specification, Version 4.2 or later

10. Appendix A: Specification Developer Guide

This section provides recommendations for developers of profile specifications who in turn use this profile.

  • For profile roles that need to both provide a service over BR/EDR and access a service over BR/EDR, both the Seeker and Provider roles of this profile should be implemented. This corresponds to profiles that would normally recommend both inquiry and inquiry scan.

  • For a profile role that only offers a service to be accessed over BR/EDR, implementation of just the Provider role should be sufficient. This corresponds to profiles that would normally recommend only inquiry scan.

  • Similarly, for a profile role that only needs to access a service over BR/EDR, implementation of just the Seeker role should be sufficient. This corresponds to profiles that would normally recommend only inquiry.