HFP Spec v16

BLUETOOTH DOC
Prepared
Date / Year-MonthDay
Approved
Revision
Document No
2011-05-10
e-mail address
V16r00
HFP_SPEC
N.B.
Telephony Working Group
telephony-feedback@bluetooth.org
HANDS-FREE PROFILE 1.6
Abstract The Hands-Free Profile (HFP) 1.6 specification defines the minimum set of functions such that a Mobile Phone can be used in conjunction with a Hands-Free device (e.g. installed in the car or represented by a wearable device such as a headset), with a Bluetooth Link providing a wireless means for both remote control of the Mobile Phone by the Hands-Free device and voice connections between the Mobile Phone and the Hands-Free device. Compliance with this specification assures interoperability between a Bluetooth enabled Hands-Free device and any Bluetooth equipped Mobile Phone supporting this profile.
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6
Page 2 of 126
Revision History
Revision Number CRr01 CRr02 CRr03 CRr04 CRr05 CRr06 CRr07 CRr08 Date 04/10/2006 08/12/2006 15/02/2007 01/03/2007 09/03/2007 05/04/2007 11/07/2007 26/07/2007 Comments First version of CR for inclusion of Wide Band Speech based on the approved FIPD Updated regarding identified issues Updated after comments, resolving main outstanding issues Changed from SDP based detection of supported codecs to AT command based indication of available codecs Updated after comments Updated after comments Updated after comments and Vienna F2F Updated conditions in tables 3.3, 3.4 & 5.6. Added EVRC-WB in tables 3.3 and 3, 4 and in sections 5.7.2.4, 5.7.3, 7 and 8. Minor edits Updated after first BARB review Updated after Modified SBC selection vote Added appendix for example PLC and quality metrics Updated Editorial Items Updated Editorial Items Start 1.6 document combining WBS CR, IIA CR, and accepted errata see next row for list: Errata: 913, Errata: 1859, Errata: 1868, Errata: 1872, Errata: 1934, Errata: 1958, Errata: 1989, Errata: 2037, Errata: 2043, Errata: 2144, Errata: 2146, Errata: 2209, Errata: 2211, Errata: 2259, Errata: 2276, Errata: 2286, Errata: 2459, Errata: 2484, Errata: 2517, Errata: 2713, Errata: 2716, Errata: 2742, Errata: 2855, Errata: 3090, Errata: 3152, Errata: 3816 Errata 3688, Errata 1878:Text clarifications to IIA sections Remove errata 2517 changes Errata: 3910 fix Changed some instances of activate and deactivate to enable and disable to avoid confusion in meaning in the Indicators Activation and Deactivation Section. 4.12.3 text edit, 4.12.2 references edit, Figure 1.2 replaced. Front page header Revision correction. Move Section 4.4 to Section 4.34 to avoid renumbering all sections in the ICS. Updated cross references. Changed Refer to to See. and UK to US spelling. Updated core spec reference in Section 14. Added M, O information for WBS and Codec. Adopted by the Bluetooth Board of Directors 10 May 2011
CRr09 CRr10 CRr11 CRr11 CRr12 CRr13 D16r01
26/07/2007 15/02/2008 24/09/2009 17/12/2009 18/01/2010 20/01/2010 23 July 2010
D16r02 D16r03 D16r04
19 August 2010 04 February 2011 16 March 2011
D16r05 D16r06
29 March 2011 5 April 2011, 3 May 2011
D16r07 V16r00
5 May 2011 10 May 2011
Page 3 of 126
Contributors
Name Aaron WEINFIELD Basam MASRI Don LIECHTY Stephen RAXTER Vartika AGARWAL Leonard HINDS Burch SEYMOUR Stephane BOUET Jamie MCHARDY Jurgen SCHNITZLER Guillaume POUJADE Dmitri TOROPOV Erwin WEINANS Tim REILLY Akira MIYAJIMA Ryan BRUNER Scott WALSH Patrick CLAUBERG Neil MACMULLEN Michael BUNTSCHECK Florencio CEBALLOS Bill BERNARD Thomas CARMODY Morgan LINDQVIST Ilya GOLDBERG Tsuyoshi OKADA Kalervo KONTOLA Antonio SALLOUM Rudiger MOSIG Patric LIND Makoto KOBAYASHI James DENT Thomas CARMODY Jiny BRADSHAW Perumal JAYAMANI Sumit SANYAL Company Denso Denso Extended Systems Johnson Controls / Network Analysis Center Motorola Motorola Motorola / Continental Automotive Systems Nissan Nokia Nokia Parrot Siemens Sony Ericsson Stonestreet One Toyota Visteon Plantronics Nokia CSR BMS Visteon Visteon CSR Ericsson Matsushita Electric Industrial Matsushita Electric Industrial Nokia Philips Berner & Mattner (B&M) Sony Ericsson Toshiba Nokia CSR CSR QUALCOMM Broadcom 10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 Name Jeremy STARK Eric RASMUSSEN Fridjof GOEBEL Robert ZOPF Michael RUSSELL Josselin de la Broise Company CSR GN Netcom Daimler Broadcom Motorola Parrot / Marvell
Page 4 of 126
10 May 2011
Page 5 of 126
Disclaimer and Copyright Notice

The copyright in this specification is owned by the Promoter Members of Bluetooth Special Interest Group (SIG), Inc. (Bluetooth SIG). Use of these specifications and any related intellectual property (collectively, the Specification), is governed by the Promoters Membership Agreement among the Promoter Members and Bluetooth SIG (the Promoters Agreement), certain membership agreements between Bluetooth SIG and its Adopter and Associate Members (the Membership Agreements) and the Bluetooth Specification Early Adopters Agreements (1.2 Early Adopters Agreements) among Early Adopter members of the unincorporated Bluetooth SIG and the Promoter Members (the Early Adopters Agreement). Certain rights and obligations of the Promoter Members under the Early Adopters Agreements have been assigned to Bluetooth SIG by the Promoter Members. Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early Adopters Agreement (each such person or party, a Member), is prohibited. The legal rights and obligations of each Member are governed by their applicable Membership Agreement, Early Adopters Agreement or Promoters Agreement. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein. Any use of the Specification not in compliance with the terms of the applicable Membership Agreement, Early Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result in termination of the applicable Membership Agreement or Early Adopters Agreement and other liability permitted by the applicable agreement or by applicable law to Bluetooth SIG or any of its members for patent, copyright and/or trademark infringement. THE SPECIFICATION IS PROVIDED AS IS WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR ANY WARRANTY ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE, PROPOSAL, SPECIFICATION OR SAMPLE. Each Member hereby acknowledges that products equipped with the Bluetooth technology ("Bluetooth products") may be subject to various regulatory controls under the laws and regulations of various governments worldwide. Such laws and regulatory controls may govern, among other things, the combination, operation, use, implementation and distribution of Bluetooth products. Examples of such laws and regulatory controls include, but are not limited to, airline regulatory controls, telecommunications regulations, technology transfer controls and health and safety regulations. Each Member is solely responsible for the compliance by their Bluetooth Products with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for their Bluetooth products related to such regulations within the applicable jurisdictions. Each Member acknowledges that nothing in the Specification provides any information or assistance in connection with securing such compliance, authorizations or licenses. NOTHING IN THE SPECIFICATION CREATES ANY WARRANTIES, EITHER EXPRESS OR IMPLIED, REGARDING SUCH LAWS OR REGULATIONS.
ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS EXPRESSLY DISCLAIMED. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY WAIVES ANY CLAIM AGAINST BLUETOOTH SIG AND ITS PROMOTER MEMBERS RELATED TO USE OF THE SPECIFICATION.
Bluetooth SIG reserve the right to adopt any changes or alterations to the Specification as it deems necessary or appropriate. Copyright 20012011. Bluetooth SIG, Inc. All copyrights in the Bluetooth Specifications themselves are owned by Ericsson AB, Lenovo (Singapore) Pte. Ltd., Intel Corporation, Microsoft Corporation, Motorola Mobility, Inc., Nokia Corporation and Toshiba Corporation. *Other third-party brands and names are the property of their respective owners.
10 May 2011
Page 6 of 126
Contents
1 Introduction .................................................................................................................................... 9 Scope ......................................................................................................................................... 9 Profile Dependencies .............................................................................................................. 10 Symbols and Conventions ....................................................................................................... 10 1.3.1 Requirement Status Symbols ........................................................................................... 10 1.3.2 Naming Conventions ......................................................................................................... 11 1.3.3 Signaling Diagram Conventions ........................................................................................ 12 Profile Overview ........................................................................................................................... 13 2.1 Protocol Stack.......................................................................................................................... 13 2.2 Configuration and Roles .......................................................................................................... 14 2.3 User Requirements and Scenarios ......................................................................................... 14 2.4 Profile Fundamentals ............................................................................................................... 15 2.5 Conformance ........................................................................................................................... 15 Application layer .......................................................................................................................... 16 Hands-Free Control Interoperability Requirements ................................................................. 19 4.1 Introduction .............................................................................................................................. 19 4.2 Service Level Connection Establishment ................................................................................ 19 4.2.1 Service Level Connection Initialization ............................................................................. 19 4.2.2 Link Loss Recovery ........................................................................................................... 23 4.3 Service Level Connection Release ......................................................................................... 23 4.4 Transfer of Registration Status ................................................................................................ 24 4.5 Transfer of Signal Strength Indication ..................................................................................... 24 4.6 Transfer of Roaming Status Indication .................................................................................... 25 4.7 Transfer of Battery Level Indication of AG .............................................................................. 26 4.8 Query Operator Selection ........................................................................................................ 27 4.9 Report Extended Audio Gateway Error Results Code ............................................................ 27 4.10 Transfer of Call, Call Setup and Held Call Status ................................................................... 28 4.11 Audio Connection Setup .......................................................................................................... 29 4.11.1 Audio Connection Setup by AG ........................................................................................ 29 4.11.2 Audio Connection Setup by HF ......................................................................................... 30 4.11.3 Codec Connection Setup .................................................................................................. 31 4.11.4 Available codecs updating ................................................................................................ 33 4.11.5 Codec re-negotiation ......................................................................................................... 34 4.12 Audio Connection Release ...................................................................................................... 34 4.13 Answer an Incoming Call ......................................................................................................... 35 4.13.1 Answer Incoming Call from the HF In-Band Ringing ..................................................... 35 4.13.2 Answer Incoming Call from the HF No In-Band Ringing................................................ 36 4.13.3 Answer Incoming Call from the AG ................................................................................... 37 4.13.4 Change the In-Band Ring Tone Setting ............................................................................ 38 4.14 Reject an Incoming Call ........................................................................................................... 39 4.14.1 Reject an Incoming Call from the HF ................................................................................ 39 4.14.2 Rejection/Interruption of an Incoming Call in the AG ........................................................ 40 4.15 Terminate a Call Process ........................................................................................................ 41 4.15.1 Terminate a Call Process from the HF.............................................................................. 41 4.15.2 Terminate a Call Process from the AG ............................................................................. 41 4.16 Audio Connection Transfer towards the HF ............................................................................ 42 4.17 Audio Connection Transfer towards the AG ............................................................................ 43 4.18 Place a Call with the Phone Number Supplied by the HF ....................................................... 44 4.19 Memory Dialing from the HF.................................................................................................... 45 4.20 Last Number Re-Dial from the HF ........................................................................................... 46 4.21 Call Waiting Notification Activation .......................................................................................... 48 4.22 Three Way Call Handling ......................................................................................................... 49 1.1 1.2 1.3 10 May 2011
3 4
Page 7 of 126
4.22.1 Three Way CallingCall Waiting Notification ................................................................... 50 4.22.2 Three Way Calls Third Party Call Placed from the HF .................................................. 51 4.23 Calling Line Identification (CLI) Notification ............................................................................. 52 4.24 The HF Requests Turning off the AGs EC and NR ................................................................ 53 4.25 Voice Recognition Activation ................................................................................................... 54 4.25.1 Voice Recognition Activation HF Initiated ...................................................................... 55 4.25.2 Voice Recognition Activation AG Initiated ..................................................................... 56 4.25.3 Voice Recognition Deactivation ........................................................................................ 56 4.26 Attach a Phone Number to a Voice Tag .................................................................................. 57 4.27 Transmit DTMF Codes ............................................................................................................ 58 4.28 Remote Audio Volume Control ................................................................................................ 58 4.28.1 Audio Volume Control ....................................................................................................... 58 4.28.2 Volume Level Synchronization .......................................................................................... 59 4.29 Response and Hold ................................................................................................................. 61 4.29.1 Query Response and Hold Status .................................................................................... 61 4.29.2 Put an Incoming Call on Hold from HF ............................................................................. 62 4.29.3 Put an Incoming Call on Hold from AG ............................................................................. 63 4.29.4 Accept a Held Incoming Call from HF ............................................................................... 64 4.29.5 Accept a Held Incoming Call from AG .............................................................................. 65 4.29.6 Reject a Held Incoming Call from HF................................................................................ 65 4.29.7 Reject a Held Incoming Call from AG ............................................................................... 66 4.29.8 Held Incoming Call Terminated by Caller ......................................................................... 68 4.30 Subscriber Number Information............................................................................................... 69 4.31 Enhanced Call Status Indications ............................................................................................ 70 4.31.1 Query List of Current Calls in AG ...................................................................................... 70 4.31.2 Indication of Status for Held Calls ..................................................................................... 70 4.32 Enhanced Call Control Mechanisms ....................................................................................... 73 4.32.1 Release Specified Call Index ............................................................................................ 73 4.32.2 Private Consultation Mode ................................................................................................ 73 4.33 AT Command and Results Codes ........................................................................................... 74 4.33.1 General ............................................................................................................................. 74 4.33.2 AT Capabilities Re-Used from GSM 07.07 and 3GPP 27.007 ......................................... 75 4.34 Indicators Activation and Deactivation .................................................................................... 84 4.34.1 Bluetooth Defined AT Capabilities .................................................................................... 85 Serial Port Profile ......................................................................................................................... 93 5.1 RFCOMM Interoperability Requirements ................................................................................ 93 5.2 L2CAP Interoperability Requirements ..................................................................................... 93 5.3 SDP Interoperability Requirements ......................................................................................... 93 5.3.1 Interaction with Hands-Free Profile Rev 0.96 Implementations ....................................... 96 5.3.2 Interaction with HFP 0.96, 1.0 and HFP 1.5 implementations .......................................... 96 5.4 Link Manager (LM) Interoperability Requirements .................................................................. 97 5.5 Link Control (LC) Interoperability Requirements ..................................................................... 98 5.5.1 Class of Device ................................................................................................................. 98 5.6 Baseband Interoperability Requirements ................................................................................ 98 5.7 Codec Interoperability Requirements ...................................................................................... 98 5.7.1 Synchronous Connection Interoperability Requirements ................................................. 99 5.7.2 Synchronization Header for Transparent Data ............................................................... 100 5.7.3 CVSD coding ................................................................................................................... 101 5.7.4 mSBC coding .................................................................................................................. 101 5.7.5 Codec vs link parameter negotiation ............................................................................... 102 5.7.6 Optional Codecs.............................................................................................................. 102 5.8 Speech Quality Recommendations ....................................................................................... 103 5.8.1 Packet Loss Concealment (PLC) .................................................................................... 103 5.8.2 Signal Levels ................................................................................................................... 103 Generic Access Profile .............................................................................................................. 104 10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 6.1 6.2 6.3 7 8 9 10 11
Page 8 of 126
12 13
14
15
Modes .................................................................................................................................... 104 Security Aspects .................................................................................................................... 104 Idle Mode Procedures ........................................................................................................... 104 References .................................................................................................................................. 105 List of Acronyms and Abbreviations ....................................................................................... 106 List of Figures ............................................................................................................................ 107 List of Tables .............................................................................................................................. 109 Appendix A: Technical Specification of mSBC ...................................................................... 110 11.1 Introduction ............................................................................................................................ 110 11.1.1 Mnemonics ...................................................................................................................... 110 11.2 Syntax .................................................................................................................................... 110 11.3 Semantics .............................................................................................................................. 110 11.3.1 Frame_header ................................................................................................................. 110 11.3.2 Padding ........................................................................................................................... 111 Appendix B: Codec IDs ............................................................................................................ 112 Appendix C: Example PLC Implementation ............................................................................ 113 13.1 Baseline Packet Loss Concealment ...................................................................................... 113 13.1.1 Waveform Substitution Based On Pattern Matching ...................................................... 113 13.1.2 Overlap-Add .................................................................................................................... 113 13.1.3 Amplitude Matching......................................................................................................... 114 13.2 Integration of PLC with mSBC ............................................................................................... 114 13.2.1 Merging in the First Substitution Frame Avoiding Delay .............................................. 114 13.2.2 Re-convergence of the mSBC Decoder in the First Correct Packet After Packet Loss . 114 13.3 API Description ...................................................................................................................... 114 13.3.1 Memory Allocation........................................................................................................... 114 13.3.2 Initialization ..................................................................................................................... 115 13.3.3 Good Frame Processing ................................................................................................. 115 13.3.4 Bad Frame Processing ................................................................................................... 115 13.3.5 SBC Decoder Zero-Input Response ............................................................................... 116 13.3.6 Bad Frame Calling Example ........................................................................................... 117 13.4 Source Code (ANSI C) .......................................................................................................... 117 13.4.1 Source code for file sbcplc.h ........................................................................................ 117 13.4.2 Source code for the file sbcplc.c .................................................................................. 117 Appendix D: Quality Metrics ..................................................................................................... 123 14.1 Audio levels ........................................................................................................................... 123 14.2 Bluetooth Sensitivity Frequency Responses ......................................................................... 124 14.2.1 Bluetooth Send Sensitivity Frequency Response ........................................................... 124 14.2.2 Bluetooth Receive Sensitivity Frequency Response ...................................................... 125 Appendix E Pre-1.6 Document History ................................................................................. 126
10 May 2011
Page 9 of 126
1 Introduction
1.1 Scope
This document defines the protocols and procedures that shall be used by devices implementing the Hands-Free Profile. The most common examples of such devices are in-car Hands-Free units used together with cellular phones, or wearable wireless headsets. The profile defines how two devices supporting the Hands-Free Profile shall interact with each other on a point-to-point basis. An implementation of the Hands-Free Profile typically enables a headset, or an embedded hands-free unit to connect, wirelessly, to a cellular phone for the purposes of acting as the cellular phones audio input and output mechanism and allowing typical telephony functions to be performed without access to the actual phone.
10 May 2011
Page 10 of 126
1.2
Profile Dependencies
In Figure 1.1, the Bluetooth profile structure and the dependencies of the profiles are depicted. A profile is dependent upon another profile if it re-uses parts of that profile, by explicitly referencing it. Dependency is illustrated in Figure 1.1.
Hands-Free Profile (HFP)
AT CMD
Serial Port Profile (SPP) Generic Access Profile (GAP)

Service Discovery Protocol (SDP)
SCO and eSCO (Audio)
RFCOMM
Logical Link and Adapation Layer (L2CAP) Host Controller Interface (HCI) Controller(s)
Figure 1.1: Bluetooth Profiles
As indicated in the figure, the Hands-Free Profile is dependent upon both the Serial Port Profile [5] and the Generic Access Profile [4]. Details are provided in Sections 5 (Serial Port Profile) and 6 (Generic Access Profile).
1.3
Symbols and Conventions
1.3.1 Requirement Status Symbols In this document, the following symbols are used: "M" for mandatory to support "O" for optional to support "X" for excluded (used for capabilities that may be supported by the device, but the Hands-Free Profile shall not use these capabilities) "C" for conditional to support
"N/A" for not applicable (in the given context this capability is not defined) Some capabilities or features (identified as X), mandated according to the relevant Bluetooth specifications, are excluded with respect to this profile because they may degrade the operation of devices in the particular use case. Therefore, features or capabilities labeled X shall never be activated while operating in a use case where they are labeled as such.
10 May 2011
Page 11 of 126
1.3.2 Naming Conventions In this document, the following naming conventions are used: Where Core Specification is said it refers to the Bluetooth Core Specification 1.1 or later adopted by the Bluetooth SIG. Where LMP link is said, it means a Link Manager (LM) level link over which only Link Manager Protocol (LMP) commands are conveyed. Where RFCOMM connection is said, it means the presence of a virtual serial port as specified in [6]. Where Service Level Connection is said, it means a synchronized high-level protocol connection involving a portion of the protocol stack. In this specific case, it refers to the presence of a RFCOMM connection, and assumes that the HF has synchronized itself to the state of the AG using the specified Service Level Connection initialization procedure. Where Service Level Connection initialization is said, it means the execution of the set of AT commands and responses specified by the profile necessary to synchronize the state of the HF with that of the AG. Where Service Level Connection establishment is said, it means the combined process of establishing the RFCOMM connection, as well as the necessary device synchronization using Service Level Connection initialization. Where Synchronous Connection is said, it means a SCO or eSCO logical link intended for supporting a full duplex Audio Connection. Where Audio Connection is said, it means a Synchronous Connection including the means to provide a complete audio path between two devices assuming roles within this profile. Where Codec Connection is said, it means a Synchronous Connection established after profile level negotiation of Codec and related configuration. Where Wide Band Speech Connection is said, it means a Codec Connection where the media being transported consists of encoded frames derived from speech (or other audio) sampled at 16 kHz. The format of the media transported over the Synchronous Connection shall be negotiated during the establishment of the Codec Connection. Where mSBC or Modified SBC is said, it means a modified version of the A2DP SBC codec that is used as the mandatory codec for Wide Band Speech Connections. Section 5.7.4 contains a complete definition of the modifications which comprise mSBC. Where incoming call is said, it means a call connection in the direction Phone Network=>AG, such that it is initiated by the Network to which the AG is attached. Where outgoing call is said, it means a call connection in the direction AG=>Phone Network, such that it is initiated by the AG towards the Network to which it is attached.
10 May 2011
Page 12 of 126
Where legacy device is said, it means a device that is compatible with an earlier version, v0.96, v1.0 or v1.5, of this specification; see Section 5.3.2. Signaling Diagram Conventions
1.3.3
The signaling diagrams in this specification are informative only. Within the diagrams, the following conventions are used to describe procedures:
A
Mandatory signal sent by A Optional signal sent by B
Mandatory procedure initiated by B
Optional procedure initiated by A
Mandatory procedure initiated by either A or B
Optional procedure initiated by either A or B
Current state/condition
Optional state/condition
Figure 1.2: Conventions used in signaling diagrams
10 May 2011
Page 13 of 126
2 Profile Overview
2.1 Protocol Stack
Application
(Audio port emulation)
Figure 2.1shows the protocols and entities used in this profile.
Application
(Audio driver)
Hands-Free control
Hands-Free control RFCOMM LMP SDP L2CAP
RFCOMM LMP
SDP
L2CAP
Baseband Audio Gateway side

