-
Revision: v1.0
-
Revision Date: 2021-09-14
-
Group Prepared By: Generic Audio Working Group
Revision History
|
Revision Number |
Date |
Comments |
|---|---|---|
|
v1.0 |
2021-09-14 |
Adopted by the Bluetooth SIG Board of Directors. |
Contributors
|
Name |
Company |
|---|---|
|
Jonathan Tanner |
Qualcomm Technologies International, Ltd |
|
Chris Church |
Qualcomm Technologies International, Ltd |
|
Robin Heydon |
Qualcomm Technologies International, Ltd |
|
Nick Hunn |
GN Hearing A/S |
|
Søren Larsen |
Widex |
|
Markus Schnell |
Fraunhofer IIS |
|
Jeff Solum |
Starkey |
|
Masahiko Seki |
Sony |
|
Andrew Estrada |
Sony |
|
Stephan Gehring |
Sonova AG |
|
Michael Ungstrup |
Widex A/S |
|
Simon Jonghun Song |
LG Electronics, Inc. |
|
Bjarne Klemmensen |
Oticon A/S |
|
Kanji Kerai |
Widex A/S |
|
Erwin Weinans |
Plantronics Inc. |
|
Scott Walsh |
Plantronics Inc. |
|
Georg Dickmann |
Sonova AG |
|
Peter Liu |
Bose Corporation |
|
Daniel Sisolak |
Bose Corporation |
|
Rasmus Abildgren |
Bose Corporation |
|
Xuemei Ouyang |
Intel Corporation |
|
Oren Haggai |
Intel Corporation |
|
Chethan Narayan Tumkur |
Intel Corporation |
|
Siegfried Lehmann |
Apple |
|
Riccardo Cavallari |
Sivantos GmbH |
|
Marcel Holtmann |
Intel Corporation |
|
Sam Geeraerts |
NXP Semiconductors |
|
Anil Kumar Vutukuru |
MindTree Limited |
|
Luiz Von Dentz |
Intel Corporation |
|
Himanshu Bhalla |
Intel Corporation |
|
Andrew Credland |
Samsung Electronics Co., Ltd |
|
Khaled Elsayed |
Synopsys |
|
Michael Rougeux |
Bose Corporation |
|
Tim Reilly |
Bose Corporation |
|
Ella Chu |
Microchip |
|
Charlie Lee |
Microchip |
|
Asbjørn Sæbø |
Nordic Semiconductor ASA |
|
David Hughes |
Broadcom |
|
Sherry Smith |
Broadcom |
|
Łukasz Rymanowski |
Codecoup |
|
Grzegorz Kołodziejczyk |
Codecoup |
|
Morteza Rahchamani |
Arm |
|
Frank Yerrace |
Microsoft |
|
Dong Jianli |
Oppo |
|
Yao Wang |
Barrot |
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–2021. 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. 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 requires the Generic Attribute Profile (GATT) described in [2]. This service is not dependent on other services.
1.3. Bluetooth Core Specification release compatibility
This service is compatible with Bluetooth Core Specification, Version 5.2 [2] or later.
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 the client and server.
Table 1.1 summarizes additional GATT sub-procedure requirements beyond those required by all GATT servers on Unenhanced Attribute Protocol (ATT) bearers.
Requirements in this section are defined as “Mandatory” (M), “Optional” (O), “Excluded” (X), and “Conditional” (C.n). Conditional requirements (C.n) are listed directly below the table in which they appear.
|
GATT Sub-Procedure |
Requirements |
|---|---|
|
Write Characteristic Value |
M |
|
Notifications |
M |
|
Read Characteristic Descriptors |
M |
|
Write Characteristic Descriptors |
M |
If the server supports characteristic values larger than the minimum (ATT_MTU -1) for the Unenhanced ATT bearer, then the server should support the Read Long Characteristic Values GATT sub-procedure if not already required by the Bluetooth Core Specification [2].
1.5. Transport dependencies
This specification does not impose any transport requirements. If reliability of Notifications is required (See Volume 3, Part F, Section 3.3.2 in [2]), higher layers can require Enhanced ATT bearer support.
1.6. Application error codes
This service does not define any ATT application error codes.
1.7. Byte transmission order
All characteristics used with this service shall be transmitted with the least significant octet (LSO) first (i.e., little endian). The LSO is identified in the characteristic definitions in Bluetooth Assigned Numbers [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.
1.9. Terminology
Table 1.2 defines terms that are needed to understand features used in this service. This service also uses terms that are defined in the Basic Audio Profile (BAP) [3].
|
Term |
Definition |
|---|---|
|
Audio Location |
Defined in [3]. |
|
broadcast Audio Stream |
Defined in [3]. |
|
Context Type |
A bitfield of values that, when set to 0b1 for a bit, describes audio data as being intended for the use case represented by that bit. Context Type values are defined in Bluetooth Assigned Numbers [1]. |
|
EATT |
An ATT bearer feature introduced in Volume 3, Part F, Section 3.2.11 in [2] |
|
Enhanced ATT bearer |
An ATT bearer using the Enhanced Credit Based Flow Control Logical Link Control and Adaptation Protocol (L2CAP) channel mode introduced in Volume 3, Part A, Section 10.2 in [2] |
|
Metadata |
Defined in [3] |
|
PAC record |
A set of parameter values that denote server audio capabilities. |
|
Supported_Sampling_Frequencies |
Defined in [3] |
|
Unenhanced ATT bearer |
An ATT bearer not using the Enhanced Credit Based Flow Control L2CAP channel mode introduced in Volume 3, Part A, Section 10.2 in [2] |
|
unicast Audio Stream |
Defined in [3] |
2. Service
2.1. Declaration
There shall be no more than one instance of the Published Audio Capabilities Service (PACS) on a server.
PACS should be a «Primary Service» and the service universally unique identifier (UUID) shall be set to «Published Audio Capabilities» as defined in [1].
2.2. Behavior
PACS can be instantiated on devices that can accept the establishment of unicast Audio Streams or devices that can receive broadcast Audio Streams. Examples of such devices are speakers, headsets, hearing aids, and microphones.
Servers expose one or more sets of audio capabilities and audio availability. Sets of audio capabilities, known as Published Audio Capability (PAC) records, are exposed by using either the Sink PAC characteristic or Source PAC characteristic. Clients can discover and read these characteristics, and servers can notify these characteristics.
Audio availability is exposed using the Available Audio Contexts characteristic. Clients can discover and read this characteristic, and servers can notify this characteristic. Audio availability represents the server’s determination of whether it considers itself available to accept the establishment of a unicast Audio Stream based on classifications of the use cases intended for such Audio Streams.
Audio capabilities, exposed in PAC records, represent the server audio capabilities independent of available resources at any given time. Audio capabilities do not distinguish between unicast Audio Streams or broadcast Audio Streams.
The server may expose multiple supported values for a given parameter in a PAC record where the format of that parameter value allows, such as bitfields.
When exposing support for multiple values in a parameter within a PAC record, the server shall support all possible combinations of that parameter value with the other parameter values contained in the same PAC record (e.g., whether single values, bitfields, or ranges).
For example, consider a server that exposes a PAC record where the server supports reception of audio data using the Sink PAC characteristic. The format of the parameters used in Table 2.1 is defined in Section 3.1 for the Sink PAC characteristic.
|
PAC Record |
i |
|
|---|---|---|
|
Codec_ID |
0x000000000D |
|
|
Codec_Specific_Capabilities_Length |
0x04 |
|
|
Codec_Specific_Capabilities |
0x00060103 |
|
|
Length |
0x03 |
|
|
Type: Supported_Sampling_Frequencies |
0x01 |
|
|
Value |
0x0006 |
|
|
Metadata_Length |
0x00 |
|
|
Metadata |
(empty) |
|
The Supported_Sampling_Frequencies [3] parameter value is a bitfield and has more than one value supported in the PAC record which is labelled i in Table 2.1. With the entire parameter value of 0x0006 representing the bit-wise OR of the individual bits 0x0002 and 0x0004, this means the server was exposing support for each supported bit in that bitfield in combination with the other parameters in the same PAC record. PAC record i would be represented, when expanded, as shown in Table 2.2.
|
PAC Record |
i (set 1) |
i (set 2) |
|
|---|---|---|---|
|
Codec_ID |
0x000000000D |
0x000000000D |
|
|
Codec_Specific_Capabilities_Length |
0x04 |
0x04 |
|
|
Codec_Specific_Capabilities |
0x00020103 |
0x000040103 |
|
|
Length |
0x03 |
0x03 |
|
|
Type: Supported_Sampling_Frequencies |
0x01 |
0x01 |
|
|
Value |
0x0002 |
0x0004 |
|
|
Metadata_Length |
0x00 |
0x00 |
|
|
Metadata |
(empty) |
(empty) |
|
For all characteristics defined in this specification, arrayed parameters are specified by using the following notation: ParameterA[i]. If more than one set of arrayed parameters is specified (e.g., ParameterA[i], ParameterB[i]), then the order of the parameters is as follows (unless noted otherwise): ParameterA[0], ParameterB[0], ParameterA[1], ParameterB[1], ParameterA[2], ParameterB[2], …ParameterA[n], ParameterB[n].
3. Service characteristics
This section defines the characteristic and descriptor requirements for PACS. The characteristics are shown in Table 3.1.
Requirements in this section are defined as “Mandatory” (M), “Optional” (O), “Excluded” (X), and “Conditional” (C.n). Conditional requirements (C.n) are listed directly below the table in which they appear.
|
Characteristic Name |
Requirement |
Mandatory Properties |
Optional Properties |
Security Permissions |
|---|---|---|---|---|
|
Sink PAC |
C.1 |
Read |
Notify |
Encryption required |
|
Sink Audio Locations |
C.2 |
Read |
Notify, Write |
Encryption required |
|
Source PAC |
C.1 |
Read |
Notify |
Encryption required |
|
Source Audio Locations |
C.3 |
Read |
Notify, Write |
Encryption required |
|
Available Audio Contexts |
M |
Read, Notify |
None |
Encryption required |
|
Supported Audio Contexts |
M |
Read |
Notify |
Encryption required |
- C.1:
-
Mandatory to support at least one of the Sink PAC characteristic or Source PAC characteristic.
- C.2:
-
Optional to support if the Sink PAC characteristic is supported, otherwise Excluded.
- C.3:
-
Optional to support if the Source PAC characteristic is supported, otherwise Excluded.
At least one Sink PAC characteristic shall exist on the server if the Sink PAC characteristic is supported.
A single Sink Audio Locations characteristic may exist on the server if the Sink PAC characteristic is supported.
At least one Source PAC characteristic shall exist on the server if the Source PAC characteristic is supported.
A single Source Audio Locations characteristic may exist on the server if the Source PAC characteristic is supported.
A single Available Audio Contexts characteristic shall exist on the server.
A single Supported Audio Contexts characteristic shall exist on the server.
3.1. Sink PAC
The Sink PAC characteristic is used to expose PAC records when the server supports reception of audio data.
When the server supports reception of audio data, the decision to expose all supported PAC records within a single Sink PAC characteristic or multiple Sink PAC characteristics is left to the implementation.
Examples of situations where a server that supports reception of audio data might want to expose multiple Sink PAC characteristics:
-
The server wanted to support a smaller maximum transmission unit (ATT_MTU, as defined in Volume 3, Part F, Section 3.2.8 in [2]) size. Exposing all supported PAC records in a single Sink PAC characteristic would require the server to increase its supported Maximum Transmission Unit (MTU) size to a value the server considered excessive.
-
The server wanted to expose support for proprietary audio capabilities (such as vendor-specific audio codecs, as denoted by the Codec_ID parameter value) separately from support for non- vendor-specific audio capabilities and used separate Sink PAC characteristics to expose such support.
-
The server wanted to minimize the amount of data to be transferred, when sending notifications to a client that the Sink PAC characteristic value changed, by exposing the audio capabilities likely to change quicker than others in separate Sink PAC characteristics.
The Sink PAC characteristic format is defined in Table 3.2.
|
Parameter |
Size (Octets) |
Description |
|---|---|---|
|
Number_of_PAC_records |
1 |
Number of PAC records, [i], in this characteristic. |
|
Codec_ID[i] |
5 |
Octet 0: Coding Format of the [ith] PAC record. Coding_Format values are defined in Bluetooth Assigned Numbers [1]. Octet 1–2: Company_ID value of the [ith] PAC record. Company_ID values are defined in Bluetooth Assigned Numbers [1]. Shall be 0x0000 if octet 0 is not 0xFF. Octet 3–4: Vendor-specific codec_ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF. |
|
Codec_Specific_Capabilities_Length[i] |
1 |
Length, in octets, of the Codec_Specific_Capabilities value of the [ith] PAC record. Shall be 0x00 if the Codec_Specific_Capabilities value of the [ith] PAC record is empty. |
|
Codec_Specific_Capabilities[i] |
Varies |
Codec_Specific_Capabilities value of the [ith] PAC record. |
|
Metadata_Length[i] |
1 |
Length of the Metadata field of the [ith] PAC record. Shall be 0x00 if the Metadata value of the [ith] PAC record value is empty. |
|
Metadata[i] |
Varies |
Length-type-value (LTV)-formatted Metadata applicable to the [ith] PAC record. Shall exist only if the value of the Metadata_Length field is not 0x00. |
3.1.1. Sink PAC behavior
The Sink PAC characteristic returns its characteristic value when read by a client.
If the server supports changing a PAC record, the server shall support notifications for the Sink PAC characteristic instance containing the PAC record that can change, e.g., if the server has updated firmware, or if a new application supporting different codecs or different capabilities for currently supported codecs is installed, then the characteristic value could be updated.
If notifications are supported, the Sink PAC characteristic can be configured for notifications by using the GATT Write Characteristic Descriptors sub‑procedure on the Client Characteristic Configuration descriptor.
If the characteristic value changes when in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value to the client.
If the characteristic value changes when not in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value when reconnecting to a bonded client.
3.2. Sink Audio Locations
The Sink Audio Locations characteristic is used to expose the supported Audio Locations when the server supports reception of audio data.
The Sink Audio Locations characteristic format is defined in Table 3.3.
|
Parameter |
Size (Octets) |
Description |
|---|---|---|
|
Sink_Audio_Locations |
4 |
Device-wide bitmap of supported Audio Location values for all PAC records where the server supports reception of audio data. Audio Location values are defined in Bluetooth Assigned Numbers [1]. |
3.2.1. Sink Audio Locations behavior
The Sink Audio Locations characteristic returns its characteristic value when read by a client.
If the server supports local changes to the value of the Sink Audio Locations characteristic, the server shall support notifications of the Sink Audio Locations characteristic.
The server may support writes to the Sink Audio Locations characteristic value by clients.
If the server supports writes to the Sink Audio Locations characteristic by clients, the server shall support notifications of the Sink Audio Locations characteristic.
If writes are supported, the Sink Audio Locations characteristic can be written by a client.
If notifications are supported, the characteristic can be configured for notifications by using the GATT Write Characteristic Descriptors sub-procedure on the Client Characteristic Configuration descriptor.
If the characteristic value changes when in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value to the client.
If the characteristic value changes when not in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value when reconnecting to a bonded client.
3.2.1.1. Error Handling
If the server detects that the Sink_Audio_Locations parameter value, written by a client by using the GATT Write Characteristic Value sub-procedure, is not 4 octets in length, or if the parameter value written includes any RFU bits set to a value of 0b1, the server shall respond with an ATT Error Response and shall set the Error Code parameter to Write Request Rejected as defined in [4].
3.3. Source PAC
The Source PAC characteristic is used to expose PAC records when the server supports transmission of audio data.
When the server supports transmission of audio data, the decision to expose all supported PAC records within a single Source PAC characteristic or multiple Source PAC characteristics is left to the implementation.
Examples of situations where a server that supports transmission of audio data might want to expose multiple Source PAC characteristics:
-
The server wanted to support a smaller maximum transmission unit (ATT_MTU, as defined in Volume 3, Part F, Section 3.2.8 in [2]) size. Exposing all supported PAC records in a single Source PAC characteristic would require the server to increase its supported MTU size to a value the server considered excessive.
-
The server wanted to expose support for proprietary audio capabilities (such as vendor-specific audio codecs, as denoted by the Codec_ID parameter value) separately from support for non-vendor-specific audio capabilities and used separate Source PAC characteristics to expose such support.
-
The server wanted to minimize the amount of data to be transferred, when sending notifications to a client that the Source PAC characteristic value changed, by exposing the audio capabilities likely to change quicker than others in separate Source PAC characteristics.
The Source PAC characteristic format is defined in Table 3.4.
|
Parameter |
Size (Octets) |
Description |
|---|---|---|
|
Number_of_PAC_records |
1 |
Number of PAC records, [i], for this characteristic |
|
Codec_ID[i] |
5 |
Octet 0: Coding_Format value of the [ith] PAC record. Coding_Format values are defined in Bluetooth Assigned Numbers [1]. Octet 1–2: Company _ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF. Company_ID values are defined in Bluetooth Assigned Numbers [1]. Octet 3–4: Vendor-specific codec_ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF. |
|
Codec_Specific_Capabilities_Length[i] |
1 |
Length of the Codec_Specific_Capabilities value of the [ith] PAC record. Shall be 0x00 if the Codec_Specific_Capabilities value of the [ith] PAC record is empty. |
|
Codec_Specific_Capabilities[i] |
Varies |
Codec_Specific_Capabilities value of the [ith] PAC record. |
|
Metadata_Length[i] |
1 |
Length of the Metadata field of the [ith] PAC record. Shall be 0x00 if the Metadata value of the [ith] PAC record value is empty. |
|
Metadata[i] |
Varies |
LTV-formatted Metadata applicable to the [ith] PAC record. Shall exist only if the value of the Metadata_Length field is not 0x00. |
3.3.1. Source PAC behavior
The Source PAC characteristic returns its characteristic value when read by a client. The characteristic can be configured for notifications by using the GATT Write Characteristic Descriptors sub-procedure on the Client Characteristic Configuration descriptor if the server supports notifications of the Source PAC characteristic.
If the server supports changing a PAC record, the server shall support notifications for the Source PAC characteristic instance containing the PAC record that can change, e.g., if the server has updated firmware, or if a new application supporting different codecs or different capabilities for currently supported codecs is installed, then the characteristic value could be updated.
If the characteristic value changes when in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value to the client.
If the characteristic value changes when not in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value when reconnecting to a bonded client.
3.4. Source Audio Locations
The Source Audio Locations characteristic is used to expose the supported Audio Locations when the server supports transmission of audio data.
The Source Audio Locations characteristic format is defined in Table 3.5.
|
Parameter |
Size (Octets) |
Description |
|---|---|---|
|
Source_Audio_Locations |
4 |
Device-wide bitmap of supported Audio Location values for PAC records where the server supports transmission of audio data. Audio Location values are defined in Bluetooth Assigned Numbers [1]. |
3.4.1. Source Audio Locations behavior
The Source Audio Locations characteristic returns its characteristic value when read by a client.
If the server supports local changes to the value of the Source Audio Locations characteristic, the server shall support notifications of the Source Audio Locations characteristic.
The server may support writes to the Source Audio Locations characteristic value by clients.
If the server supports writes to the Source Audio Locations characteristic by clients, the server shall support notifications of the Source Audio Locations characteristic.
If writes are supported, the Source Audio Locations characteristic can be written by a client.
If notifications are supported, the characteristic can be configured for notifications by using the GATT Write Characteristic Descriptors sub-procedure on the Client Characteristic Configuration descriptor.
If the characteristic value changes when in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value to the client.
If the characteristic value changes when not in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value when reconnecting to a bonded client.
3.4.1.1. Error Handling
If the server detects that the Source_Audio_Locations parameter value, written by a client by using the GATT Write Characteristic Value sub-procedure, is not 4 octets in length, or if the parameter value written includes any RFU bits set to a value of 0b1, the server shall respond with an ATT Error Response and shall set the Error Code parameter to Write Request Rejected as defined in [4].
3.5. Available Audio Contexts
The Available Audio Contexts characteristic exposes the availability of the server for reception and/or transmission of unicast audio data associated with specific Context Types.
The determination of whether the server considers itself available is left to the implementation, unless defined by higher-layer specifications.
The Available Audio Contexts characteristic format is defined in Table 3.6.
|
Field |
Size (Octets) |
Description |
|---|---|---|
|
Available_Sink_Contexts |
2 |
Bitmask of audio data Context Type values available for reception. 0x0000 = server is not available to receive audio for any Context Type value. Context Type values are defined in Bluetooth Assigned Numbers [1]. |
|
Available_Source_Contexts |
2 |
Bitmask of audio data Context Type values available for transmission. 0x0000 = server is not available to transmit audio for any Context Type values. Context Type values are defined in Bluetooth Assigned Numbers [1]. |
3.5.1. Available Audio Contexts behavior
The Available Audio Contexts characteristic returns its characteristic value when read by a client.
The characteristic can be configured for notifications by clients by using the GATT Write Characteristic Descriptors sub-procedure on the Client Characteristic Configuration descriptor.
The server may expose different values of the Available Audio Contexts characteristic to each client.
If the corresponding bit in the Supported Audio Contexts characteristic value is not set to 0b1, the server shall not set a bit to 0b1 in the Available Audio Contexts characteristic value.
The server shall update the value of Available_Sink_Contexts and/or Available_Source_Contexts fields when a change in its availability occurs, as determined by the implementation or by a higher-layer specification.
If the characteristic value exposed for a client changes when in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value to the client.
If the characteristic value exposed for a client changes when not in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value when reconnecting to a bonded client.
3.6. Supported Audio Contexts
The Supported Audio Contexts characteristic exposes the server’s support for reception and/or transmission of unicast audio data associated with specific Context Types.
The value of the Supported Audio Contexts characteristic allows clients to determine whether the server supports a particular Context Type, which is distinct from the server’s availability to receive and/or transmit audio data associated with that Context Type as defined by the value of the Available Audio Contexts characteristic.
The Supported Audio Contexts characteristic format is defined in Table 3.7.
|
Field |
Size (Octets) |
Description |
|---|---|---|
|
Supported_Sink_Contexts |
2 |
Bitmask of audio data Context Type values supported for reception. Context Type values are defined in Bluetooth Assigned Numbers [1]. |
|
Supported_Source_Contexts |
2 |
Bitmask of audio data Context Type values supported for transmission. Context Type values are defined in Bluetooth Assigned Numbers [1]. |
3.6.1. Supported Audio Contexts behavior
The Supported Audio Contexts characteristic returns its characteristic value when read by a client.
If the server supports changes to its supported audio data Context Types, the server shall support notifications of the Supported Audio Contexts characteristic. The server shall update the value of Supported_Sink_Contexts and/or Supported_Source_Contexts fields if a change in its supported Context Types occurs, for example, as the result of a software update.
If notifications are supported, the Supported Audio Contexts characteristic can be configured for notifications by clients by using the GATT Write Characteristic Descriptors sub-procedure on the Client Characteristic Configuration descriptor.
If the characteristic value changes when in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value to the client.
If the characteristic value changes when not in a connection, and the value of the Client Characteristic Configuration descriptor is configured for notifications, the server shall notify the new characteristic value when reconnecting to a bonded client.
4. SDP interoperability
When PACS is supported over Basic Rate/Enhanced Data Rate (BR/EDR), the attributes defined in Table 4.1 shall be included in the Service Discovery Protocol (SDP) service record.
|
Item |
Definition |
Type |
Value |
Requirement |
|---|---|---|---|---|
|
Service Class ID List |
– |
– |
– |
M |
|
Service Class #0 |
– |
UUID |
«Published Audio Capabilities» |
M |
|
Protocol Descriptor List |
– |
Data Element Sequence |
– |
M |
|
Protocol #0 |
– |
UUID |
«L2CAP» |
M |
|
Parameter #0 for Protocol #0 |
Protocol/Service Multiplexer (PSM) |
uint16 |
PSM = ATT |
M |
|
Protocol #1 |
– |
UUID |
«ATT» |
M |
|
Additional Protocol Descriptor List |
– |
Data Element Sequence |
– |
C.1 |
|
Protocol Descriptor List |
– |
Data Element Sequence |
– |
C.1 |
|
Protocol #0 |
– |
UUID |
«L2CAP» |
C.1 |
|
Parameter #0 for Protocol #0 |
PSM |
uint16 |
PSM = EATT |
C.1 |
|
Protocol #1 |
– |
UUID |
«ATT» |
C.1 |
|
BrowseGroupList |
– |
– |
PublicBrowseRoot Other browse UUIDs may also be included in the list. |
M |
- C.1:
-
Mandatory to support if EATT is supported, otherwise Excluded.
5. Acronyms and abbreviations
|
Acronym/Abbreviation |
Meaning |
|---|---|
|
ATT |
Attribute Protocol |
|
BAP |
Basic Audio Profile |
|
BR/EDR |
Basic Rate/Enhanced Data Rate |
|
EATT |
Enhanced Attribute Protocol |
|
GATT |
Generic Attribute Profile |
|
L2CAP |
Logical Link Control and Adaptation Protocol |
|
LSO |
least significant octet |
|
MTU |
Maximum Transmission Unit |
|
PAC |
Published Audio Capability |
|
PACS |
Published Audio Capabilities Service |
|
PDU |
Protocol Data Unit |
|
PSM |
Protocol Service Multiplexer |
|
RFU |
Reserved for Future Use |
|
SDP |
Service Discovery Protocol |
|
UUID |
universally unique identifier |
6. References
Bibliography
[1] Bluetooth Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers
[2] Bluetooth Core Specification, Version 5.2 or later
[3] Basic Audio Profile Specification, Version 1
[4] Bluetooth Core Specification Supplement, Version 9 or later