Hearing Access Profile

This profile requires the Common Audio Profile (CAP) [4], Basic Audio Profile (BAP) [3], Volume Control Profile (VCP) [11], Microphone Control Profile (MICP) [12], Coordinated Set Identification Profile (CSIP) [6], Call Control Profile (CCP) [13], and the Generic Attribute Profile (GATT) [1].

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.

This profile requires Bluetooth Core Specification 5.2 [1] or later for the Hearing Aid (HA), Hearing Aid Unicast Client (HAUC) and Hearing Aid Remote Controller (HARC) roles (see Section 3, Section 4, and Section 5). If the Immediate Alert Client (IAC) role (see Section 6) is the only HAP role implemented on a device, this profile requires Bluetooth Core Specification 4.2 [9] or later.

The interpretation rules defined in Section 1.5 of [3] apply throughout this specification.

Table 1.1 defines terms that are needed to understand features used in this specification.

HAP defines the following profile roles:

This profile does not specify a role for transmitting broadcast audio streams using the LE Isochronous Channels feature, because there are no additional requirements beyond BAP and CAP.

Table 2.1 shows the conformance requirements for HAP roles with CAP roles.

All IAC profile requirements are specified in Section 6.

Table 2.2 shows the conformance requirements for HAP roles with other LE Audio profile roles. A dash in a table cell indicates that HAP makes no change to the requirement as specified in CAP. All other cells indicate requirements that are in addition to what is specified in CAP.

C.1: Mandatory if the HA is capable of being part of a Binaural Hearing Aid Set; otherwise Excluded.

C.2: Mandatory if the HA supports the BAP Audio Source role (see Section 3.7); otherwise Excluded.

Additional requirements for the LE Audio profile roles in Table 2.2 are specified in Section 3 to Section 5 for each HAP role. If a role is not mentioned in these sections, it means that the HAP does not specify additional requirements beyond the mandatory requirements specified in the corresponding profile specification.

This profile does not impose limitations/restrictions on any combination of roles that may be concurrently occupied by a device.

This profile does not impose additional topology limitation/restrictions beyond those defined by other profiles implemented on a device and referenced here.

This profile shall operate over an LE transport only.

An HA may optionally support the following feature:

This section describes requirements for the Low Energy transport.

The HA shall support the LE 2M PHY (Physical Layer).

To improve the performance of the mandatory LC3 codec at a 10 ms frame duration over a transport interval of 7.5 ms, an HA shall support the parameters in Table 3.1 when accepting the establishment of a Connected Isochronous Stream (CIS) or synchronizing to a Broadcast Isochronous Stream (BIS).

An HA may support LC3 codec configurations with a 7.5 ms frame duration.

If the HA supports the BAP Audio Source role (see Section 3.7), and the HA has accepted the establishment of a CIS configured with the parameters shown in Table 3.1, then the HA shall support sending unsegmented Service Data Units (SDUs) to prevent an undesirable increase of the frame loss rate (i.e., the HA sends one SDU in a given PDU).

The HA shall support accepting the establishment of a CIS and synchronizing to a BIS with the parameters in Table 3.2.

The maximum SDU size referred to in Table 3.1 and Table 3.2 is equal to the maximum size of the LC3 Media Packet that is supported by the HA (see Section 4.2 in [3]), and is calculated as:

Supported_Max_Codec_Frames_Per_SDU × (octets2‐3ofSupported_Octets_Per_Codec_Frame).

Supported_Max_Codec_Frames_Per_SDU and Supported_Octets_Per_Codec_Frame are the values of the LTV structures defined in Bluetooth Assigned Numbers [2] and exposed in PAC (Published Audio Capabilities) records.

If the HA is in one of the Generic Access Profile (GAP) discoverable modes, the HA shall include the Hearing Access Service Universally Unique Identifier (UUID) defined in [2] in the Service UUID Advertising Data (AD) Type field of the advertising data or scan response data.

If the HA is in one of the GAP connectable modes and is using a resolvable private address, the HA shall not include the Hearing Access Service UUID in the Service UUID AD type field of the advertising data or scan response.

