零. 概述

本文章主要讲下电话免提协议HFP（Hands-Free Profile）Connection management。包括connection establishment     跟connection realease，那connection establishment又会涉及到HFP SLC的建立过程。

本节讲解的内容就是一下HFP feature中的NO.1

一. 声明

本专栏文章我们会以连载的方式持续更新，本专栏计划更新内容如下：

第一篇:蓝牙综合介绍 ，主要介绍蓝牙的一些概念，产生背景，发展轨迹，市面蓝牙介绍，以及蓝牙开发板介绍。

第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP，基于USB的H2等

第三篇:传统蓝牙controller介绍，主要介绍传统蓝牙芯片的介绍，包括射频层（RF），基带层（baseband），链路管理层（LMP）等

第四篇:传统蓝牙host介绍，主要介绍传统蓝牙的协议栈，比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的协议吧。

第五篇：低功耗蓝牙controller介绍，主要介绍低功耗蓝牙芯片，包括物理层（PHY），链路层（LL）

第六篇：低功耗蓝牙host介绍，低功耗蓝牙协议栈的介绍，包括HCI,L2CAP,ATT,GATT,SM等

第七篇：蓝牙芯片介绍，主要介绍一些蓝牙芯片的初始化流程，基于HCI vendor command的扩展

第八篇：附录，主要介绍以上常用名词的介绍以及一些特殊流程的介绍等。

另外，开发板如下所示，对于想学习蓝牙协议栈的最好人手一套。以便更好的学习蓝牙协议栈，相信我，学完这一套视频你将拥有修改任何协议栈的能力（比如Linux下的bluez，Android下的bluedroid）。

-------------------------------------------------------------------------------------------------------------------------

CSDN学院链接（进入选择你想要学习的课程）：https://edu.csdn.net/lecturer/5352?spm=1002.2001.3001.4144

蓝牙交流扣扣群：970324688

Github代码：https://github.com/sj15712795029/bluetooth_stack

入手开发板：https://item.taobao.com/item.htm?spm=a1z10.1-c-s.w4004-22329603896.18.5aeb41f973iStr&id=622836061708

蓝牙学习目录：https://blog.csdn.net/XiaoXiaoPengBo/article/details/107727900

--------------------------------------------------------------------------------------------------------------------------

二. HFP Connection management 介绍

HFP connection Management分为两个小节：1）connection establishment     2）connection realease

下面我们就来分别介绍下两个小节

2.1 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.

When an RFCOMM connection has been established, the Service Level Connection Initialization procedure shall be executed.

其中以上的意思大概就是：在建立HFP SLC之必须要有一个RFCOMM通道，也就是HFP的Server channel必须存在

你可能会问HFP的SLC是什么，拿SLC（Service Level Connection）就是一堆HFP HF角色跟AG角色的一些AT command的交互，这些AT command交互完毕才叫HFP SLC建立，SLC建立的流程如下：

下面我们就来分别介绍下小步骤（注意哈，虚线部分是可选步骤，在SLC建立的时候可以不做）：

2.1.1 Supported features exchange

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.

这个过程很简单充当HF角色首先要发送AT+BRSF=<HF supported features>，AG会回复+BRSF=<AG supported features>

BRSF (Bluetooth Retrieve Supported Features)，此命令就是用于HF和AG互相告知对方支持的特性，HF&AG的support feature都是一个32bit的数，HF的support feature的bit map为

其中bit7为V1.6才添加，bit 7,8,9是V1.7才添加，AG的support feature的bit map为：

其中bit9为V1.6才添加，bit10,11是V1.7才添加

2.1.2 Codec Negotiation（HFP V1.6增加的特性）

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 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 available codecs> command to the AG to notify the AG of the available codecs in the HF.

如果HF和AG都支持BRSF中的Codec negotiation，那么HF发送：

AT+BAC=<HF available codecs>

BAC(Bluetooth Available Codecs)

Description:

This command informs the remote device (AG) about what codecs (see Table 3.3) 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.

这个命令是HF告知AG，自己支持的codec,CVSD就是NBS（窄带通话，8KHz）的编解码方式，mSBC就是WBS(宽带电话，16KHz)的编解码方式,ID如下表所示

2.1.3 AG Indicators

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.

这部分有几个重点：

① 发送AT+CIND=?问询支持的indicators(包括service/call/callsetup/callheld/signal/ roam/ battchg)的index

AT+CIND=?是问询AG有多少indicators，并且自己解析每个indicators的index

