|
This Hands-Free Profile defines the protocols and
procedures that shall be used by devices implementing the usage model
called "Operating a Phone via an In-Car Device". The most common
examples of such devices are Hands-Free units and cellular phones.
An implementation of the Hands-Free Profile
typically enables a car’s embedded Hands-Free unit to be wirelessly
connected to a cellular phone for the purposes of acting as the cellular
phone’s audio input and output mechanism, providing full duplex audio
and perhaps combinations of voice recognition, noise suppression, and
acoustic echo cancellation.
For more details : Download the PAN Profile from the Bluetooth.org
website.
The figure below shows the protocols and entities
used in this profile.
*Diagram Source: Courtesy of Bluetooth SIG, Hands-Free
Profile, Figure 2.1 , p 14
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. Hands-Free control is
the entity responsible for Hands-Free unit specific control signalling;
this signalling is AT command based.
Although not shown in the model above, it is assumed by
this profile that Hands-Free Control has access to some lower layer
procedures (for example, SCO link establishment).
The audio port emulation layer shown above is the
entity emulating the audio port on the Audio Gateway, and the audio driver
is the driver software in the Hands-Free unit.
For the shaded protocols/entities above, the Serial
Port Profile [6] is used as the base standard. For these protocols, all
requirements stated in the Serial Port Profile apply except in those cases
where this specification explicitly states deviations.
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).
Two roles are defined for
Bluetooth devices in this profile, Audio Gateway (AG) and
Hands-Free unit (HF):
- 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.
- Hands-Free unit (HF) – This is the device acting as the
Audio Gateway’s remote audio input and output mechanism. It also
provides some remote control means.
The following restrictions apply to this profile:
- For this profile, it is assumed that only a single "Operating a
Phone via an In-Car Device" use case can be active between the
two devices at a time.
- The profile mandates the usage of CVSD for transmission of audio
(over the Bluetooth link). The resulting audio is monophonic, with a
quality that, under normal circumstances, will not have perceived
audio degradation. Optionally, other audio codecs may be used.
- Between the Hands-Free unit and the Audio Gateway, only one Audio
Connection at a time is supported.
- Both the Audio Gateway and the Hands-Free unit can initiate Audio
Connection establishment and release. The Hands-Free unit directly
connects (or disconnects) the internal audio streams upon proper SCO
link establishment (or release). Valid speech exists on the SCO link
in both directions, once the Audio Connection is established.
- Whenever an "Audio Connection" exists, the presence of a
related "Service Level Connection" is always assumed. On the
other hand, removing an "Audio Connection" does not mean
releasing its corresponding "Service Level Connection". In
fact, the service level connection may be kept to perform control
functions not directly related to pure call processing procedures (for
example a periodic update of the service status).
- The presence of a "Service Level Connection" does not
necessarily imply that an "Audio Connection" also exists.
Removing a "Service Level Connection" always implies
releasing any existing "Audio Connection" related to it.
- The profile offers only basic interoperability. Handling of
multiparty calls at the Audio Gateway, for example, is not covered in
depth in this profile.
A Hands-Free unit may be able to use the services of
the Audio Gateway without the creation of a secure connection. It is up to
the application to determine if security enforcement will be
provided/supported for the user.
Whenever baseband authentication and/or encryption
is desired, the two devices must create a secure connection using the GAP
authentication procedure as described in the Generic Access Profile.
This procedure may include entering a PIN code and creation of proper link
keys. In cases when the UI of the Hands-free unit is limited, a fixed PIN
code may be used during the GAP authentication procedure.
If a LMP link is not already established between the
Hands-Free unit and the Audio Gateway, the LMP link must be set-up before
any other procedure is performed. Normally, this requires paging the other
device, but optionally it may require unparking.
Note: There are no fixed master/slave roles.
The Audio Gateway and Hands-Free unit 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 Hands-Free unit to the Audio Gateway. AT
commands are parsed by the Audio Gateway and responses are sent to the
Hands-Free unit via the Bluetooth serial port connection.
Upon a user action or an internal event, either the
HF or the AG may initiate a Service Level Connection set up procedure.
A Service Level Connection establishment requires
the existence of a RFCOMM connection, that is, a RFCOMM data link channel
between the HF and the AG. Both the HF and the AG may initiate the RFCOMM
connection establishment. If there is no RFCOMM session between the AG and
the HF, the initiating device shall first initialize RFCOMM.
In general, prior to the RFCOMM connection
establishment, proper SDP sessions shall be set up between the HF and the
AG, such that both devices can retrieve the necessary SDP parameters from
each other.
Two possible Service Level Connection set up related
procedures are considered below. The selection of the procedure to be
performed in each case is based on whether the PARK mode is supported or
not in the HF and the AG.
See Section 4.2.1: Service Level Connection
Establishment & 4.2.2 : Park Mode Service
Level Connection in the actual Hands-free Profile Unparking for more
details of these procedures. Section 4.2.3 also addresses the situation of
a link loss recovery from a HF unit.
This section describes two procedures related to the
Service Level Connection release. The selection of the procedure to be
performed in each case is based on whether or not the PARK mode is
supported in the HF and the AG.
- Service Level Connection removal: Upon a user action or an
internal event, both the HF and the AG may completely remove an
existing connection whenever necessary. The disconnection of a Service
Level Connection shall immediately mean the removal of the
corresponding RFCOMM data link channel between the HF and the AG. The
removal of the L2CAP and link layers is optional.
- Park Mode: Service Level Connection parking: When the HF or
AG are said to enter "park mode" or are described as
"parked", it means that they are "parked"
exclusively with respect to the existing link/connection between them.
How the HF and the AG handle any possible links/connections with other
devices is beyond the scope of this specification. If Park Mode is
supported in both the AG and the HF, and the Service Level Connection
is not needed, the HF and the AG are parked. The parking procedure can
be initiated from either side.
The AT+CMER command, enables the "Registration
status update" in the AG. As a result, the AG will send the +CIEV
unsolicited result code with the corresponding indicator values whenever
its registration status changes. The HF shall use the information provided
by the +CIEV result code to generate at least a "service/no
service" indication.
As pre-condition for this procedure, an ongoing
Service Level Connection between the AG and the HF shall exist. If this
connection does not exist, the AG shall establish the Service Level
Connection using the proper procedure.
The AT+CMER command, enables the "Call Status
indicator update" function in the AG.As a general rule, the AG shall
issue the +CIEV result code (with the proper indicator value) on detection
of a change in its current call status, and prior to any other action.
The HF shall use the information provided by the
+CIEV result code to generate at least a "call process ongoing/no
call present" indication.
Upon a user action or an internal event, either the
HF or the AG may initiate the establishment of an Audio Connection
whenever necessary. Further internal actions may be needed by the HF or
the AG to internally route the audio paths.
An Audio Connection set up procedure always means
the establishment of a SCO link and it is always associated with an
existing Service Level Connection.
Upon a user action or an internal event, either the
HF or the AG may release an existing Audio Connection whenever necessary.
An Audio Connection removal always means the disconnection of its
corresponding SCO link.
Upon an incoming call, the AG will send a sequence
of unsolicited RING alerts to the HF. The RING alert shall be repeated for
as long as the call acceptance is pending, or until the incoming call is
interrupted for any reason.
The HF may produce a local alert (e.g. a ring tone)
in reaction to the RING. In addition, the AG may provide an in-band ring
tone being sent via the SCO link.
- Answer incoming call from the HF – in-band ringing : Section
4.8.1 of the Hands-Free profile describes a procedure of
answering incoming call from HF if the in-band ring tone is provided
or not. The HF may use this information in order to determine whether
to produce a local alert. The AG may abort the incoming call when
necessary. It shall then stop alerting the HF.
- Answer incoming call from the HF – no in-band ringing : Section
4.8.2 of the Hands-Free profile describes a procedure of answering
incoming call from HF if the in-band ring tone is not provided.
- Answer incoming call from an AG : For this procedure, The AG
shall alert the HF and the HF shall alert the user.
- Change the in-band ring tone setting : The SDP record entry
"In-band ring tone" of the "Supported features"
record informs the HF if the AG is capable of sending an in-band ring
tone or not. If the AG is capable of sending an in-band ring tone, it
shall send the in-band ring tone by default. Optionally, this setting
can subsequently be changed:
The same considerations as in "Answer an
incoming call" shall be observed. The only exception is that, in this
case, the call is rejected and the normal process is interrupted. Two
different procedures are covered:
- Reject an incoming call from the HF
- Rejection/interruption of an incoming call in the AG
An ongoing call procedure can be terminated by
either the HF or the AG by means of a user action or any other event. Two
different procedures are covered:
- Terminate a call process from the HF
- Terminate a call process from the AG
The audio paths of an ongoing call can be
transferred from the AG to the HF. This procedure represents a particular
case of an "Audio Connection set up" procedure.
The call connection transfer from the AG to the HF
is initiated by a user action either on the HF or on the AG side. This
results in either the HF or the AG, respectively, initiating an
"Audio Connection set up" procedure with the audio paths of the
current call being routed to the HF.
The following pre-conditions apply for this
procedure:
- An ongoing Service Level Connection between the AG and the HF shall
exist. If this connection does not exist, the initiator of the
"Audio Connection transfer towards the HF" procedure shall
establish the Service Level Connection.
- There shall be no Audio Connection between the HF and the AG. If
this connection exists, the initiator of the "Audio Connection
transfer towards the HF" procedure shall release the Audio
Connection.
The audio paths of an ongoing call can be
transferred from the HF to the AG. This procedure represents a particular
case of an "Audio Connection set up" procedure.
The call connection transfer from the HF to the AG
is initiated by a user action in the HF or due to an internal event or
user action in the AG side. This results in a "Audio Connection
release" procedure being initiated either by the HF or the AG
respectively, with the current call kept and its audio paths routed to the
AG.
As pre-condition for this procedure, an ongoing call
process shall exist in the AG. The audio paths of the ongoing call shall
be available in the HF via an Audio Connection established between the AG
and the HF.
The HF can initiate outgoing voice calls by
providing the destination phone number to the AG. To start the call
set-up, the HF will initiate the Service Level Connection establishment
(if necessary) and will send a proper ATDdd…dd; command to the AG. The
AG then starts the call establishment procedure using the phone number
received from the HF.
The HF can initiate outgoing voice calls using the
memory dialing feature of the AG. To start the call set-up, the HF will
initiate the Service Level Connection establishment (if necessary) and
will send an ATD>nnn; command to the AG. The AG will then start the
call establishment procedure using the phone number stored in the AG
memory location given by nnn.
The HF can initiate outgoing voice calls by
recalling the last number dialed by the AG. To start the call set-up, the
HF will initiate the Service Level Connection establishment (if necessary)
and will send an AT+BLDN command to the AG. The AG then starts the call
establishment procedure using the last phone number dialed by the AG.
The HF may issue the AT+CCWA command to enable the
"Call Waiting notification" function in the AG. Once the
"Call Waiting notification" is enabled, the AG will send the
corresponding +CCWA unsolicited result code to the HF whenever an incoming
call is waiting during an ongoing call. It is always assumed that the
"call waiting" service is already active in the network.
Once the HF issues the AT+CCWA command, the AG shall
respond with OK. It shall then keep the "Call Waiting
notification" enabled until either the AT+CCWA command is issued to
disable "Call Waiting notification," or the current Service
Level Connection between the AG and the HF is dropped for any reason.
In general, when the user deals with multiple
concurrent calls, the HF shall issue the corresponding AT+CHLD command as
a result of user actions. This command allows the control of multiple
concurrent calls and provides means for holding calls, releasing calls,
switching between two calls, and adding a call to a multiparty conference.
This section covers two cases. In one case the third
party call is received in the AG, and notification is sent to the HF via a
Call Waiting notification. In the second case, the third party call is
placed from the HF. The procedure are:
- Three way calling - Call waiting notification
- Three way calls – Third party call placed from the HF
The HF may issue the AT+CLIP command to enable the
"Calling Line Identification notification" function in the AG.
If the calling subscriber number information is
available from the network, the AG shall issue the +CLIP unsolicited
result code just after every RING indication when the HF is alerted in an
incoming call. See Section 4.8 for more details.
Once the HF issues the AT+CLIP command, the AG shall
respond with OK. The AG shall then keep the "Calling Line
Identification notification" enabled until either the AT+CLIP command
is issued by the HF to disable it, or the current Service Level Connection
between the AG and the HF is dropped for any reason.
The HF may disable the echo cancelling and noise
reduction functions resident in the AG via the +NREC command. This
procedure should be performed before any Audio Connection between the HF
and the AG is established.
The HF may activate/deactivate the voice recognition
function resident in the AG via the AT+BVRA command. The functionality
associated with the operation of the voice recognition function in the AG
is considered fully implementation dependent, therefore it is out of the
scope of this specification. Two procedures are covered in this section:
- Voice recognition activation
- Voice recognition deactivation
This procedure is applicable to HF units
supporting internal voice recognition functionality. It provides a means
to read numbers from the AG for the purpose of creating a unique voice tag
and storing the number and its linked voice tag in the HF unit’s memory.
The HF unit can then use its internal Voice.
Recognition to dial the linked phone numbers when a
voice tag is recognized by using the procedure "Place a call with the
phone number supplied by the HF" described above.
There are two different procedure covered in this section
- Audio volume control : This procedure enables the user to
modify the speaker volume and microphone gain of the HF from the AG.
- Volume level synchronization : This procedure allows the HF
to inform the AG of the current values of the HF’s speaker volume
and microphone gain.
For the exchange of the commands and unsolicited
results codes, the format, syntax and procedures of GSM 07.07 shall be
taken as reference. 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. The AG transmits result codes, using the verbose
(rather than numeric) format.
The format for a command from the HF to the AG is
thus:
AT<cmd>=<value><cr>
If the command is processed successfully, the
resulting response from the AG to the HF is:
<cr><lf>OK<cr><lf>
If the command is not processed successfully, the
resulting response from the AG to the HF is:
<cr><lf>ERROR<cr><lf>
The format for an unsolicited result code from
the AG to the HF is:
<cr><lf><result code><cr><lf>
The Hands-Free Profile uses a subset of AT commands
and result codes from existing standards; these are listed in Section
4.24.2 of the Hands-Free Profile. Section 4.24.3 lists the new Bluetooth
defined AT commands and result codes not re-used from any existing
standard.
This profile requires compliance with the Serial
Port Profile.For the Hands-Free profile, both the AG and the HF can
initiate connection establishment. For the purposes of reading the Serial
Port Profile, both the AG and the HF can assume the role of Device A or B.
- For the RFCOMM & L2CAP layer, no additions to the requirements
as stated in the Serial Port Profile shall apply
- For the SDP layer, there is one service record defined for the
hands-free unit and the audio gateway respectively. They can be found
in Section 5.3 of the Hands-Free 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 HF 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.
|