If the HA is in one of the GAP discoverable modes, the HA may include the value of the Appearance characteristic in its advertising data or scan response data for an enhanced user experience.

If the HA is in one of the GAP connectable modes and is using a resolvable private address, the HA shall not include the value of the Appearance characteristic in its advertising data or scan response data.

If the HA is part of a Binaural Hearing Aid Set, the HA shall satisfy the following requirements:

This section specifies additional mandatory requirements beyond those specified by BAP.

The HA shall support the BAP Audio Sink role.

The HA may support the BAP Audio Source role. By supporting the BAP Audio Source role, the HA can stream audio to the HAUC. In a Binaural Hearing Aid Set of two hearing aids, zero, one or both hearing aids may support this feature. When both hearing aids support this feature and audio streaming from the HA to the HAUC is required, the HAUC can decide to use both or only one of the hearing aids as a BAP Audio Source.

If the HA supports the BAP Audio Source role, the HA shall support the BAP Audio Source and BAP Audio Sink role concurrently and shall support the establishment of a bidirectional CIS with a HAUC.

If the HA is part of a Binaural Hearing Aid Set, the HA shall set at least one of the Front Left bit or the Front Right bit to a value of 0b1 in the Sink Audio Locations characteristic value as defined in [2].

A Banded Hearing Aid in the HA role shall set both the Front Left and the Front Right bits to the value of 0b1 in the Sink Audio Locations characteristic value.

This specification does not define any requirements for setting or define any behavior associated with the audio location bits that may be set in the Source Audio Locations characteristic that is included by a device implementing the HA role.

The HA shall support the Audio Capability Settings defined as mandatory for the Unicast Server role in Table 3.5 of BAP (see [3]). In addition, the HA shall support the corresponding mandatory Quality of Service (QoS) configuration requirements for the Unicast Server role specified in Table 5.2 of BAP (see [3]).

The HA should set to 0b1 at least the bits representing ‘Conversational’, ‘Media’, and ‘Live’ Context Types in the Supported_Sink_Contexts field of the Supported Audio Contexts characteristic in Published Audio Capabilities Service (PACS), in addition to the ‘Unspecified’ Context Type mandated by BAP. The values of Context Types are defined in [2].

The HA shall support a Presentation Delay range in the Codec Configured state that includes the value of 20ms, in addition to the requirement specified in Table 5.2 of [3].

The HA shall be capable of rendering audio streams that use a mandatory LC3 configuration from Table 3.11 of BAP no later than 20ms after the SDU Synchronization reference (see Section 7.1.1 of [3]).

This section specifies additional mandatory requirements beyond those specified by VCP.

The Volume Control Service (VCS) is used to expose the volume level of the audio at the hearing aid speaker (also known as the receiver in hearing aid terminology). How the Volume State characteristic affects the internal volume control of a hearing aid is implementation specific. It could act as the overall volume control or it could operate on other volume levels as well; for example, it could control only the volume level of a received audio stream.

An HA may instantiate one or more instances of Audio Input Control Service (AICS) to expose control of the gain of its inputs to a Volume Controller.

For example, if an HA intends to expose the volume level of the sound captured by its microphone, the volume level of the sound captured by an IEC 60118-4 compliant audio-frequency induction loop, (commonly known as a telecoil), and the volume level of Audio Streams as defined in [3], then it will instantiate three instances of AICS with the value of the Audio Input Description characteristics set to Microphone, Telecoil, and Bluetooth LE Audio, respectively. This example is depicted in Figure 3.1 where solid lines represent audio flow and dashed lines represent GATT include definitions between services.

If the HA supports the Volume Balance feature (see Section 3.1) and the HA is part of a Binaural Hearing Aid Set, the HA shall instantiate one instance of Volume Offset Control Service (VOCS).

If the HA supports the Volume Balance feature (see Section 3.1) and the HA is a Banded Hearing Aid, the HA shall instantiate two instances of VOCS.

Figure 1. Figure 3.1: Example of VCS, AICS, and VOCS in an HA

If the HA supports the BAP Audio Source role (see Section 3.7), the HA shall expose one instance of the Microphone Input Control Service (MICS), and optionally one instance of AICS, to enable the peer device in the MICP Microphone Controller role to mute/unmute the microphone that picks up the user’s voice.

