Headset Profile

This Headset profile defines the protocols and procedures that shall be used by devices requiring a full-duplex audio connection combined with minimal device control commands. The most common examples of such devices are headsets, personal computers, PDAs, and cellular phones, though most cellular phones will prefer to use a more advanced profile such as Hands-Free Profile.

The headset can be wirelessly connected for the purposes of acting as the device’s audio input and output mechanism, providing full duplex audio. The headset increases the user’s mobility while maintaining call privacy.

The Headset profile is dependent upon both the Serial Port Profile and the Generic access profile – details are provided in Serial Port Profile and Generic Access Profile.

The following arrows are used in diagrams describing procedures:

Figure 1.1. Arrows used in signaling diagrams

Figure 2.1 shows the protocols and entities used in this profile.

Figure 2.1. Figure 2.1: Protocol model

The Controller, HCI, and L2CAP are the OSI layer 1 and 2 Bluetooth protocols. RFCOMM is the Bluetooth adaptation of GSM TS 07.10 [5]. SDP is the Bluetooth Service Discovery Protocol. Headset Profile and AT CMD are the entities responsible for headset specific control signaling, which is AT command based.

.For the HSP layer in Figure 2.1 the Serial Port Profile is used as a base standard. For this protocol, all requirements stated in the Serial Port Profile apply except in those cases where this profile explicitly states deviations.

The figures below show two typical configurations of devices for which the Headset profile is applicable:

Figure 2.2. Figure 2.2: Headset profile, example with cellular phone

Figure 2.3. Figure 2.3: Headset profile, example with personal computer

The following roles are defined for this profile:

Audio Gateway (AG) – This device acts as either the end point, or a relay, for telephony quality audio, which is typically two-way. Exemplary devices acting as Audio Gateways are cellular phones and personal computers.

Headset (HS) – This device provides the Audio Gateway’s remote audio input and output mechanism.

The abbreviations AG and HS are used in the rest of this document to designate these roles.

The Headset profile defines the protocols and procedures that shall be used by devices implementing this use case.

The following restrictions apply to this profile:

Depending on the underlying core specification version^[2], an HS may be able to use the services of the AG without the creation of a secure connection. It is the implementer’s responsibility to enforce security on devices that support authentication and/or encryption in the execution of this profile. If baseband authentication and/or encryption is desired, the two devices shall create a secure connection, using the authentication procedure as described in the Generic Access profile.

A link must be established before establishing an audio connection. Normally, this requires paging of the other device.

There are no fixed master/slave roles.

The AG and HS provide serial port emulation by using the serial port profile, which in turn uses the RFCOMM protocol. The serial port emulation is used to exchange the user data including modem control signals and AT commands and responses. AT commands are parsed by the AG and responses are sent to the HS.

If conformance to this profile is claimed, all capabilities indicated as mandatory for this profile shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated. All mandatory capabilities, and optional and conditional capabilities for which support is indicated, are subject to verification as part of the Bluetooth qualification program.

The interoperability requirements for the Headset Control entity are completely contained in this chapter. Sections 4.2 through Section 4.7 specify the requirements for the procedures directly relating to the application layer features.

Section 4.8 specifies the AT commands and results codes used for signaling purposes.

Sect ion 4.9 specifies how the layers beneath the Headset Control entity are used to establish and release a connection.

Upon an internal or user generated event, the AG will initiate connection establishment (see Section 4.8.1), once the connection is established, there are then two options as described in the Sections 4.2.1and Sections 4.2.2. The SCO link establishment can take place anytime after the ACL connection establishment.

4.2.1. Using In-Band Ringing

An in-band ring tone is an audible alert, such as a tone, melody, short music clip, that is transmitted by the AG, to the HS, to alert the user of an event; typically an incoming call. As shown in Figure 4.1, the AG may generate an in-band ring tone using the SCO connection to the HS. The AG decides how to use this SCO connection. When using an in-band ring tone, the AG shall not send the RING unsolicited result code to the HS^[3].

Figure 4.1. Figure 4.1: Incoming audio connection establishment using in-band ring tone

4.2.2. Using the RING message

As shown in Figure 4.2, the AG will repeatedly send the RING unsolicited result code to the HS for a time period decided by the AG. The RING may be repeated for as long as the connection establishment is pending.

Figure 4.2. Figure 4.2 Incoming connection establishment (using RING message)

