Radio Baseband LMP HCI L2CAP RFCOMM SDP Profiles

K6 - Headset Profile

   

     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.

        Table Of Contents

6.1 Profile Overview
6.1.1 Profile Stack
6.1.2 Roles/Configurations
6.1.3 Profile Scenarios
6.1.4 Profile Operation/Fundamentals
6.2 Headset Control Interoperability Requirements
6.2.1 Incoming Audio Connection
6.2.2 Outgoing Audio Connection
6.2.3 Audio Connection Release
6.2.4 Audio Connection Transfer
6.2.5 Remote Audio Volume Control
6.2.6 AT Commands and Result Codes
6.2.7 Lower Layer Handling
6.3 Serial Port Profile/Generic Access Profile

 

6.1  Profile Overview

6.1.1  Profile Stack

    The figure below shows the protocols and entities used in this profile.

headset_stack.gif (17888 bytes)

*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.

6.1.2  Roles/Configurations

       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.

6.1.3  Profile Scenarios

    The following restrictions apply to this profile:

  1. For this profile, it is assumed that the ultimate headset use case is the only use case active between the two devices;
  2. 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.
  3. Between headset and audio gateway, only one audio connection at a time is supported;
  4. 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;
  5. The profile offers only basic interoperability – for example, handling of multiple calls at the audio gateway is not included;
  6. The only assumption on the headset’s user interface is the possibility to detect a user initiated action (e.g. pressing a button).

6.1.4  Profile Operation/Fundamentals

    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.

6.2  Headset Control Interoperability Requirements

6.2.1  Incoming Audio Connection

    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).

6.2.2  Outgoing Audio Connection

    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.

6.2.3  Audio Connection Release

    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

6.2.4  Audio Connection Transfer

    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.

6.2.5  Remote 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 establishment.

6.2.6  AT 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.

6.2.7  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.

    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.

6.3  Serial Port Profile/Generic Access Profile

    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.