【BT 协议】HFP 协议

原文链接：https://blog.csdn.net/shichaog/article/details/52123439

HFP(Hands-free Profile)，让蓝牙设备可以控制电话，如接听、挂断、拒接、语音拨号等，拒接、语音拨号要视蓝牙耳机及电话是否支持。

目前HFP的使用场景有车载蓝牙，耳机和PDA，定义了AG和HFP两种角色。
AG（Audio Gate）音频网关—音频设备输入输出网关
HF（Hands Free）免提—该设备作为音频网关的远程音频输入/输出机制，并可提供若干遥控功能。

在车载蓝牙中，手机侧是AG，车载蓝牙侧是HF，在android源代码中，将AG侧称为HFP/AG，将HF侧称为HFPClient/HF。

回到上面错误，该信息源于将现有手机平台设置成HF而出现的错误，有两个关键字RFCOMM和AT。

HF协议栈

[Hands-Free Profile 1.7.1 Bluetooth ® Profile Specification]
上图是源码Bluetooth官网关于HFP的定义文档，该文档中可以看出有RFCOMM和AT CMD这两个部分，RFCOMM是AG和HF通信的虚拟串口，AT是Attention命令集合。 各种profile的解释见http://blog.csdn.net/shichaog/article/details/51931898–[蓝牙 bluetooth-之一 ]

HFP feature和procedure

名词意义

• LMP link: Link Manager (LM) level link over which only Link Manager Protocol (LMP) commands are conveyed
• RFCOMM connection:虚拟串口通道存在
• Service Level Connection：同步的部分协议栈高层协议，HFP协议层指的是RFCOMM connection，和AG同步。
• Service Level Connection initialization:AT命令集执行 responses specified by the profile necessary to synchronize the state of the HF with that of the AG.
• Service Level Connection establishment:the combined process of establishing the RFCOMM connection, as well as the necessary device synchronization using Service Level Connection initialization.
• Synchronous Connection：为全双工音频链接的SCO或者eSCO逻辑link。
• Audio Connection：包括音频通路的同步链接
• incoming call：表示由Phone Network到AG的通话。
• outgoing call：表示由AG到Phone Network的通话。

Baseband,LMP,L2CAP是OSI模型的Layer1和Layer2层。RFCOMM是蓝牙串口，SDP是服务发现协议。Hands-Free control层基于AT命令实现控制。audio port是AG音频通道，audio driver是HF侧的音频驱动。音频有两种格式CVSD和SBC。

• CVSD: pcm: 8kHz, 16 bits, 1 channel.
  compression ratio: 16 (controller encoding)
  insert ratio: 8
  pcm data rate= 16kB/s =8K*16/8
  CVSD data rate=8kB/s =16kB/s* 8/16
  air data: CVSD
• mSBC: pcm 16kHz, 16 bits, 1 channel.
  compression ratio: 4 (host encoding: 240->60)
  pcm data rate= 32kB/s
  mSBC data rate=8kB/s = 32kB/s / 4
  air data: transparent data (mSBC)

AG和HF需要支持的功能

（M，必须，O可选）

 
 
 
 

• 1

HF control通信流程

Service Level Connection

AG和HF均可以通过内部或者用户事件发起Service Level连接建立。Service Level Connection建立的前提是RFCOMM已经建立。同样RFCOMM的建立发起者可以是AG或者HF。
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].

• 支持能力交换
  首先HF发送AT+BRSF=< HF supported features >给AG，目的是首先通知AG其具有的能力，其次接收AG返回的其自身的BRSF能力。
• Codec协商
  如果HF支持Codec Negotiation特征，其会查看AG返回的BRSF中是否也支持该特性，如果都支持该特性，则HF将发送AT+BAC=< HF available codecs >命令给AG以告知其可用的codec。
• AG Indicator
  HF从AG接收到的BRSF，可以知道AG支持的Indicator，并按顺序拍好，这是因为根据3GPP 27.007规范，AG可以支持Hands-Free不支持的profile。HF使用AT+CIND=?测试命令接收AG支持的indicator以及它们的次序。
  当HF获得必须的Indicator和它们的次序，它将通过AT+CIND?命令取得AG端正在使用indicator的状态。
  当HF取得AG的indicator后，HF会使用AT+CMER使能AG的indicator状态跟新功能，AG会返回OK作为应答。当service，call或者call建立状态发生时，AG将发送和indicator相关的+CIEV结果码给HF。HF根据收到的+CIEV码来跟新其自身内部的indicator。
  AG侧会一直保持indicator状态跟新功能使能直到收到AT+CMER指示其关闭或者HF和AG端的Service Level Connection连接断开。
  当HF使能AG的indicator状态跟新，如果AG和HF都支持呼叫等待（Call waiting）和3方通信（3-way calling）。HF将发送AT+CHLD=?测试命令取得AG是如何支持这种功能的。如果HF或者AG其中之一不支持三方通信，AT+CHLD=?命令不会被发送。