Figure 2.1: Protocol stack
Baseband Hands-Free side
The Baseband, LMP and L2CAP are the OSI layer 1 and 2 Bluetooth protocols. RFCOMM is the Bluetooth serial port emulation entity. SDP is the Bluetooth Service Discovery Protocol. See [1] for more details on these topics. Compatibility to v1.1 or later Core Specification is required. Hands-Free control is the entity responsible for Hands-Free unit specific control signaling; this signaling 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, Synchronous Connection establishment). The audio port emulation layer shown in Figure 2.1 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 in Figure 2.1, the Serial Port Profile [5] is used as the base standard. For these protocols, all mandatory requirements stated in the Serial Port Profile apply except in those cases where this specification explicitly states deviations.
10 May 2011
Page 14 of 126
2.2
Configuration and Roles
Figure 2.2 shows typical configurations of devices for which the Hands-Free Profile is applicable:
Simple Headset Cellular Connection
OR
Bluetooth Connection
Public Wireless Network
Hands-Free unit installed in the car
Figure 2.2: Typical Hands-Free Use
The following roles are defined for this profile: 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 Gateways remote audio input and output mechanism. It also provides some remote control means. These terms are used in the rest of this document to designate these roles.
2.3
User Requirements and Scenarios
The following rules apply to this profile: a) The profile states the mandatory and optional features when the Hands-Free Profile is active in the Audio Gateway and the Hands-Free unit. b) 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, does not have perceived audio degradation. c) Between the Hands-Free unit and the Audio Gateway, only one Audio Connection per Service Level Connection at a time is supported. d) Both the Audio Gateway and the Hands-Free unit may initiate Audio Connection establishment and release. Valid speech data shall exist on the Synchronous Connection in both directions after the Audio Connection is established. Since it is only the AG that knows if wide band speech should be used, it should always be the AG that establishes the Synchronous Connection with the required codec. e) Whenever an Audio Connection exists, a related Service Level Connection shall also exist. f) The presence of a Service Level Connection shall not imply that an Audio Connection exists. Releasing a Service Level Connection shall also release any existing Audio Connection related to it.
10 May 2011
Page 15 of 126
2.4
Profile Fundamentals
If a LMP link is not already established between the Hands-Free unit and the Audio Gateway, the LMP link shall be set up before any other procedure is performed. There are no fixed master or slave roles in the profile. The Audio Gateway and Hand-Free unit provide serial port emulation. For the serial port emulation, RFCOMM (see [1]) is used. The serial port emulation is used to transport the user data including modem control signals and AT command from the Hands-Free unit to the Audio Gateway. The AT commands are parsed by the Audio Gateway and responses are sent to the Hands-Free unit via the Bluetooth serial port connection.
2.5
Conformance
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. Devices that claim compliance to this profile shall not have a dependency on any other profiles and protocols beyond what is specified in Section 2.1. All mandatory, optional and conditional capabilities, for which support is indicated, are subject to verification as part of the Bluetooth Qualification Program.
10 May 2011
Page 16 of 126
3 Application layer
This section describes the feature requirements for units complying with HFP. Table 3.1 shows the feature requirements for this profile.
1. 2. 3. 4 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21a. 21b. 22. 23 Feature Connection management Phone status information Audio Connection handling Accept an incoming voice call Reject an incoming voice call Terminate a call Audio Connection transfer during an ongoing call Place a call with a phone number supplied by the HF Place a call using memory dialing Place a call to the last number dialed Call waiting notification Three way calling Calling Line Identification (CLI) Echo canceling (EC) and noise reduction (NR) Voice recognition activation Attach a Phone number to a voice tag Ability to transmit DTMF codes Remote audio volume control Respond and Hold Subscriber Number Information Enhanced Call Status Enhanced Call Controls Individual Indicator Activation Wide Band Speech Support in HF M M M M M M M O O O O O O O O O O O O O O O O O
(note 4) (note 2) (note 1)
Support in AG M M M M O M M M M M M O O O O M O O M M O M O
(note 4) (note 3)
24 Codec Negotiation O O Note 1: The HF shall support at least the two indicators "service" and "call". Note 2: If "Three way calling" is supported by the HF, it shall support AT+CHLD values 1 and 2. The HF may additionally support AT+CHLD values 0, 3 and 4. Note 3: If "Three way calling" is supported by the AG, it shall support AT+CHLD values 1 and 2. The AG may additionally support AT+CHLD values 0, 3, and 4. Note 4: If Wide Band Speech is supported, Codec Negotiation shall also be supported. Table 3.1: Application layer procedures
10 May 2011
Page 17 of 126
Table 3.2 maps each feature to the procedures used for that feature. All procedures are mandatory if the feature is supported.
Feature 1. 2. Connection management Phone status information Procedure Service Level Connection establishment Service Level Connection release Transfer of Registration Status Transfer of Signal Strength Indication Transfer of Roaming Status Indication Transfer of Battery Level Indication Query of Operator Selection Extended Audio Gateway Error Codes Transfer of Call, Call Setup and Call Held Status Ref. 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10
3.
Audio Connection handling
Audio Connection set up Audio Connection release Codec Connection set up Answer an incoming call Reject an incoming call Terminate a call process Audio Connection transfer towards the HF Audio Connection transfer towards the AG Place a call with the phone number supplied by the HF Memory dialing from the HF Last number re-dial from the HF Call waiting notification activation Three way call handling Calling Line Identification (CLI) notification HF requests turning off the AGs EC and NR Voice recognition activation Attach a voice tag to a phone number Transmit DTMF code Remote audio volume control Volume level synchronization
4.11 4.12 4.11 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28
4. 5. 6. 7.
Accept an incoming voice call Reject an incoming voice call Terminate a call Audio Connection transfer during an ongoing call Place a call with the phone number supplied by the HF Place a call using memory dialing Place a call to the last number dialed Call waiting notification Three way calling Calling Line Identification (CLI) Echo canceling (EC) and noise reduction (NR) Voice recognition activation Attach a phone number to a voice tag Ability to transmit DTMF codes Remote audio volume control
8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 Feature 19. Response and Hold Procedure Query response and hold status Put an incoming call on hold from HF Put an incoming call on hold from AG Accept a held incoming call from HF Accept a held incoming call from AG Reject a held incoming call from HF Reject a held incoming call from AG Held incoming call terminated by caller Subscriber Number Information Query Call List Indication of Held Call Status Release Specified Call Private Consult Mode Indicators Activation and Deactivation Wide Band Speech Codec Negotiation
Page 18 of 126 Ref. 4.29 4.29 4.29 4.29 4.29 4.29 4.29 4.29 4.30 4.31 4.31 4.32 4.32 4.5 Apdx A, B, C 4.11
20. 21a. 21b. 22. 23 24
Subscriber Number Information Enhanced Call Status Enhanced Call Control Individual Indicator Activation Wide Band Speech Codec Negotiation
Table 3.2: Application layer feature to procedure mapping
Table 3.3 shows the codec requirements for this profile.

1. 2. Codec CVSD mSBC Support in HF M C.1 Support in AG M C.1
C.1: Mandatory if Wide Band Speech is supported, or excluded otherwise Table 3.3: Requirements on supported codecs
Table 3.4 shows a summary of the mapping of codec requirements on link features for this profile.
1. 2. 3. 4. 5 6. Feature D0 CVSD on SCO link (HV1) D1 CVSD on SCO link (HV3) S1 CVSD eSCO link (EV3) S2 CVSD on EDR eSCO link (2-EV3) S3 CVSD on EDR eSCO link (2-EV3) T1 mSBC on eSCO link (EV3) Support in HF M M C1 C2 C2 C3 Support in AG M M C1 C2 C2 C3 C3
7. T2 mSBC on EDR on eSCO link (2-EV3) C3 C1: Mandatory if eSCO is supported, or excluded otherwise C2: Mandatory if EDR is supported, or excluded otherwise C3: Mandatory if Wide Band Speech is supported, or excluded otherwise Table 3.4: Codec to link feature mapping
10 May 2011
Page 19 of 126
4 Hands-Free Control Interoperability Requirements

4.1 Introduction
The interoperability requirements for the Hands-Free Control entity are completely contained in this section. Sections 4.2 through 4.28 specify the requirements for the procedures directly related to the application layer features. The procedures listed in this section are primarily based on the use of a minimum set of AT commands as the control protocol. Section 4.33 specifies these AT commands and their result codes. Section 4.2 specifies how Service Level Connections are handled in general and specifically states how the layers beneath the Hands-Free Control entity are used to establish and release a Service Level Connection.
4.2
Service Level Connection Establishment
Upon a user action or an internal event, either the HF or the AG may initiate a Service Level Connection establishment 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. The RFCOMM connection establishment shall be performed as described in Section 7.3 of Generic Access Profile [5] and Section 3 of Serial Port Profile [6]. 4.2.1 Service Level Connection Initialization When an RFCOMM connection has been established the Service Level Connection Initialization procedure shall be executed. First in the initialization procedure the HF shall send the AT+BRSF=<HF supported features> command to the AG to both notify the AG of the supported features in the HF, as well as to retrieve the supported features in the AG using the +BRSF result code.1 Secondly in the initialization procedure, if the HF supports the Codec Negotiation feature, it shall check if the AT+BRSF command response from the AG to see if the AG has indicated that it supports the Codec Negotiation feature. If both the HF and AG do support the Codec Negotiation feature then the HF shall send the AT+BAC=<HF
Audio Gateways supporting the 0.96 version of Hands-Free Profile will return ERROR as a response to AT+BRSF 10 May 2011
Page 20 of 126
available codecs> command to the AG to notify the AG of the available codecs in the HF.2 After having retrieved the supported features in the AG, the HF shall determine which indicators are supported by the AG, as well as the ordering of the supported indicators. This is because, according to the 3GPP 27.007 specification [2], the AG may support additional indicators not provided for by the Hands-Free Profile, and because the ordering of the indicators is implementation specific. The HF uses the AT+CIND=? Test command to retrieve information about the supported indicators and their ordering. Once the HF has the necessary supported indicator and ordering information, it shall retrieve the current status of the indicators in the AG using the AT+CIND? Read command. After having retrieved the status of the indicators in the AG, the HF shall then enable the "Indicators status update" function in the AG by issuing the AT+CMER command, to which the AG shall respond with OK. As a result, the AG shall send the +CIEV unsolicited result code with the corresponding indicator value whenever a change in service, call, or call setup status occurs. When an update is required for both the call and call setup indicators, the AG shall send the +CIEV unsolicited result code for the call indicator before sending the +CIEV unsolicited result code for the call setup indicator. The HF shall use the information provided by the +CIEV code to update its own internal and/or external indications. Once the "Indicators status update" function has been enabled, the AG shall keep the function enabled until either the AT+CMER command is issued to disable it, or the current Service Level Connection between the AG and the HF is dropped for any reason. After the HF has enabled the Indicators status update function in the AG, and if the Call waiting and 3-way calling bit was set in the supported features bitmap by both the HF and the AG, the HF shall issue the AT+CHLD=? test command to retrieve the information about how the call hold and multiparty services are supported in the AG. The HF shall not issue the AT+CHLD=? test command in case either the HF or the AG does not support the "Three way calling" feature. The HF shall consider the Service Level Connection fully initialized, and thereby established, in either of the following cases: After the HF has successfully retrieved information about how call hold and multiparty services are supported in the AG using the AT+CHLD command, if and only if the Call waiting and 3-way calling bit was set in the SupportedFeatures attribute of the SDP records for both HF and AG. After the HF has successfully enabled the Indicator status update using the AT+CMER command, if and only if the Call waiting and 3-way calling bit was not
Legacy devices shall not indicate support for the Codec Negotiation Feature. 10 May 2011
Page 21 of 126
set in the SupportedFeatures attribute of the SDP records for either the HF or the AG. If the HF receives an indication from the AG that a call is currently active, the HF may determine if an unanswered call is currently on hold by querying the Response and Hold state of the AG (see Section 4.28.1). The AG shall consider the Service Level Connection to be fully initialized, and thereby established, in either of the following cases: After that the AG has successfully responded with information about how call hold and multiparty services are supported in the AG using +CHLD as well as responded OK, if and only if the Call waiting and 3-way calling bit was set in the supported features bitmap for both HF and AG.
After the AG has successfully responded with OK to the AT+CMER command (to enable the Indicator status update function), if and only if the Call waiting and 3way calling bit was not set in the supported features bitmap for either the HF or the AG. See Section 4.33 for more information on the AT+CIND, AT+CMER, AT+CHLD, AT+BAC and AT+BRSF commands and the +CIEV unsolicited result code.
10 May 2011
Page 22 of 126
HF
AG
Internal event or user action
RFCOMM connection establishment
Service Level Connection Initialization Procedure

