蓝牙Hands-Free Profile 1.6：无线移动电话与车载设备的互操作规范

需积分: 25 132 浏览量更新于2024-07-24 1 收藏 1.55MB PDF 举报

"蓝牙 Hands-Free Profile 1.6 规范" 蓝牙 Hands-Free Profile（HFP）1.6 是一个定义了移动电话与蓝牙连接的手持设备（如车载系统或穿戴式耳机）协同工作的标准规范。它确保通过蓝牙链接提供无线方式，使手持设备能远程控制移动电话，并实现移动电话与手持设备之间的语音通信。该规范的目的是保证支持此配置文件的蓝牙启用的手持设备与任何蓝牙装备的移动电话之间能够实现互操作性。 HFP 1.6 规范涵盖了以下关键知识点： 1. **功能集**：该规范定义了基本功能集，包括设备之间的语音通话和远程控制功能。例如，用户可以通过车载音响系统或蓝牙耳机接听、拨打电话，而无需接触手机。 2. **无线连接**：蓝牙链接作为无线连接手段，允许设备之间无需物理接触即可进行通信。这对于驾驶时的安全操作尤其重要，因为驾驶员可以保持双手在方向盘上，视线不离开道路。 3. **远程控制**：手持设备可以远程控制移动电话，比如接听、挂断电话，调整音量，甚至访问电话簿等功能，提供了极大的便利性。 4. **语音连接**：HFP 支持高质量的语音通话，确保了移动电话与手持设备间的清晰通话体验。早期版本的 HFP 可能仅支持窄带语音，但随着技术发展，后来的版本可能还包括宽频语音（WideBand Speech），以提供更接近自然对话的音质。 5. **互操作性**：符合 HFP 1.6 规范的设备可以与其他任何支持该配置文件的蓝牙设备无缝协作，这保证了设备间的兼容性和广泛的应用范围。 6. **修订历史**：文档记录了 HFP 规范的修订过程，包括不同版本的日期、评论和改进内容。例如，CRr01 引入了宽频语音，CRr02 和 CRr03 则针对识别到的问题进行了更新和完善。 7. **技术标准**：蓝牙规范是蓝牙技术联盟（Bluetooth Special Interest Group, SIG）制定的一系列技术文档，确保蓝牙设备之间的通信一致性。HFP 1.6 是这些规范的一部分，旨在提高蓝牙设备在语音通信领域的用户体验和性能。蓝牙 Hands-Free Profile 1.6 是蓝牙技术在车载和穿戴设备领域应用的重要规范，它促进了移动通信与车载信息系统、个人穿戴设备之间的融合，提升了用户在驾驶和其他场景下的安全性和便利性。

BLUETOOTH SPECIFICATION Page 16 of 126

Hands-Free Profile 1.6

10 May 2011

3 Application layer

This section describes the feature requirements for units complying with HFP.

Table 3.1 shows the feature requirements for this profile.

Feature

Support in HF

Support in AG

Connection management

Phone status information

(note 1)

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

10.

Place a call to the last number dialed

11.

Call waiting notification

12.

Three way calling

(note 2)

(note 3)

13.

Calling Line Identification (CLI)

14.

Echo canceling (EC) and noise reduction (NR)

15.

Voice recognition activation

16.

Attach a Phone number to a voice tag

17.

Ability to transmit DTMF codes

18.

Remote audio volume control

19.

Respond and Hold

20.

Subscriber Number Information

21a.

Enhanced Call Status

21b.

Enhanced Call Controls

22.

Individual Indicator Activation

Wide Band Speech

Codec Negotiation

(note 4)

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

BLUETOOTH SPECIFICATION Page 19 of 126

Hands-Free Profile 1.6

10 May 2011

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.

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

BLUETOOTH SPECIFICATION Page 20 of 126

Hands-Free Profile 1.6

10 May 2011

available codecs> command to the AG to notify the AG of the available codecs in the

HF.

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.

剩余125页未读，继续阅读

czneilsun

粉丝: 0
资源: 1

蓝牙Hands-Free Profile 1.6：无线移动电话与车载设备的互操作规范

蓝牙HFP1.6协议（Hands-Free Profile）

蓝牙协议HFP文档.zip

bluetooth协议（2.1~5.1）及常用profile协议

hw4-hand-gesture-tracking-and-recognition-WeiyanZhu：hw4-hand-gesture-tracking-and-recognition-WeiyanZhu由GitHub Classroom创建

hand-in-hand-networkextension:“手把手开发NetworkExtension”系列的源码-源码开源

hw4-hand-gesture跟踪和识别-williamjdai：GitHub Classroom创建的hw4-hand-gesture跟踪和识别-williamjdai

hand-in-hand

Frontend-Mentor---Profile-card-component

poker-hand-db:poker-hand-db 允许您管理许多不同场景的扑克手牌范围，以允许您使用扑克理论制定最佳的扑克游戏策略

Hand-Written-digit-recognition-

最新资源