A headset (HS) originated ACL connection is initiated (see Section 4.9) by a user action (e.g. pressing a button on the headset). Upon completion of a connection establishment that was initiated by pressing the “headset button”, the HS shall send the AT+CKPD=200 command to the AG. If the HS connection is initiated by an event other than a headset button press, the HS shall not send AT+CKPD=200.

The AG may initiate a SCO connection after the completion of the ACL connection establishment, but before receiving the AT+CKPD=200 command from the HS. This may be desirable when the AG is a mobile phone. In all cases, the AG is responsible for establishing the SCO link if needed. Further internal actions may be needed on the AG to internally establish and/or route the audio stream to the HS^[4].

As shown in Figure 4.3, the SCO link connection may be set up prior to receiving the AT+CKPD=200 command. If this is not the case, then the SCO link connection shall be set up after receiving the AT+CKPD=200 command.

Figure 4.3. Figure 4.3: Audio connection establishment

While a headset profile connection exists between AG and HS, and upon the receipt of a user initiated action (for example, button press) on the HS, the HS shall send the AT+CKPD=200 command to the AG. The action performed by the AG on receipt of the AT+CKPD=200 command is implementation dependent. The actions performed by the AG may be dictated by the state the AG is in at the time it received the command.

Figure 4.4. Figure 4.4: Audio connection release – HS initiated

Figure 4.5. Figure 4.5: Audio connection release – AG initiated

The AG may release the Audio connection (SCO) upon an internal event in the AG or after the AG receives an indication of a user initiated action (e.g. button press) from the AG or HS.

The HS may initiate an Audio connection (SCO) release in circumstances such as power-down event while an Audio connection (SCO) is established.

Irrespective of the initiating side, the AG is responsible for releasing the profile’s serial port (RFCOMM) connection (see Section 4.9.1.2).

An audio connection can be transferred from AG to HS or from HS to AG. The connection is transferred to the device initiating the transfer.

4.6.1. Audio Connection Transfer from AG to HS

The audio connection transfer from AG to HS is initiated by a user action on the HS

side. To effect this transfer, the HS shall send the AT+CKPD=200 command to the AG.

Figure 4.6. Figure 4.2: Audio connection transfer from AG to HS

4.6.2. Audio Connection Transfer from HS to AG

The audio connection transfer from HS to AG is initiated by a user action on the AG. This user action shall result in the AG releasing the SCO connection.

Figure 4.7. Figure 4.3: Audio connection transfer from HS to AG

The AG can control the gain of the microphone or speaker of the HS by sending unsolicited result codes +VGM or +VGS respectively. There is no restriction on the number or order of these result codes. Support for remote audio volume control is optional, so an implementation may support none, either, or both of the controls for microphone volume and speaker volume.

Figure 4.8. Figure 4.4: Audio volume control – example flow

Both the speaker and microphone gain are represented as parameter to the +VGS and +VGM, on a scale from 0 to 15. The values are absolute values, relating to a particular (implementation-dependent) volume level controlled by the HS.

The HS may store the VGS and VGM settings at connection release. At connection establishment, the HS may restore the previous settings using the AT commands AT+VGS and AT+VGM. In case physical mechanisms (buttons, dials etc.) means are implemented on the HS to control the volume levels, the HS shall also use the AT commands AT+VGS and AT+VGM to inform the AG of any changes in the volume levels.

Figure 4.9. Figure 4.5: Volume level synchronization – example flow

This section describes how the layers below the Headset Control entity are used to establish and release a connection.

For the RFCOMM layer, no additions to the requirements as stated in the Serial Port Profile Section 4 shall apply.

For the L2CAP layer, no additions to the requirements as stated in the Serial Port Profile Section 5 shall apply [3].

This profile [3] defines following service records for the headset and the audio gateway respectively.

The codes assigned to the mnemonics used in the Value column as well as the codes assigned to the attribute identifiers (if not specifically mentioned in the AttrID column) can be found on the Bluetooth Assigned Numbers web page.

In addition to the requirements for the Link Manager as stated in the Serial Port Profile, this profile mandates support for SCO links, in both the HS and AG.

CVSD audio shall be supported in both the AG and HS.

The table shows the support status for Modes within this profile.

No changes to the requirements as stated in the Generic Access Profile [3].

Support for general inquiry mode is mandatory in the AG.