The HF notifies the AG about its own supported features and the AG responds with its supported features AT+BRSF=<HF Supported features> +BRSF:<AG Supported features> OK
The HF notifies the AG about its own available codecs if it supports the Codec Negotiation Feature.
AT+BAC=<HF Available Codecs> OK
AT+CIND=? The HF retrieves the information describing the indicators supported in the AG +CIND: OK AT+CIND? ? +CIND: OK
The HF requests the current status of the indicators in the AG
The HF requests enabling Indicator Status update in the AG
AT+CMER= OK
AT+CHLD=? The HF retrieves the information describing the call hold and multiparty services supported in the AG +CHLD: OK
Figure 4.1: Service Level Connection establishment
10 May 2011
Page 23 of 126
4.2.2 Link Loss Recovery This section addresses the link loss recovery from an HF. The HF may reconnect with the AG whenever there is loss of Bluetooth link. When a Service Level Connection is disconnected due to explicit termination at one end (using the "Service connection release" as described in Section Service Level Connection Release), then both devices (AG and HF) shall wait for an explicit user action before an attempt is made to re-establish the Service Level Connection. If the HF determines that the Service Level Connection was disconnected due to a link supervision timeout, then the HF may execute the "Service Level Connection establishment" procedure as described in Section 4.2 to establish a new Service Level Connection to the AG. Following a link loss due to link supervision timeout, the HF shall not assume that the service level connection state from the previous connection is valid (such as Call Status, Service Status).
4.3
Service Level Connection Release
This section describes the procedure for releasing a Service Level Connection. The disconnection of a Service Level Connection shall result in the immediate removal of the corresponding RFCOMM data link channel between the HF and the AG. Also, an existing audio connection has to be removed as consequence of the removal of the Service Level Connection. The removal of the L2CAP and link layers is optional. An established Service Level Connection shall be released using a Service Level Connection removal procedure. Either the HF or AG shall initiate the Service Level Connection release procedure due to an explicit user request. The Service Level Connection release procedure shall be initiated if the Bluetooth functionality is disabled in either the HF or AG.
The Service Level Connection release procedure may be initiated if an Audio Connection transfer towards the AG, as stated in section 4.11, is performed during an ongoing call in the AG. In the case that the Service Level Connection is removed, the AG shall attempt to re-establish the Service Level Connection once the call is dropped. As pre-condition for this procedure, an ongoing Service Level Connection between the AG and the HF shall exist.
10 May 2011
Page 24 of 126
HF
Established Service Level Connection
AG
Internal event or user action RFCOMM connection removal
Figure 4.2: Service Level Connection removal
4.4
Transfer of Registration Status
The AT+CMER command, as described in Section 4.33, enables the Registration status update function in the AG. The AT+BIA command, as described in Section 4.33, allows the HF to deactivate/reactivate individual indicators. When the CMER function is enabled and the registration status indicator has not been deactivated by the AT+BIA command, the AG shall send the +CIEV unsolicited result code with the corresponding service indicator and value whenever the AG's registration status changes. The HF shall be capable of interpreting the information provided by the +CIEV result code to determine the service availability status as listed in Section 4.32.2. If the CMER function is disabled or the indicator has been deactivated by the AT+BIA command, the AG shall not send the unsolicited result code.
HF
AG
Internal event: Registration Status changes
The HF refreshes its registration status indication
+CIEV:
The AG reports the change in the Registration Status
Figure 4.3: Typical Registration Status update
4.5
Transfer of Signal Strength Indication
The AT+CMER command, as described in Section 4.2, enables the Signal strength Indication function in the AG.
10 May 2011
Page 25 of 126
The AT+BIA command, as described in Section 4.2, allows the HF to deactivate/reactivate individual indicators. When the CMER function is enabled and the indicator has not been deactivated by the AT+BIA command, the AG shall send the +CIEV unsolicited result code with the corresponding signal strength indicator and value whenever the AG's signal strength changes. The HF shall be capable of interpreting the information provided by the +CIEV result code to determine the signal strength as listed in Section 4.32.2. If the CMER function is disabled or the indicator has been deactivated by the AT+BIA command, the AG shall not send the unsolicited result code.
HF
AG
Established service level connection
Internal event: Signal strength Status changes
+CIEV: <Signal strength Ind>,<Value>
The AG reports the change in the signal strength Status
Figure 4.4: Transfer of Signal strength indication
As a result, the AG shall send the +CIEV unsolicited result code with the corresponding signal strength value whenever its signal strength changes.
4.6
Transfer of Roaming Status Indication
The AT+CMER command, as described in Section 4.33, enables the Roaming Status Indication function in the AG. The AT+BIA command, as described in Section 4.33, allows the HF to deactivate/reactivate individual indicators. When the CMER function is enabled and the indicator has not been deactivated by the AT+BIA command, the AG shall send the +CIEV unsolicited result code with the corresponding roaming status indicator and value whenever the AG's roaming status changes. The HF shall be capable of interpreting the information provided by the +CIEV result code to determine the roaming status as listed in Section 4.32.2. If the CMER function is disabled or the indicator has been deactivated by the AT+BIA command, the AG shall not send the unsolicited result code.
10 May 2011
Page 26 of 126
HF
Established Service Level
AG
Internal event: Roaming Status changes
+CIEV: <RoamingInd>,<Value>
[The AG reports the change in the Roaming Status
Figure 4.5: Transfer of Roaming Status Indication
4.7
Transfer of Battery Level Indication of AG
The AT+CMER command, as described in Section enables the Battery Level Indication function in the AG. The AT+BIA command, as described in Section 4.33, allows the HF to deactivate/reactivate individual indicators. When the CMER function is enabled and the indicator has not been deactivated by the AT+BIA command, the AG shall send the +CIEV unsolicited result code with the corresponding battery level indicator and value whenever the AG's battery level changes. The HF shall be capable of interpreting the information provided by the +CIEV result code to determine the battery level as listed in Section 4.32.2. If the CMER function is disabled or the indicator has been deactivated by the AT+BIA command, the AG shall not send the unsolicited result code.
HF
AG
Internal event: Battery level changes +CIEV: <Battery level Ind>,<Value>
The AG reports the change in the Battery Status
Figure 4.6: Transfer of Battery level indication 10 May 2011
Page 27 of 126
4.8
Query Operator Selection
The HF shall execute this procedure to find out the name of the currently selected Network operator by AG. The following pre-condition applies for this procedure: An ongoing connection between the AG and the HF shall exist. If this connection did not exist, the AG shall establish a connection using Service Level Connection set up procedure described in Section 4.2.
HF
AG
The HF sets the network name format to long alphanumeric (only needs to be sent once)
AT+COPS=3,0
OK
The HF requests current Network Name
AT+COPS?
+COPS: <mode>, 0, <operator>
OK
The AG reports the current Network operator name in long alphanumeric format.
Figure 4.7: Query currently selected Network operator
HF shall send AT+COPS=3,0 command to set name format to long alphanumeric. Long alphanumeric is defined as a maximum of 16 characters. The value of 3 as the first parameter indicates that this command is only affecting the format parameter (the second parameter). The second parameter, 0, is the value required to set the format to long alphanumeric. Upon an internal event or user-initiated action, HF shall send the AT+COPS? (Read) command to find the currently selected operator. AG shall respond with +COPS response indicating the currently selected operator. If no operator is selected, <format> and <operator> are omitted.
4.9
Report Extended Audio Gateway Error Results Code
The HF shall execute this procedure to enable/disable Extended Audio Gateway Error result codes in the AG. The following pre-condition applies for this procedure:
10 May 2011
Page 28 of 126
An ongoing connection between the AG and the HF shall exist. If this connection did not exist, the AG shall establish a connection using Service Level Connection set up procedure described in section 4.2.
HF
AG
AT+CMEE=<n>
The HF enables/disables Error result code in AG
OK
Figure 4.8: Enable/Disable AG Error result code
The HF shall issue the AT+CMEE command to enable/disable the Extended Audio Gateway Error Result Code in the AG. The parameter <n> controls the activation/deactivation of the Extended Error result code notification. Whenever there is an error relating to the functionality of the AG as a result of AT command, the AG shall send +CME ERROR: <err> response to the HF.
4.10 Transfer of Call, Call Setup and Held Call Status

The AT+CMER command, as described in Section 4.33, enables the Call Status indicators update function in the AG. The AT+BIA command, as described in Section 4.33, allows the HF to deactivate/reactivate individual indicators. The AT+BIA command shall have no effect on the Call, Call Setup and Held Call indicators. These indicators cannot be deactivated using the AT+BIA command. When the CMER function is enabled, the AG shall issue a +CIEV unsolicited result code with the corresponding call indicator and value whenever the AG's current call status changes. Likewise, the AG shall issue a +CIEV unsolicited result code with the corresponding callsetup indicator and value whenever the AG's current call setup status changes. The AG shall also issue a +CIEV unsolicited result code with corresponding callheld indicator and value whenever the AGs current held call status changes. If the CMER function is disabled the AG shall not send the unsolicited result code. The HF shall be capable of interpreting the information provided by the +CIEV result code to determine the call status as listed in Section 4.33.2. Furthermore, the HF may also be capable of interpreting the optional callsetup state information provided by the +CIEV result code as listed in Section 4.33.2. The HF shall be able to accept unknown indicators provided by the +CIEV result code. The HF may ignore unknown indicators provided by the +CIEV result code.
10 May 2011
Page 29 of 126
Note: Although the HF is required to parse the +CIEV result codes, the HF is not required to provide User Interface indicators for the +CIEV result codes.
4.11 Audio Connection Setup

Upon a user action or an internal event, either the HF or the AG may initiate the establishment of an audio connection as needed. Further internal actions may be needed by the HF or the AG to internally route, modify sample rate, frame and/or sample alignment of the audio paths. More formally stated, the requirements for audio connection setup are: The HF shall be capable of initiating an audio connection during a call process. The HF may be capable of initiating an audio connection while no call is in process. The AG shall be capable of initiating an audio connection during a call process.
The AG may be capable of initiating an audio connection while no call is in process. Incoming call audio handling is further described in section 4.12. Outgoing call audio handling is further described in sections 4.17, 4.18, and 4.19. An Audio Connection set up procedure always means the establishment of a Synchronous Connection and it is always associated with an existing Service Level Connection. In principle, setting up an Audio Connection by using the procedure described in this section is not necessarily related to any call process. 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 initiator of the procedure shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. Both the initiator and the acceptor shall notify the presence of the new Audio Connection. 4.11.1 Audio Connection Setup by AG When the AG is to setup an Audio Connection, it shall initiate the Codec Connection establishment procedure if the Service Level Negotiation indicated that the both sides support this feature.
10 May 2011
Page 30 of 126
HF
AG
Codec Connection Setup
Audio paths properly routed

Established Audio Connection
Figure 4.9: Procedure for Establishment of Audio Connection from AG
4.11.2 Audio Connection Setup by HF For all HF initiated audio connection establishments for which both sides support the Codec Negotiation feature, the HF shall trigger the AG to establish a Codec Connection. This is necessary because only the AG knows about the codec selection and settings of the network.
HF
Established Service Level Connection Internal event or user action
AG
AT+BCC OK
Codec Connection Setup

Figure 4.10: Procedure for Establishment of Audio Connection from HF
When the HF triggers the establishment of the Codec Connection it shall send the AT command AT+BCC to the AG. The AG shall respond with OK if it will start the Codec Connection procedure and with ERROR in case it cannot start the Codec Connection procedure.
10 May 2011
Page 31 of 126
After the AG has sent the OK response, the AG shall initiate the Codec Connection Setup procedure. The type of Synchronous Connection that is established in this procedure and the settings used for it are dependent on the format of the media that is going to be transported over the connection and can be found in the chapters 4.2.1 and 5.7.2. 4.11.3 Codec Connection Setup Upon a user action or an internal event, either the HF or the AG may initiate the establishment of a Codec Connection Setup procedure, whenever necessary. Further internal actions may be needed by the HF or the AG to internally route, modify sample rate, frame and/or sample alignment of the audio paths. Although the Audio Connection may be triggered by either the AG or the HF, the Codec Connection and the Synchronous Connection shall always be established by the AG (unless one of the devices is a legacy device) The AG shall initiate a Codec Connection only if the HF has indicated support for the Codec Negotiation feature and has sent at least one AT+BAC on the current service level connection. When selecting which codec to use for a codec connection, the AG shall use the information on codecs available in the HF as provided in the most recently received AT+BAC. The AG shall inform the HF which codec ID is to be used before establishing the Synchronous Connection. If a codec has been successfully selected at least once on the current service level connection, the AG does not need to inform the HF about which codec to use unless a change of codec is required for the next synchronous connection. In case the HF has sent an additional AT+BAC after the completion of the Service Level Connection procedure, there may be a need to re-select the codec.
10 May 2011
Page 32 of 126
HF
AG
+BCS:<Codec ID> AT+BCS=<Codec ID> OK
Synchronous Connection Setup
The presence of a new connection is notified

Established Codec Connection
The presence of a new connection is notified
Figure 4.11: Procedure for the Establishment of Codec Connection
The AG shall send a +BCS=<Codec ID> unsolicited response to the HF. The HF shall then respond to the incoming unsolicited response with the AT command AT+BCS=<Codec ID>. The ID shall be the same as in the unsolicited response code as long as the ID is supported. If the received ID is not available, the HF shall respond with AT+BAC with its available codecs. The AG shall always respond with OK if the ID received in AT+BCS is the same as the one sent, and with ERROR otherwise. If no AT+BCS is received but instead a AT+BAC is received after sending +BCS, the procedure shall end but may be restarted by the AG after re-selecting codec ID based on the information in the just received AT+BAC. After sending the OK response the AG shall open the Synchronous Connection with the settings that are determined by the ID. The HF shall be ready to accept the synchronous connection establishment as soon as it has sent the AT commands AT+BCS=<Codec ID>. After the Synchronous Connection has been established, the Codec Connection is established. The selection of codec with the +BCS command is in effect for this connection as well as subsequent Codec Connections. The Codec selection procedure needs to be redone only if a different codec is to be used for a new Synchronous Connection. If the Codec Connection establishment procedure fails before a Synchronous Connection has been established, the Codec Connection establishment procedure shall be re-started before any Synchronous Connection is established.
10 May 2011
Page 33 of 126
If an (e)SCO link cannot be established according to the parameters required for the selected codec (e.g. basebands negotiation fails for a link with re-transmission although a wide band codec has been selected), the Codec Connection establishment procedure shall be re-started by the AG with the purpose of selecting a codec that can be used. The mandatory narrow band Codec (CVSD) shall be used before the AG gives up trying to establish a Codec connection. The type settings for the Synchronous Connection that is established in this procedure are dependent on the format of the media that is going to be transported over the audio connection and can be found in the section 5.7.2. 4.11.4 Available codecs updating Any time on an established service level connection for which both sides support the Codec Negotiation Feature, the HF may send AT+BAC to inform the AG about dynamic changes in the set of available codecs. It is only informative and does not mandate the closing of any existing audio connection. In case the AG has started the Codec Connection Setup procedure, AT+BAC shall be sent by the HF in response to the +BCS unsolicited response from the AG when the selected codec has become unavailable. In case the last selected codec becomes un-available, the HF shall send AT+BAC to the AG to ensure that the AG re-selects codec before the next Codec Connection set-up and AG shall send the +BCS unsolicited response before starting establishment of a Synchronous Connection. The mandatory narrow band codec shall always be advertised in the AT+BAC command. Hence the AT+BAC shall never be an empty list, this ensures that a fallback option is always available to setup an Audio Connection. The mandatory wide band codec shall also always be advertised in the AT+BAC commands unless support for wide band speech has become temporarily unavailable. If the HF has previously indicated in its AT+BAC command that it supports wide band speech, then the AG shall interpret this as temporary suspension of wide band speech support until the HF sends the next AT+BAC command. If the mandatory wide band speech Codec is not included in the AT+BAC command then no other optional wide band speech codec shall be included.
HF
AG
AT+BAC=<u1,u2,> OK
Figure 4.12: Procedure for updating the list of available Codecs 10 May 2011
Page 34 of 126
4.11.5 Codec re-negotiation When the AG establishes an Audio Connection, it will decide what codec to use based upon the list of available codecs communicated during the most recent AT+BAC command exchange. The selected Bluetooth codec shall then be used throughout the ongoing Synchronous Connection irrespective of any changes on the connection at the AG or HF side. To change the selected Bluetooth Codec the AG may initiate a Codec Connection Setup procedure. The newly selected Codec as a result of this Codec renegotiation shall be used for the next Audio Connection.
4.12 Audio Connection Release

Upon a user action or an internal event, either the HF or the AG may release an existing Audio Connection. More formally stated, the requirements for audio connection release are: The HF shall be capable of releasing an audio connection during a call process. If the HF has the ability to set up an audio connection with no call in process, the HF shall be capable of releasing the audio connection while no call is in process. The AG shall be capable of releasing an audio connection during a call process.
If the AG has the ability to set up an audio connection with no call in process, the AG shall be capable of releasing the audio connection while no call is in process. As pre-condition for this procedure, an ongoing Audio Connection between the AG and the HF shall exist. An Audio Connection release always means the disconnection of its corresponding Synchronous Connection. When the audio connection is released, the audio path shall be routed to the AG.3
HF
AG
Internal event or user action Synchronous Connection release Audio path in the HF released
Audio path in the AG routed to the AG
Figure 4.13: Audio Connection release
In principle, removing an Audio Connection by using the procedure described in this section is not necessarily related to any call process. 10 May 2011
Page 35 of 126
4.13 Answer an Incoming Call

Upon an incoming call, the AG shall 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 shall produce a local alerting in reaction to the RING. If the AG's SDP record (or +BRSF message) indicates "In-band ring tone" is supported, the AG shall send in-band ring tones unless subsequently changed using procedures defined in Section 4.13.4. The AG may abort the incoming call when necessary. It shall then stop sending the RING alert to the HF. 4.13.1 Answer Incoming Call from the HF In-Band Ringing Optionally, the AG may provide an in-band ring tone. This case is described in Figure 4.14 below and implies, as pre-condition, that an ongoing Service Level Connection between the AG and the HF shall exist. If this connection does not exist, the AG shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. As the figure below shows, if an in-band ring tone is used, the AG shall send the ring tone to the HF via the established Audio Connection.
10 May 2011
Page 36 of 126
HF
AG
+CIEV: (callsetup = 1)
Incoming Call Incoming call process ongoing in the AG AG shall initiate an audio connection establishment
Audio Connection set up
Established Audio Connection The audio paths of the incoming call are routed to the HF AG is ringing
The audio paths of the incoming call are available at the HF
RING (ALERT) +CLIP: In band ring tone (ALERT)
RING (ALERT) +CLIP:
Repeated Alerting
User initiated action : Answer the incoming call
In band ring tone (ALERT)
ATA (ANSWER)
Stop Alerting
OK Call active +CIEV: (call = 1) +CIEV: (callsetup = 0)
AG answers the call
Call active
Figure 4.14: Answer an incoming call from the HF in-band ring tone
The user accepts the incoming voice call by using the proper means provided by the HF. The HF shall then send the ATA command (see Section 4.33) to the AG. The AG shall then begin the procedure for accepting the incoming call. If the normal incoming call procedure is interrupted for any reason, the AG shall issue the +CIEV result code, with the value indicating (callsetup=0) to notify the HF of this condition (see also Section 4.14.2). 4.13.2 Answer Incoming Call from the HF No In-Band Ringing As pre-condition, an ongoing Service Level Connection between the AG and the HF shall exist. If this connection does not exist, the AG shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. As the figure below shows, if no in-band ring tone is used and an Audio Connection does not exist, the AG shall set up the Audio Connection and route the audio paths to the HF upon answering the call.
10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 HF AG
Page 37 of 126
Established Service Level Connection (or optionally an Audio Connection) Incoming call +CIEV: (callsetup = 1) The HF alerts the user RING (ALERT) +CLIP: RING (ALERT) +CLIP: AG is ringing Incoming call process ongoing in the AG
Repeated Alerting
User initiated action : Answer the incoming call
OK
ATA (ANSWER)
Stop Alerting AG answers the call
Call active
+CIEV: (call =1 ) +CIEV: (callsetup = 0) Call active
AG shall initiate the audio connection establishment if an audio connection is not present
Established Audio Connection The audio paths of the incoming call are available at the HF The audio paths of the incoming call are routed to the HF
Figure 4.15: Answer an incoming call from the HF no in-band ring tone
The user accepts the incoming voice call by using the proper means provided by the HF. The HF shall then send the ATA command (see Section 4.33) to the AG, and the AG shall start the procedure for accepting the incoming call and establishing the Audio Connection if an Audio Connection does not exist (refer to Section 4.11). If the normal incoming call procedure is interrupted for any reason, the AG shall issue the +CIEV result code, with the value indicating (callsetup=0) to notify the HF of this condition (see also Section 4.14.2). 4.13.3 Answer Incoming Call from the AG The following pre-conditions apply for this procedure: As a pre-condition for this procedure, an ongoing Service Level Connection between the AG and the HF shall exist. The AG shall alert the HF using either of the two procedures described in Sections 4.13.1 and 4.13.2. The HF shall alert the user.
10 May 2011
Page 38 of 126
HF
AG is alerting the HF
AG
The HF alerts user of ringing condition
The AG is alerting the HF
Call answered in the AG
AG stops alerting +CIEV: (call = 1) Call active +CIEV: (callsetup = 0) Call active
Figure 4.16: Answer an incoming call from the AG
The user accepts the incoming call by using the proper means provided by the AG. If the normal incoming call procedure is interrupted for any reason, the AG shall issue the +CIEV result code, with the value indicating (callsetup=0) to notify the HF of this condition (see also Section 4.14.2). 4.13.4 Change the In-Band Ring Tone Setting The SDP record entry In-band ring tone of the Supported features record (see Table 5.4) 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. The AG may subsequently change this setting. In case the AG wants to change the in-band ring tone setting during an ongoing service level connection, it shall use the unsolicited result code +BSIR (Bluetooth Set In-band Ring tone) to notify the HF about the change. See Figure 4.17 for details. See Section 4.33 for more information on the +BSIR unsolicited result code. The in-band ring tone setting may be changed several times during a Service Level Connection. 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 autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2.
10 May 2011
Page 39 of 126
HF
AG
+BSIR : 0 The HF may generate its own alert upon receiving a RING command The AG will not provide inband ring tones
+BSIR : 1 The HF decides how to alert an incoming call The AG will provide in-band ring tones
Figure 4.17: Change of the in-band ring tone setting initiated by the AG
In case the HF does not want to use the AGs in-band ring tone, it may mute the Audio Connection after it has received +CIEV:(callsetup=1). The HF shall un-mute the Audio Connection upon receiving the +CIEV:(callsetup=0) indication.
4.14 Reject an Incoming Call

In case of an incoming call, the AG shall alert the HF by either one of the two procedures described in Sections 4.13.1 and 4.13.2. Instead of answering the call, the user may reject the incoming call process by user action at the HF or the AG. These two procedures are described in the following sections. 4.14.1 Reject an Incoming Call from the HF As a precondition to this procedure, the AG shall alert the HF using either of the two procedures described in Sections 4.13.1 and 4.13.2. The user rejects the incoming call by using the User Interface on the Hands-Free unit. The HF shall then send the AT+CHUP command (see Section 4.33) to the AG. This may happen at any time during the procedures described in Sections 4.13.1 and 4.13.2. The AG shall then cease alerting the HF of the incoming call and send the OK indication followed by the +CIEV result code, with the value indicating (callsetup=0).
10 May 2011
Page 40 of 126
HF
AG
User initiated action: Reject the incoming call

AT+CHUP (REJECT)
AG stops alerting OK Call rejected in the AG +CIEV: (callsetup = 0)
Figure 4.18: Reject an incoming call from the HF
4.14.2 Rejection/Interruption of an Incoming Call in the AG As a precondition to this procedure, the AG shall alert the HF using either of the two procedures described in Sections 4.13.1 and 4.13.2. The user rejects the incoming call by using the User Interface on the AG. Alternatively the incoming call process may be interrupted in the AG for any other reason. As consequence of this, the AG shall send the +CIEV result code, with the value indicating (callsetup=0). The HF shall then stop alerting the user. This may happen at any time during the procedures described in Sections 4.13.1 and 4.13.2.
HF
AG
User initiated action or internal event:
+CIEV: (callsetup = 0) The HF stops alerting the user and assumes the interruption of the call process in the AG
AG stops alerting Call rejected/interrupted in the AG
Figure 4.19: Rejection/interruption of an incoming call in the AG 10 May 2011
Page 41 of 126
4.15 Terminate a Call Process

An ongoing call process may be terminated by either the HF or the AG by means of a user action or any other event. 4.15.1 Terminate a Call Process from 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2.
A call related process is ongoing in the AG. Although not required for the call termination process, an Audio Connection is typically present between the HF and AG.
HF
AG
User initiated action: Terminate current call AT+CHUP OK Ongoing call process terminated +CIEV: (call = 0)
Ongoing call process
Start call disconnection procedure
Figure 4.20: Terminate ongoing call - HF initiated
The user may abort the ongoing call process using whatever means provided by the Hands-Free unit. The HF shall send AT+CHUP command (see Section 4.33) to the AG, and the AG shall then start the procedure to terminate or interrupt the current call procedure. The AG shall then send the OK indication followed by the +CIEV result code, with the value indicating (call=0). Performing a similar procedure, the AT+CHUP command described above may also be used for interrupting a normal outgoing call set-up process. 4.15.2 Terminate a Call Process from the AG 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 AG shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. A call related process is ongoing in the AG.
10 May 2011
Page 42 of 126
HF
AG
Ongoing call process
Internal event/user initiated action: The call has been dropped Ongoing call process terminated +CIEV: (call = 0)
Figure 4.21: Terminate ongoing call - AG initiated
This procedure is fully applicable for cases in which an ongoing call process is interrupted in the AG for any reason. In this case the AG shall send the +CIEV result code, with the value indicating (call=0).
4.16 Audio Connection Transfer towards the HF

The audio paths of an ongoing call may be transferred from the AG to the HF. This procedure represents a particular case of an Audio Connection set up procedure, as described in Section 4.11. 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 shall result 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. This procedure is only applicable if there is no current Audio Connection established between the HF and the AG. In fact, if the Audio Connection already exists, this procedure is not necessary because the audio path of the AG is assumed to be already routed towards 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 autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. An ongoing call exists in the AG, with the audio paths routed to the AG means.
10 May 2011
Page 43 of 126
HF
AG
Ongoing call process with the audio paths routed towards the AG
User initiated action: Audio transfer Audio Connection set up
User initiated action: Audio transfer
Established Audio Connection The audio paths of the ongoing call are available at the HF The audio paths of the ongoing call are routed to the HF
Figure 4.22: Audio Connection transfer to the HF
4.17 Audio Connection Transfer towards the AG

The audio paths of an ongoing call may be transferred from the HF to the AG. This procedure represents a particular case of an Audio Connection release procedure, as described in Section 4.12. 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 on the AG side. These results in an 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. If as a consequence of an HF initiated Audio Connection transfer towards the AG procedure, the existing Service Level Connection is autonomously removed by the AG, the AG shall attempt to re-establish the Service Level Connection once the current call ends. 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.
10 May 2011
Page 44 of 126
HF
Established Audio Connection The audio paths of the ongoing call are available at the HF
AG
Ongoing call with the audio paths routed to the HF
User initiated action: Audio transfer Audio Connection release Audio paths in the HF released
Internal event or user action: Audio transfer
Ongoing call process with the audio paths routed towards the AG
Figure 4.23: Audio Connection transfer to the AG
4.18 Place a Call with the Phone Number Supplied by the HF

The HF may initiate outgoing voice calls by providing the destination phone number to the AG. To start the call set-up, the HF shall initiate the Service Level Connection establishment (if necessary) and send a proper Adddd; command to the AG. The AG shall then start the call establishment procedure using the phone number received from the HF and issues the +CIEV result code, with the value (callsetup=2) to notify the HF that the call set-up has been successfully initiated. See Section 4.33 for more information on the Adddd; command. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. If an Audio Connection is not established the AG shall establish the proper Audio Connection and route the audio paths of the outgoing call to the HF immediately following the commencement of the ongoing call set up procedure. Once the AG is informed that the alerting of the remote party has begun, the AG shall issue the +CIEV result code, with the value indicating (callsetup=3). If the wireless network does not provide the AG of an indication of alerting the remote party, the AG may not send this indication. Upon call connection the AG shall send the +CIEV result code, with the value indicating (call=1). If the normal outgoing call establishment procedure is interrupted for any reason, the AG shall issue the +CIEV result code, with the value indicating (callsetup=0), to notify the HF of this condition (see Section 4.15.2). If the AG supports the Three-way calling feature and if a call is already ongoing in the AG, performing this procedure shall result in a new call being placed to a third party with
10 May 2011
Page 45 of 126
the current ongoing call put on hold. For details on how to handle multiparty calls refer to Section 4.22.2.
HF
Established Service Level Connection (or optionally an Audio Connection) User initiated action:
AG
Place call with the digits entered
ATDdddd ;
OK +CIEV: (callsetup = 2)
Outgoing call set-up successfully initiated
AG shall initiate the audio connection establishment if audio connection is not present
Established Audio Connection The audio paths of the outgoing call are available at the HF +CIEV: (callsetup = 3) The audio paths of the outgoing call are routed to the HF
+CIEV: (call = 1) Call active +CIEV: (callsetup = 0)
Remote party reached and being alerted Remote party answered Call active
Figure 4.24: Place an outgoing voice call with the digits entered in the HF
4.19 Memory Dialing from the HF

The HF may initiate outgoing voice calls using the memory dialing feature of the AG. To start the call set-up, the HF shall initiate the Service Level Connection establishment (if necessary) and send an ATD>Nan; command to the AG. The AG shall then start the call establishment procedure using the phone number stored in the AG memory location given by Nan; and issue the +CIEV result code, with the value (callsetup=2) to notify the HF that the call set-up has been successfully initiated. See Section 4.33 for more information on the ATD>Nan command. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. If an Audio Connection is not established, the AG shall establish the proper Audio Connection and route the audio paths of the outgoing call to the HF immediately following the commencement of the ongoing call set up procedure.
10 May 2011
Page 46 of 126
Once alerting of the remote party begins, the AG shall issue the +CIEV result code, with the value indicating (callsetup=3). Upon call connection the AG shall send the +CIEV result code, with the value indicating (call=1). If the normal outgoing call establishment procedure is interrupted for any reason, the AG shall issue the +CIEV result code, with the value indicating (callsetup=0), to notify the HF of this condition (see Section 4.15.2). If the AG supports the Three-way calling feature and if a call is already ongoing in the AG, performing this procedure shall result in a new call being placed to a third party with the current ongoing call put on hold. For details on how to handle multiparty calls refer to Section 4.22.2. If there is no number stored for the memory location given by the HF, the AG shall respond with ERROR.
HF
Established Service Level Connection (or optionally an Audio Connection) User initiated action:Place call
AG
using memory dialing
ATD>nnn OK +CIEV: (callsetup = 2) Outgoing call set-up successfully initiated
Established Audio Connection The audio paths of the outgoing call are routed to the HF +CIEV: (callsetup = 3)
The audio paths of the outgoing call are available at the HF
+CIEV: (call = 1) Call active +CIEV: (callsetup = 0)
Remote party reached and being alerted Remote party answered Call active
Figure 4.25: Place an outgoing voice call using memory dialing
4.20 Last Number Re-Dial from the HF

The HF may initiate outgoing voice calls by recalling the last number dialed by the AG. To start the call set-up, the HF shall initiate the Service Level Connection establishment (if necessary) and send an AT+BLDN command to the AG. The AG shall then start the call establishment procedure using the last phone number dialed by the AG, and issues
10 May 2011
Page 47 of 126
the +CIEV result code, with the value (callsetup=2), to notify the HF that the call set-up has been successfully initiated. See Section 4.33 for more information on the AT+BLDN command. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. If an Audio Connection is not established, the AG shall establish the proper Audio Connection and route the audio paths of the outgoing call to the HF immediately following the commencement of the ongoing call set up procedure. Once alerting of the remote party begins, the AG shall issue the +CIEV result code, with the value indicating (callsetup=3). Upon call connection the AG shall send the +CIEV result code, with the value indicating (call=1). If the normal outgoing call establishment procedure is interrupted for any reason, the AG shall issue the +CIEV result code, with the value indicating (callsetup=0), to notify the HF of this condition (see Section 4.15.2). If the AG supports the Three-way calling feature and if a call is already ongoing in the AG, performing this procedure shall result in a new call being placed to a third party with the current ongoing call put on hold. For details on how to handle multiparty calls refer to Section 4.22.2. If there is no number stored for the memory location given by the HF, the AG shall respond with ERROR.
10 May 2011
Page 48 of 126
HF
Established Service Level Connection (or optionally an Audio Connection)
AG
User initiated action:
Place call to the last number dialed
AT+BLDN OK +CIEV: (callsetup = 2)
Outgoing call set-up successfully initiated
Established Audio Connection The audio paths of the outgoing call are available at the HF
The audio paths of the outgoing call are routed to the HF +CIEV: (callsetup = 3) Remote party reached and being alerted Remote party answered Call active +CIEV: (callsetup = 0)
+CIEV: (call = 1) Call active
Figure 4.26: Place an outgoing voice call with the last number dialed
4.21 Call Waiting Notification Activation

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 shall 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. See Section 4.33 for more information on the AT+CCWA command. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2.
10 May 2011
Page 49 of 126
HF
AG
Internal event or user requested: Enable Call Waiting notification
The HF requests enabling Call Waiting notification indication
AT+CCWA=1 OK The AG enables the Call Waiting notification indication
Figure 4.27: Activation of Call waiting notification
4.22 Three Way Call Handling

Proper management of several concurrent calls shall be accomplished by performing the procedures described in [2] but with some limitations stated in this specification. For more details, refer to Section 4.33. The HF device cannot always assume that the "call hold and/or multiparty" services are available in the network. If the AG determines that a requested action by the HF device cannot be performed due to the inability of the network to support that feature or lack of subscriber subscription, the AG shall return a +CME error. There are two +CME ERROR codes that are used to indicate network related failure reasons to the HF: 30 - No Network Service. Indicates that an AT+CHLD command cannot be implemented due to network limitations. 31 - Network Timeout. Indicates that an AT+CHLD command cannot be implemented due to network problems. 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. When this feature is supported, the HF and AG are only mandated to implement the basic Three Way calling commands AT+CHLD = 1 and 2. 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. See Section 4.33 for more information on the AT+CHLD command. The following pre-conditions apply for these procedures:
10 May 2011
Page 50 of 126
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 initiator of the procedure shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. An ongoing call in the AG shall exist.
4.22.1 Three Way CallingCall Waiting Notification In addition to the two previously stated preconditions, the Call Waiting notification to the HF shall already be enabled in the AG (that is, the procedure stated in Section 4.21 has been performed).
HF
AG
Established Service Level Connection (or optionally an Audio Connection) Ongoing call Call Waiting notification to the HF is enabled +CCWA: +CIEV: (callsetup = 1) AT+CHLD=1, 2 or 3 OK The AG accepts the waiting call AG shall send OK if function is allowed or ERROR if function is not supported. If AG returns ERROR, no further actions are taken.
Internal event: a call is waiting The AG ports the presence of new call waiting
The HF indicates the presence of the new call waiting to user User action: accept the call
OR
+CME ERROR: <30 or 31>
+CIEV: (callsetup = 0) +CIEV: (callheld=1)* AG shall initiate the audio connection establishment if an audio connection is not present *If the original call is placed on hold, then callheld status is updated The audio paths of the new call are routed to the HF
Audio Connection set up The audio paths of the new call are available at the HFF Established Audio Connection
Figure 4.28: Typical Call Waiting indication followed by a three way call set up process
If the AG receives a third party call, it shall send the call waiting notification +CCWA and +CIEV result code, with the value indicating (callsetup=1), to the HF. If the user rejects the call at the HF, the HF shall send the AT+CHLD command with parameter 0 to the AG. The AG shall then reject the call and respond with OK, and issue the +CIEV result code with the value indicating (callsetup=0).
10 May 2011
Page 51 of 126
If the user accepts the call at the HF, the HF shall send the AT+CHLD with parameter 1 or 2 to the AG. (The HF cannot cause the waiting call to be added as a conference call via a single AT+CHLD command; but if this is desired the HF can achieve this by first issuing an AT+CHLD=2 command, and then issuing an AT+CHLD=3 command.)The AG shall then accept the waiting call and respond with OK, and issue the +CIEV result code with the value indicating (callsetup=0). If the HF elects to send AT+CHLD=2 (placing the original call on hold), then the AG shall send the +CIEV result code with the value indicating a held call (callheld=1). Optionally, the HF may then use the AT+CHLD command, in order to change the status of the held and active calls. If the normal incoming call procedure is interrupted for any reason, the AG shall issue the +CIEV result code, with the value indicating (callsetup=0), to notify the HF of this condition (see Section 4.14.2). 4.22.2 Three Way Calls Third Party Call Placed from the HF
HF
User initiated action:
AG
Place call to a third party
ATD
OK +CIEV: (callheld=2) +CIEV: (callsetup = 2)
Ongoing call Current call put on hold and third party outgoing call set-up procedure successfully ongoing
There is no enforced order for the callheld and callsetup indicator updates.
Established Audio Connection The audio paths of the new call are available at the HF There is no enforced order for the callheld and callsetup indicator updates. +CIEV: (callsetup = 3) The audio paths of the new call are routed to the HF Remote party reached and being alerted Remote party answered
The AG process the user request
+CIEV: (callsetup = 0)
AT+CHLD= OK
User Action
Figure 4.29: Three way call handling when the third party call is placed from the HF
If a third party call is placed from the HF using the ATD command, the AG shall send the OK indication and two +CIEV result codes, one with the value indicating (callsetup=2), and one with the value indicating (callheld=2) to the HF. It is permissible for the AG to send these two +CIEV result codes in either order as the timing of events in the AG may differ between implementations and network types. If the remote party is
10 May 2011
Page 52 of 126
reached and alerted, the AG shall issue the +CIEV result codes with the values indicating (callsetup=3) and (callheld=1). As before, there is no enforced order to these two +CIEV result codes. If the wireless network does not provide the AG of an indication of alerting the remote party, the AG may not send this indication. If the remote party answers the call, the AG shall issue the +CIEV result code with the value indicating (callsetup=0). Optionally, the HF may then use the AT+CHLD command in order to change the status of the held and active calls. If the AT+CHLD command results in the change in a held call status the AG shall provide the status indication using the +CIEV result code with the value indicating the call held status (callheld=<0,1,2>). If the normal outgoing call procedure is interrupted for any reason, the AG shall issue the +CIEV result code, with the value indicating (callsetup=0), to notify the HF of this condition (see Section 4.15.2). The AG shall then update the callheld status to indicate the change of status of the original (held) call based upon one of the two following scenarios: The AG may choose to leave the original call on hold. In this case the AG shall issue the +CIEV result code with the value indicating (call held=2).
Alternatively the AG may autonomously retrieve the held call, thus changing the status and shall send the +CIEV indicator (call held=0). In either case the +CIEV response code (call=1) shall remain unchanged.
4.23 Calling Line Identification (CLI) Notification

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.13 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. See Section 4.33 for more information on the AT+CLIP command. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2.
10 May 2011
Page 53 of 126
HF
AG
Internal event or user requested: Enable CLI notification
The HF requests enabling CLI notification
AT+CLIP=1 OK The AG enables the CLI notification
Figure 4.30: Activation of CLI notification
4.24 The HF Requests Turning off the AGs EC and NR

The HF may disable the echo canceling and noise reduction functions resident in the AG via the AT+NREC command. If the HF supports embedded EC and/or NR functions it shall support the AT+NREC command as described in the procedures in this section. Moreover, if the HF has these functions enabled, it shall perform this procedure before any Audio Connection between the HF and the AG is established. By default, if the AG supports its own embedded echo canceling and/or noise reduction functions, it shall have them activated until the AT+NREC command is received. From then on, and until the current Service Level Connection between the AG and HF is dropped for any reason, the AG shall disable these functions every time an Audio Connection between the HF and the AG is used for audio routing. If the AG does not support any echo canceling and noise reduction functions, it shall respond with the ERROR indicator on reception of the AT+NREC command. See Section 4.33 for more information on the AT+NREC command. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2.
10 May 2011
Page 54 of 126
HF
Established Service Level Connection The EC and NR of the AG shall be disabled
AG
AT+NREC=0 OK OK if EC and NR are supported by AG ERROR if EC and NR are not supported by AG
ERROR
Figure 4.31: NR and EC functions available in the AG
The HF sends the AT+NREC command and AG confirms with either OK or ERROR indication.
4.25 Voice Recognition Activation

The HF, via the AT+BVRA command, or the AG autonomously, may activate/deactivate the voice recognition function resident in the AG. Beyond the audio routing and voice recognition activation capabilities, the rest of the voice recognition functionality is implementation dependent. Whenever the AG supports a voice recognition function it shall support the AT+BVRA command as described in the procedures in this section. If the HF issues the AT+BVRA command, the AG shall respond with the OK result code if it supports voice recognition, then initiate an Audio Connection to the HF (if the Audio Connection does not already exist) and begin the voice input sequence. If the AG does not support voice recognition, the AG shall respond with the ERROR indication. When the voice recognition function is activated from the AG, it shall inform the HF via the +BVRA: 1 unsolicited result code and the AG shall initiate an Audio Connection to the HF (if the Audio Connection does not already exist) and begin the voice input sequence. Once activated, depending upon the voice recognition implementation, the AG shall then keep the voice recognition function enabled: For the duration of time supported by the implementation (momentary on voice recognition implementation). In this case, the AG shall notify the HF by sending a +BVRA: 0 unsolicited result code. Or until the AT+BVRA command is issued to disable voice recognition from the HF. Or until the current Service Level Connection between the AG and the HF is dropped for any reason.
10 May 2011
Page 55 of 126
See Section 4.33 for more information on the AT+BVRA command and the +BVRA result code. As pre-condition for these procedures, an ongoing Service Level Connection between the AG and the HF shall exist. If this connection does not exist, the initiator of the procedure shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. 4.25.1 Voice Recognition Activation HF Initiated
HF
Established Service Level Connection (or optionally an Audio Connection) Enable voice recognition in the AG AT+BVRA=1
AG
OK
OK if voice recognition is now enabled in AG If OK, AG shall initiate the audio connection establishment if audio connection is not present
Audio connection set up
ERROR
ERROR if voice recognition is not supported by AG
Figure 4.32: Voice recognition activation HF initiated
10 May 2011
Page 56 of 126
4.25.2 Voice Recognition Activation AG Initiated
HF
AG
+BVRA: 1 Voice recognition is enabled in the AG
User action/internal event: Voice recognition enabled in the AG
Figure 4.33: Voice recognition activation AG initiated
4.25.3 Voice Recognition Deactivation
HF
AG
Voice recognition is enabled Voice recognition disabled
+BVRA: 0 Voice recognition function in the AG disabled
Figure 4.34: Voice recognition deactivation momentary on approach
10 May 2011
Page 57 of 126
HF
AG
Disable voice recognition in the AG AT+BVRA=0
Voice recognition is enabled
OK
OK if voice recognition is now disabled in AG ERROR if voice recognition is not supported by AG
ERROR
Figure 4.35: Voice recognition deactivation from the HF
4.26 Attach a Phone Number to a Voice Tag

This procedure is applicable to HFs 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 HFs memory. The HF may 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 in Section 4.18. Upon an internal event or user action, the HF may request a phone number from the AG by issuing the AT+BINP=1 command. Depending on the current status of the AG, it may either accept or reject this request. If the AG accepts the request, it shall obtain a phone number and send the phone number back to the HF by issuing the +BINP response. If the AG rejects the request from the HF, it shall issue the ERROR result code to indicate this circumstance to the HF. When this procedure is executed multiple times (to retrieve multiple AG phone numbers to be linked to voice tags), it is the responsibility of the AG to provide the next phone number to be passed to the HF each time the procedure is executed. See Section 4.33 for more information on the AT+BINP command and the +BINP response. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2.
10 May 2011
Page 58 of 126
HF
AG
AT+BINP=1 AG obtains a phone number +BINP: <Phone number> OK ERROR if the request is rejected by AG
ERROR
Figure 4.36: Request phone number to the AG
4.27 Transmit DTMF Codes

During an ongoing call, the HF transmits the AT+VTS command to instruct the AG to transmit a specific DTMF code to its network connection. See Section 4.33 for more information on the AT+VTS command. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. An ongoing call in the AG exists.
HF
Established Service Level Connection User initiated action: The user pushes a key AT+VTS= OK
AG
Ongoing call
The AG generates the DTMF code towards the network
Figure 4.37: Transmit DTMF code
4.28 Remote Audio Volume Control

4.28.1 Audio Volume Control This procedure enables the user to modify the speaker volume and microphone gain of the HF from the AG.
10 May 2011
Page 59 of 126
The AG may control the gain of the microphone and speaker of the HF by sending the unsolicited result codes +VGM and +VGS respectively. There is no limit in the amount and order of result codes. If the remote audio volume control feature is supported in the HF device, it shall support at least remote control of the speaker volume. 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 autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2. An audio connection is not a necessary pre-condition for this feature.
HF
AG
Set HF microphone gain The HF changes its microphone gain +VGM: 12
The HF changes its speaker volume
+VGS: 5
Set HF speaker gain
Figure 4.38: Typical example of audio volume control
Both the speaker and microphone gains are represented as parameter to the +VGS and +VGM, on a scale from 0 to 15. The values are absolute values, and relate to a particular (implementation dependent) volume level controlled by the HF. See Section 4.33 for more information on these commands and unsolicited result codes. 4.28.2 Volume Level Synchronization This procedure allows the HF to inform the AG of the current gain settings corresponding to the HFs speaker volume and microphone gain. On Service Level Connection establishment, the HF shall always inform the AG of its current gain settings by using the AT commands AT+VGS and AT+VGM. If local means are implemented on the HF to control the gain settings, the HF shall also use the AT commands AT+VGS and AT+VGM to permanently update the AG of changes in these gain settings. In all cases, the gain settings shall be kept stored, at both sides, for the duration of the current Service Level Connection. Moreover, if the Service Level Connection is released as a consequence of an HF initiated Audio Connection transfer towards the AG as
10 May 2011
Page 60 of 126
stated in Section 4.17, the HF shall also keep the gain settings and re-store them when the Service Level Connection is re-established again. The HF shall support speaker gain synchronization when it supports remote speaker gain control. The HF shall support microphone gain synchronization when it supports remote microphone gain control. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2.
HF
AG
Internal event: The volumes in the AG and HF shall be synchronized AT+VGS=6 OK The AG synchronizes its microphone gain and speaker volume values
AT+VGM=5 OK User initiated action: Set the HF speaker volume
AT+VGS=7 OK
The AG updates its speaker volume value
Figure 4.39: Typical example of volume level synchronization
See Section 4.33 for more information on these commands and unsolicited result codes.
10 May 2011
Page 61 of 126
4.29 Response and Hold

This procedure allows the user to put an incoming call on hold and then accept or reject the call from the HF or AG. This feature is specific to the limited markets where PDC and CDMA networks support this function. 4.29.1 Query Response and Hold Status The HF shall execute this procedure to query the status of the Response and Hold state of the AG.
HF
AG
The HF queries the current Respond & Hold status of the AG
AT+BTRH?
+BTRH: 0
The AG reports the current Respond & Hold status of the HF
OK
Figure 4.40: Query Response and Hold State of AG
The HF shall issue AT+BTRH? command to query the current Response and Hold state of the AG. If the AG is currently in any of the Response and Hold states, then the AG shall send a +BTRH: Response with the parameter set to 0. If the AG is not in the Response and Hold states, then no response shall be sent. The AG shall send OK response to signal completion of the AT+BTRH? command.
10 May 2011
Page 62 of 126
4.29.2 Put an Incoming Call on Hold from HF
HF
AG
Incoming call +CIEV: (callsetup=1)
RING
+CLIP
The HF alerts the user

RING
Repeated Alerting
+CLIP
User initiated action : Put the incoming call on Hold
AT+BTRH = 0 Puts the incoming call on Hold +BTRH: 0
On Hold
OK
Call Active
+CIEV: (call =1)
+CIEV: (callsetup=0)
Figure 4.41: Put an incoming call on Hold from HF
As a pre-condition to this procedure, the AG shall not have an active call or a call on hold.
10 May 2011
Page 63 of 126
The AG shall send a sequence of unsolicited RING alerts to the HF. The RING alert shall be repeated until the HF accepts the incoming call or until the incoming call is interrupted for any reason. If the HF has enabled the Calling Line Identification [CLI], the AG shall send a +CLIP Response to HF. The user may put the incoming voice call on hold by using the proper means provided by the HF. The HF shall then send the AT+BTRH command with the parameter <n> set to 0. The AG shall then begin the procedure for putting the incoming call on hold. The AG shall send +BTRH Response with the parameter set to 0 as soon as the incoming call is put on hold. The +CIEV: (callheld = 2) message shall not be sent when a call is held via the AT+BTRH=0 message. The AG shall send the +CIEV Response with the call status set to 1. The AG shall send the +CIEV Response with the callsetup status set to 0.
4.29.3 Put an Incoming Call on Hold from AG
HF
AG
Incoming call +CIEV: (callsetup=1)
RING +CLIP
The HF alerts the user

RING +CLIP
Repeated Alerting
User initiated action; Put the incoming call on Hold
On Hold
+BTRH: 0
+CIEV: (call =1) Call Active +CIEV: (callsetup=0)
Figure 4.42: Put an incoming call on Hold from AG
As a pre-condition to this procedure, the AG shall not have an active call or a call on hold.
10 May 2011
Page 64 of 126
The AG shall send a sequence of unsolicited RING alerts to the HF. The RING alert shall be repeated until the HF accepts the incoming call or until the incoming call is interrupted for any reason. If the HF has enabled the Calling Line Identification [CLI], the AG shall send a +CLIP Response to the HF. The user may put the incoming voice call on hold by using the proper means provided by the AG unit. The AG shall then send +BTRH Response with the parameter <n> set to 0 to indicate that the incoming call is on hold. The +CIEV: (callheld = 2) message shall NOT be sent by the audio gateway when it holds a call via the response and hold method. Depending on whether in band ringing is enabled or disabled, there may or may not be a synchronous connection established between the HF and AG. The synchronous connection state (enabled or disabled) shall not be changed when an incoming call is placed on hold. The AG shall send the +CIEV Response with the call status set to 1. The AG shall send the +CIEV Response with the callsetup status set to 0.
4.29.4 Accept a Held Incoming Call from HF The following additional pre-condition applies to this procedure: An incoming call was put on hold.
HF
AG
Incoming call is on hold
Internal event or user requested: Accept held incoming call AT+BTRH=1
+BTRH: 1
The AG accepts the held incoming call
OK
AG shall initiate the audio connection establishment if an audio connection is not present
Figure 4.43: Accept a held incoming call from HF
10 May 2011
Page 65 of 126
The user may accept the incoming voice call on hold by using the proper means provided by the HF. The HF shall then send the AT+BTRH command with the parameter <n> set to 1. The AG shall then begin the procedure for accepting the incoming call that was put on hold. The AG shall then send +BTRH Response with the parameter <n> set to 1 to notify HF that the held incoming call was accepted. The AG shall start the procedure for establishing the audio connection and route the audio paths to the HF only if the audio connection was not established.
4.29.5 Accept a Held Incoming Call from AG The following additional pre-condition applies to this procedure: An incoming call was put on hold.
HF
AG
Internal event or user requested: Accept held incoming call
+BTRH: 1
The AG accepts the held incoming call
Figure 4.44: Accept a held incoming call from AG
The user may accept the incoming voice call on hold by using the proper means provided by the AG unit. The AG shall then send +BTRH Response with the parameter <n> set to 1 to notify the HF that the held incoming call was accepted.
4.29.6 Reject a Held Incoming Call from HF The following additional pre-condition applies to this procedure: An incoming call was put on hold.
10 May 2011
Page 66 of 126
HF
AG
Internal event or user requested: Reject held incoming call AT+BTRH=2
+BTRH: 2
The AG rejects the held incoming call
OK
+CIEV: (Call=0) No Call
Figure 4.45: Reject a held incoming call from HF
The user may reject the incoming voice call on hold by using the proper means provided by the HF. Either of the following two sequences shall be permissible by the HF and AG: The HF may send the AT+BTRH command with the parameter <n> set to 2. The AG shall then begin the procedure for rejecting the incoming call that was put on hold. The AG shall send +BTRH Response with the parameter <n> set to 2 to notify the HF that the held incoming call was rejected. The HF may send the AT+CHUP command to reject the held incoming call. The AG shall reject the held call and send the OK indication to the HF.
The AG shall send the +CIEV Response with the call status set to 0.
4.29.7 Reject a Held Incoming Call from AG The following additional pre-condition applies to this procedure: An incoming call was put on hold.
10 May 2011
Page 67 of 126
HF
AG
user requested: Reject held incoming call
+BTRH: 2
The AG rejects the held incoming call
No Call
+CIEV: (Call=0)
Figure 4.46: Reject a held incoming call from AG
The user may reject the incoming voice call on hold by using the proper means provided by the AG unit. The AG shall then send +BTRH Response with the parameter <n> set to 2 to notify HF that the held incoming call was rejected. The AG shall also send the +CIEV Response with the call status parameter set to 0 to indicate that the AG is currently not in a call.
10 May 2011
Page 68 of 126
4.29.8 Held Incoming Call Terminated by Caller The following additional pre-condition applies to this procedure: An incoming call was put on hold.
HF
AG
Held incoming call terminated by caller +BTRH: 2
+CIEV: (Call =0) No Call
Figure 4.47: Held incoming call terminated by caller
The caller may terminate the held incoming call. The AG shall then send +BTRH Response with the parameter <n> set to 2 to notify the HF that the held incoming call was terminated. The AG shall send the +CIEV Response with the Call status parameter set to 0 to indicate that the AG is currently not in a call.
10 May 2011
Page 69 of 126
4.30 Subscriber Number Information

This procedure allows HF to query the AG subscriber number.
HF
AG
HF sends command to get the Subscriber Number Information
AT+CNUM
+CNUM: ,<number>,<type>[,, <service>]
AG sends Subscriber Number Information
...
+CNUM: ,<number>,<type>[,, <service>]
OK
Figure 4.48: Query Subscriber Number Information of AG
This procedure illustrates AG response to the query of an empty subscriber number.
HF
AG
HF sends command to get the Subscriber Number Information
AT+CNUM
OK
Figure 4.49: Empty Subscriber Number Information from AG
The following pre-condition applies for this procedure: An ongoing Service Level Connection between the HF and AG shall exist. If this connection does not exist, the HF shall establish a connection using the Service Level Connection set up procedure described in Section 4.2. The HF shall send the AT+CNUM command to query the AG subscriber number information.
10 May 2011
Page 70 of 126
If the subscriber number information is available, the AG shall respond with the +CNUM response. If multiple numbers are available, the AG shall send a separate +CNUM response for each available number. The AG shall signal the completion of the AT+CNUM action command with an OK response. The OK will follow zero or more occurrences of the +CNUM response. (See Figure 4.45 and Figure 4.46).
4.31 Enhanced Call Status Indications

4.31.1 Query List of Current Calls in AG The HF shall execute this procedure to query the list of current calls in AG. The following pre-condition applies for this procedure: A SLC must exist between the AG and HF devices. If no current SLC exists, the HF shall first initiate a SLC.
HF
AG
The HF queries the current list of current calls in AG
AT+CLCC +CLCC: <idx>,<dir>,<status>,<mode>,<mprty>[,<number>,<type>] +CLCC: <idx>,<dir>,<status>,<mode>,<mprty>[,<number>,<type>]
The AG reports the list of current calls
OK
Figure 4.50: Query List of Current Calls
HF shall find out the list of current calls in AG by sending the AT+CLCC command. If the command succeeds and if there is an outgoing (Mobile Originated) or an incoming (Mobile Terminated) call in AG, AG shall send a +CLCC response with appropriate parameters filled in to HF. If there are no calls available, no +CLCC response is sent to HF. The AG shall always send OK response to HF.
4.31.2 Indication of Status for Held Calls Upon the change in status of any call on hold in the AG, the AG shall execute this procedure to advise the HF of the held call status. The values for the callheld indicator are:
10 May 2011
Page 71 of 126
0= No calls held 1= Call is placed on hold or active/held calls swapped (The AG has both and active AND a held call) 2= Call on hold, no active call The following pre-condition applies for this procedure: The HF shall have enabled the Call Status Indicators function in the AG. A SLC shall exist between the AG and HF devices. Whenever an active call is placed on hold such that the AG now has both an active and held call or the active/held call positions swapped by a request from the HF or by action on the AG the AG shall issue a +CIEV unsolicited result code with the callheld indicator value of 1.
HF
AG
Existing Call
HF request call to be held or active held position swap
AT+CHLD=2 OK
+CIEV:<CallHeld Indicator>,1
OR action on AG to hold active call or swap active/held position.
Figure 4.51: Call Held or Active/Held Position Swap
Consequently, upon the release of any call on hold by the HF, the AG or by network event, or actions by the HF or AG to retrieve a held call, the AG shall issue a +CIEV unsolicited result code with the callheld indicator value of 0.
10 May 2011
Page 72 of 126
HF
AG
Existing Call on Hold
HF request release or retrieval of held call
AT+CHLD=0 OK
+CIEV:< CallHeld Indicator >,0
OR action on AG or network to release held call or call retrieval
Figure 4.52: Held Call Release
If a call is still on hold when an active call is terminated or a single active call is put on hold, the AG shall issue a +CIEV unsolicited result code with the callheld indicator value of 2.
HF
AG
1 Call Active and Existing Call on Hold
HF request to terminate active call only
AT+CHUP OK
+CIEV:< CallHeld Indicator >,2
OR action on AG or network to terminate active call only.
Figure 4.53: Active Call Terminated/Call Remains Held
10 May 2011
Page 73 of 126
4.32 Enhanced Call Control Mechanisms

As stated earlier, the Enhanced Call Control mechanism is simply an extension of the current AT+CHLD command. These extensions are defined as additional arguments to the AT+CHLD command. The new arguments for this command include an index of a specific call as indicated in the +CLCC response. 4.32.1 Release Specified Call Index The HF shall execute this procedure to release a specific call in the AG. The following pre-condition applies for this procedure: A SLC must exist between the AG and HF devices. If no current SLC exists, the HF shall first initiate a SLC.
HF
AG
Existing call
HF request change in call status.
AT+CHLD=1<idx>
OK
AG releases specified call AG reports change in call status.
+CIEV:<Call Indicator>, <value>
Figure 4.54: Release Specified Active Call
The HF shall send the AT+CHLD=1<idx> command to release a specific active call.
The AG shall release the specified call. If there is a change in the call status, the AG shall report the change in call status. If there is a change in the held call status, the AG shall report the change in call held status. If the index (<idx>) is not valid, the AG shall report the proper error code. 4.32.2 Private Consultation Mode The HF shall execute this procedure to place all parties of a multiparty call on hold with the exception of the specified call. The following pre-condition applies for this procedure: A SLC must exist between the AG and HF devices. If no current SLC exists, the HF shall first initiate a SLC.
10 May 2011
Page 74 of 126
Existing multiparty call is active in AG.
HF
AG
Existing multiparty call
HF request private consultation mode.
AT+CHLD=2<idx>
OK +CIEV: < CallHeld Indicator >,1
AG places ALL parties of multiparty call on hold, except specified call AG reports change in call status for HELD calls.
Figure 4.55: Request Private Consultation Mode
HF shall send the AT+CHLD=2<idx> command to request private consultation mode. AG shall place all other parties of call on hold. AG shall report the change in status of the held parties. If the index (<idx>) is not valid, the AG shall respond with the proper error code.
4.33 AT Command and Results Codes

4.33.1 General For the exchange of the commands and unsolicited results codes, the format, syntax and procedures of 3GPP 27.007 [2] shall be taken as reference. The following rules specifically apply for the HFP specification: Only one command (or unsolicited result code) per command line needs to be expected. The AG, by default, shall not echo the command characters. The AG shall always transmit result codes using verbose format. The characters below shall be used for AT commands and result codes formatting: <cr> corresponds to the carriage return (0/13) as stated in [7]. <lf> corresponds to the line feed (0/10) as stated in [7]. The format of an AT command from the HF to the AG shall be: <AT command><cr> The format of the OK code from the AG to the HF shall be:
10 May 2011
Page 75 of 126
<cr><lf>OK<cr><lf> The format of the generic ERROR code from the AG to the HF shall be: <cr><lf>ERROR<cr><lf> The format of an unsolicited result code from the AG to the HF shall be: <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.33.2. Section 4.34 lists the new Bluetooth defined AT commands and result codes not re-used from any existing standard. In general, the AG shall use the OK code, as described in Section 4.33.2, for acknowledgement of the proper execution of a command and respond with the proper error indication to any unknown command received from the HF. It is mandatory for the AG to properly respond to any error condition and for the HF to properly process the corresponding error indication code received from the AG. The code ERROR, as described in Section 4.33.2, shall be used as error indication for this purpose. The HF shall always ignore any unknown or unexpected indication code received from the AG. The only exception is the case in which the AG issues a Mobile Equipment Error indication using the +CME ERROR: result code (see [2]). In this case, the HF shall interpret this result code in the same way as if it was a generic ERROR code. As a general rule, when an AT command or result code of this specification is implemented, support for the associated parameters covered in this specification, and all their corresponding possible values, shall be considered mandatory unless otherwise explicitly stated in each particular case. 4.33.2 AT Capabilities Re-Used from GSM 07.07 and 3GPP 27.007 The re-used AT commands and unsolicited result codes for implementing the functionality described in this specification are listed below: As a convention, if a parameter of an AT command or result code is not covered in this specification, it shall not be present in the corresponding AT command, and the HF shall ignore the parameter whenever it is received in a result code. ATA Standard call answer AT command. See Annex G in [2].
ATDdddd; Standard AT command intended for placing a call to a phone number. Only voice calls are covered in this specification. See Section 6.2 in [2]. ATD>nnn...; Extension of the standard ATD command, intended for memory dialing. Only voice calls are covered in this specification. See Section 6.3 in [2]. ERROR
10 May 2011
Page 76 of 126
Standard error indication code. It shall be issued on detection of any syntax, format or procedure error condition. The Mobile Equipment Error report code +CME ERROR: is covered below. See Annex B in [2]. OK Standard acknowledgement to the execution of a command. See Annex B in [2]. NO CARRIER, BUSY, NO ANSWER, DELAYED, BLACKLISTED Extended response indication codes for AT commands. These codes shall be issued from the AG to the HF as responses to AT commands from the HF to the AG or from the AG as unsolicited result codes. These are in addition to the +CME ERROR: responses. RING Standard incoming call indication. See Annex B in [2]. AT+CCWA Standard Call Waiting notification AT command. Within the AT+CCWA=[<n>[,<mode>[,<class>]]]command, only enabling/disabling of the Call Waiting notification unsolicited result code +CCWA , using the <n> parameter, is covered in this specification. See Section 7.12 in [2]. +CCWA Standard Call Waiting notification unsolicited result code. In the +CCWA result code only <number> and <type> parameters are covered in this specification. Other parameters are not considered relevant in this specification and shall be ignored by the HF. The <number> parameter shall be a text string and shall always be contained within double-quotes. The <type> field specifies the format of the phone number provided, and can be one of the following values: values 128-143: The phone number format may be a national or international format, and may contain prefix and/or escape digits. No changes on the number presentation are required. values 144-159: The phone number format is an international number, including the country code prefix. If the plus sign ("+") is not included as part of the number and shall be added by the AG as needed. values 160-175: National number. No prefix nor escape digits included. See Section 7.12 in [2]. AT+CHLD Standard call hold and multiparty handling AT command. In the AT+CHLD=<n> command, this specification only covers values for <n> of 0, 1, 1<idx>, 2, 2<idx>, 3 and 4, where:
10 May 2011
Page 77 of 126
0 = Releases all held calls or sets User Determined User Busy (UDUB) for a waiting call. 1 = Releases all active calls (if any exist) and accepts the other (held or waiting) call.
1<idx> = Releases specified active call only (<idx>).
2 = Places all active calls (if any exist) on hold and accepts the other (held or waiting) call.
2<idx> = Request private consultation mode with specified call (<idx>). (Place all calls on hold EXCEPT the call indicated by <idx>.)
3 = Adds a held call to the conversation. 4 = Connects the two calls and disconnects the subscriber from both calls (Explicit Call Transfer). Support for this value and its associated functionality is optional for the HF. Where both a held and a waiting call exist, the above procedures shall apply to the waiting call (i.e. not to the held call) in conflicting situation. The test command AT+CHLD=? may be used for retrieving information about the call hold and multiparty services available in the AG (see Section 4.2.1). See Section 7.13 in [2] and Section 4.5.5.1 in [8] for details. AT+CHUP Standard hang-up AT command. Execution command causes the AG to terminate the currently active call. This command shall have no impact on the state of a held call except in the use of rejecting a call placed on hold by the Respond and Hold feature as defined in Section 4.29.6. See Section 6.5 in [2]. AT+CHUP is also used as the command to reject any incoming call prior to answer. AT+CIND Standard indicator update AT command. Only read command AT+CIND? and test command AT+CIND=? are required in this specification. The AT+CIND? read command is used to get current status of the AG indicators. The AG shall return all the indicators listed in the AT+CIND=? command. The deactivation of any indicator(s) using AT+BIA command shall have no effect on the AGs response to the AT+CIND? read command. The AT+CIND=? test command is used to retrieve the mapping between each indicator supported by the AG and its corresponding range and order index. It shall be issued at least once before any other command related to these indicators (AT+CIND? or AT+CMER) is used.
10 May 2011
Page 78 of 126
The Hands Free Profile specification limits the number of indicators returned by the AG to a maximum of 20. The following indicators are covered in this specification: service: Service availability indication, where: <value>=0 implies no service. No Home/Roam network available. <value>=1 implies presence of service. Home/Roam network available. call: Standard call status indicator, where: <value>=0 means there are no calls in progress <value>=1 means at least one call is in progress callsetup: Bluetooth proprietary call set up status indicator4. Support for this indicator is optional for the HF. When supported, this indicator shall be used in conjunction with, and as an extension of the standard call indicator. Possible values are as follows: <value>=0 means not currently in call set up. <value>=1 means an incoming call process ongoing. <value>=2 means an outgoing call set up is ongoing. <value>=3 means remote party being alerted in an outgoing call. See Section 8.9 in [2]. callheld: Bluetooth proprietary call hold status indicator. Support for this indicator is mandatory for the AG, optional for the HF. Possible values are as follows: 0= No calls held 1= Call is placed on hold or active/held calls swapped (The AG has both an active AND a held call) 2= Call on hold, no active call signal: Signal Strength indicator, where: <value>= ranges from 0 to 5 roam: Roaming status indicator, where: <value>=0 means roaming is not active <value>=1 means a roaming is active battchg: Battery Charge indicator of AG, where: <value>=ranges from 0 to 5
This status indicator is not defined in the GSM 07.07 specification 10 May 2011
Page 79 of 126
+CIND Standard list of current phone indicators. See section 8.9 in [2]. AT+CLCC Standard list current calls command. See section 7.18 in [2]. +CLCC Standard list current calls result code. See section 7.18 in [2]. Supported parameters are as follows: idx= The numbering (starting with 1) of the call given by the sequence of setting up or receiving the calls (active, held or waiting) as seen by the served subscriber. Calls hold their number until they are released. New calls take the lowest available number. dir= 0 (outgoing), 1 (incoming) status= 0 = Active o 1 = Held o 2 = Dialing (outgoing calls only) o 3 = Alerting (outgoing calls only) o 4 = Incoming (incoming calls only) o 5 = Waiting (incoming calls only) o 6 = Call held by Response and Hold mode= 0 (Voice), 1 (Data), 2 (FAX) mpty= o 0 - this call is NOT a member of a multi-party (conference) call o 1 - this call IS a member of a multi-party (conference) call number (optional) type (optional)
AT+COPS The AT+COPS=3,0 shall be sent by the HF to the AG prior to sending the AT+COPS? command. AT+COPS=3,0 sets the format of the network operator string to the long format alphanumeric. The AT+COPS? command is used for reading network operator. This profile shall only support the "reading" of the name of the network operator. The response to this command from the AG shall return a +COPS:<mode>,<format>,<operator> where: <mode> contains the current mode and provides no information with regard to the name of the operator.
10 May 2011
Page 80 of 126
<format> specifies the format of the <operator> parameter string, and shall always be 0 for this specification. <operator> specifies a quoted string in alphanumeric format representing the name of the network operator. This string shall not exceed 16 characters. See Section 7.3 in [2]. AT+CMEE Standard AT command used to enable the use of result code +CME ERROR: <err> as an indication of an error relating to the functionality of the AG. The set command AT+CMEE=1 is covered in this specification. +CME ERROR This is the Extended Audio Gateway Error Result Code response. Format of the response is: +CME ERROR: <err>. The format of <err> shall be numeric in this specification. The possible values for <err> covered in this specification are described below. These error codes may be provided instead of the standard ERROR response code to provide additional information to the HF. The ERROR response code is still allowed while using the Extended Audio Gateway Error Result Codes. +CME ERROR: 0 AG failure +CME ERROR: 1 no connection to phone +CME ERROR: 3 operation not allowed +CME ERROR: 4 operation not supported +CME ERROR: 5 PH-SIM PIN required +CME ERROR: 10 SIM not inserted +CME ERROR: 11 SIM PIN required +CME ERROR: 12 SIM PUK required +CME ERROR: 13 SIM failure +CME ERROR: 14 SIM busy +CME ERROR: 16 incorrect password +CME ERROR: 17 SIM PIN2 required +CME ERROR: 18 SIM PUK2 required +CME ERROR: 20 memory full +CME ERROR: 21 invalid index +CME ERROR: 23 memory failure +CME ERROR: 24 text string too long +CME ERROR: 25 invalid characters in text string
10 May 2011
Page 81 of 126
+CME ERROR: 26 dial string too long +CME ERROR: 27 invalid characters in dial string +CME ERROR: 30 no network service +CME ERROR: 31 - network Timeout. +CME ERROR: 32 network not allowed Emergency calls only AT+CLIP Standard Calling Line Identification notification activation AT command. It enables/disables the Calling Line Identification notification unsolicited result code +CLIP. See Section 7.6 in [2]. +CLIP Standard Calling Line Identification notification unsolicited result code. In the +CLIP: <number>, type> [,<subaddr>,<satype> [,[<alpha>] [,<CLI validity>]]] result code. Only <number> and <type> parameters are covered in this specification. Other parameters are not considered relevant in this specification and shall be ignored by the HF. The <number> parameter shall be a text string and shall always be contained within double-quotes. The <type> field specifies the format of the phone number provided, and can be one of the following values: values 128-143: The phone number format may be a national or international format, and may contain prefix and/or escape digits. No changes on the number presentation are required. values 144-159: The phone number format is an international number, including the country code prefix. If the plus sign ("+") is not included as part of the number and shall be added by the AG as needed. values 160-175: National number. No prefix nor escape digits included. See Section 7.11 in [2]. AT+CMER Standard event reporting activation/deactivation AT command. In the AT+CMER=[<mode>[,<keyp>[,<disp>[,<ind> [,<bfr>]]]]] command, only the <mode>, and <ind> parameters are relevant for this specification. Only their values <mode>=(3) and <ind>=(0,1) are covered in this specification. See Section 8.10 in [2]. The following examples show how the AT+CMER command may be used for activating or deactivating the indicator events reporting result code: AT+CMER=3,0,0,1 activates indicator events reporting. AT+CMER=3,0,0,0 deactivates indicator events reporting.
10 May 2011
Page 82 of 126
+CIEV Standard indicator events reporting unsolicited result code. In the +CIEV: <ind>,<value> result code, only the indicators stated in the AT+CIND command above are relevant for this specification where: <ind>: Order index of the indicator within the list retrieved from the AG with the AT+CIND=? command. The first element of the list shall have <ind>=1. <value>: current status of the indicator. If the HF receives any unknown indicator or value, it shall ignore it. See Section 8.10 in [2].
AT+VTS Standard DTMF generation AT command. Only the AT+VTS=<DTMF> command format is covered in this specification. See Annex C.2.11 in [2]. AT+CNUM Syntax: AT+CNUM AT+CNUM=? Description: Command issued by HF for the Subscriber Number Information feature in the AG. Only the action command AT+CNUM format is used. (Retrieve Subscriber Number Information) (Test Subscriber Number Information Not Implemented)
+CNUM Syntax: +CNUM: [<alpha>],<number>, <type>,[<speed> ,<service>] (Response for AT+CNUM) Description: Standard Response used for sending the Subscriber Number Information from AG to HF. The AG shall send the +CNUM: response for the AT+CNUM from the HF. Values: <alpha>: This optional field is not supported, and shall be left blank. <number>: Quoted string containing the phone number in the format specified by <type>.
10 May 2011
Page 83 of 126
<type> field specifies the format of the phone number provided, and can be one of the following values: o values 128-143: The phone number format may be a national or international format, and may contain prefix and/or escape digits. No changes on the number presentation are required. o values 144-159: The phone number format is an international number, including the country code prefix. If the plus sign ("+") is not included as part of the number and shall be added by the AG as needed. values 160-175: National number. No prefix nor escape digits included. <speed>: This optional field is not supported, and shall be left blank. <service>: Indicates which service this phone number relates to. Shall be either 4 (voice) or 5 (fax). Example: +CNUM: ,"5551212",129,,4 See section 7.1 in [2].
10 May 2011
Page 84 of 126
4.34 Indicators Activation and Deactivation

The HF shall execute this procedure to change the subset of indicators that shall be sent by the AG. 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 HF shall autonomously establish the Service Level Connection using the proper procedure as described in Section 4.2.
HF
AG
Internal event (ex : screen switched off)
The HF sends an Indicators Activation command to
AT+BIA=1,1,1,1,0,1,0,1,1,1 OK The AG updates the subset of indicators it will send to the HF.
deactivate some indicators and keep some others activated.
Note: the given example does not imply a mandatory order for CIND fields, nor does it imply a mandatory set of CIND indicator fields. The HF shall issue the AT+BIA command if it needs to change the activated/deactivated status of indicators in the AG. The AG shall send the OK result code to the HF after processing a correctly formatted command. The AG shall send the ERROR result code to the HF if the command is incorrectly formatted. Following the successful processing of an AT+BIA command the AG shall not send the indicators that are deactivated. The AG shall send the activated indicators response only if the event reporting is enabled. The effect of the AT+BIA command shall persist during the current SLC only. When an SLC is terminated and a new SLC is established all indicators are activated by default. It is valid to send the AT+BIA command while the event reporting is disabled. If the event reporting is enabled before the SLC is terminated, the AG shall send only the indicators that were activated by the most recently processed AT+BIA command.
10 May 2011
Page 85 of 126
If the event reporting (CMER) is disabled and then re-enabled, the AG shall send only the indicators that were activated by the most recently processed AT+BIA command, or all indicators in the case where no AT+BIA was sent by the HF. The AT+BIA command has no impact on the response to the AT+CIND? read command (See Section 4.33.2 in [1]). A restriction to the AT+BIA command applies to the indicators call, call status and held call. The AG shall always consider these indicators activated, even if the HF requests their deactivation. It is mandatory for the AG to support the AT+BIA command. It is optional for the HF to support the AT+BIA command. It is optional for HF device to use the AT+BIA command. See section 4.33 in [1] for more information on the AT+CMER (event reporting) command. 4.34.1 Bluetooth Defined AT Capabilities The GSM 07.07 [2] format and syntax rules shall be taken as the reference for these commands. The new Bluetooth specific AT capabilities are listed below: AT+BIA (Bluetooth Indicators Activation) Syntax: AT+BIA=[[<indrep 1>][,[<indrep 2>][,[,[<indrep n>]]]]]] Description: Activates or deactivates the indicators individually. The mapping of the indicators is given by the AT+CIND=? test command (See Section 4.33.2 in [1]) <indrep x>: reporting state of the indicator x. 1 to activate, 0 to deactivate. If an indicator state is omitted between commas, the current reporting state of that indicator shall not change. For example, if the HF sends the command AT+BIA=,1,,0 only the second and fourth indicators may be affected. The reporting state of indicators two and three shall remain unchanged. If the AG supports more indicators than the number of indicator-reporting-states provided by the HF, the AG shall maintain the current reporting states of those indicators. For example, if the AG supports five indicators and the HF sends the command AT+BIA=1,0,1 then only the first three AG indicators may be affected by the command. Call, Call Setup and Held Call indicators have been defined as mandatory indicators. This implies that whatever the reporting state the HF gives, these indicators shall always been kept activated by the AG. The AG shall gracefully ignore any excess parameter(s) at the end. The AG shall silently ignore a request to deactivate a mandatory indicator.
10 May 2011
Page 86 of 126
The previous three points allow the HF to activate or deactivate all the indicators, except the mandatory ones, by using a fixed string. For example, if the maximum indicator count is 20: All indicators can be set to active by using the fixed string: AT+BIA=1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1 and to inactive (except for the always active ones) by using: AT+BIA=0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 The actual number of allowed indicators is defined by the AT+CIND command. AT+BINP (Bluetooth INPut) Syntax: AT+BINP=<datarequest> Expected response: +BINP: <dataresp1><datarespn> Description: Command used for requesting some specific data input from the AG5. On reception of this command the AG shall perform the proper actions such that the requested information is sent back to the HF using the +BINP response. The type of data the HF shall expect in the <dataresp> parameter returned by the AG depends on the information requested in each case. Only support for execution command is mandated. Neither the read nor test commands are mandatory. Values: <datarequest>: 1, where 1 = Phone number corresponding to the last voice tag recorded in the HF. <dataresp1..n>: Data parameters returned by the AG. Their contents depend on the value of the <datarequest> parameter as follows: <datarequest> value 1 <dataresp> parameters <Phone number>: Phone number string (max. 32 digits). The format (type of address) of the phone number string shall conform with the rules stated in [7], sub-clause 10.5.4.7, for a value (in integer format) of the type of address octet of 145, if dialing string includes international access code
AT+BINP was created with future extensibility in mind. While the Hands-Free Profile only specifies a <datarequest> value of 1 (i.e. phone number), future profiles may choose to add values for <datarequest> to support the retrieval of additional data from the AG. 10 May 2011
Page 87 of 126
character +, and for a value of 129 otherwise. AT+BLDN (Bluetooth Last Dialed Number) Syntax: AT+BLDN Description: Command used for calling the last phone number dialed. On reception of this command, the AG shall set up a voice call to the last phone number dialed. Only support for execution command is mandated. Neither the read nor test commands are mandatory. AT+BVRA (Bluetooth Voice Recognition Activation) Syntax: AT+BVRA=<vrec> Description: Enables/disables the voice recognition function in the AG. Only support for execution command is mandated. Neither the read nor test commands are mandatory. Values: <vrec>: 0, 1, entered as integer values, where 0 = Disable Voice recognition in the AG 1 = Enable Voice recognition in the AG +BVRA (Bluetooth Voice Recognition Activation) Syntax: +BVRA: <vrect> Description: Unsolicited result code used to notify the HF when the voice recognition function in the AG is activated/deactivated autonomously from the AG. The unsolicited +BVRA: 1 result code shall not be sent by the AG to the HF if the corresponding voice recognition activation has been initiated by the HF. Likewise, the unsolicited +BVRA: 0 result code shall not be sent by the AG to the HF if the corresponding voice recognition deactivation has been initiated by the HF, regardless of which side initiated the voice recognition activation. Values: <vrect>: 0, entered as integer value, where 0 = Voice recognition is disabled in the AG 1 = Voice recognition is enabled in the AG AT+BRSF (Bluetooth Retrieve Supported Features) Syntax: AT+BRSF=<HF supported features bitmap> Description:
10 May 2011
Page 88 of 126
Notifies the AG of the supported features available in the HF, and requests information about the supported features in the AG. The supported features shall be represented as a decimal value. Values: <HF supported features bitmap>: a decimal numeric string, which represents the value of a 32 bit unsigned integer. The 32 bit unsigned integer represents a bitmap of the supported features in the HF as follows: Bit 0 1 2 3 4 5 6 7 Feature EC and/or NR function Call waiting or 3-way calling CLI presentation capability Voice recognition activation Remote volume control Enhanced call status Enhanced call control Codec negotiation
8-31 Reserved for future definition The reserved bits [8-31] shall be initialized to Zero. +BRSF (Bluetooth Retrieve Supported Features) Syntax: +BRSF: <AG supported features bitmap> Description: Result code sent by the AG in response to the AT+BRSF command, used to notify the HF what features are supported in the AG. The supported features shall be represented as a decimal value. Values: <AG supported features bitmap>: a decimal numeric string, which represents the value of a 32 bit unsigned integer. The 32 bit unsigned integer represents a bitmap of the supported features in the AG as follows: Bit 0 1 2 3 4 5 6 7 Feature Three-way calling EC and/or NR function Voice recognition function In-band ring tone capability Attach a number to a voice tag Ability to reject a call Enhanced call status Enhanced call control
10 May 2011
Page 89 of 126
8 Extended Error Result Codes 9 Codec negotiation 10-31 Reserved for future definition The reserved bits (10-31) shall be initialized to Zero. AT+NREC (Noise Reduction and Echo Canceling) Syntax: AT+NREC=<nrec> Description: Command issued to disable any Echo Canceling and Noise Reduction functions embedded in the AG. Only support for execution command is mandated. Neither the read nor test commands are mandatory. Values: <nrec>: 0, entered as integer value, where 0 = Disable EC/NR in the AG AT+VGM (Gain of Microphone) Syntax: AT+VGM=<gain> Description: Command issued by the HF to report its current microphone gain level setting to the AG. <gain> is a decimal numeric constant, relating to a particular (implementation dependent) volume level controlled by the HF. This command does not change the microphone gain of the AG; it simply indicates the current value of the microphone gain in the HF. Only support for execution command is mandated. Neither the read nor test commands are mandatory. Values: <gain>: 0 -15, entered as integer values, where 0 = Minimum gain 15 = Maximum gain AT+VGS (Gain of Speaker) Syntax: AT+VGS=<gain> Description: Command issued by the HF to report its current speaker gain level setting to the AG. <gain> is a decimal numeric constant, relating to a particular (implementation dependent) volume level controlled by the HF. This command does not change the speaker gain of the AG; it simply indicates the current value of the speaker volume in the HF.
10 May 2011
Page 90 of 126
Only support for execution command is mandated. Neither the read nor test commands are mandatory. Values: <gain>: 0 -15, entered as integer values, where 0 = Minimum gain 15 = Maximum gain +VGM (Gain of Microphone) Syntax: +VGM:<gain> Description: Unsolicited result code issued by the AG to set the microphone gain of the HF. <gain> is a decimal numeric constant, relating to a particular (implementation dependent) volume level controlled by the HF. Due to the small inconsistency between the GSM standard [2]) and the current Headset specification ([3]), the HF shall also accept the = symbol, in place of :, as a valid separator for this unsolicited result code. Values: <gain>: 0 -15, integer values, where 0 = Minimum gain 15 = Maximum gain +VGS (Gain of Speaker) Syntax: +VGS:<gain> Description: Unsolicited result code issued by the AG to set the speaker gain of the HF. <gain> is a decimal numeric constant, relating to a particular (implementation dependent) volume level controlled by the HF. Due to the small inconsistency between the GSM 07.07 standard ([2]) and the current Headset specification [3]), the HF shall also accept the = symbol, in place of :, as valid separator for this unsolicited result code. Values: <gain>: 0 -15, integer values, where 0 = Minimum gain 15 = Maximum gain +BSIR (Bluetooth Setting of In-band Ring tone) Syntax: +BSIR: <bsir> Description:
10 May 2011
Page 91 of 126
Unsolicited result code issued by the AG to indicate to the HF that the in-band ring tone setting has been locally changed. The HF may react accordingly by changing its own alert method. Values: <bsir>: 0 = the AG provides no in-band ring tone 1 = the AG provides an in-band ring tone AT+BTRH (Bluetooth Response and Hold Feature) Syntax: AT+BTRH=<n> Description: Command issued by the HF for the Response and Hold feature in the AG. This specification defines the use of the set and read command. The AT+BTRH? command shall be used by the HF to query the current Response and Hold state of the AG. Values: <n>: 0, 1, 2 entered as integer values, where 0 = Put Incoming call on hold 1 = Accept a held incoming call 2 = Reject a held incoming call +BTRH (Bluetooth Response and Hold Feature) Syntax: +BTRH: <n> (Response for AT+BTRH) Description: Result code used to notify the HF when-ever the incoming call is either put on hold or accepted or rejected. The AG shall also respond back with this response for the AT+BTRH? command from the HF. Values: <n>: 0,1,2 entered as integer value, where 0 = Incoming call is put on hold in the AG 1 = Held incoming call is accepted in the AG 2 = Held incoming call is rejected in the AG AT+BCC (Bluetooth Codec Connection) Syntax: AT+BCC Description:
10 May 2011
(Set command)
AT+BTRH? (Read Current Status)
Page 92 of 126
This command is used by the HF to request the AG to start the codec connection procedure. AT+BCS (Bluetooth Codec Selection) Syntax: AT+BCS= (u is a Codec ID) Description: This command confirms to the remote device (AG) the codec, and implicitly also which synchronization protocol, will be used on the synchronous connection. If no value is included, the command is invalid. Values: : All possible Codec IDs, see definition of AT+BAC. +BCS (Bluetooth Codec Selection) Syntax: +BCS: (u is a codec ID) Description: This command informs to the remote device (HF) the codec, and implicitly also which synchronization protocol, will be used on the synchronous connection. Values: : All possible Codec IDs, see definition of AT+BAC. AT+BAC (Bluetooth Available Codecs) Syntax: AT+BAC= [<u1>[,<u2>[,...[,<un>]]]] (u1,u2, ..., un are a codec IDs) Description: This command informs the remote device (AG) about what codecs (see Table 3.3) that the HF supports. The Codec ID for the mandatory narrow band codec (CVSD) shall always be included. If wide band speech is supported then the mandatory codec (mSBC) shall be included unless it is temporarily unavailable. Any other optional wide band speech codecs may also be included in this list as long as the mandatory codec is included first. Values: : All possible Codec IDs. Codec IDs shall be transferred as string representations of decimal numbers. The format of the Codec IDs is 8 bit aliases that are defined in section 12 (Appendix B: Codec IDs). For a single codec with ID=12 and the mandatory default codecs (1 and 2), the command: AT+BAC=1,2,12 is sent.
10 May 2011
Page 93 of 126
5 Serial Port Profile