如图所示：service的index是1，call的index是2，callsetup的index是3，battchg的index是4，signal的index是5，roam的index是6，callheld的index是7，后续AG更新过来+CIEV是通过这个index来决定他是跟的什么值

② 发送AT+CIND?问询各个indicators的status，此命令就是统一问下各个indicator的值，接着上图问询AT+CIND?

如图，service的值为1，call的值为0，callsetup的值为0, battchg的值为2, signal的值为3, roam的值为0, callheld的值为0，那么你一定会好奇各个value的值代表什么意思，下面我们就一一贴出

2.1.4 AT+CMER

发送AT+CMER enable各个indicators,发送这个后，如果某一个indicator有变化，那么AG就可以发送+CIEV来告知

AT+CMER 是Standard event reporting activation/deactivation AT command.说白了就是使能/失能 indicator，一共有两种格式

AT+CMER=3,0,0,1 activates “indicator events reporting”.

AT+CMER=3,0,0,0 deactivates “indicator events reporting”.

使能之后，AG可以发送+CIEV命令来汇报各个indicator的变化

先来看下+CIEV AT command

+CIEV:Standard “indicator events reporting” unsolicited result code.

格式为：+CIEV: <ind>,<value>，举例来说（此部分要根据CIND的index来角色，每个AG可能index不同，所以代码重要有解析index的动作，我这个index是根据2.1.3小节的index来讲解）

如果后续AG发送过来 +CIEV:1,x那么就是service有变化，值为x,

如果AG发送过来+CIEV:5,x那么就是signal有变化,值为x

再来个具体的例子，如图

这个就说明signal的值有变化，变成了4

2.1.5 AT+CHLD=? 三方通话功能

以上三个发送完毕后，如果HF&AG都支持三方通话，那么发送AT+CHLD=?

此部分是问询手机三方通话的支持的特性都有哪些，一共有以下几个特性

比如如图就是支持0,1,1x,2,2x,3,下面我们就来说下每个值得功能，这个功能是以后三方功能HF主动给AG下AT command用的

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>).

->挂断idx的通话中的电话

2 =Places all active calls (if any exist) on hold and accepts the other (held or waiting) call.

->把所有通话中的电话设置为hold状态，然后接听电话

2<idx> = Request private consultation mode with specified call (<idx>). (Place all calls on hold EXCEPT the call indicated by <idx>.)

->请求接受<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.

->连接两个电话并且断开两个电话的订阅。HF侧可选。

注意此部分，虽然手机都显示支持，但是部分cmd手机还是会返回error，尤其带有idx的cmd

2.1.6 HF Indicators（HFP V1.7增加的特性）

If the HF supports the HF indicator feature, it shall check the +BRSF response to see if the AG also supports the HF Indicator feature. If both the HF and AG support the HF Indicator feature, then the HF shall send the AT+BIND=<HF supported HF indicators> command to the AG to notify the AG of the supported indicators’ assigned numbers in the HF. The AG shall respond with OK. After having provided the AG with the HF indicators it supports, the HF shall send the AT+BIND=? to request HF indicators supported by the AG. The AG shall reply with the +BIND response listing all HF indicators that it supports followed by an OK.

Once the HF receives the supported HF indicators list from the AG, the HF shall send the AT+BIND? command to determine which HF indicators are enabled. The AG shall respond with one or more +BIND responses. The AG shall terminate the list with OK. From this point onwards, the HF may send the AT+BIEV command with the corresponding HF indicator value whenever a change in value occurs of an enabled HF indicator. The AG may enable or disable the notification of any HF indicator at any time by using the +BIND

unsolicited response.

这部分有几个重点：

① 如果HF & AG都支持HF Indicators的feature,那么HF发送AT+BIND=<HF supported HF indicators>来告知AG支持那些indicator

② 发送AT+BIND=?问询AG支持哪些indicator

③ 发送AT+BIND?问询AG哪些indicator是enable的

④ 发送AT+BIEV来使能某一个indicator

HFP的indicator一共有两个：

下面我们来看下我们抓取的btsnoop（在资料中STM32_UBUNTU_BLUETOOTH\2-蓝牙资料\蓝牙协议分析\hfp_slc连接.log）

整个流程如下：

我们生成一个流程图

这些图放在这里当作你们的参考

2.2 Service Level Connection Release

断开连接比较简单，就是断开RFCOMM link就OK了

好了，本节内容到此结束