蓝牙协议--HFP协议--转

时间:2024-04-08 09:08:43

HFP协议

    目前HFP的使用场景有车载蓝牙,耳机和PDA,定义了AG和HFP两种角色。 

    AG(Audio Gate)音频网关—音频设备输入输出网关 
    HF(Hands Free)免提—该设备作为音频网关的远程音频输入/输出机制,并可提供若干遥控功能。

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

蓝牙协议--HFP协议--转

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 Connectioninitialization:AT命令集执行 responses specified by the profile necessary to synchronize thestate of the HF with that of the AG.
Service Level Connectionestablishment:the combined process of establishing the RFCOMM connection, aswell as the necessary device synchronization using Service Level Connectioninitialization.
Synchronous Connection:为全双工音频链接的SCO或者eSCO逻辑link。
Audio Connection:包括音频通路的同步链接
incoming call:表示由Phone Network到AG的通话。

outgoing call:表示由AG到Phone Network的通话。

蓝牙协议--HFP协议--转

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 Section7.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-waycalling)。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 LevelConnection 
HF需要知道Service Level Connection被完全建立,这可以通过以下几个方式:
·        当且仅当AG通过+BRSF命令告知HF其支持的HFindicator,在HF收到AG通过AT+BIND?命令发来的其支持的HF indicator可认为完全建立。
·        当且仅当SDP服务发现AH和AG双方均支持“Callwaiting and 3-way calling”,在HFAG通过AT+CHLD命令发来的其对呼叫等待和多方电话的支持,对这种情况,HFindicator不要设置该比特位,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-waycalling”比特在HF和AG的SDP服务中被置位,在AG通过+CHLD加OK结尾命令成功响应其对呼叫保持和多方电话支持时SLC会被完全建立。对这种情况,+BRSF不应该设置该HF indicator比特位。

·        在AG成功响应AT+CMER命令。

蓝牙协议--HFP协议--转

连接丢失恢复

在蓝牙连接丢失时,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协议--转

HF侧发起音频连接

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

蓝牙协议--HFP协议--转

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

编解码连接建立

蓝牙协议--HFP协议--转
尽管AG和HF都可以发起建立音频连接,但是编解码和同步连接建立只能有AG侧建立(除非其中一个设备是legacy设备)。 
仅当HF通知AG其支持Codec Negotiation时,AG才会通过当前的SLC发送AT+BAC命令发起CodecConnection。AG会根据HF对AT+BAC的应答来选择合适的Codec connection。
AG将会通知HF在建立Synchronous Connection前使用哪个codec ID。 
AG将会发送未经请求的命令+BCS=<Codec ID>给HF。HF将以AT+BCS=< CodecID>命令响应,只要该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)SCOlink无法建立,AG将会重启启动CodecConnection建立过程。在Codec connection建立连接之前,CVSD编码将被启用。
可选的codec跟新
对AG和HF都支持CodecNegotiaton特性的SLC场景。HF可以发送AT+BAC通知AG可选codec的动态变化。如果AG已经发起Codec Connection建立过程,HF将会发起AT+BAC命令以响应AG的未经请求的+BCS命令的codec不可用的情况。
原文: https://mp.weixin.qq.com/s/4FWo97i275KvfrKs1cTb4A