Revision: v1.0

Revision Date: 2022-06-07

Prepared By: Hearing Aid Working Group

Abstract:

The Hearing Access Service (HAS) is used to identify hearing aids and to control hearing aid presets.

Revision History

Revision Number

Date (yyyy-mm-dd)

Comments

v1.0

2022-06-07

Adopted by the Bluetooth SIG Board of Directors.

Acknowledgments

Name

Company

Bjarne Klemmensen

Demant A/S

Nick Hunn

GN Hearing A/S

Georg Dickmann

Sonova AG

Andrew Estrada

Sony Corporation

Jeff Solum

Starkey

Riccardo Cavallari

WS Audiology Denmark A/S

 

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 © 2016–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

The Hearing Access Service is used to identify a hearing aid and optionally to control hearing aid presets.

A hearing aid preset represents a configuration of the hearing aid signal processing parameters tailored to a specific listening situation. This service exposes the names (Unicode Transformation Format - UTF-8 strings) of the presets supported by a hearing aid. The names are usually localized in the language of the user.

The preset used by a hearing aid can be changed by user action on the hearing aid or on a client device (e.g., smartphone, remote controller), or autonomously by the hearing aid.

The hearing aid can modify the list of preset records by adding and deleting presets, changing their names, and changing their availability over time. As defined in this specification, client devices are informed about these changes.

Examples of hearing aid presets are “Universal,” “Noisy environment,” “Outdoor,” and “Reverberant room.” The names and functionality of these presets are manufacturer specific.

1.1. Language

1.1.1. Language conventions

The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, 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.

note

Text that calls attention to a particular point, requirement, or implication or reminds the reader of a previously mentioned point. It is useful for clarifying text to which the reader ought to pay special attention. It shall not include requirements. A note begins with “Note:” and is set off in a separate paragraph. When interpreting the text, the relevant requirement shall take precedence over the clarification.

If there is a discrepancy between the information in a figure and the information in other text of the specification, the text prevails. Figures are visual aids including diagrams, message sequence charts (MSCs), tables, examples, sample data, and images. When specification content shows one of many alternatives to satisfy specification requirements, the alternative shown is not intended to limit implementation options. Other acceptable alternatives to satisfy specification requirements may also be possible.

1.1.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.1.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.2. Table requirements

