|
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
Page.
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 establishment).
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 the headset.
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):
- Audio Gateway (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 Gateway’s
remote audio input and output mechanism.
The following 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 headset’s user interface is the
possibility to detect a user initiated action (e.g. pressing a button).
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 master/slave roles.
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.
Optionally, the AG may provide an in-band ringing tone.
The in-band ringing tone is used to alert the user in the headset earpiece
when the user is wearing the headset on his head. In this case, first SCO
link establishment takes place. In this case, the SCO link establishment
takes place first.
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).
Incoming audio connection establishment
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.
The AG may initiate a SCO connection after the
completion of the ACL connection establishment before receiving the AT+CKPD
command from the HS. This may be desirable when the AG is a mobile phone. For
a cellular phone a call may need to be established, for example using last
dialled number or a pre-programmed number. For a personal computer this may
be playing a .wav file, or an audio CD.
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. In the figure,
the SCO link connection should be possible prior to receiving the AT+CKPD
message.
Outgoing audio connection establishment
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.
Audio connection release – HS initiated
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.
The 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 the AG.
Audio connection transfer from AG to HS
Audio connection transfer from HS to AG
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 establishment.
Audio volume control – example flow
Volume level synchronization – example flow
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.
The command line termination character is a carriage
return . The response formatting character is a line feed. The AG does not
echo command characters (This is the opposite of the default recommended by
V.250[1]). The AG transmits result codes, using the verbose (rather than
numeric) format.
The format for a command from the HS to the AG is thus:
AT<cmd>=<value><cr>
If the command is processed successfully, the resulting
response from the AG
to the HS is:
<cr><lf>OK<cr><lf>
If the command is not processed successfully, the
resulting response from the
AG to the HS is:
<cr><lf>ERROR<cr><lf>
The format for an unsolicited result code (such as
RING) from the AG to the HS
is:
<cr><lf><result code><cr><lf>
The mandatory set of AT commands and unsolicited result
codes are given
in the table below.
| AT Capability |
Description |
|
RING |
The Incoming call indication of V.250 [1], Section
6.3.4. |
Mandatory AT capabilities
Optionally, the AT capabilities as indicated in the
table below may be supported.
| AT capability |
Syntax |
Description |
Values |
| Microphone Gain |
+VGM=<gain> |
Unsolicited result code issued by the AG to set the
microphone gain of the HS.
<gain> is a decimal number relating to a particular
implementation-dependent volume level controlled by the HS. |
<gain>: 0-15 |
| Speaker Gain |
+VGS=<gain> |
Unsolicited result code issued by the AG to set the
speaker gain of the HS. |
<gain>: 0-15 |
| Microphone Gain Level Report |
+VGM=<gain> |
Command issued by the HS to report the current
microphone gain level setting to the AG. |
<gain>: 0-15 |
| Speaker Gain Level Indication Report |
+VGS=<gain> |
Command issued by the HS to report the tion report
current speaker gain level setting to the AG. |
<gain>: 0-15 |
| Headset Button Press |
+CKPD=200 |
Command issued by HS to indicate that the button has
been pressed. |
|
Optional AT capabilities
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.
Connection Handling Without 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 connection release.
Connection Handling With Park Mode:
- 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 release.
This profile 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.
- For the RFCOMM & L2CAP layer, no additions to the requirements as
stated in the Serial Port Profile shall apply
- 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
Access Profile
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
Specification.
|