This profile requires compliance to the Serial Port Profile [6]. The following text together with the associated sub-clauses defines the requirements with regard to this profile in addition to the requirements as defined in the Serial Port Profile. For the Hands-Free Profile, both the AG and the HF may initiate connection establishment. Therefore, for the purposes of reading the Serial Port Profile [5], both the AG and the HF may assume the role of Device A or B.
5.1
RFCOMM Interoperability Requirements
For the RFCOMM layer, no additions to the requirements as stated in the Serial Port Profile [6] Section 4 apply.
5.2
L2CAP Interoperability Requirements
For the L2CAP layer, no additions to the requirements as stated in the Serial Port Profile [6] Section 5 apply.
5.3
SDP Interoperability Requirements
The following service records are defined for the Hands-Free Profile. There is one service record applicable to the Hands-Free unit and another for the Audio Gateway. The attribute SupportedFeatures states the features supported in each device. This attribute is not encoded as a data element sequence; it is simply a 16-bit unsigned integer. The set of features supported in each case is bit-wise defined in this attribute on a yes/no basis. The mapping between the features and their corresponding bits within the attribute is listed below in Table 5.2 for the HF and in Table 5.4 for the AG. If a device indicates support for a feature, then it shall support that feature in the manner specified by this Profile, and be subject to verification as part of the Bluetooth Qualification Program. 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), are listed in the Bluetooth Assigned Numbers (see URL [8]). The values of the SupportedFeatures bitmap given in Table 5.2 shall be the same as the values of the Bits 0 to 4 of the AT-command AT+BRSF (see Section 4.34).
Item
ServiceClassIDList ServiceClass0 ServiceClass1 ProtocolDescriptorList Protocol0 UUID L2CAP UUID UUID Hands-Free Generic Audio
Definition
Type
Value
Status
M M M M M
Default
10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 Item

