零. 概述

本文章主要講下電話免提協議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一共有兩個：