The Headset profile defines the requirements
for Bluetooth devices necessary to support the Headset use case.
Essentially the Headset profile defines the protocols and procedures that
shall be used by devices implementing the usage model called Ultimate
Headset. The most common examples of such devices are headsets,
personal computers, and cellular phones.
For more details : Download the K6
Specification from the SIG website, or visit the Documents
The figure below
shows the protocols and entities used in this profile.
*Diagram Source: Courtesy of Bluetooth SIG, K6
Profile, Figure 2.1 , p 196
The Baseband, LMP
and L2CAP are the OSI layer 1 and 2 Bluetooth protocols. RFCOMM is the
Bluetooth adaptation of GSM TS 07.10 . SDP is the Bluetooth Service
Discovery Protocol. Headset Control is the entity responsible for headset
specific control signalling; this signalling is AT command based.
Note: although not shown
in the model above, it is assumed by this profile that Headset Control has
access to some lower layer procedures (for example SCO link
The audio port emulation
layer shown in the figure above is the entity emulating the audio port on
the cellular phone or PC, and the audio driver is the driver software in
For the shaded
protocols/entities shown above, the Serial Port
Profile is used as base standard. For these protocols, all
requirements stated in the Serial Port Profile apply except in those cases
where this profile explicitly states deviations.
Two roles are defined for Bluetooth devices in this profile, Audio Gateway
(AG) and Headset (HS):
(AG) This is the device that is the gateway of the
audio, both for input and output. Typical devices acting as Audio
Gateways are cellular phones and personal computer.
Headset (HS) This
is the device acting as the Audio Gateways remote audio input and
restrictions apply to this profile:
- For this profile, it is assumed that the ultimate headset use case
is the only use case active between the two devices;
- The profile mandates the usage of CVSD for transmission of audio
(for the Bluetooth part). The resulting audio is monophonic, with a
quality that under normal circumstances will not have
perceived audio degradation.
- Between headset and audio gateway, only one audio
connection at a time is supported;
- The audio gateway controls the SCO link establishment and release.
The headset directly connects (disconnects) the internal audio streams
upon SCO link establishment (release). Valid speech exists on the SCO
link in both directions, once established;
- The profile offers only basic interoperability for example,
handling of multiple calls at the audio gateway is not included;
- The only assumption on the headsets user interface is the
possibility to detect a user initiated action (e.g. pressing a
A headset may be
able to use the services of audio gateway without the creation of a secure
connection. It is up to the user, if he/she wants 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 have to create a secure connection, using the GAP
authentication procedure. This procedure may then include entering a PIN
code, and will include creation of link keys.
A link has to be
established when a call is initiated or received. Normally, this requires
paging of the other device but, optionally, it may require unparking.
Note: There are no fixed
The audio gateway and
headset provide serial port emulation. For the serial port emulation,
RFCOMM is used. The serial port emulation is used to transport the user
data including modem control signals and AT commands from the headset to
the audio gateway. AT commands are parsed by the audio gateway and
responses are sent to the headset.
Upon an internal
or user generated event, the AG will initiate connection establishment,
and once the connection is established, will send an unsolicited result
code RING to alert the user. The RING may be repeated for as long as the
connection establishment is pending.
The user accepts the
incoming audio connection by pressing the button on the headset. By doing
this, the HS will send the AT+CKPD command to the AG, whereupon the AG
establishes the SCO link (if not already established).
An outgoing audio connection is
initiated on the HS by pushing the button. The HS will initiate connection
establishment, and will send the AT+CKPD command to the AG. Further
internal actions may be needed on the AG to internally establish and/or
route an audio stream to the HS 2 . The AG is responsible for establishing
the SCO link.
A call can be terminated either on the HS or on the
AG. On the HS based upon the button being pushed, on the AG based upon
internal actions or user intervention.Irrespective of the initiating side,
the AG is responsible for releasing the connection
An audio connection can be transferred from AG to HS
or from HS to AG. The connection is transferred to the device initiating
audio connection transfer from AG to HS is initiated by a
user action on the HS side, which results in an AT+CKPD command being sent
to the AG.
The audio connection
transfer from HS to AG is initiated by a user action on
Audio Volume Control
The AG can control the
gain of the microphone and speaker of the HS by sending unsolicited result
codes +VGM and +VGS respectively. There is no limit to the amount and
order of result codes, as long as there is an active audio connection
ongoing. When supporting the remote audio volume control, an
implementation is not mandated to support both the control of the
microphone volume and speaker volume.
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, to restore the volume levels at the next connection
Commands and Result Codes
For the exchange of the commands
and unsolicited results codes, the format, syntax and procedures of V.250
apply, with the exception that only one command (or unsolicited result
code) per command line needs to be expected. The headset profile uses
a subset of AT commands and result codes from existing standards.
Lower Layer Handling
Layers below the
Headset Control entity are used to establish and release a connection. Not
all Bluetooth devices will implement PARK mode, therefore connections
handling has to take into account whether or not PARK mode is supported.
Handling Without Park Mode:
Handling With Park Mode:
- Both the HS and the AG can initiate
connection establishment. If there is no RFCOMM session between the AG
and the HS, the initiating device shall first initialise RFCOMM.
- When the audio connection is released,
the connection may be released as well. The AG always initiates
requires compliance with the Serial Port Profile.
As with the headset profile, both the AG and the
HS can initiate connection establishment. For the purposes of reading the
Serial Port Profile, both the AG and the HS can assume the role of Device
A and B.
- If the PARK mode is supported, the connection is established once
(e.g. on the first request for an audio connection). Later, when an
audio connection is required, the parked device is unparked.Both sides
may initiate the initial connection establishment. After initial
connection establishment, the park mode is activated.
- When the audio connection is released, the connection is parked
again,When the audio connection is released, the complete connection
may alternatively be released. The AG always initiates connection
- For the RFCOMM & L2CAP layer, no
additions to the requirements as stated in the Serial Port Profile
- For the SDP layer, a number of service
records are defined for the headset and the audio gateway
respectively. They can be found on page 211 of the Headset Profile
- In addition to the requirements for the Link
Manager as stated in the Serial
Port Profile , Section 5.6, this profile mandates support for SCO
links, in both the HS and AG.
This profile requires compliance with the Generic
Note , the above text contains excerpts from the Bluetooth
SIG's Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth