Asset Tracking Profile

Abstract

This specification defines a GATT-based profile for connection-oriented Angle of Arrival (AoA) based direction detection of another Bluetooth Low Energy device as described in the Bluetooth Core Specification, Version 5.1 or later [2].

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
Juha Salokannel	Nokia
Ian Blair	Qualcomm
Mayank Batra	Qualcomm Technologies International, Ltd.
Florian Lefeuvre	Texas Instruments
Victor Zhodzishsky	Cypress

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 © 2015–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 Asset Tracking Profile (ATP) defines the procedures used by a Bluetooth Low Energy device (Locator) to find the relative direction and, optionally, the location of another Bluetooth Low Energy device (Asset Tag). While ATP does not define any methods for calculating the relative direction and position, it defines the procedures used by the Locator to configure the Asset Tag and to obtain the data required to perform those calculations.

The ATP enables use of the Constant Tone Extension (CTE) Service [3] on a peer device.

1.1. Profile dependencies

This profile requires the Generic Attribute Profile (GATT) and the Generic Access Profile (GAP).

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 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.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 Specification release compatibility

This profile is compatible with any Bluetooth Core Specification, Version 5.1 or later that includes the Connection CTE Request, Connection CTE Response, Antenna Switching During CTE Reception (AoA), and Receiving Constant Tone Extensions (AoA) features [2].

2. Configuration

2.1. Roles

This profile defines two roles: Asset Tag and Locator. The Asset Tag is the device that exposes support for the Constant Tone Extension Service.

Asset Tag shall be an AoA-capable Low Energy transmitter and shall be a GATT server.
Locator shall be an AoA-capable Low Energy receiver equipped with an antenna array and shall be a GATT client.

2.2. Profile/service role relationships

Figure 2.1 shows the relationships between the Constant Tone Extension Service and the two profile roles.

Figure 2.1. Profile and service role relationships

The Locator configures the Asset Tag to transmit direction finding enabled packets using a single antenna (see Section 2.1.5 in [2]).

The Locator, consisting of a Radio Frequency (RF) switch and antenna array, switches antennae while receiving part of those packets and captures in-phase and quadrature (IQ) samples. The Locator uses the IQ samples to calculate the phase difference in the radio signal received using different elements of the antenna array, which in turn are used to estimate the direction to the Asset Tag (see Bluetooth Core Specification Vol 6, Part A, Section 5.2).

The Locator, which knows its own location, the Received Signal Strength Indicator (RSSI) of the packets and the calculated AoA can estimate the distance (by RSSI) to the Asset Tag and can thus also estimate the location (combination of RSSI and AoA) of the Asset Tag.

2.3. Concurrency limitations/restrictions

There are no concurrency limitations or restrictions in this profile.

2.4. Topology limitations/restrictions

The Asset Tag shall support the Generic Access Profile (GAP) Peripheral role and may additionally support the GAP Central role.

The Locator shall support the GAP Central role and may additionally support the GAP Peripheral role.

2.5. Transport dependencies

The Asset Tracking Profile operates only over the Bluetooth Low Energy transport.

The Locator device’s Link Layer shall support the Connection CTE Request feature and the Antenna Switching During CTE Reception (AoA) feature [2].

The Asset Tag’s Link Layer shall support the Connection CTE Response feature and the Receiving Constant Tone Extensions (AoA) feature [2].

3. Asset Tag role requirements

Asset Tag shall instantiate only one Constant Tone Extension Service.

The Constant Tone Extension Service shall be instantiated as a «Primary Service».

Service	Asset Tag
« Constant Tone Extension Service»	M

Table 3.1. Constant Tone Extension Service requirements

M:: Mandatory

3.1. Incremental Constant Tone Extension Service requirements

This section describes additional Asset Tag requirements beyond those defined in the Constant Tone Extension Service.

3.1.1. Service UUIDs AD type

While in GAP Discoverable Mode for initial connection to a Locator, the Asset Tag shall include the Constant Tone Extension Service Universally Unique Identifier (UUID) (defined in [1]) in the Service UUID’s AD type field of the Advertising Data. This enhances the user experience because an Asset Tag may be identified by the Locator before initiating a connection.

