蓝牙之八-HFP

HFP

在调试安卓的HFP client时遇到了如下问题:
这里写图片描述
其中有一个E提示,因为AT命令的错误,所有创建SLC失败,然后断开RFCOMM链接,表现出来的是已经配对的手机不停的断开重连。


HFP协议

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协议栈


蓝牙之八-HFP_第1张图片
[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的通话。

蓝牙之八-HFP_第2张图片

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可选)

蓝牙之八-HFP_第3张图片

蓝牙之八-HFP_第4张图片

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命令。

这一过程如下图:
蓝牙之八-HFP_第5张图片
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侧发起音频连接时,它将初始化编解码器连接建立过程。
蓝牙之八-HFP_第6张图片

HF侧发起音频连接

对于两边都支持编解码器协商特性的场景,由HF发起的建立音频连接将会触发AG确立编解码器连接。这是必须的,因为只有AG知道编解码格式。
蓝牙之八-HFP_第7张图片
当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。
蓝牙之八-HFP_第8张图片

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不可用的情况。

你可能感兴趣的:(蓝牙)