Published Audio Capabilities Service

Revision: v1.0.1
Revision Date: 2022-06-21
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.
v1.0.1	2022-06-21	Adopted by the Bluetooth SIG Board of Directors.

Version History

Versions		Changes
v1.0 to v1.0.1		Incorporated errata E18614, E18778, E18779.

Acknowledgments

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. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”

Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.

Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.

Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.

Copyright © 2017–2022. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.

1. Introduction

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

Table 1.1. Additional GATT sub-procedure requirements on Unenhanced ATT bearers

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]

Table 1.2. Terminology

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)

Table 2.1. Example of a PAC record where the server supports reception of audio data

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)

Table 2.2. Representation of expanded PAC record in Table 2.1

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.

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

Table 3.1. PACS characteristics

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. Shall be ≥ 1.
Codec_ID[i]	5	Octet 0: Coding Format of the [i^th] PAC record. Coding_Format values are defined in Bluetooth Assigned Numbers [1]. Octet 1–2: Company_ID value of the [i^th] 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 [i^th] 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 [i^th] PAC record. Shall be 0x00 if the Codec_Specific_Capabilities value of the [i^th] PAC record is empty.
Codec_Specific_Capabilities[i]	Varies	Codec_Specific_Capabilities value of the [i^th] PAC record.
Metadata_Length[i]	1	Length of the Metadata field of the [i^th] PAC record. Shall be 0x00 if the Metadata value of the [i^th] PAC record value is empty.
Metadata[i]	Varies	Length-type-value (LTV)-formatted Metadata applicable to the [i^th] PAC record. Shall exist only if the value of the Metadata_Length field is not 0x00.

Table 3.2. Format of Sink PAC characteristic

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].

Parameter

Size (Octets)

Description

Sink_Audio_Locations

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].

Table 3.3. Format of Sink Audio Locations characteristic

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.

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. Shall be ≥ 1.
Codec_ID[i]	5	Octet 0: Coding_Format value of the [i^th] PAC record. Coding_Format values are defined in Bluetooth Assigned Numbers [1]. Octet 1–2: Company _ID value of the [i^th] 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 [i^th] 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 [i^th] PAC record. Shall be 0x00 if the Codec_Specific_Capabilities value of the [i^th] PAC record is empty.
Codec_Specific_Capabilities[i]	Varies	Codec_Specific_Capabilities value of the [i^th] PAC record.
Metadata_Length[i]	1	Length of the Metadata field of the [i^th] PAC record. Shall be 0x00 if the Metadata value of the [i^th] PAC record value is empty.
Metadata[i]	Varies	LTV-formatted Metadata applicable to the [i^th] PAC record. Shall exist only if the value of the Metadata_Length field is not 0x00.

Table 3.4. Format of Source PAC characteristic

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.

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].

Parameter

Size (Octets)

Description

Source_Audio_Locations

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].

Table 3.5. Format of Source Audio Locations characteristic

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.

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].

Field

Size (Octets)

Description

Available_Sink_Contexts

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

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].

Table 3.6. Format of Available Audio Contexts characteristic

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].

Field

Size (Octets)

Description

Supported_Sink_Contexts

Bitmask of audio data Context Type values supported for reception.

Context Type values are defined in Bluetooth Assigned Numbers [1].

Supported_Source_Contexts

Bitmask of audio data Context Type values supported for transmission.

Context Type values are defined in Bluetooth Assigned Numbers [1].

Table 3.7. Format of Supported Audio Contexts characteristic

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.

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

Table 4.1. SDP record

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

Table 5.1. Acronyms and abbreviations

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

Published Audio Capabilities Service

Bluetooth® Service Specification

Revision History

Version History

Acknowledgments

1. Introduction

1.1. Conformance

1.2. Service dependencies

1.3. Bluetooth Core Specification release compatibility

1.4. GATT sub-procedure requirements

1.5. Transport dependencies

1.6. Application error codes

1.7. Byte transmission order

1.8. Language

1.8.1. Language conventions

1.8.2. Reserved for Future Use

1.8.3. Prohibited

1.9. Terminology

2. Service

2.1. Declaration

2.2. Behavior

3. Service characteristics

3.1. Sink PAC

3.1.1. Sink PAC behavior

3.2. Sink Audio Locations

3.2.1. Sink Audio Locations behavior

3.2.1.1. Error Handling

3.3. Source PAC

3.3.1. Source PAC behavior

3.4. Source Audio Locations

3.4.1. Source Audio Locations behavior

3.4.1.1. Error Handling

3.5. Available Audio Contexts

3.5.1. Available Audio Contexts behavior

3.6. Supported Audio Contexts

3.6.1. Supported Audio Contexts behavior

4. SDP interoperability

5. Acronyms and abbreviations

6. References

Bibliography

Bluetooth^® Service Specification