-
Revision: v1.0
-
Revision Date: 2021-01-12
-
Group Prepared By: Direction Finding Working Group (DFWG)
Revision History
|
Revision Number |
Date |
Comments |
|---|---|---|
|
v1.0 |
2021-01-12 |
Adopted by the Bluetooth SIG Board of Directors. |
Contributors
|
Name |
Company |
|---|---|
|
Ian Blair |
CSR |
|
Juha Salokannel |
Nokia Corporation |
|
Mayank Batra |
Qualcomm Technologies International, Ltd. |
|
Florian Lefeuvre |
Texas Instruments |
|
Victor Zhodzishsky |
Cypress Semiconductor Corporation |
|
Angel Polo |
Broadcom Corporation |
|
Jonathan Berner |
E.G.O. Elektro-Gerätebau GmbH |
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
The Constant Tone Extension Service allows a client to configure the Constant Tone Extension [2] transmitted by a server, both on a connection and on the advertising channels.
1.1. 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.2. Service dependencies
This service has no dependencies on other GATT-based services.
1.3. Bluetooth Core Specification release compatibility
This service is compatible with any Bluetooth Core Specification Host that includes the Generic Attribute Profile (GATT) and any Bluetooth Core Specification Controller that supports the Connection CTE Response or the Connectionless CTE Transmitter Link Layer features [2].
1.4. GATT sub-procedure requirements
Requirements in this section represent a minimum set of requirements for a server. Other GATT sub-procedures may be used if supported by both client and server.
Table 1.1 summarizes additional GATT sub-procedures required beyond those required by all GATT servers.
|
GATT Sub-Procedure |
Requirements |
|---|---|
|
Write Characteristic Value |
M |
- M:
-
Mandatory
1.5. Transport dependencies
This service is only intended to operate over the Bluetooth Low Energy (LE) transport, which is the only transport that supports the Connection CTE Response and Connectionless CTE Transmitter Core features [2].
1.6. Application error codes
This service does not define any new Attribute Protocol Application Error Codes.
1.7. Byte transmission order
All characteristics used with this service shall be transmitted with the least significant octet first (i.e., little endian). The least significant octet is identified in the characteristic definitions on the Bluetooth Assigned Numbers webpage [1].
1.8. Language
1.8.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.8.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.8.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. Service
2.1. Declaration
The service shall be either a «Primary Service» or «Secondary Service», and the service UUID (Universally Unique Identifier) shall be set to «Constant Tone Extension Service» as defined on the Bluetooth Assigned Numbers webpage [1]. This service should be instantiated as a «Secondary Service», which is included from the relevant primary service on the device.
2.2. Behavior
The server should advertise the «Constant Tone Extension Service» in the Service UUID AD type. The server shall expose this service only if the Controller supports either the Connection CTE Response or the Connectionless CTE Transmitter Link Layer features.
3. Service characteristics
The following characteristics shall be exposed by this service:
|
Characteristic Name |
Requirement |
Mandatory Properties |
Optional Properties |
Security Permissions |
|---|---|---|---|---|
|
Constant Tone Extension Enable |
M |
Write |
None |
Specified by the higher layers |
|
Advertising Constant Tone Extension Minimum Length |
C.1 |
Write |
None |
Specified by the higher layers |
|
Advertising Constant Tone Extension Minimum Transmit Count |
C.1 |
Write |
None |
Specified by the higher layers |
|
Advertising Constant Tone Extension Transmit Duration |
C.1 |
Write |
None |
Specified by the higher layers |
|
Advertising Constant Tone Extension Interval |
C.1 |
Write |
None |
Specified by the higher layers |
|
Advertising Constant Tone Extension PHY |
C.1 |
Write |
None |
Specified by the higher layers |
- M:
-
Mandatory
- C.1:
-
Mandatory when CTE on advertising channels is supported, else excluded.
3.1. Constant Tone Extension Enable
3.1.1. Constant Tone Extension Enable characteristic behavior
The Constant Tone Extension Enable characteristic is a control-point attribute that stores the type of Constant Tone Extension that the server transmits on an ACL (Asynchronous Connection-oriented [logical transport]) connection or on the advertising channels. There is only one instance of the Constant Tone Extension Enable characteristic within the Constant Tone Extension service definition. A Constant Tone Extension Enable value shall exist for each client with a trusted relationship.
When allowed by the Security Permissions and successfully written, the server shall update the characteristic value and the type of Constant Tone Extension either for the given client or on the advertising channels.
The characteristic property requirements are stated in Table 3.1. A higher layer may specify additional permission requirements, but only authorized devices should be permitted to write.
When bit 0 of the Constant Tone Extension Enable characteristic value is set to 1, the server shall enable AoA (Angle of Arrival) Constant Tone Extension on the ACL connection with the client. Once enabled, the server shall transmit an AoA Constant Tone Extension whenever requested by the client, using the Constant Tone Extension Request Link Layer Control procedure.
When bit 1 of the Constant Tone Extension Enable characteristic value is set to 1 by any client allowed by the Security Permissions, the server shall enable AoD (Angle of Departure) Constant Tone Extension in advertising packets.
If enabling the Constant Tone Extension succeeds, the server shall send a Write Response; otherwise, the server shall send an Error Response, setting the Error Code to Write Request Rejected (0xFC) [3].
When bit 0 of the Constant Tone Extension Enable characteristic value is set to 0, the server shall disable AoA Constant Tone Extension on the ACL connection with the client.
When bit 1 of the Constant Tone Extension Enable characteristic value is set to 0 by all the clients allowed by the Security Permissions, the server shall disable AoD Constant Tone Extension in advertising packets.
3.1.1.1. Constant Tone Extension Enable characteristic field
The Constant Tone Extension Enable characteristic is a 1-octet field that is defined in Table 3.2.
|
Constant Tone Extension Enable |
Size: 1 octet |
|
Bit Number |
Parameter Description |
|---|---|
|
0 |
Enable AoA Constant Tone Extension on the ACL connection with the client |
|
1 |
Enable AoD Constant Tone Extension in advertising packets |
|
All other bits |
Reserved for Future Use |
3.2. Advertising Constant Tone Extension Minimum Length
3.2.1. Advertising Constant Tone Extension Minimum Length characteristic behavior
The Advertising Constant Tone Extension Minimum Length characteristic is a control-point attribute that stores the minimum length of Constant Tone Extension that the server transmits on the advertising channels. There is only one instance of the Advertising Constant Tone Extension Minimum Length characteristic within the Constant Tone Extension service definition. An Advertising Constant Tone Extension Minimum Length value shall exist for each client with a trusted relationship.
When allowed by the Security Permissions and successfully written, the server shall update the characteristic value and the minimum length of Constant Tone Extension on the advertising channels. The server may transmit Constant Tone Extension longer than the minimum length. On advertising channels, the server shall transmit Constant Tone Extension equal to or longer than the maximum value out of the minimum Constant Tone Extension length values written by the clients.
The Advertising Constant Tone Extension Minimum Length characteristic is mandatory for advertising channels.
The characteristic property requirements are stated in Table 3.1. A higher layer may specify additional permission requirements, but only authorized devices should be permitted to write.
When the Advertising Constant Tone Extension Minimum Length characteristic value is updated, the server shall update the length of the Constant Tone Extension being transmitted on the ACL connection or on advertising channels.
If updating the Advertising Constant Tone Extension Minimum Length succeeds, the server shall send a Write Response.
If the client sets the Advertising Constant Tone Extension Minimum Length characteristic value to outside the valid range, the server shall send an Error Response, setting the Error Code to Out of Range (0xFF). In all other failure cases, the server shall send an Error Response, setting the Error Code to Write Request Rejected (0xFC) [3].
3.2.1.1. Advertising Constant Tone Extension Minimum Length characteristic field
The Advertising Constant Tone Extension Minimum Length characteristic is an unsigned 1-octet field that is defined in Table 3.3.
|
Advertising Constant Tone Extension Minimum Length |
Size: 1 octet |
|
Bit Number |
Parameter Description |
|---|---|
|
0–4 |
Minimum length of the Constant Tone Extension in 8 μs units Valid values: 2 to 20 inclusive |
|
All other bits |
Reserved for Future Use |
3.3. Advertising Constant Tone Extension Minimum Transmit Count
3.3.1. Advertising Constant Tone Extension Minimum Transmit Count characteristic behavior
The Advertising Constant Tone Extension Minimum Transmit Count characteristic is a control-point attribute that stores the minimum number of times the server transmits Constant Tone Extension packets on the advertising channels at each Constant Tone Extension Interval. This characteristic does not apply to ACL connections. There is only one instance of the Advertising Constant Tone Extension Minimum Transmit Count characteristic within the Constant Tone Extension service definition. An Advertising Constant Tone Extension Minimum Transmit Count value shall exist for each client with a trusted relationship.
When allowed by the Security Permissions and successfully written, the server shall update the characteristic value and the minimum transmit count of Constant Tone Extension for the advertising channels. The server should transmit Constant Tone Extension packets enough times to satisfy the transmit count. On the server, the value used for the Advertising Constant Tone Extension Minimum Transmit Count should be greater than or equal to the maximum value of the Advertising Constant Tone Extension Minimum Transmit Count values written by the clients.
The Advertising Constant Tone Extension Minimum Transmit Count characteristic is mandatory for advertising channels when CTE on advertising channels is supported, else excluded.
The characteristic property requirements are stated in Table 3.1. A higher layer may specify additional permission requirements, but only authorized devices should be permitted to write.
When the Advertising Constant Tone Extension Minimum Transmit Count characteristic value is updated, the server shall update the number of times Constant Tone Extension packets are transmitted on advertising channels at each Constant Time Extension Interval.
If updating the Advertising Constant Tone Extension Minimum Transmit Count succeeds, the server shall send a Write Response.
If the client sets the Advertising Constant Tone Extension Minimum Transmit Count characteristic value to outside the valid range, the server shall send an Error Response, setting the Error Code to Out of Range (0xFF). In all other failure cases, the server shall send an Error Response, setting the Error Code to Write Request Rejected (0xFC).
3.3.1.1. Advertising Constant Tone Extension Minimum Transmit Count characteristic field
The Advertising Constant Tone Extension Minimum Transmit Count characteristic is an unsigned 1-octet field that is defined in Table 3.4.
|
Advertising Constant Tone Extension Minimum Transmit Count |
Size: 1 octet |
|
Value |
Description |
|---|---|
|
1 - 15 |
Minimum times a packet with the Constant Tone Extension is transmitted at each Constant Tone Extension Interval |
|
16 – 255 |
Reserved for Future Use |
3.4. Advertising Constant Tone Extension Transmit Duration
3.4.1. Advertising Constant Tone Extension Transmit Duration characteristic behavior
The Advertising Constant Tone Extension Transmit Duration characteristic is a control-point attribute that stores the duration for which the server transmits packets containing a Constant Tone Extension on the advertising channels. There is only one instance of the Advertising Constant Tone Extension Transmit Duration characteristic within the Constant Tone Extension service definition. An Advertising Constant Tone Extension Transmit Duration value shall exist for each client with a trusted relationship.
When allowed by the Security Permissions and successfully written, the server shall update the characteristic value and the duration for which it transmits packets containing a Constant Tone Extension on the advertising channels. The server shall transmit packets containing a Constant Tone Extension for the maximum duration value out of the duration values written by the clients.
The Advertising Constant Tone Extension Transmit Duration characteristic is mandatory for advertising channels.
The characteristic property requirements are stated in Table 3.1. A higher layer may specify additional permission requirements, but only authorized devices should be permitted to write.
When the Advertising Constant Tone Extension Transmit Duration characteristic value is updated, the server shall update the duration for which it transmits packets containing a Constant Tone Extension on the advertising channels.
If updating the Advertising Constant Tone Extension transmit duration succeeds, the server shall send a Write Response; otherwise, the server shall send an Error Response, setting the Error Code to Write Request Rejected (0xFC) [3].
3.4.1.1. Advertising Constant Tone Extension Transmit Duration characteristic field
The Advertising Constant Tone Extension Transmit Duration characteristic is an unsigned 1-octet field that is defined in Table 3.5.
|
Advertising Constant Tone Extension Transmit Duration |
Size: 1 octet |
|
Value |
Description |
|---|---|
|
N |
The time duration for which the server transmits packets containing a Constant Tone Extension on the advertising channels is given by the value 1.1N-64 in seconds, with N being the raw 8-bit value. Range: 0 to 255 Time Range: 2467 µs to 80,538,375 s A raw value of 0 means an indefinite time duration. |
3.5. Advertising Constant Tone Extension Interval
3.5.1. Advertising Constant Tone Extension Interval characteristic behavior
The Advertising Constant Tone Extension Interval characteristic is a control-point attribute that stores the interval at which the server transmits packets containing a Constant Tone Extension on the advertising channels. There is only one instance of the Advertising Constant Tone Extension Interval characteristic within the Constant Tone Extension service definition. An Advertising Constant Tone Extension Interval value shall exist for each client with a trusted relationship.
When allowed by the Security Permissions and successfully written, the server shall update the characteristic value and the interval at which it transmits packets containing a Constant Tone Extension on the advertising channels.
The Advertising Constant Tone Extension Interval characteristic is mandatory for advertising channels.
The characteristic property requirements are stated in Table 3.1. A higher layer may specify additional permission requirements, but only authorized devices should be permitted to write.
When the Advertising Constant Tone Extension Interval characteristic value is updated, the server shall update the interval at which it transmits packets containing a Constant Tone Extension on the advertising channels. The server should transmit packets containing a Constant Tone Extension at the minimum interval value out of all the interval values written by the clients.
If updating the Advertising Constant Tone Extension Interval succeeds, the server shall send a Write Response.
If the client sets the Advertising Constant Tone Extension Interval characteristic value to outside the valid range, the server shall send an Error Response, setting the Error Code to Out of Range (0xFF). In all other failure cases, the server shall send an Error Response, setting the Error Code to Write Request Rejected (0xFC) [3].
3.5.1.1. Advertising Constant Tone Extension Interval characteristic field
The Advertising Constant Tone Extension Interval characteristic is an unsigned 2-octet field that is defined in Table 3.6.
|
Advertising Constant Tone Extension Interval |
Size: 2 octets |
|
Value |
Description |
|---|---|
|
0x0000 – 0x0005 |
Reserved for Future Use |
|
0x0006 – 0xFFFF |
The interval at which the server transmits packets containing a Constant Tone Extension on the advertising channels is given by the value N*1.25 ms, with N being the raw 16-bit value. Time Range: 7.5 ms to 81.91875 s |
3.6. Advertising Constant Tone Extension PHY
3.6.1. Advertising Constant Tone Extension PHY characteristic behavior
The Advertising Constant Tone Extension PHY characteristic is a control-point attribute that stores the type of PHY used by the server for transmitting Constant Tone Extension on the advertising channels. There is only one instance of the Advertising Constant Tone Extension PHY characteristic within the Constant Tone Extension service definition. An Advertising Constant Tone Extension PHY value shall exist for each client with a trusted relationship.
When allowed by the Security Permissions and successfully written, the server shall update the characteristic value and the PHY of Constant Tone Extension on the advertising channels. If multiple clients have written different values of PHY, the server shall use the LE 1M PHY.
The Advertising Constant Tone Extension PHY characteristic is mandatory for advertising channels.
The characteristic property requirements are stated in Table 3.1. A higher layer may specify additional permission requirements, but only authorized devices should be permitted to write.
If updating of the Advertising Constant Tone Extension PHY succeeds, the server shall send a Write Response; otherwise, the server shall send an Error Response, setting the Error Code to Write Request Rejected (0xFC) [3].
3.6.1.1. Advertising Constant Tone Extension PHY characteristic field
The Advertising Constant Tone Extension PHY characteristic is an unsigned 1-octet field that is defined in Table 3.7.
|
Advertising Constant Tone Extension PHY |
Size: 1 octet |
|
Value |
Parameter Description |
|---|---|
|
0 |
LE 1M PHY |
|
1 |
LE 2M PHY |
|
All other values |
Reserved for Future Use |
4. Acronyms and abbreviations
|
Abbreviation |
Meaning |
|---|---|
|
ACL |
Asynchronous Connection-oriented [logical transport] |
|
AoA |
Angle of Arrival |
|
AoD |
Angle of Departure |
|
CTE |
Constant Tone Extension |
|
DFWG |
Direction Finding Working Group |
|
GATT |
Generic Attribute Profile |
|
LE |
Low Energy |
|
PDU |
Protocol Data Unit |
|
RFU |
Reserved for Future Use |
|
UUID |
Universally Unique Identifier |
5. References
Bibliography
[1] Characteristic and Descriptor descriptions are accessible via the Bluetooth SIG Assigned Numbers
[2] Bluetooth Core Specification, Version 5.1 or later
[3] Bluetooth Core Specification Supplement Version 7 (CSSv7) or later