Requirements in this section are defined as "Mandatory" (M), "Optional" (O), "Excluded" (X), “Not Applicable” (N/A), or "Conditional" (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.

1.3. 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.4. Byte transmission order

All characteristics used with this service shall be transmitted with the least significant octet (LSO) first (i.e., little endian). Where the format is described in tables in this document, the LSO is the first octet in the topmost field of the table; the most significant octet (MSO) is the last octet in the bottommost field of the table. Where characteristics are defined in the GATT Specification Supplement (GSS), see GSS Section 2.2 [5].

1.5. Terminology

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

Term

Definition

Active preset

The preset that the hearing aid is using.

Active preset record

The preset record that corresponds to the active preset.

Banded Hearing Aid

Two hearing aids with a connection to one another that expose a single Bluetooth radio interface.

Binaural Hearing Aid Set

Two hearing aids that form a Coordinated Set, one for the right ear and one for the left ear of the user. Typically used by a user with bilateral hearing loss.

Monaural Hearing Aid

A single hearing aid for the left or the right ear. Typically used by a user with unilateral hearing loss.

Preset record

The data structure that contains the information about presets exposed by a server.
Table 1. Table 1.1: Terminology

2. Service

2.1. Service dependencies

The Hearing Access Service does not depend on any other service.

2.2. Bluetooth Core Specification release compatibility

This specification is compatible with the Bluetooth Core Specification version 4.2 and later [2].

2.3. Transport dependencies

This service shall operate on the Bluetooth Low Energy (LE) transport only.

Notifications that are sent using GATT are considered unreliable when used with an Unenhanced Attribute Protocol (ATT) bearer, because the client will discard them if they cannot be processed due to buffer overflows (see Volume 3, Part F, Section 3.3.2 in the Bluetooth Core Specification [2]).

An Enhanced ATT (EATT) bearer can be used where reliable notifications are required.

2.4. Attribute Profile error codes

This service defines the ATT application error codes listed in Table 2.1.

Name

Error Code

Description

Invalid Opcode

0x80

An invalid opcode has been used in a control point operation.

Write Name Not Allowed

0x81

The client executed the Write Preset Name procedure with an Index parameter corresponding to a read-only preset record.

Preset Synchronization Not Supported

0x82

The client executed a Synchronized Locally Hearing Aid Preset Control Point operation to a server that does not support Preset Synchronization (see Section 3.3).

Preset Operation Not Possible

0x83

The requested preset operation cannot be executed at this time. This could happen when the requested preset is incompatible with the state of operation of the hearing aid or the preset record is marked as unavailable.

Invalid Parameters Length

0x84

The client requested to write a valid opcode but with parameters of invalid length.
Table 2. Table 2.1: Attribute Protocol Application error codes defined by this service

2.5. GATT sub-procedure requirements

The requirements in this section represent a minimum set of requirements for a server. Other Generic Attributes Profile (GATT) sub-procedures may be used if supported by both client and server.

Table 2.2 summarizes additional GATT sub-procedure requirements beyond those required by all GATT servers.

GATT Sub-Procedure

Requirements

Write Characteristic Value

C.1

Notifications

C.2

Indications

C.1

Read Characteristic Descriptors

C.1

Write Characteristic Descriptors

C.1
Table 3. Table 2.2: GATT Sub-procedure requirements

C.1: Mandatory if the Hearing Aid Preset Control Point characteristic is supported; otherwise Optional.

C.2: Mandatory if the Hearing Aid Preset Control Point characteristic and EATT are both supported; otherwise Optional.

The server shall support a minimum ATT_MTU value of 49 octets.

2.6. Declaration

The Hearing Access Service shall be instantiated as a «Primary Service».

The service Universally Unique Identifier (UUID) shall be set to «Hearing Access Service» as defined in [1].

2.7. Behavior

Hearing aid presets are exposed by a server as a list of preset records. The format of a preset record is specified in Section 2.8.

By using Preset Control Point operations, a client can read the name of preset records and write the name of writable preset records. A client can also be notified of changes to the list of preset records exposed by a server.

Methods for setting the name of read-only preset records are implementation specific (for example, during manufacturing of the device).

A client may read the preset records to present their names on a display to the user. A client that cannot display preset names (e.g., a key-fob remote control without a display) may limit its functionality by only changing the hearing aid preset in use to the previous or next hearing aid preset in the list of preset records, using the appropriate Preset Control Point operations.

The hearing aid preset that the server is using is called the active preset. The Index field (see Section 2.8) of the active preset is exposed in the Active Preset Index characteristic. There cannot be more than one active preset at the same time. The active preset may be changed by the server (e.g., because of a user interaction with the server) or by a client, using one of the dedicated Preset Control Point operations.

In some scenarios that involve a Binaural Hearing Aid Set, it is desirable for a client to change the active preset on only one hearing aid and let that hearing aid relay the change to the other hearing aid in the Coordinated Set. A hearing aid that has this functionality uses the Hearing Aid Features characteristic to expose this capability to clients. This allows the client to connect to only one hearing aid, saving energy and time. To perform this, the client uses dedicated Preset Control Point operations for synchronizing a change to a preset (see Section 3.2.2.7 to Section 3.2.2.9).

The method to relay a preset change from one hearing aid to the other hearing aid is implementation specific.

2.8. Preset record

The preset record contains all the information about a hearing aid preset. The server shall maintain a list of preset records.

A preset record, when used in the procedures described in Section 3, shall have the format described in Table 2.3.

Field Name

Size (Octets)

Type

Index

1

uint8

Properties

1

struct

Name

1–40

UTF-8 string
Table 4. Table 2.3: Format of a preset record

The Index field uniquely identifies a preset record in the list of preset records. Allowed values are integers from 0x01 to 0xFF. The value 0x00 is used in the Active Preset Index characteristic (see Section 3.3) to indicate that no preset is used; therefore, the server shall not use the value 0x00 for the Index field of a preset record. The implementation shall arrange the list of preset records in order of increasing Index field. The Index values of preset records may not necessarily be consecutive.

The Properties field shall have the format described in Table 2.4.

Field Name

Bit(s)

Value

Writable

0

0b0 = The name of the preset cannot be written by the client

0b1 = The name of the preset can be written by the client

isAvailable

1

0b0 = The preset is unavailable

0b1 = The preset is available

RFU

2–7

RFU
Table 5. Table 2.4: Properties field format

The server shall not set the isAvailable field of the active preset to 0b0. The Index field of the active preset is exposed by the Active Preset Index characteristic (see Section 3.3).

The Name field is a UTF-8 string that contains the human-readable name of the preset.

When preset records are used in the procedures described in Section 3, one ATT PDU transports at most one preset record; therefore, the size of the variable-length Name field is not sent over the air and can be calculated by subtracting the sum of the fixed-length fields from the size of the Attribute Value field of the ATT PDU.

3. Service characteristics

This section defines the characteristic and descriptor requirements.

Characteristic Name

Requirement

Mandatory Properties

Optional Properties

Security Permissions

Hearing Aid Features

M

Read

Notify

Encryption required

Hearing Aid Preset Control Point

O

Write, Indicate

Notify (if EATT is supported)

Encryption required

Active Preset Index

C.1

Read, Notify

None

Encryption required
Table 6. Table 3.1: Hearing Access Service characteristics

C.1: Mandatory if Hearing Aid Preset Control Point is supported by the server; otherwise Excluded.

3.1. Hearing Aid Features

The value of the Hearing Aid Features characteristic exposes the features of the Hearing Access Service supported by the server.

The format of the Hearing Aid Features characteristic is a one octet bitfield, described in Table 3.2.

Field Name

Bit(s)

Value

Hearing Aid Type

0–1

0b00 = Binaural Hearing Aid

0b01 = Monaural Hearing Aid

0b10 = Banded Hearing Aid

0b11 = RFU

Preset Synchronization Support

2

0b0 = Preset Synchronization is not supported

0b1 = Preset Synchronization is supported

Independent Presets

3

0b0 = The list of preset records on this server is identical to the list of preset records in the other server of the Coordinated Set

0b1 = The list of preset records on this server may be different from the list of preset records in the other server of the Coordinated Set

Dynamic Presets

4

0b0 = the list of preset records does not change

0b1 = the list of preset records may change

Writable Presets Support

5

0b0 = The server does not support writable preset records

0b1 = The server supports writable preset records

–

6–7

RFU
Table 7. Table 3.2: Hearing Aid Feature characteristic value fields

The Hearing Aid Type field indicates if the server is part of a Binaural Hearing Aid Set, is a Monaural Hearing Aid, or is a Banded Hearing Aid (see Section 1.5).

The Preset Synchronization Support field indicates the capability of the server to relay active preset changes to the other server in the Binaural Hearing Aid Set. In a Binaural Hearing Aid Set, both, only one, or none of the servers may set the Preset Synchronization Support field to 0b1. The Preset Synchronization Support field shall be set to 0b0 if the Independent Presets field is set to 0b1, or if the Hearing Aid Type field is set to 0b01 (Monaural Hearing Aid) or 0b10 (Banded Hearing Aid).

The Independent Presets field shall be set to 0b0 if the list of preset records on the server is identical to the list of preset records on the other server in the Binaural Hearing Aid Set. If the list of preset records on one server is different from the list of preset records on the other server in the Binaural Hearing Aid Set, then the Independent Presets field shall be set to 0b1. If the server sets the Hearing Aid Type field to 0b01 (Monaural Hearing Aid) or 0b10 (Banded Hearing Aid), the server shall set the Independent Presets field to 0b0.

If the list of preset records on the server can change in time, then the server shall set the Dynamic Presets field to 0b1. Changes to the list of preset records include:

  • A preset record has been added to the list of preset records.

  • A preset record has been deleted from the list of preset records.

  • A preset record has become available or unavailable.

  • The name of a preset record has changed.

The server shall set the Dynamic Presets field to 0b0 if the list of preset records on this server does not change with time. Two servers that are part of a Binaural Hearing Aid Set shall set the Dynamic Presets field to the same value if the Independent Presets fields on both servers are set to 0b0.

If the server exposes at least one preset record with the Writable flag set to 0b1, then the server shall set the Writable Presets Support to 0b1.

As an example, the value of the Hearing Aid Features characteristic set to 0b00110001, corresponding to the hexadecimal value 0x31, indicates a Monaural Hearing Aid that supports changes to the list of preset records and supports writable presets.

3.1.1. Hearing Aid Features characteristic behavior

The Hearing Aid Feature characteristic value may be read by the client.

The server shall expose the same value of the Hearing Aid Features to all clients.

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 client of the new characteristic value.

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. Hearing Aid Preset Control Point characteristic

A procedure is triggered by writing, notifying, or indicating a value of the Hearing Aid Preset Control Point characteristic that includes an opcode specifying the operation. The procedure might require a parameter that is valid within the context of that opcode, as shown in Table 3.3. When a client writes a value, the server shall respond either by sending an ATT_WRITE_RSP PDU to confirm that it has accepted the request or by sending an ATT_ERROR_RSP [2] with an appropriate ATT Error or ATT Application Error Code, as specified in Section 3.2.2. One or more notifications or indications of the Hearing Aid Preset Control Point characteristic can follow the response depending on the operation requested by the client.

3.2.1. Hearing Aid Preset Control Point operation requirements

Table 3.3 shows the requirements for the Hearing Aid Preset Control Point operations.

Opcode

Operation

Parameters

Reference

Sent by

Description

Support

0x00

RFU

–

–

–

–

–

0x01

Read Presets Request

StartIndex, NumPresets

Section 3.2.2.1

Client

Request to read NumPresets presets from the Server, starting with the first preset record with an Index greater than or equal to StartIndex.

M

0x02

Read Preset Response

isLast, PresetRecord

Section 3.2.2.1

Server

Response to a Read Presets Request.

M

0x03

Preset Changed

ChangeId, isLast, additional parameters depend on ChangeId

Section 3.2.2.2

Server

Used by the server to inform clients of changes to a preset record.

C.2

0x04

Write Preset Name

Index, Name

Section 3.2.2.3

Client

Write the Name field of a writable preset record identified by the Index field.

C.1

0x05

Set Active Preset

Index

Section 3.2.2.4

Client

Set the preset record identified by the Index field as the active preset.

M

0x06

Set Next Preset

None

Section 3.2.2.5

Client

Set the next preset record in the server’s list of preset records as the active preset.

M

0x07

Set Previous Preset

None

Section 3.2.2.6

Client

Set the previous preset record in the server’s list of preset records as the active preset.

M

0x08

Set Active Preset –Synchronized Locally

Index

Section 3.2.2.7

Client

Set the preset record identified by the Index field as the active preset. The server must relay this change to the other member of the Binaural Hearing Aid Set, as specified in Section 3.2.2.7.

C.3

0x09

Set Next Preset – Synchronized Locally

None

Section 3.2.2.8

Client

Set the next preset record in the server’s list of preset records as the active preset. The server must relay this change to the other member of the Binaural Hearing Aid Set, as specified in Section 3.2.2.8.

C.3

0x0A

Set Previous Preset – Synchronized Locally

None

Section 3.2.2.9

Client

Set the previous preset record in the server’s list of preset records as the active preset. The server must relay this change to the other member of the Binaural Hearing Aid Set, as specified in Section 3.2.2.9.

C.3

0x0B–0xFF

RFU
Table 8. Table 3.3: Requirements for the Hearing Aid Preset Control Point operations

C.1: Mandatory if the Writable Presets Support field of the Hearing Aid Features characteristic is set to 0b1; otherwise Excluded.

C.2 Mandatory if the Dynamic Presets field of the Hearing Aid Features characteristic is set to 0b1; otherwise Excluded.

C.3: Mandatory if the Preset Synchronization Support field of the Hearing Aid Features characteristic is set to 0b1; otherwise Excluded.

3.2.2. Hearing Aid Preset Control Point behavior

The Hearing Aid Preset Control Point characteristic value may be written by a client and may be indicated and notified by the server. If the server supports notifications of the Hearing Aid Preset Control Point characteristic, then the server should notify this characteristic only on an EATT bearer.

If a client writes

  • The Read Presets Request opcode, or

  • The Write Preset Name opcode, or

  • The Set Active Preset opcode, or

  • The Set Active Preset – Synchronized Locally opcode

to the Hearing Aid Control Point characteristic, and the Client Characteristic Configuration Descriptor of the Hearing Aid Control Point is not configured for indications, the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the error code parameter set to Client Characteristic Configuration Descriptor Improperly Configured as defined in [3].

If a client writes an opcode that is not supported by the server and that may not be written by a client (as indicated by the Sent by column in Table 3.3), or that is marked as RFU in Table 3.3, then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the error code parameter set to Invalid Opcode as defined in Table 2.1.

If a client writes an opcode that is supported by the server, but with parameters of an invalid length, then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the error code parameter set to Invalid Parameters Length as defined in Table 2.1.

When an operation includes the Index parameter and the Index parameter does not correspond to a preset record exposed by the server, then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the error code set to Out of Range, as defined in [3].

3.2.2.1. Read Presets Request operation

The format of the Hearing Aid Preset Control Point characteristic used for the Read Presets Request operation is shown in Table 3.4.

Field Name

Size (Octets)

Value

Opcode

1

0x00 = Read Presets Request opcode

StartIndex

1

0x01–0xFF

NumPresets

1

0x01–0xFF
Table 9. Table 3.4: Read Presets Request operation format

If the Read Presets Request opcode is written to the Hearing Aid Preset Control Point characteristic, then the server shall reply with an ATT_WRITE_RSP PDU, and the server shall send to the client one notification or indication of the Hearing Aid Preset Control Point characteristic for the preset beginning with an Index equal to or greater than StartIndex followed by the next (NumPresets-1) presets. If the server encounters a preset record with the isLast value set to 0x01 (see Table 3.5) during this operation, then it will notify or indicate that preset record and then terminate the operation.

The value of the notifications or indications shall be formatted as described in Table 3.5. The server shall send the notifications or indications in order of increasing Index field of the preset record. The server shall set the isLast field to 0x00 for all notifications or indications except the last one. The server shall set the isLast field of the last notification or indication (i.e., the one that contains the preset record with the highest Index field) to 0x01, indicating to the client that all preset records have been sent and the procedure can be considered concluded.

Field Name

Size (Octets)

Value

Opcode

1

0x02 = Read Preset Response opcode

isLast

1

See Section 3.2.2.1

PresetRecord

varies

Preset record formatted as in Table 2.3
Table 10. Table 3.5: Hearing Aid Preset Control Point characteristic value format when notified or indicated by the server with opcode set to Read Preset Response

If the ATT bearer is terminated before all notifications or indications are sent, then the server shall consider the Read Presets Request operation aborted and shall not either continue or restart the operation when the client reconnects.

If the client writes a Read Presets Request in which:

  • the StartIndex value is beyond the range of preset records on the Server, or

  • the StartIndex is set to 0x00, or

  • the NumPresets is set to 0x00, or

  • there are no presets,

the server shall reject the request by returning an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the error code parameter set to Out of Range, as defined in [3].

If a client writes either of the following opcodes to the Preset Control Point characteristic:

before the server has sent all the notifications or indications triggered by a write of the Read Presets Request opcode by the same client or by another client, then the server shall reject the request by returning an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the error code parameter set to Procedure Already in Progress, as defined in [3].

3.2.2.2. Preset Changed operation

The Preset Changed operation is autonomously initiated by the server to inform the clients that have registered for notifications or indications of the Hearing Aid Preset Control Point characteristic that a preset record has changed.

The permitted changes to a preset record are:

  • A preset record has been added to the list of preset records.

  • A preset record has been deleted from the list of preset records.

  • A preset record has become available.

  • A preset record has become unavailable.

  • The name of a preset record has changed.

Immediately after one or more of the above listed events happens, the server shall initiate a Preset Changed operation with all connected clients. If a bonded client is not connected, the server shall initiate the Preset Changed operation after reconnecting to that client.

The server initiates a Preset Changed operation by notifying or indicating the Hearing Aid Preset Control Point characteristic with a value formatted as shown in Table 3.6. The opcode shall be set to “Preset Changed”, and the field ChangeId shall be set to one of the values listed in Table 3.7 to identify the type of change.

Field Name

Size (Octets)

Value

Opcode

1

0x03 = Preset Changed

ChangeId

1

See Table 3.7

isLast

1

See Section 3.2.2.1.

Additional parameters

varies

Dependent on ChangeId
Table 11. Table 3.6: Hearing Aid Preset Control Point characteristic value format when notified or indicated by the server with opcode set to Preset Changed

ChangeId

Value

Generic Update

0x00

Preset Record Deleted

0x01

Preset Record Available

0x02

Preset Record Unavailable

0x03

RFU

0x04–0xFF
Table 12. Table 3.7: Values of the ChangeId parameter for the Preset Changed operation

When the server informs the client of a change to a single preset record, the server shall send one notification or indication with the isLast field set to 0x01. When the server informs the client of changes to more than one preset record, the server shall send all notifications or indications in order of increasing Index field. The server shall set the isLast field to 0x00 for all notifications or indications except the last one. The server shall set the isLast field of the last notification or indication to 0x01, indicating to the client that all changes to preset records have been sent and the procedure can be considered concluded.

The isLast field is followed by one or more parameters that depend on the ChangeId as described in Section 3.2.2.2.1 to Section 3.2.2.2.4.

If the ATT bearer is terminated before all notifications or indications are sent, then the server shall consider the Preset Changed operation aborted and shall continue the operation when the client reconnects. If indications are used, and if the last indication sent by the server before the ATT bearer was terminated has not been confirmed by the client, then the server shall re-send the indication when the client reconnects.

3.2.2.2.1. Generic Update ChangeId

When executing a Preset Changed operation, the server shall set the value of the Hearing Aid Preset Control Point characteristic as described in Table 3.8 to send an entire preset record to a client.

The Generic Update ChangeId shall be used to inform clients when a new preset record is added to the list of preset records, or when the name of an existing preset record has changed or has been written by a client. The Generic Update ChangeId may also be used when more than one change happened while the client was disconnected (for example, an unavailable preset record became available, and later changed its name). To inform the client of these changes, the server may send one notification or indication with the Generic Update ChangeId instead of two notifications or indications, one with the Preset Record Available ChangeId followed by one with the Generic Update ChangeId.

Field Name

Size (Octets)

Value

Opcode

1

0x03 = Preset Changed

ChangeId

1

0x00 = Generic Update

isLast

1

See Section 3.2.2.2

PrevIndex

1

See Section 3.2.2.2.1

PresetRecord

varies

Preset record formatted as in Table 2.3
Table 13. Table 3.8: Hearing Aid Preset Control Point characteristic value format when notified or indicated by the server with opcode set to Preset Changed and ChangeId set to Generic update

The PrevIndex field shall contain the Index field value of the previous preset record in the list of preset records. If the preset record is at the top of the list (i.e., it is the preset record with the lowest value of Index field), then the PrevIndex field shall be set to 0x00.

The field PresetRecord shall contain a preset record formatted as in Table 2.3.

When adding a preset record, the server shall not modify the Index field of any existing preset record and shall maintain the list of preset records ordered by increasing Index field.

When adding a preset record, the server may reuse an Index value from a preset record that was previously deleted. If the preset record is added at the top of the list, the PrevIndex field shall be set to 0x00.

The use of PrevIndex allows the server to convey information about deleted presets and added presets using a single notification or indication, instead of two or more. For example, to inform a client that the list of preset records shown in Table 3.9 has changed to the one shown in Table 3.10 (i.e., preset records with Index 5 and Index 8 have been deleted, and a preset record with Index 10 has been added), the server can send a single Preset Changed notification or indication with the following parameters:

  • ChangeId = Generic update

  • isLast = 0x01

  • PrevIndex = 1

  • PresetRecord = preset record for the new preset with Index = 10

Because preset records are ordered by increasing Index field, the value of PrevIndex set to 1 and the value of Index field set to 10 indicates that there are no preset records between Index 1 and Index 10.

Alternatively, the server can send three Preset Changed notifications or indications, two for the deleted presets with Index 5 and Index 8, and one for the added preset with Index 10.

Index

Properties

Name

1

0x03

“Universal”

5

0x03

“Outdoor”

8

0x03

“Noisy environment”

22

0x03

“Office”
Table 14. Table 3.9: Example of list of preset records

Index

Properties

Name

1

0x03

“Universal”

10

0x03

“Reverberant room”

22

0x03

“Office”
Table 15. Table 3.10: Example of list of preset records after some preset records have changed

3.2.2.2.2. Preset Record Deleted ChangeId

The server shall set the value of the Hearing Aid Preset Control Point characteristic as described in Table 3.11 to inform the client that a preset record has been deleted from the list of preset records.

When deleting a preset record, the server shall not modify the Index field of the remaining preset records.

Field Name

Size (Octets)

Value

Opcode

1

0x03 = Preset Changed

ChangeId

1

0x01 = Preset Record Deleted

isLast

1

See Section 3.2.2.2

Index

1

Index field of the preset record that has been deleted
Table 16. Table 3.11: Hearing Aid Preset Control Point characteristic value format when notified or indicated by the server with opcode set to Preset Changed and ChangeId set to Preset Record Deleted

The Index field shall contain the Index field of the preset record that has been deleted from the list of preset records.

3.2.2.2.3. Preset Record Available ChangeId

The server shall set the value of the Hearing Aid Preset Control Point characteristic as described in Table 3.12 to inform the client that a preset record has become available.

Field Name

Size (Octets)

Value

Opcode

1

0x03 = Preset Changed

ChangeId

1

0x02 = Preset Record Available

isLast

1

See Section 3.2.2.2

Index

1

Index field of the preset record that has become available
Table 17. Table 3.12: Hearing Aid Preset Control Point characteristic value format when notified or indicated by the server with opcode set to Preset Changed and ChangeId set to Preset Record Available

The Index field shall contain the Index field of the preset record that has become available.

3.2.2.2.4. Preset Record Unavailable ChangeId

The server shall set the value of the Hearing Aid Preset Control Point characteristic as described in Table 3.13 to inform the client that a preset record has become unavailable.

Field Name

Size (Octets)

Value

Opcode

1

0x03 = Preset Changed

ChangeId

1

0x03 = Preset Record Unavailable

isLast

1

See Section 3.2.2.2

Index

1

Index field of the preset record that has become unavailable
Table 18. Table 3.13: Hearing Aid Preset Control Point characteristic value format when notified or indicated by the server with opcode set to Preset Changed and ChangeId set to Preset Record Unavailable

The Index field shall contain the Index field of the preset record that has become unavailable.

3.2.2.3. Write Preset Name operation

If the Write Preset Name opcode is written to the Hearing Aid Preset Control Point characteristic, the Index parameter corresponds to the Index field of a preset record exposed by the server, and the Writable bit in the Properties field of the preset record which is identified by the Index parameter is set to 0b1, then

  • The server shall reply with an ATT_WRITE_RSP, and

  • The server shall set the Name field of the preset record identified by the Index parameter to the value of the Name parameter, and

  • The server shall send the preset record identified by the Index parameter to all clients that registered for notifications or indications of the Preset Control Point characteristic, by executing the Preset Changed operation (see Section 3.2.2.2.1).

If the Writable bit in the Properties field of the preset record which is identified by the Index parameter is set to 0b0, then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the Error Code parameter set to Write Name Not Allowed.

If the Name parameter is not present, or the Name parameter is longer than 40 octets, then the server shall respond with an ATT_ERROR_RSP PDU with the Error Code parameter set to Invalid Parameters Length.

The Hearing Aid Preset Control Point characteristic value used for the Write Preset Name operation shall be formatted as listed in Table 3.14.

Field Name

Size (Octets)

Value

Opcode

1

0x04 = Write Preset Name opcode

Index

1

0x01–0xFF

Name

1–40

Preset Name UTF-8 string
Table 19. Table 3.14: Write Preset Name operation format

3.2.2.4. Set Active Preset operation

If the Set Active Preset opcode is written to the Hearing Aid Preset Control Point characteristic and the Index parameter corresponds to a preset record exposed by the server, then the server shall set the Active Preset Index characteristic value to the value of the Index parameter.

If the Set Active Preset operation cannot be executed because it is incompatible with the state of the server, or the isAvailable bit of the Properties field of the preset record identified by the Index parameter is set to 0b0, then the server shall return an ATT_ERROR_RSP PDU with the Error Code parameter set to Preset Operation Not Possible. It is implementation specific to define when an operation is incompatible with the state of the server.

If this operation causes the value of the Active Preset Index characteristic to change, then the server shall notify clients of the new Active Preset Index value (see Section 3.3).

The Hearing Aid Preset Control Point characteristic value used for the Set Active Preset operation shall be formatted as listed in Table 3.15.

Field Name

Size (Octets)

Value

Opcode

1

0x05 = Set Active Preset opcode

Index

1

0x01–0xFF
Table 20. Table 3.15: Set Active Preset operation format

3.2.2.5. Set Next Preset operation

If the Set Next Preset opcode is written to the Hearing Aid Preset Control Point characteristic, then the server shall set the Active Preset Index characteristic value to the Index field of the first available preset record succeeding the active preset record in the list of preset records. If the active preset record corresponds to the last preset record in the list of preset records, then the server shall set the Active Preset Index characteristic value to the Index field of the first available preset record in the list of preset records.

If this operation cannot be executed because it is incompatible with the state of the server, then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the Error Code parameter set to Preset Operation Not Possible. It is implementation specific to define when an operation is incompatible with the state of the server.

If this operation causes the value of the Active Preset Index characteristic to change, then the server shall notify clients of the new Active Preset Index value (see Section 3.3).

The Hearing Aid Preset Control Point characteristic value used for the Set Next Preset operation shall be formatted as listed in Table 3.16.

Field Name

Size (Octets)

Value

Opcode

1

0x06 = Set Next Preset opcode
Table 21. Table 3.16: Set Next Preset operation format

3.2.2.6. Set Previous Preset operation

If the Set Previous Preset opcode is written to the Hearing Aid Preset Control Point characteristic, then the server shall set the Active Preset Index characteristic value to the Index field of the first available preset record preceding the active preset record in the list of preset records. If the active preset record corresponds to the first preset record in the list of preset records, then the server shall set the Active Preset Index characteristic value to the Index field of the last available preset record in the list of preset records.

If this operation cannot be executed because it is incompatible with the state of the server, then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the Error Code parameter set to Preset Operation Not Possible. It is implementation specific to define when an operation is incompatible with the state of the server.

If this operation causes the value of the Active Preset Index characteristic to change, then the server shall notify clients of the new Active Preset Index value (see Section 3.3).

The Hearing Aid Preset Control Point characteristic value used for the Set Previous Preset operation shall be formatted as listed in Table 3.17.

Field Name

Size (Octets)

Value

Opcode

1

0x07 = Set Previous Preset opcode
Table 22. Table 3.17: Set Previous Preset operation format

3.2.2.7. Set Active Preset – Synchronized Locally operation

If the Set Active Preset – Synchronized Locally opcode is written to the Hearing Aid Preset Control Point characteristic, then the server shall behave as specified in Section 3.2.2.4.

In addition, if the Set Active Preset – Synchronized Locally operation causes the value of the Active Preset Index characteristic to change, then the server shall relay the change to the other server that is part of the Binaural Hearing Aid Set. It is implementation specific to define how the server relays the change to the other server that is part of the Binaural Hearing Aid Set.

If the server does not support Preset Synchronization (see Section 3.1), then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the Error Code parameter set to Preset Synchronization Not Supported.

The Hearing Aid Preset Control Point characteristic value used for the Set Active Preset – Synchronized Locally operation shall be formatted as listed in Table 3.18.

Field Name

Size (Octets)

Value

Opcode

1

0x08 = Set Active Preset – Synchronized Locally opcode

Index

1

0x01–0xFF
Table 23. Table 3.18: Set Active Preset – Synchronized Locally operation format

3.2.2.8. Set Next Preset – Synchronized Locally operation

If the Set Next Preset – Synchronized Locally opcode is written to the Hearing Aid Preset Control Point characteristic, then the server shall behave as specified in Section 3.2.2.5.

In addition, if the Set Next Preset – Synchronized Locally operation causes the value of the Active Preset Index characteristic to change, then the server shall relay the change to the other hearing aid part of the Binaural Hearing Aid Set. It is implementation specific to define how the server relays the change to the other server that is part of the Binaural Hearing Aid Set.

If the server does not support Preset Synchronization (see Section 3.1), then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the Error Code parameter set to Preset Synchronization Not Supported.

The Hearing Aid Preset Control Point characteristic value used for the Set Next Preset – Synchronized Locally operation shall be formatted as listed in Table 3.19.

Field Name

Size (Octets)

Value

Opcode

1

0x09 = Set Next Preset – Synchronized Locally opcode
Table 24. Table 3.19: Set Next Preset – Synchronized Locally operation format

3.2.2.9. Set Previous Preset – Synchronized Locally operation

If the Set Previous Preset – Synchronized Locally opcode is written to the Hearing Aid Preset Control Point characteristic, then the server shall behave as specified in Section 3.2.2.6.

In addition, if the Set Previous Preset – Synchronized Locally operation causes the value of the Active Preset Index characteristic to change, then the server shall relay the change to the other hearing aid part of the Binaural Hearing Aid Set. It is implementation specific to define how the server relays the change to the other server that is part of the Binaural Hearing Aid Set.

If the server does not support Preset Synchronization (see Section 3.1), then the server shall return an ATT_ERROR_RSP PDU to the ATT_WRITE_REQ PDU with the Error Code parameter set to Preset Synchronization Not Supported.

The Hearing Aid Preset Control Point characteristic value used for the Set Previous Preset – Synchronized Locally operation shall be formatted as listed in Table 3.20.

Field Name

Size (Octets)

Value

Opcode

1

0x0A = Set Previous Preset – Synchronized Locally opcode
Table 25. Table 3.20: Set Previous Preset – Synchronized Locally operation format

3.3. Active Preset Index characteristic

The Active Preset Index characteristic exposes the Index field of the active preset record, or the value 0x00 if no preset is active (see Table 1.1).

The Active Preset Index characteristic shall be formatted as in Table 3.21.

Field Name

Size (Octets)

Value

Active Preset Index

1

Index field of the Active preset record, or 0x00 if no preset is active
Table 26. Table 3.21: Active Preset Index characteristic value format

The value of the Active Preset Index characteristic shall be equal to the Index field of the Active preset record. If no preset is active, the Active Preset Index characteristic value shall be set to 0x00. The server shall not set the value of the Active Preset Index characteristic to the Index field of a preset record with the isAvailable bit of the Properties field set to 0b0 (i.e., an unavailable preset record).

When the server autonomously changes the preset in use (e.g., because of user action on the server), the server shall modify the Active Preset Index field accordingly.

3.3.1. Active Preset Index characteristic behavior

The Active Preset Index characteristic value may be read by the client.

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 client of the new characteristic value.

If the characteristic value changes when not in a connection and the value of the Client Characteristic Configuration descriptor is configured for notifications, then the server shall notify the new characteristic value when reconnecting to a bonded client.

4. Acronyms and abbreviations

Acronym/Abbreviation

Meaning

ATT

Attribute Protocol

EATT

Enhanced ATT

GATT

Generic Attribute Profile

HAP

Hearing Access Profile

HAS

Hearing Access Service

LE

Bluetooth Low Energy

LSO

Least Significant Octet

MSC

Message Sequence Charts

MSO

Most Significant Octet

PDU

Protocol Data Unit

RFU

Reserved for Future Use

UTF

Unicode Transformation Format

UUID

Universally Unique Identifier
Table 27. Table 4.1: Acronyms and abbreviations

5. References

[1] Bluetooth SIG Assigned Numbers, https://www.bluetooth.com/specifications/assigned-numbers

[2] Bluetooth Core Specification, Version 4.2 or later

[3] Bluetooth Core Specification Supplement, Version 10

[4] Hearing Access Profile Specification, Version 1.0

[5] GATT Specification Supplement (GSS), Version 6