3.1.2. Local Name AD type

While in GAP Discoverable Mode, the Asset Tag should include the Local Name (containing either the complete or shortened value of the Device Name characteristic defined in [1]) in its Advertising Data or Scan Response Data.

3.1.3. Writable GAP Device Name characteristic

The Asset Tag may support the write property for the Device Name characteristic to allow a Locator to write a device name to the Asset Tag.

3.1.4. Appearance characteristic

For enhanced user experience, an Asset Tag should include the value of the Appearance characteristic (defined in [1]) in its Advertising Data or Scan Response Data.

4. Locator role requirements

This section describes the profile procedure requirements for a Locator.

Profile Requirement	Section	Support in Locator
Service Discovery	4.2	-
Constant Tone Extension Service Discovery	4.2	M
Characteristic Discovery	4.3	-
Constant Tone Extension Service Characteristic Discovery	4.3.1	M

Table 4.1. Profile requirements for the Locator role

M:: Mandatory

4.1. GATT sub-procedure requirements

This section presents a minimum set of requirements for a Locator. Other GATT sub‑procedures may be used if they are supported by both client and server. Table 4.2 lists the GATT sub‑procedures that are required for a Locator in addition to the sub-procedures required for all GATT clients.

GATT Sub-Procedure	Locator 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
Read Characteristic Value	M
Write Characteristic Value	M

Table 4.2. Additional GATT sub-procedure requirements

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

In order for the Locator to discover the Constant Tone Extension Service, the Locator 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.3. Characteristic discovery

4.3.1. Constant Tone Extension Service characteristic discovery

The Locator may perform 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 Constant Tone Extension Service.

Table 4.3 lists the discovery requirements for the Locator.

Characteristic	Discovery Requirement for Locator
Constant Tone Extension Enable	M

Table 4.3. Discovery requirements for the Locator

M:: Mandatory

4.4. Constant Tone Extension Service characteristics

4.4.1. Constant Tone Extension Enable

To enable the Asset Tag to transmit the Constant Tone Extension field in Link Layer packets, the Locator shall set the value of bit 0 of the Constant Tone Extension Enable characteristic to 1. Thereafter, the Locator may start requesting the Asset Tag to transmit the Constant Tone Extension field using the Constant Tone Extension Request Link Layer Control procedure [2]. The rate at which the Locator requests the Asset Tag to transmit the Constant Tone Extension field should be configured with consideration for user expectations.

The value of the Constant Tone Extension Enable characteristic shall not be retained on the Asset Tag when the connection between the Locator and the Asset Tag ends.

5. Connection establishment procedures

This profile does not add any requirements to those specified in GAP [2].

6. Security considerations

This section describes the security considerations for an Asset Tag and Locator.

6.1. Asset Tag security considerations

All supported characteristics specified by the Constant Tone Extension Service should be set to Security Mode 1 and Security Level 2 or higher.

The Asset Tag may bond with the Locator depending upon the user scenario.

The Asset Tag should use the Privacy feature.

6.2. Locator security considerations

The Locator may bond with the Asset Tag depending upon the user scenario.

The Locator should use the Privacy feature.

7. Acronyms and abbreviations

Abbreviation	Meaning
AoA	Angle of Arrival
ATP	Asset Tracking Profile
CTE	Constant Tone Extension
DFWG	Direction Finding Working Group
GAP	Generic Access Profile
GATT	Generic Attribute Profile
IQ	In-phase and Quadrature
PDU	Protocol Data Unit
RF	Radio Frequency
RFU	Reserved for Future Use
RSSI	Received Signal Strength Indicator
UUID	Universally Unique Identifier

Table 7.1. Acronyms and abbreviations

8. References

Bibliography

[1] Service UUIDs, Characteristics, and Descriptors available from Bluetooth SIG Assigned Numbers

[2] Bluetooth Core Specification, Version 5.1 or later

[3] Constant Tone Extension Service, Version 1.0 or later