The HA may expose an instance of MICS and an instance of AICS to control the capture of ambient sound.

This section describes requirements for the Low Energy transport.

The HAUC shall support the LE 2M PHY.

To provide interoperability with a device in the HA role that does not support an LC3 codec configuration with a 7.5 ms frame duration, a device in the HAUC role shall support establishing an isochronous stream with the parameters listed in Table 4.1. These parameters make it possible to avoid segmentation of SDUs and avoid an undesirable increase of the frame loss rate.

According to the Bluetooth Core Specification v5.2 [1], it is possible to avoid segmentation when framed ISOAL is used for unicast or broadcast Audio Streams by setting an appropriate Max_PDU value. The maximum value for Max_PDU is the maximum payload size of an Isochronous Physical Channel PDU that is 251 octets (see Volume 6, Part B, Section 2.6 in [1]).

The maximum SDU size referred to in Table 4.1 is equal to the maximum size of the LC3 Media Packet (see Section 4.2 in [3]) that is supported by the HAUC, and can be calculated as

(Octets_Per_Codec_Frame × (numberofbitssettoavalueof0b1inAudio_Channel_Allocation) × Codec_Frame_Blocks_Per_SDU).

Octets_Per_Codec_Frame, Audio_Channel_Allocation, and Codec_Frame_Blocks_Per_SDU are the values of the LTV structures defined in Bluetooth Assigned Numbers [2].

The HAUC shall perform Primary Service Discovery on the HA by using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure.

The HAUC shall discover the Hearing Access Service.

This section specifies additional mandatory requirements beyond those specified by BAP.

The HAUC shall support the BAP Audio Source role.

The HAUC shall support the Codec Configuration Settings defined as mandatory for the Unicast Client role in Table 3.11 of BAP (see [3]) and the corresponding mandatory QoS configuration requirements for the Unicast Client role specified in Table 5.2 of BAP (see [3]).

The HAUC shall support establishing two unicast Audio Streams: one for the Front Left Audio Location and one for the Front Right Audio Location (i.e., a CIG with two unidirectional CISes). Each Audio Stream transports one Audio Channel from the HAUC to each of the two HAs of a Binaural Hearing Aid Set, or to a Banded Hearing Aid.

Note: The HAUC can optionally support sending two Audio Channels in one unicast Audio Stream as specified in BAP (see Section 4 in [3]).

If the HAUC supports the CCP Call Control Server role, it shall support at least one bidirectional CIS and the BAP Audio Sink role. The HAUC should use a bidirectional CIS instead of two CISes in opposite directions to optimize bandwidth usage and power consumption.

This section describes the requirements when using this profile over the Low Energy transport.

The HARC shall support the LE 2M PHY.

The HARC shall discover the Hearing Access Service.

The HAS characteristic discovery requirements are listed in Table 5.1.

C.1: Mandatory if the HARC supports the Active Preset Index characteristic; otherwise Optional.

C.2: Mandatory if the HARC supports the Preset Control Point characteristic; otherwise Excluded.

If the HARC supports the Hearing Aid Features characteristic and if the HA supports notifications of this characteristic, then the HARC shall register for notifications.

If the HARC supports the Preset Control Point characteristic and the Read Preset procedure and an enhanced ATT bearer exists between the client and the server, then the HARC shall register for indications and may register for notifications of this characteristic.

If the HARC supports the Preset Control Point characteristic and the Read Preset procedure and only the unenhanced ATT bearer exists between the client and the server, then the HARC shall register for indications of this characteristic.

The procedures specified in this section are used by a HARC to control the presets on an HA.

An HA may not support all opcodes of the Hearing Aid Preset Control Point characteristic. The HARC shall read the Hearing Aid Features characteristic to determine which opcodes are supported (see [5]).

If the HARC supports the Preset Control Point characteristic, the HARC shall satisfy the support requirements for the HAP procedure listed in Table 5.2.

C.1: Mandatory if the HARC supports the Set Active Preset procedure OR Write Preset Name procedure; otherwise Optional.