Protocol1 ProtocolSpecificParamete r0 BluetoothProfileDescriptorList Profile0 Param0 ServiceName SupportedFeatures Supported Profiles Profile Version Display-able Text name Features supported UUID Uint16 String Uint16 Hands-Free 0x0106
6
Page 94 of 126 Definition Type

UUID Server Channel Uint8
Value
RFCOMM N=server channel #
Status
M M M M M O M
Default
Hands-Free
Service-provider defined Device dependent
Hands-Free unit 0x0000
Table 5.1: Service Record for the HF Bit position (0=LSB) 0 1 2 3 4 5 Feature EC and/or NR function (yes/no, 1 = yes, 0 = no) Call waiting or three way calling(yes/no, 1 = yes, 0 = no) CLI presentation capability (yes/no, 1 = yes, 0 = no) Voice recognition activation (yes/no, 1= yes, 0 = no) Remote volume control (yes/no, 1 = yes, 0 = no) Wide band speech (yes/no, 1 = yes, 0 = no) Default in HF 0 0 0 0 0 0
Table 5.2: SupportedFeatures attribute bit mapping for the HF
The "Network" attribute states if the AG has the capability to reject incoming calls 7. This attribute is not encoded as a data element sequence; it is simply an 8-bit unsigned integer. The information given in the Network attribute shall be the same as the information given in Bit 5 of the unsolicited result code +BRSF (see Section 4.34). An attribute value of 0x00 is translated to a bit value of 0; an attribute value of 0x01 is translated to a bit value of 1. The values of the SupportedFeatures bitmap given in Table 5.4 shall be the same as the values of the Bits 0 to 4 of the unsolicited result code +BRSF (see Section 4.34).
Indicating version HFP 1.6. In previous versions of the Hands-Free Profile, the attribute values were called "GSM like" and "others". 10 May 2011
Page 95 of 126
Item ServiceClassIDList ServiceClass0 ServiceClass1 ProtocolDescriptorList Protocol0 Protocol1 ProtocolSpecificP arameter0 BluetoothProfileDescriptorLi st Profile0 Param0 ServiceName Network
Definition
Type
Value
Statu s M
Default
UUID UUID
AG Hands-Free Generic Audio
M M M
UUID UUID Server Channel Uint8
L2CAP RFCOMM N=server channel #
M M M M
Supported Profiles Profile Version Display-able Text name
UUID Uint16 String Uint8
Hands-Free 0x01068 Service-provider defined 0x01 Ability to reject a call 0x00 No ability to reject a call Device dependent
M M O M
Hands-Free
Voice gateway
SupportedFeatures
Features supported
Uint16
0x0009
Table 5.3: Service Record for the AG Bit position (0=LSB) 0 1 2 3 4 5 Feature Three-way calling (yes/no, 1 = yes, 0 = no) EC and/or NR function (yes/no, 1 = yes, 0 = no) Voice recognition function (yes/no, 1 = yes, 0 = no) In-band ring tone capability (yes/no, 1 = yes, 0 = no) Attach a phone number to a voice tag (yes/no, 1 = yes, 0 = no) Wide band speech (yes/no, 1 = yes, 0 = no) Default in AG 1 0 0 1 0 0
Table 5.4: SupportedFeatures attribute bit mapping for the AG
Indicating version HFP 1.6. 10 May 2011
Page 96 of 126
5.3.1 Interaction with Hands-Free Profile Rev 0.96 Implementations HF implementations, which are according to the Hands-Free Profile specification Rev. 0.96, will not send the AT+BRSF command. Likewise, AG implementations, which are according to the Hands-Free Profile specification Rev. 0.96, will not be able to respond to AT+BRSF with the +BRSF unsolicited result code. Instead they will respond with ERROR. In order to retrieve the SupportedFeatures information from an HF, which does not send AT+BRSF, Service Discovery should be used by the AG implementation. Whenever the SupportedFeatures attribute is not present in the HF service record, or if the AG does not perform the Service Discovery procedure, default values as stated in Table 5.2 shall be assumed. In order to retrieve the SupportedFeatures and Network information from an AG, which does not send +BRSF, Service Discovery should be used by the HF implementation. Whenever the SupportedFeatures attribute is not present in the AG service record, or if the HF does not perform the Service Discovery procedure, default values as stated in Table 5.4 shall be assumed. 5.3.2 Interaction with HFP 0.96, 1.0 and HFP 1.5 implementations HF implementations that comply with the Hands-Free Profile specification Rev. 0.96,1.0 or 1.5, shall not indicate support for the Codec Negotiation feature and shall neither send the AT+BAC command nor the AT+BCC command to trigger an audio connection establishment by the AG. AG implementations that comply with the Hands-Free Profile specification Rev. 0.96,1.0 or 1.5, shall not indicate support for the Codec Negotiation feature and shall neither send the AT+BCS command. In order to guarantee backward compatibility, HFP Rev. x.y implementations shall be able to handle establishment of synchronous connections according to Hands-Free Profile specification Rev. 1.0 or 1.5. The HF shall be able to accept establishment of a synchronous connection from a HFP 1.0 or 1.5 AG. The AG shall be able to initiate establishment of a synchronous connection to a HFP 1.0 or 1.5 HF.
10 May 2011
Page 97 of 126
HF
AG