• HF Indicator
  如果HF支持HF indicator，其会查看AG是否支持HF indicator。
  如果HF和AG支持HF indicator特性，HF将发送AT+BIND=< HF supported HF indicators >通知HF侧支持的indicator，AG以OK应答。
  当AG接收到HF告知的HF indicator特性，HF将发送AT+BIND=?请求AG侧支持的HF indicator。AG将会以+BIND和以OK结尾的应答。
  当HF接收到AG支持的HF indicator，HF将会发送AT+BIND?命令确定HF目前使能的HF indicator。AG将会一次或多次以+BIND应答和以OK结尾的应答。
  至此HF可能发送AT+BIEV命令告知AG其使能的HF indicator发生变化。
  AG可以使用+BIND使能或者禁止任何HF indicator。\
• End of Service Level Connection
  HF需要知道Service Level Connection被完全建立，这可以通过以下几个方式：
• 当且仅当AG通过+BRSF命令告知HF其支持的HF indicator，在HF收到AG通过AT+BIND？命令发来的其支持的HF indicator可认为完全建立。
• 当且仅当SDP服务发现AH和AG双方均支持“Call waiting and 3-way calling”，在HFAG通过AT+CHLD命令发来的其对呼叫等待和多方电话的支持，对这种情况，HF indicator不要设置该比特位，AG也不要在+BRSF命令中设置该比特位。
• 在HF使用AT+CMER命令成功使能了“Indicator status update”功能，对这种情况SDP服务不应该设置“Call waiting and 3-way calling”比特位。
  如果HF收到AG通过indicator指示当前有电话时，HF查询AG的接听和保持状态来判断是否是未接听电话。
  同样AG侧Service Level Connection完全建立也有几种情况：
• 当且仅当HF indicator在HF被设置且AG侧支持的indicator已经通过+BRSF命令应答，则AG以+BIND加OK结尾的命令应答其使能的HF indicator时可认为Service Level Connection完全建立。
• 当且仅当“Call waiting and 3-way calling”比特在HF和AG的SDP服务中被置位，在AG通过+CHLD加OK结尾命令成功响应其对呼叫保持和多方电话支持时SLC会被完全建立。对这种情况，+BRSF不应该设置该HF indicator比特位。
• 在AG成功响应AT+CMER命令。

这一过程如下图：

AT命令见http://blog.csdn.net/shichaog/article/details/52126415 [蓝牙之九-AT命令]

连接丢失恢复

在蓝牙连接丢失时，HF侧会主动重连AG。但当Service Level Connect被用命令主动断开连接时，AG和HF将会在接收到重连命令后等待一个确定时间再重连。

电话建立保持的传输

AT+CMER命令使能了AG侧的“Call Status indicator update”功能。

音频连接建立

HF和AG可以根据用户动作或者内部事件建立音频连接，AH和AG也许需要内部动作来路由，更改采样率，帧/或者音频通路采样对齐。正式点的说法是音频连接建立：

• HF在接听电话中能够初始化音频连接建立
• HF在无电话时能初始化音频连接建立
• HG在接听电话中能够初始化音频连接建立
• HG在无电话时能初始化音频连接建立
  音频连接建立过程总是意味着同步连接（Synchronous Connection）建立，并且同步连接和已经建立的SLC是相关的。
  该过程的一个先决条件是，AG和HF之间需要存在SLC，如果不存在则将会先建立这个连接。
  发起者和接收者都将通知新音频连接已经存在。

由AG发起的音频连接建立

当AG侧发起音频连接时，它将初始化编解码器连接建立过程。

HF侧发起音频连接

对于两边都支持编解码器协商特性的场景，由HF发起的建立音频连接将会触发AG确立编解码器连接。这是必须的，因为只有AG知道编解码格式。

当HF发起音频编解码连接建立时，其将发送AT命令AT+BCC给AG。AG在启动编解码建立过程时会发送OK应答，如果不启动编解码时会发送ERROR应答。

编解码连接建立

尽管AG和HF都可以发起建立音频连接，但是编解码和同步连接建立只能有AG侧建立（除非其中一个设备是legacy设备）。
仅当HF通知AG其支持Codec Negotiation时，AG才会通过当前的SLC发送AT+BAC命令发起Codec Connection。AG会根据HF对AT+BAC的应答来选择合适的Codec connection。

AG将会通知HF在建立Synchronous Connection前使用哪个codec ID。

AG将会发送未经请求的命令+BCS=< Codec ID>给HF。HF将以AT+BCS=< Codec ID>命令响应，只要该ID是支持的，ID将会和AG发来的未经请求的命令是一样的。但是如果ID不支持，HF将以AT+BAC和其可用的codec作为应答。
如果AG收到的AT+BCS命令的ID和之前其发送的一样，则会发送OK应答，否则发送ERROR。如果AG发送命令+BCS后没有收到AT+BCS而是AT+BAC，这一过程将会结束但是AG在重新选择codec ID后会重新这一过程。
在发送OK响应后，AG将会根据ID打开相应设置的同步连接，而HF在发送AT+BCS=< Codec ID>命令后也能够接收同步连接建立请求。
在同步连接建立完成后，codec 连接建立也完成。+BCS命令是对这次和后续连接codec选择。
如果(e)SCO link无法建立，AG将会重启启动Codec Connection建立过程。在Codec connection建立连接之前，CVSD编码将被启用。

可选的codec跟新

对AG和HF都支持Codec Negotiaton特性的SLC场景。HF可以发送AT+BAC通知AG可选codec的动态变化。如果AG已经发起Codec Connection建立过程，HF将会发起AT+BAC命令以响应AG的未经请求的+BCS命令的codec不可用的情况。