C.2: Mandatory if the HARC supports the Active Preset Index characteristic; otherwise Optional.

C.3: Mandatory for the HARC to support at least one of these procedures.

C.4: Mandatory if the HARC supports the Set Active Preset procedure; otherwise Excluded.

C.5: Mandatory if the HARC supports the Set Next Preset procedure; otherwise Excluded.

C.6: Mandatory if the HARC supports the Set Previous Preset procedure; otherwise Excluded.

Before executing the Write Preset Name procedure, the Set Active Preset procedure, or the Set Active Preset – Synchronized Locally procedure, the HARC shall execute the Read Presets Request procedure to read the preset records exposed by the server or use the most recent cached value of the list of preset records.

If the HARC supports the Read Presets Request procedure, then the HARC shall support an ATT_MTU value no less than 49.

When a procedure from Table 5.2 is composed of more than one ATT PDU exchange, the HARC shall consider the procedure as failed if the ATT bearer is terminated before all the ATT PDUs have been exchanged, or if the HA is unresponsive for an application-defined amount of time. When a procedure from Table 5.2 fails, the HARC may try again to execute the procedure after an application-defined amount of time.

If only one HA of a Binaural Hearing Aid Set is available at the time the HARC intends to execute any of the procedures in Table 5.2, except for Write Preset Name procedure, the HARC should execute the procedure with the available HA. An HARC can consider an HA as available when one of the following statements is true:

The HARC shall not execute the Write Preset Name procedure when only one HA of the Binaural Hearing Aid Set is available.

The two HAs of a Binaural Hearing Aid Set may expose different preset records. In this case, the Independent Presets flag will be set to 0b1, and the HARC will control the presets on the two HAs independently, as defined in Section 5.5.3 to Section 5.5.6.

If the HARC supports the Active Preset Index characteristic, then the HARC shall register for notifications of this characteristic.

The HARC may use the Read Presets Request procedure to retrieve the name of the active preset after reading the Active Preset Index characteristic or receiving a notification of the Active Preset Index characteristic.

The IAC shall perform primary service discovery on the HA by using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure to discover the Immediate Alert Service.

The IAC shall use either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure to discover the Alert Level characteristic.

If a device supports the IAC role and supports the HAUC role, and the HAUC fails to set up audio streams because of the non-availability of the HA for a particular Context Type value, as described in Section 7.3.1.2.1 of CAP (see [4]), the IAC should send an appropriate level of alert to the HA by writing a “Mild Alert” or “High Alert” value to the Alert Level characteristic to gain the attention of the hearing aid wearer.

A device that supports the IAC role and the HAUC role and the CCP Client role should inform an HA that does not support the CCP Client role of an incoming call by writing a “Mild Alert” or “High Alert” value to the Alert Level characteristic to gain the attention of the hearing aid wearer. The hearing aid wearer can then accept the incoming call on the HAUC device.

When the IAC role is implemented on a device that does not support the HAUC role, the IAC should send an appropriate level of alert to the HA by writing a “Mild Alert” or “High Alert” value to the Alert Level characteristic to gain the attention of the hearing aid wearer. For example, a doorbell that does not support audio streaming can connect and write “High Alert” to the Alert Level characteristic.

The security requirements for all characteristics specified by HAS and IAS shall be set to LE Security Mode 1 Level 2 (see Volume 3, Part C, Section 10.2.1 in [1]).

Access to all characteristics defined in HAS and IAS shall require an encryption key with at least 128 bits of entropy, derived from any of the following:

Other security requirements are specified in the profile specifications referred to in Table 2.2 for the HA role.

Security requirements are specified in the profile specifications referred to in Table 2.2 for the HAUC role.

Security requirements are specified in the profile specifications referred to in Table 2.2 for the HARC role.

The IAC shall support Bondable mode, defined in Volume 3, Part C, Section 9.4.3 in [9].

The IAC should support the Bonding procedure defined in Volume 3, Part C, Section 9.4.4 in [9].

The IAC should accept the LE Security mode and the LE Security Level combination that is requested by the HA.

If the IAC is using Privacy, the IAC shall distribute its Identity Address and Identity Resolving Key (IRK) [9].