Figure 5.1: Procedure for Establishment of an Audio Connection from AG
The HF shall be able to initiate establishment of a synchronous connection to a HFP 1.0 or 1.5 AG. The AG shall be able to accept establishment of a synchronous connection from a HFP 1.0 or 1.5 HF.
HF
Established Service Level Connection Internal event or user action
AG

Figure 5.2: Procedure for Establishment of an Audio Connection from HF
5.4
Link Manager (LM) Interoperability Requirements
The profile adopts the requirements for the Link Manager as stated in the Serial Port Profile [6]. Additionally this profile mandates that both the AG and HF devices shall support synchronous logical transports, subject to the requirements in Section 5.6.
10 May 2011
Page 98 of 126
5.5
Link Control (LC) Interoperability Requirements
Table 5.5 shows the changes from Link Controller requirements in the Serial Port Profile [6].
Capability 1. 2. 7 C Inquiry Inquiry scan Voice CODEC CVSD M M O Support in AG Support in HF O
Table 5.5: Link Controller requirements
5.5.1 Class of Device A device implementing the HF role of HFP shall set the "Audio" bit in the Service Class field. Optionally, if the HF intends to be discovered as a "Hands-Free", it may use the following values in the Class of Device field: 1. Indicate "Audio" as Major Device class. 2. Indicate Hands-Free as the Minor Device class. An inquiring AG may use this information to filter the inquiry responses.
5.6
Baseband Interoperability Requirements
The eSCO link and the air mode Transparent Data shall be supported if wide band speech is supported and are optional otherwise. Erroneous data delivery may be used for wide band speech only if core version 2.1 or higher is supported.
Item 1.1.3/3 1.1.7/4 Capability Support of eSCO link Transparent data Status C1 C1
1.1.8/2 Erroneous data delivery C2 C1: Mandatory if wide band speech is supported, or optional otherwise. C2: Optional if core version 2.1 or higher is supported, or excluded otherwise Table 5.6: Baseband Requirements
5.7
Codec Interoperability Requirements

