• 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

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.

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

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.

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.

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

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.

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.

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.

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

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.

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

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

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.

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

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

[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