Support Ref
Table 5.7 shows supported Mandatory and Optional codecs in this profile.
Codec Type CVSD M 5.7.3 mSBC C1 5.7.4 C1: Mandatory if wide band speech is supported or excluded otherwise. Table 5.7: Supported Codecs
10 May 2011
Page 99 of 126
5.7.1 Synchronous Connection Interoperability Requirements Synchronous connections may be realized by a SCO or by an eSCO logical transport. The support for SCO logical transports is always mandated. If wide band speech is supported, eSCO support is also mandated. HCI level parameters are given as a reference. On systems not incorporating HCI, values for LMP level eSCO parameters TeSCO, W eSCO and packet length shall be associated that correspond to these HCI parameters and fall into the mandatory parameter ranges for these packet types as given in the LMP specification, and the Voice Setting parameter translates into the air mode parameter of LMP. Requirements related to the use of SCO links is covered by the parameter sets D0-D1. The following requirements apply to the support and use of eSCO logical transports and are based on parameter sets S1-S3 and T1-T2: The device starting the request for a Synchronous Connection is known as the Initiator, the device receiving the request from the Initiator is known as the Responder. The Responder is able to accept or reject a request for eSCO transport. The Responder shall always accept a request for SCO transport. If wide band speech is supported, and the request for eSCO transport is rejected the Initiator shall always attempt to setup a Codec connection using the narrow band CVSD codec and SCO transport before giving up. If support for eSCO logical transports is indicated at the Controller level, the Initiator may request the setup of an eSCO logical transport instead of SCO. If wide band speech is supported, the Initiator shall request the setup of an eSCO transport. The Initiators request for an eSCO transport may involve any configuration parameters matching the bidirectional throughput requirements of the voice codec (see Section 5.5). If an HCI is supported on this device, the request for setting up a synchronous connection may include single or multiple packet types masked within the same request. The Responder may choose to accept or reject the request from the Initiator. It may reject the request for an eSCO transport, or may accept it with parameters that do not match the requested parameters. In this case the Initiator may retry the Synchronous Connection setup with different configuration parameters. If one or subsequent requests for an eSCO logical transport fails, the Initiator shall not abandon the setup of an eSCO transport without having requested eSCO using the safe settings S1. If wide band speech is supported, the Initiator shall not abandon the setup of an eSCO transport without having requested eSCO using the safe settings T1. Only for HCI-based devices: if the Responder does not reject the request for an eSCO transport, the response shall include the parameters corresponding to the safe settings S1 when accepting a request. The Responder shall not request eSCO parameters that would inhibit the ability of the Initiator to negotiate the S1 settings. If wide band speech is supported, the Responder shall not request eSCO parameters that would inhibit the ability of the Initiator to negotiate the T1 settings.
10 May 2011
Page 100 of 126
If the Initiator fails to establish an eSCO transport with the S1 settings, the Initiator shall request the setup of a SCO transport. If wide band speech is supported, and the Initiator fails to establish an eSCO transport with the T1 settings, the Initiator shall always attempt to setup a Codec connection using the narrow band CVSD codec and SCO transport.
Only for HCI-based devices: the Responder shall include the parameters for a SCO transport when accepting a request for a Synchronous Connection. The following requirements apply if a device supports both eSCO logical transports and Enhanced Data Rate (as of Bluetooth core specification v2.0 + EDR or later). The Controller shall support the packet type 2-EV3, hence mandatory eSCO parameters ranges as given in the LMP specification and contained in settings S2 and S3. If wide band speech is supported, settings T2 shall be supported in addition. On an HCI-Responder, at least the settings S2 shall be included in the list of acceptable parameters.
5.7.2 Synchronization Header for Transparent Data Two synchronization headers have been defined; the first one only contains a sequence number. The second one has both a synchronization word and a sequence number. H1: Header with sequence number Figure 5.3: shows the layout of the header H1 that only contains the sequence number. The one octet header shall contain a 4 bit sequence number (SN0,, SN3). The sequence number is protected by a simple repetition code (all bits are duplicated). Hence, each sequential pair of bits in the sequence number shall be always 00 or 11.
SN0 SN1
0
SN2
SN3
7
Codec frame
Figure 5.3: One octet frame synchronization H1 header
When using the Erroneous data delivery feature, the sequence number in the H1 header shall always be different from 0. The reason is that the Erroneous data delivery feature sets 0 for payload data octets corresponding to missing (e)SCO packets. H2: Header with synchronization word and sequence number Figure 5.4 shows the layout of the header H2 that contains both the synchronization word and the sequence number. The two octet header shall contain a 12 bit synchronization word and a 2 bit sequence number (SN0, SN1). The latter is protected by a simple repetition code (both bits are duplicated). Hence, each pair of bits in the sequence number shall be always 00 or 11.
10 May 2011
Page 101 of 126
1 0
0
0 0
0 0 0 0 1
7 0
SN0
SN1
7
Codec frame
Figure 5.4: Two octet frame synchronization H2 header
It should be noted that when the transparent data transport is used, any alignment of the coded audio stream frames (codec frames and synchronization word) with eSCO packet boundaries is left up to the implementation. The use of the synchronization header enables unaligned codec audio frames to be recovered by the receiving side. 5.7.3 CVSD coding Table 5.8 defines SCO configuration parameter sets D0 and D1 for usage of CVSD coding.
SCO parameter set Packet type Transmit/Receive Bandwidth Voice_Setting (air coding) Max_Latency Retransmission_Effort D0 HV1 8000 CVSD NA NA D1 HV3 8000 CVSD NA NA
Table 5.8: SCO synchronous connections (HCI Reference parameters)
Table 5.9 defines eSCO configuration parameter sets S1, S2 and S3 for usage of CVSD coding.
eSCO parameter set Packet type Transmit/Receive Bandwidth Voice_Setting (air coding) Max_Latency Retransmission_Effort S1 Safe Settings EV3 8000 CVSD 0x0007 (7 ms) 0x01 S2 2-EV3 8000 CVSD 0x0007 (7 ms) 0x01 S3 2-EV3 8000 CVSD 0x000A (10ms) 0x01
Table 5.9: eSCO synchronous connections (HCI Reference parameters)
5.7.4 mSBC coding Support for a modified version of the SBC codec (hereafter called mSBC) is mandatory if Wide Band Speech is supported in this profile. The original SBC codec is specified in A2DP [9]. The modifications to SBC that constitute mSBC are specified in Appendix A of this profile. The various mandatory and optional settings for this codec are specified in the tables below.
10 May 2011
Page 102 of 126
Support for the following mSBC configuration is mandatory if wide band speech is supported.
Parameter Channel mode Sampling rate Allocation method Subbands Blocklength Bitpool Value Mono 16 kHz Loudness 8 15 26
Table 5.10: mSBC mandatory parameter set
An mSBC frame shall have the synchronization header H2 before every frame. The H2 header will ensure that the receiver knows if one or more radio link packets are dropped. Wide band speech, when using the mSBC codec, shall only use the eSCO transport. The eSCO T1 setting below shall be supported. If one or more eSCO setup requests fail, it is required that T1 settings are used before wide band speech over eSCO transport is abandoned.
eSCO parameter set Packet type Transmit/Receive Bandwidth Voice_Setting (air coding) Max_Latency Retransmission_Effort T1 Safe Settings EV3 8000 Transparent Data 8 ms 0x02 T2 2-EV3 8000 Transparent Data 13 ms 0x02
Table 5.11: eSCO parameters for a wide band speech connection using the mSBC codec.
5.7.5 Codec vs link parameter negotiation The codec negotiation procedure defined in this profile is used to negotiate what codec to use when establishing an audio connection. The procedure is not used to negotiate what link parameters to use with the selected codec. The link parameters are negotiated by the link managers using the link manager protocol. The recommended link parameter preferences for a given codec are: For CVSD: S3 is preferred over S2, S2 is preferred over S1, S1 is preferred over D1 and D1 is preferred over D0. For mSBC: T2 is preferred over T1.
5.7.6 Optional Codecs The device may also support optional codecs to maximize its usability. When both the initiating device and responding device support the same optional codec, this codec
10 May 2011
Page 103 of 126
may be used instead of the mandatory codec. Currently no optional Codecs are listed as part of this specification. Future versions of this specification document could include optional codecs by adding new optional Codec IDs to Appendix B and the optional Codec specification.
5.8
Speech Quality Recommendations
The introduction of wide band speech to the HFP profile will raise the end customers expectations of perceived speech quality. The recommendations in the following sections if followed will help ensure high levels of customer satisfaction. 5.8.1 Packet Loss Concealment (PLC) It is strongly recommended that some form of PLC should be implemented on receiving ends of the wide band speech connection to deliver satisfactory speech quality under all channel conditions. The example PLC algorithm provided in Appendix B may be used. The speech quality of this example PLC under typical packet loss conditions is considered satisfactory. If implementations choose to modify or implement an alternate PLC scheme, the performance of any such alternate PLC should meet or exceed the performance of the example PLC provided in Appendix C. 5.8.2 Signal Levels Full swing at the 16 bit linear PCM interface to the Codecs in this profile specification is defined to be 3 dBm0. This definition applies to devices that support narrow band and wide band speech. Further details on recommended audio levels is specified in Appendix D section 14.1 Recommended specifications for send and receive frequency masks are provided in Appendix D section 14.2.
10 May 2011
Page 104 of 126
6 Generic Access Profile

This section defines the support requirements for the capabilities as defined in the Generic Access Profile of the Core Specification.
6.1
Modes
Table 6.1shows the support status for GAP Modes in this profile.
Procedure General discoverable mode Procedure Pairable mode Table 6.1: Modes M M Support in AG Support in HF
6.2
Security Aspects
Baseband authentication and encryption is optional for both the Hands-Free unit and the Audio Gateway. If both devices support authentication and encryption, the application on either device may require its use. A Hands-Free unit may be able to use the services of the Audio Gateway without the creation of a secure connection. It is implementation specific whether the Hands-Free unit provides or supports security enforcement for the user. Whenever baseband authentication and/or encryption is used, the two devices shall create a secure connection using the GAP authentication procedure as described in Section 5.1 of the Generic Access Profile [5]. This procedure may include entering a Bluetooth PIN code and creation of proper link keys. In cases when the UI of the HandsFree unit is limited, a fixed Bluetooth PIN code may be used during the GAP authentication procedure.
6.3
Idle Mode Procedures

Support in AG M O O
Table 6.2 shows the support status for Idle mode procedures within this profile.
Procedure Initiation of general inquiry Initiation of general bonding Initiation of dedicated bonding Table 6.2: Idle mode procedures
10 May 2011
Page 105 of 126
7 References
Specification of the Bluetooth System; Core, v1.1 or later 3GPP 27.007 v6.8.0 now supersedes and replaces ETS 300 916, Digital cellular telecommunications system (Phase 2+); AT command set for GSM Mobile Equipment (ME) (GSM 07.07 version 7.5.0) [3] http://www.3gpp.org/ftp/Specs/html-info/27007.htm [4] Specification of the Bluetooth System; Profiles, v1.1 or later, Headset Profile [5] Specification of the Bluetooth System; Core, v1.1 or later, Generic Access Profile [6] Specification of the Bluetooth System; Profiles, v1.1 or later, Serial Port Profile [7] ITU-T50, Terminal Equipment and Protocols for telematic services: International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 IA5). Information technology 7-Bit coded character set for information interchange [8] Digital cellular telecommunication system (Phase 2+); Mobile radio interface layer 3 specification", (GSM 04.08 version 6.11.0) [9] GSM 02.30 (version 7.1.0): Digital cellular telecommunications system (Phase 2+); Man-Machine Interface (MMI) of the Mobile Station (MS) [10] Bluetooth Assigned Number URL is https://www.bluetooth.org/foundry/assignnumb/document/assigned_numbers [11] Bluetooth Specification, Advanced Audio Distribution Profile, v1.0 or later [12] D. Goodman, et al., Waveform Substitution Techniques for Recovering Missing Speech Segments in Packet Voice Communications, IEEE Transaction on Acoustics, Speech and Signal Processing, December 1986, pp. 1440 - 1448. [1] [2]
10 May 2011
Page 106 of 126
8 List of Acronyms and Abbreviations

Abbreviation or Acronym AG AT BTR CLI CODEC CVSD DTMF EC EDR eSCO GAP GSM HF L2CAP LMP mSBC NR OSI PLC PIN POI RFCOMM SBC SCO SDP UI UUID WBS Meaning Audio Gateway Attention Bluetooth Reference Point Calling Line Identification COder DECoder Continuously Variable Slope Delta modulation Dual Tone Multi-Frequency Echo Cancellation Enhanced Data Rate Extended Synchronous Connection Oriented Generic Access Profile Global System for Mobile communication Hands-Free unit Logical Link Control and Adaptation Protocol Link Manager Protocol Modified Sub Band Codec Noise Reduction Open System Interconnection Packet Loss Concealment Personal Identification Number Point Of Interconnection Serial port transport protocol over L2CAP Sub Band Codec Synchronous Connection Oriented Service Discovery Protocol User Interface Universally Unique Identifier Wide Band Speech
10 May 2011
Page 107 of 126
9 List of Figures
Figure 1.1: Bluetooth Profiles ...................................................................................................................... 10 Figure 1.2: Conventions used in signaling diagrams .................................................................................. 12 Figure 2.1: Protocol stack ........................................................................................................................... 13 Figure 2.2: Typical Hands-Free Use ........................................................................................................... 14 Figure 4.1: Service Level Connection establishment .................................................................................. 22 Figure 4.2: Service Level Connection removal ........................................................................................... 24 Figure 4.3: Typical Registration Status update ........................................................................................... 24 Figure 4.4: Transfer of Signal strength indication ....................................................................................... 25 Figure 4.5: Transfer of Roaming Status Indication ..................................................................................... 26 Figure 4.6: Transfer of Battery level indication ........................................................................................... 26 Figure 4.7: Query currently selected Network operator .............................................................................. 27 Figure 4.8: Enable/Disable AG Error result code ........................................................................................ 28 Figure 4.9: Procedure for Establishment of Audio Connection from AG .................................................... 30 Figure 4.10: Procedure for Establishment of Audio Connection from HF ................................................... 30 Figure 4.11: Procedure for the Establishment of Codec Connection ......................................................... 32 Figure 4.12: Procedure for updating the list of available Codecs ............................................................... 33 Figure 4.13: Audio Connection release ....................................................................................................... 34 Figure 4.14: Answer an incoming call from the HF in-band ring tone ...................................................... 36 Figure 4.15: Answer an incoming call from the HF no in-band ring tone ................................................. 37 Figure 4.16: Answer an incoming call from the AG .................................................................................... 38 Figure 4.17: Change of the in-band ring tone setting initiated by the AG ................................................... 39 Figure 4.18: Reject an incoming call from the HF ....................................................................................... 40 Figure 4.19: Rejection/interruption of an incoming call in the AG ............................................................... 40 Figure 4.20: Terminate ongoing call - HF initiated ...................................................................................... 41 Figure 4.21: Terminate ongoing call - AG initiated ..................................................................................... 42 Figure 4.22: Audio Connection transfer to the HF ...................................................................................... 43 Figure 4.23: Audio Connection transfer to the AG ...................................................................................... 44 Figure 4.24: Place an outgoing voice call with the digits entered in the HF ............................................... 45 Figure 4.25: Place an outgoing voice call using memory dialing ................................................................ 46 Figure 4.26: Place an outgoing voice call with the last number dialed ....................................................... 48 Figure 4.27: Activation of Call waiting notification ...................................................................................... 49 Figure 4.28: Typical Call Waiting indication followed by a three way call set up process .......................... 50 Figure 4.29: Three way call handling when the third party call is placed from the HF ............................... 51 Figure 4.30: Activation of CLI notification ................................................................................................... 53 Figure 4.31: NR and EC functions available in the AG ............................................................................... 54 Figure 4.32: Voice recognition activation HF initiated .............................................................................. 55 Figure 4.33: Voice recognition activation AG initiated ............................................................................. 56 Figure 4.34: Voice recognition deactivation momentary on approach .................................................. 56 Figure 4.35: Voice recognition deactivation from the HF ............................................................................ 57 Figure 4.36: Request phone number to the AG .......................................................................................... 58 Figure 4.37: Transmit DTMF code .............................................................................................................. 58 Figure 4.38: Typical example of audio volume control ............................................................................... 59 Figure 4.39: Typical example of volume level synchronization ................................................................... 60 Figure 4.40: Query Response and Hold State of AG .................................................................................. 61 Figure 4.41: Put an incoming call on Hold from HF .................................................................................... 62 Figure 4.42: Put an incoming call on Hold from AG .................................................................................... 63 Figure 4.43: Accept a held incoming call from HF ...................................................................................... 64 Figure 4.44: Accept a held incoming call from AG ...................................................................................... 65 Figure 4.45: Reject a held incoming call from HF ....................................................................................... 66 10 May 2011
Page 108 of 126
Figure 4.46: Reject a held incoming call from AG ...................................................................................... 67 Figure 4.47: Held incoming call terminated by caller .................................................................................. 68 Figure 4.48: Query Subscriber Number Information of AG ......................................................................... 69 Figure 4.49: Empty Subscriber Number Information from AG .................................................................... 69 Figure 4.50: Query List of Current Calls ..................................................................................................... 70 Figure 4.51: Call Held or Active/Held Position Swap .................................................................................. 71 Figure 4.52: Held Call Release ................................................................................................................... 72 Figure 4.53: Active Call Terminated/Call Remains Held ............................................................................. 72 Figure 4.54: Release Specified Active Call ................................................................................................. 73 Figure 4.55: Request Private Consultation Mode ....................................................................................... 74 Figure 5.1: Procedure for Establishment of an Audio Connection from AG ............................................... 97 Figure 5.2: Procedure for Establishment of an Audio Connection from HF ................................................ 97 Figure 5.3: One octet frame synchronization H1 header .......................................................................... 100 Figure 5.4: Two octet frame synchronization H2 header .......................................................................... 101 Figure 14.1: Example setup for audio level testing ................................................................................... 123
10 May 2011
Page 109 of 126
10 List of Tables
Table 3.1: Application layer procedures ...................................................................................................... 16 Table 3.2: Application layer feature to procedure mapping ........................................................................ 18 Table 3.3: Requirements on supported codecs .......................................................................................... 18 Table 3.4: Codec to link feature mapping ................................................................................................... 18 Table 5.1: Service Record for the HF ......................................................................................................... 94 Table 5.2: SupportedFeatures attribute bit mapping for the HF ............................................................... 94 Table 5.3: Service Record for the AG ......................................................................................................... 95 Table 5.4: SupportedFeatures attribute bit mapping for the AG ............................................................... 95 Table 5.5: Link Controller requirements ...................................................................................................... 98 Table 5.6: Baseband Requirements ........................................................................................................... 98 Table 5.7: Supported Codecs ..................................................................................................................... 98 Table 5.8: SCO synchronous connections (HCI Reference parameters) ................................................. 101 Table 5.9: eSCO synchronous connections (HCI Reference parameters) ............................................... 101 Table 5.10: mSBC mandatory parameter set ........................................................................................... 102 Table 5.11: eSCO parameters for a wide band speech connection using the mSBC codec. .................. 102 Table 6.1: Modes ...................................................................................................................................... 104 Table 6.2: Idle mode procedures .............................................................................................................. 104 Table 11.1: Mnemonics ............................................................................................................................. 110 Table 11.2: Syntax of mSBC speech frame .............................................................................................. 110 Table 11.3: Syntax of mSBC frame header .............................................................................................. 110 Table 11.4: Mapping of Codec Ids to mSBC parameters ........................................................................ 111 Table 12.1: Mapping of Codec Types to Codec IDs ................................................................................ 112 Table 14.1:Tolerance Mask for the Bluetooth Send Sensitivity Frequency Response ............................. 124 Table 14.2: Tolerance Mask for the Receive Sensitivity Frequency Response ....................................... 125
10 May 2011
Page 110 of 126
11 Appendix A: Technical Specification of mSBC

11.1 Introduction
This appendix describes the changes to the SBC codec defined in A2DP [9] standard which comprises the Modified SBC codec. The changes to the A2DP SBC are limited to the frame header syntax and semantics. All other parts of the SBC definition remain unmodified 11.1.1 Mnemonics The following mnemonics are defined to describe the different data types used in the coded bit-stream.
Mnemonic Description
Char8 Character of 8 bits UiMsbf Unsigned integer, Most significant bit first SiMsbf Signed integer, Most significant bit first BsMsbf Bit-stream, Most significant bit first PCM Pulse Code Modulation Na Not available Table 11.1: Mnemonics
11.2 Syntax
Syntax audio_frame() { frame_header() scale_factors() audio_samples() padding() } Table 11.2: Syntax of mSBC speech frame Note: The syntax of the mSBC speech frame has not changed from the original SBC definition in A2DP [10].Syntax frame_header() { Syncword Reserved for future use crc_check } Table 11.3: Syntax of mSBC frame header No. of bits Mnemonic No. of bits Mnemonic
8 16 8
BsMsbf UiMsbf UiMsbf
11.3 Semantics
11.3.1 Frame_header syncword -- The 8 bit string %10101101 or $AD.
10 May 2011
Page 111 of 126
The syncword is different from that specified for the SBC in A2DP specifications so that implementations may use this is an additional indication that the encoded stream is meant to contain Wide Band Speech. Codec ID The following table represents the values of the various mSBC parameters that correspond to the values specified in the Codec ID field.
8 bit Codec ID 0x02 Mandatory Or Optional M mSBC Parameters Channel Mode Mono Sampling rate 16 kHz Allocation method loudness Subbands 8 Block length 15 Bitpool 26
Table 11.4: Mapping of Codec Ids to mSBC parameters
Note: The interpretation of the mSBC parameters as specified in Table 11.4 is identical to that specified in SBC definition in A2DP [9]. 11.3.2 Padding The all zero 8 bit string %00000000 or $00 shall be used for padding.
10 May 2011
Page 112 of 126
12 Appendix B: Codec IDs

The following table specifies the mapping of the Codecs to their respective Codec Ids.
Codec Type CVSD mSBC Other optional codecs may be added here Table 12.1: Mapping of Codec Types to Codec IDs Codec ID 0x01 0x02 Reserved Ref. 5.7.3 5.7.4 Reserved
10 May 2011
Page 113 of 126
13 Appendix C: Example PLC Implementation

This appendix describes a packet loss concealment (PLC) method based on the paper by D. Goodman, et al. [11] and adapted for use with mSBC.
13.1 Baseline Packet Loss Concealment

A baseline packet loss concealment algorithm based on the techniques presented in [1] is discussed. This baseline PLC is a generic PCM-based system and makes no assumptions on mSBC. Its integration into mSBC to form a reference PLC for mSBC is described in a later section. The following subsections describe the techniques used from] in the baseline PLC algorithm. 13.1.1 Waveform Substitution Based On Pattern Matching The technique in Section IV Waveform Substitution Based on Pattern Matching of [1] is used to construct an estimate of the waveform in missing packets. This algorithm searches a history buffer of previously received samples to find a packet-worth of samples to replace the missing packet. The selection is based on constructing a template of M samples immediately preceding the missing packet and scanning a search window of N samples in the history buffer to find the M samples that best match the template. It then uses as a replacement packet the L samples that follow the best match. The pattern matching criterion used is the cross-correlation similar to that in equation (4) of the paper except the denominator contains a square root as in the standard definition of cross-correlation. The implementation follows the recommendations of the paper and uses a template of 4ms (M=64) and a search window of 16ms (N=256). A frame size of 7.5ms (L=120) was used corresponding to the frame size of the default mSBC configuration. 13.1.2 Overlap-Add As described in Section III of the paper, in order to reduce the audible distortion caused by discontinuities at the boundaries between correct packets and substitution packets, it is important to merge the two waveforms by way of an overlap-add procedure. The example PLC follows the recommendation of the paper and uses a raised-cosine weighting with a merge duration of 1ms (16 samples). The paper adds 1ms of delay in order to merge at the boundary between the last correct packet and the substitution packet. However, the example PLC avoids this added delay by using the partial signal contained in the mSBC decoder memory. This will be described in more detail in section 13.2.1. At the boundary between the first correct packet after packet loss and the substitution packet, the paper extends the substitution waveform 1ms into the correct packet in order to perform the merge. The example PLC follows a similar method except that the substitution waveform is further extended to allow for the mSBC decoder signal to re-converge after packet loss. This is also described later.
10 May 2011
Page 114 of 126
13.1.3 Amplitude Matching Section B of the paper describes a procedure to adjust the amplitude of the substitution packet to match that of the preceding packet. The example PLC implements this approach with the mean-absolute-value measure of packet amplitude.
13.2 Integration of PLC with mSBC

The PLC described in the paper was designed for PCM without any considerations for integration with a codec such as mSBC. The main issue with mSBC as far as integration of a PLC is the response of the sub-band filters in the mSBC decoder. The integration is described in the next sub-sections. 13.2.1 Merging in the First Substitution Frame Avoiding Delay As previously mentioned, the paper performs a merge between the last correct packet and the substitution packet by introducing a 1ms delay. This delay is avoided in the example PLC by taking advantage of the signal embedded in the mSBC decode subband filter memory. In the first substitution frame, the mSBC decoder is fed a bit-stream corresponding to an all-zero input signal. The output of decoder is then used to merge with the substitution waveform using a 1ms raised-cosine weighting as described in the paper. This procedure also has the advantage of setting the decoder memory to zero. 13.2.2 Re-convergence of the mSBC Decoder in the First Correct Packet After Packet Loss The delay caused by the sub-band filters in the mSBC decoder means that when the first correct packet after packet loss is decoded, there will be a period of time before the output re-converges to the desired decoder output. Since the decoder memory is essentially reset to zero by the procedure described in Section 13.2.1, the decoder output will ramp up from zero as it re-converges. The substitution waveform is extended into the first correct packet after packet loss by an amount equal to this re-convergence time and used as output. Once the decoder output has sufficiently re-converged, the substitution waveform is merged with the decoder output using a 1 ms raised-cosine weighting. The re-convergence time used was experimentally tuned to 36 samples (2.25ms).
13.3 API Description

This section describes the API for the example PLC for mSBC. 13.3.1 Memory Allocation The calling application must allocate memory for the PLC memory structure. The structure is defined in the file sbcplc.h and is shown below:
/* PLC State Information */ struct PLC_State { 10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 short hist[LHIST+FS+SBCRT+OLAL]; short bestlag; int }; nbf;
Page 115 of 126
The main test program can allocate the space by simply declaring a variable as below:
struct PLC_State plc_state;
13.3.2 Initialization The calling application must initialize the PLC memory that was allocated as described in Section 13.3.1. The initialization function must be called once before processing begins. The initialization function is:
void InitPLC(struct PLC_State *plc_state)
and is found in sbcplc.c. The calling program should include sbcplc.h containing the header:
#include "sbcplc.h"
and should call the initialization function:

InitPLC(&plc_state);
13.3.3 Good Frame Processing If a good frame is received, the frame should be decoded by mSBC. The output PCM samples from the mSBC decoder must then be passed to the function:
void PLC_good_frame(struct PLC_State *plc_state, short *in, short *out)
where:
struct PLC_State *plc_state short *in the PLC memory block Pointer to the array of samples from the mSBC decoder containing the PCM samples of the good decoded frame. Pointer to the array of samples processed by PLC_good_frame().
short *out
Note that the calling application owns the memory pointed to by *in and *out. The size of these arrays should be no smaller than the frame size. The samples pointed to by *out are the final output samples. 13.3.4 Bad Frame Processing If a frame is lost, the calling application must do the following: Call the mSBC decoder with channel indices representing an all-zero input PCM signal. This is further described in Section 13.3.5 Call the mSBC PLC function
10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 void PLC_bad_frame(struct PLC_State *out)
Page 116 of 126 *plc_state, short *ZIRbuf, short
where:
struct PLC_State *plc_state short *ZIRbuf short *out the PLC memory block. the zero input response of the mSBC decoder from step 1) of length equal to the frame size. pointer to the buffer where the PLC will write the concealment samples for the current lost frame.
13.3.5 SBC Decoder Zero-Input Response At time of receiving the first bad frame, the mSBC decoder filter banks contain data from previous good frames, called signal memory. This signal memory can be extracted by calling the mSBC decoder with a bit-stream that represents an all-zero PCM signal. The resulting signal is termed the Zero-Input Response (ZIR) of the mSBC decoder. The example PLC requires this signal as part of its input. The indices representing the all-zero signal can be obtained offline and stored. The indices are then used as input to the decoder every time a frame is lost. To obtain the indices, use an all-zero PCM signal as input to the encoder, and capture the indices. Store these indices and use them as described above. The zero input bit stream for the default mSBC configuration is pre-computed and provided below:
#if FS==120 #define FSIDX #define NROFBLK #define CHMODE 2=stereo, 3=joint #define ALLOCMETHOD 1=SNR */ #define NROFSB #define BITPOOL #endif short 0xb6, 0xb6, 0xb6, 0xb6, indices0[] = {0xad, 0x0, 0x0, 0xdd, 0xdb, 0x6d, 0xb7, 0x76, 0xdd, 0xdb, 0x6d, 0xb7, 0x76, 0xdd, 0xdb, 0x6d, 0xb7, 0x76, 0xdd, 0xdb, 0x6d, 0xb7, 0x76, 0xc5, 0xdb, 0xdb, 0xdb, 0xdb, 0x0, 0x0, 0x0, 0x0, 0x77, 0x6d, 0x6d, 0xdd, 0xb6, 0xdb, 0x77, 0x6d, 0x6d, 0xdd, 0xb6, 0xdb, 0x77, 0x6d, 0x6d, 0xdd, 0xb6, 0xdb, 0x77, 0x6d, 0x6c}; /* Frame Size of 120 samples 57 15 0 */ 0 8 26 /* Frame Size Indexes*/ /* NumbeR OF BLocKs*/ /* CHannel MODE 0=mono, 1=dual, 0=loudness,
/* bit ALLOCation METHOD /* NumbeR OF SubBands */ /* BITPOOL size */
10 May 2011
Page 117 of 126
13.3.6 Bad Frame Calling Example In the case of a bad frame, using the above example data, the calling application would do the following:
SBCdecode( indices0, ZIRbuf); PLC_bad_frame(plc_state, ZIRbuf, outbuf);
The application would then use the contents of outbuf for playback.
13.4 Source Code (ANSI C)

13.4.1 Source code for file sbcplc.h
/******************************************************** SBC Example PLC ANSI-C Source Code File: sbcplc.h ***************************************************************************** / #ifndef SBCPLC_H #define SBCPLC_H #define #define #define #define #define #define FS 120 /* Frame Size */ N 256 /* 16ms - Window Length for pattern matching */ M 64 /* 4ms - Template for matching */ LHIST (N+FS-1) /* Length of history buffer required */ SBCRT 36 /* SBC Reconvergence Time (samples) */ OLAL 16 /* OverLap-Add Length (samples) */
/* PLC State Information */ struct PLC_State { short hist[LHIST+FS+SBCRT+OLAL]; short bestlag; int nbf; }; /* Prototypes */ void InitPLC(struct PLC_State *plc_state); void PLC_bad_frame(struct PLC_State *plc_state, short *ZIRbuf, short *out); void PLC_good_frame(struct PLC_State *plc_state, short *in, short *out); #endif /* SBCPLC_H */
13.4.2 Source code for the file sbcplc.c

/************************************************************* SBC Example PLC ANSI-C Source Code File: sbcplc.c *************************************************************/ #include <math.h> //#include "sbc.h" #include "sbcplc.h" /* Local Function Prototypes */ float CrossCorrelation(short *x, short *y); int PatternMatch(short *y); 10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 float AmplitudeMatch(short *y, short bestmatch);
Page 118 of 126
/* Raised COSine table for OLA */ float rcos[OLAL] = {0.99148655f,0.96623611f,0.92510857f,0.86950446f, 0.80131732f,0.72286918f,0.63683150f,0.54613418f, 0.45386582f,0.36316850f,0.27713082f,0.19868268f, 0.13049554f,0.07489143f,0.03376389f,0.00851345f}; +
/*****************************************************************************
* * * * * Function: InitPLC() * Purpose: Perform PLC initialization of memory vectors. * Inputs: *plc_state - pointer to PLC state memory * Outputs: *plc_state - initialized memory. * Date: 03-18-2009
*****************************************************************************/
void InitPLC(struct PLC_State *plc_state) { int i; plc_state->nbf=0; plc_state->bestlag=0; for (i=0;i<LHIST+SBCRT;i++) plc_state->hist[i] = 0; } /*********************************************************** * Function: PLC_bad_frame() * * Purpose: Perform bad frame processing. * * Inputs: *plc_state - pointer to PLC state memory * *ZIRbuf - pointer to the ZIR response of the SBC decoder * * Outputs: *out - pointer to the output samples * * Date: 03-18-2009 ************************************************************/ void PLC_bad_frame(struct PLC_State *plc_state, short *ZIRbuf, short *out) { int i; float val; float sf; plc_state->nbf++; sf=1.0f; i=0; if (plc_state->nbf==1) { /* Perform pattern matching to find where to replicate */ plc_state->bestlag = PatternMatch(plc_state->hist); plc_state->bestlag += M; /* the replication begins after the template match */ /* Compute Scale Factor to Match Amplitude of Substitution Packet to that of Preceding Packet */ sf = AmplitudeMatch(plc_state->hist, plc_state->bestlag); 10 May 2011
Page 119 of 126
for (i=0;i<OLAL;i++) { val = ZIRbuf[i]*rcos[i] + sf*plc_state->hist[plc_state>bestlag+i]*rcos[OLAL-i-1]; if (val > 32767.0) val= 32767.0; if (val < -32768.0) val=-32768.0; plc_state->hist[LHIST+i] = (short)val; } for (;i<FS;i++) { val = sf*plc_state->hist[plc_state->bestlag+i]; if (val > 32767.0) val= 32767.0; if (val < -32768.0) val=-32768.0; plc_state->hist[LHIST+i] = (short)val; } for (;i<FS+OLAL;i++) { val = sf*plc_state->hist[plc_state->bestlag+i]*rcos[i-FS]+plc_state>hist[plc_state->bestlag+i]*rcos[OLAL-1-i+FS]; if (val > 32767.0) val= 32767.0; if (val < -32768.0) val=-32768.0; plc_state->hist[LHIST+i] = (short)val; } for (;i<FS+SBCRT+OLAL;i++) plc_state->hist[LHIST+i] = plc_state->hist[plc_state->bestlag+i]; } else { for (;i<FS;i++) plc_state->hist[LHIST+i] = plc_state->hist[plc_state->bestlag+i]; for (;i<FS+SBCRT+OLAL;i++) plc_state->hist[LHIST+i] = plc_state->hist[plc_state->bestlag+i]; } for (i=0;i<FS;i++) out[i] = plc_state->hist[LHIST+i]; /* shift the history buffer */ for (i=0;i<LHIST+SBCRT+OLAL;i++) plc_state->hist[i] = plc_state->hist[i+FS]; } /**************************************************************************** * * Function: PLC_good_frame() * * Purpose: Perform good frame processing. Most of the time, this function * just updates history buffers and passes the input to the output, * but in the first good frame after frame loss, it must conceal the * received signal as it reconverges with the true output. * * Inputs: *plc_state - pointer to PLC state memory * *in - pointer to the input vector * * Outputs: *out - pointer to the output samples * Date: 03-18-2009 10 May 2011
Page 120 of 126
***************************************************************************** / void PLC_good_frame(struct PLC_State *plc_state, short *in, short *out) { int i; i=0; if (plc_state->nbf>0) { for (i=0;i<SBCRT;i++) out[i] = plc_state->hist[LHIST+i]; for (;i<SBCRT+OLAL;i++) out[i] = (short)(plc_state->hist[LHIST+i]*rcos[i-SBCRT] + in[i]*rcos[OLAL-1-i+SBCRT]); } for (;i<FS;i++) out[i] = in[i]; /*Copy the output to the history buffer */ for (i=0;i<FS;i++) plc_state->hist[LHIST+i] = out[i]; /* shift the history buffer */ for (i=0;i<LHIST;i++) plc_state->hist[i] = plc_state->hist[i+FS]; plc_state->nbf=0; } /**************************************************************************** * * Function: CrossCorrelation() * * Purpose: Compute the cross correlation according to Eq. (4) of Goodman * paper, except that the true correlation is used. His formula * seems to be incorrect. * * Inputs: *x - pointer to x input vector * *y - pointer to y input vector * * Outputs: Cn - return value containing the cross-correlation of x and y * * Date: 03-18-2009 ***************************************************************************** / float CrossCorrelation(short *x, short *y) { int m; float num; float den; float Cn; float x2, y2; num=0; den=0; 10 May 2011
BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 x2=0.0; y2=0.0; for (m=0;m<M;m++) { num+=((float)x[m])*y[m]; x2+=((float)x[m])*x[m]; y2+=((float)y[m])*y[m]; } den = (float)sqrt(x2*y2); Cn = num/den; return(Cn); }
Page 121 of 126
/**************************************************************************** * * Function: PatternMatch() * * Purpose: Perform pattern matching to find the match of template with the * history buffer according to Section B of Goodman paper. * * Inputs: *y : pointer to history buffer * * Outputs: return(int): the lag corresponding to the best match. The lag is * with respect to the beginning of the history buffer. * * Date: 03-18-2009 ***************************************************************************** / int PatternMatch(short *y) { int n; float maxCn; float Cn; int bestmatch; maxCn=-999999.0; /* large negative number */ bestmatch=0; for (n=0;n<N;n++) { Cn = CrossCorrelation(&y[LHIST-M] /* x */, &y[n]); if (Cn>maxCn) { bestmatch=n; maxCn = Cn; } } return(bestmatch); } /**************************************************************************** * * Function: AmplitudeMatch() 10 May 2011
Page 122 of 126
* * Purpose: Perform amplitude matching using mean-absolute-value according * to Goodman paper. * * Inputs: *y : pointer to history buffer * bestmatch : value of the lag to the best match * * Outputs: return(float): scale factor * * Date: 03-19-2009 ***************************************************************************** / float AmplitudeMatch(short *y, short bestmatch) { int i; float sumx; float sumy; float sf; sumx = 0.0; sumy = 0.000001f; for (i=0;i<FS;i++) { sumx += abs(y[LHIST-FS+i]); sumy += abs(y[bestmatch+i]); } sf = sumx/sumy; /* This is not in the paper, but limit the scaling factor to something reasonable to avoid creating artifacts */ if (sf<0.75f) sf=0.75f; if (sf>1.2f) sf=1.2f; return(sf); }
10 May 2011
Page 123 of 126
14 Appendix D: Quality Metrics

14.1 Audio levels
The Bluetooth Core Specification (Volume 2, Part B, Section 9, Audio) describes the CVSD codec for voice on the Bluetooth air interface. The Core Specification also provides general audio recommendations for narrowband voice. This appendix provides recommendations for the wide band speech update of the Hands-Free Profile. For both CVSD (narrow band ) and the wide band speech codecs, the full scale sine wave PCM data should meet the network level of +3dBm0 as previously specified for the CVSD codec. The AG manufacturer should adjust the gain from the Bluetooth Reference Point (BTR) to the cellular network, as shown in the core specification. The HF is responsible to adjust the speech signal to the BTR, as shown in the core specification, to ensure best interoperability between AG and HF, to enable nominal speech level of -21dbm0 in the networks at given nominal sound pressure level of -4.7 dBPa at the mouth reference point of the HF.as described in ITU-T P.1100.
dBm0: absolute
power level in dBm referred to a point of zero relative level (0 dBr point)
A possible test setup is described in Figure 14.1.
Figure 14.1: Example setup for audio level testing 10 May 2011
Page 124 of 126
The gain from BTR to the network and the gain from the network to the BTR should be adjusted for both signal processing modes: either on the phone (AG) or on the handsfree (HF) device after confirming the AT+NREC=0 command. When the signal processing is confirmed to be disabled on the AG, a sine signal can be used to verify the gain between the BTR and the network. When the active signal processing for Echo Cancellation and Noise Reduction are performed on the AG, a sine signal can lead to wrong results and a speech like signal, like P.50 (artificial voice), should be used. A Network simulator is highly recommended during testing because of the unknown status of gain and signal processing in real networks.
14.2 Bluetooth Sensitivity Frequency Responses

14.2.1 Bluetooth Send Sensitivity Frequency Response The send sensitivity frequency response is measured from BTR to POI (reference speech codec of the system simulator, output). The tolerance mask for the send sensitivity frequency response is enumerated in the Table below, the mask is drawn by straight lines between the breaking points on a logarithmic (frequency) - linear (dB sensitivity) scale.
Frequency (Hz) Upper Limit Lower Limit
100 0 -2 6 200 0 -2 7 000 0 -3 Wide Band Mask, Note: All sensitivity values are expressed in dB on an arbitrary scale.
Frequency (Hz)
Upper Limit
Lower Limit
200 0 -2 3 100 0 -2 3 400 0 -3 Narrow Band Mask, Note: All sensitivity values are expressed in dB on an arbitrary scale. Narrow band stops at 3400 Hz Table 14.1:Tolerance Mask for the Bluetooth Send Sensitivity Frequency Response
10 May 2011
Page 125 of 126
14.2.2 Bluetooth Receive Sensitivity Frequency Response The receive sensitivity frequency response is measured from the electrical reference point (input of the system simulators, POI) to the Bluetooth reference interface. The tolerance mask for the receive sensitivity frequency response is shown in Table below, the mask is drawn by straight lines between the breaking points on a logarithmic (frequency) - linear (dB sensitivity) scale.
100 0 -2 6 200 0 -2 7 000 0 -3 Wide Band Mask Note: All sensitivity values are expressed in dB on an arbitrary scale.
200 0 -2 3 100 0 -2 3 400 0 -3 Narrow Band Mask Note: All sensitivity values are expressed in dB on an arbitrary scale. Narrow band stops at 3400 Hz Table 14.2: Tolerance Mask for the Receive Sensitivity Frequency Response
10 May 2011
Page 126 of 126
15 Appendix E Pre-1.6 Document History

Revision Number D10r06 D10r07 D10r08 D12r00 D12r01 D12r02 D15r03 D15r04 D15r05 D15r06 D15r07 D15r08 D15r09 D15r09 D15r10-11 D15r12 D15r13 V10r00 Date 01-01-29,12-11-2003 22-11-2004, 03-14-03 16-02-2005 19-03-2005 22-04-2005 28-04-2005 13-05-2005 27-05-2005 07-06-2005 07-18-2005 08-01-2005 09/02/2005 09/22/2005 09/26/2005 10/04/2005 10/05/2005 10/07/2005 11/25/2005 Comments Hands-Free Profile 0.50 published1 draft for SubWG12 Review CR document derived from FIPD07r04Additional comments from BTI/BQRB reviews Editing for Prototyping Specification standards Incorporated Prototyping Specifications Errata and corrections from IOP. HFP 1.0 Errata- 13, 261, 317, 549, 550, 575, 586, 635, 706, 731, 746 Correct formatting problems and comments from review. Errata 819, 820, 821, 822 Edits from BARB Review. Errata 823. Changes from BARB review. Editorial changes for language and readability. Comments from BTI/BARB review. Comments from BTI review. Comments from BTI review Add 3GPP 27.07 version and remove reference to Call Waiting for AT+CHUP BTI Comments Editorial changes Prepare for publication Adopted by the Bluetooth Board of Directors
st
10 May 2011

HFP Spec v16

Uploaded by

Copyright:

Available Formats

HFP Spec v16

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HFP Spec v16

Uploaded by

Copyright:

Available Formats

BLUETOOTH DOC

Telephony Working Group

HANDS-FREE PROFILE 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

CRr09 CRr10 CRr11 CRr11 CRr12 CRr13 D16r01

26/07/2007 15/02/2008 24/09/2009 17/12/2009 18/01/2010 20/01/2010 23 July 2010

D16r02 D16r03 D16r04

19 August 2010 04 February 2011 16 March 2011

29 March 2011 5 April 2011, 3 May 2011

5 May 2011 10 May 2011

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

Disclaimer and Copyright Notice

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6 6.1 6.2 6.3 7 8 9 10 11

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

Serial Port Profile (SPP) Generic Access Profile (GAP)

SCO and eSCO (Audio)

Symbols and Conventions

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

Mandatory procedure initiated by B

Optional procedure initiated by A

Mandatory procedure initiated by either A or B

Optional procedure initiated by either A or B

Figure 1.2: Conventions used in signaling diagrams

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

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

Hands-Free control RFCOMM LMP SDP L2CAP

Baseband Audio Gateway side

Baseband Hands-Free side

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

Configuration and Roles

Public Wireless Network

Hands-Free unit installed in the car

Figure 2.2: Typical Hands-Free Use

User Requirements and Scenarios

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

Audio Connection handling

8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.

20. 21a. 21b. 22. 23 24

Table 3.2: Application layer feature to procedure mapping

Table 3.3 shows the codec requirements for this profile.

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

4 Hands-Free Control Interoperability Requirements

Service Level Connection Establishment

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

BLUETOOTH SPECIFICATION Hands-Free Profile 1.6

Internal event or user action

RFCOMM connection establishment

Internal event or user action

Service Level Connection Initialization Procedure

AT+BAC=<HF Available Codecs> OK

The HF requests the current status of the indicators in the AG