同一款手機，為什么跟某些設備可以連接成功，而跟另外一些設備又連接不成功？同一個設備，為什么跟某些手機可以建立連接，而跟另外一些手機又無法建立連接？同一個手機，同一個設備，為什么他們兩者有時候連起來很快，有時候連起來又很慢？Master是什么？slave又是什么？什么又是Connection event和slave latency？希望這篇文章能幫助你回答上述問題。

Bluetooth LE連接示例

假設我們有一臺手機A（以安卓手機為例），一個設備B（設備名稱：Nordic_HRM），如下所示，我們可以通過安卓設置菜單里面的藍牙界面，讓兩者連接起來。

打開安卓設置菜單

選擇“藍牙”條目

打開藍牙

等待系統搜索結果，不出意外的話，設備“Nordic_HRM”會出現在結果列表中

點擊“Nordic_HRM”，手機將與此設備建立連接

圖1

上述即為大家直觀感受到的“連接”，那么手機要與設備Nordic_HRM建立連接，具體包含哪些流程？他們為什么可以連接成功？下面給大家一一道來。

廣播（advertising）

在手機A(Observer)跟設備B建立連接之前，設備B需要先進行廣播，即設備B（Advertiser）不斷發送如下廣播信號，t為廣播間隔。每發送一次廣播包，我們稱其為一次廣播事件（advertising event），因此t也稱為廣播事件間隔。雖然圖中廣播事件是用一根線來表示的，但實際上廣播事件是有一個持續時間的，藍牙芯片只有在廣播事件期間才打開射頻模塊，這個時候功耗比較高，其余時間藍牙芯片都處于idle狀態，因此平均功耗非常低，以Nordic nRF52810為例，每1秒鐘發一次廣播，平均功耗不到11uA。

圖2

上面只是一個概略圖，按照藍牙spec，實際上每一個廣播事件包含三個廣播包，即分別在37/38/39三個射頻通道上同時廣播相同的信息，即真正的廣播事件是下面這個樣子的。

圖3

設備B不斷發送廣播信號給手機（Observer），如果手機不開啟掃描窗口，手機是收不到設備B的廣播的，如下圖所示，不僅手機要開啟射頻接收窗口，而且只有手機的射頻接收窗口跟廣播發送的發射窗口匹配成功，而且廣播射頻通道和手機掃描射頻通道是同一個通道，手機才能收到設備B的廣播信號。也就是說，如果設備B在37通道發送廣播包，而手機在掃描38通道，那么即使他們倆的射頻窗口匹配，兩者也是無法進行通信的。由于這種匹配成功是一個概率事件，因此手機掃到設備B也是一個概率事件，也就是說，手機有時會很快掃到設備B，比如只需要一個廣播事件，手機有時又會很慢才能掃到設備B，比如需要10個廣播事件甚至更多。

圖4

建立連接（connection establishment）

根據藍牙spec規定，advertiser發送完一個廣播包之后150us（T_IFS），advertiser必須開啟一段時間的射頻Rx窗口，以接收來自observer的數據包。Observer就可以在這段時間里給advertiser發送連接請求。如下圖所示，手機在第三個廣播事件的時候掃到了設備B，并發出了連接請求CONN_REQ(CONN_REQ又稱為CONNECT_IND)。

圖5

上圖的交互流程比較粗略，為此我們引入下圖，以詳細描述連接建立過程。

圖6：連接建立過程

注：圖中M代表手機，S代表設備B，M->S表示手機將數據包發給設備B，即手機開啟Tx窗口，設備B開啟Rx窗口；S->M正好相反，表示設備B將數據包發給手機，即設備B開啟Tx窗口，手機開啟Rx窗口。

如圖所示，手機在收到A1廣播包ADV_IND后，以此為初始錨點（這個錨點不是連接的錨點），T_IFS時間后給Advertiser發送一個connection request命令，即A2數據包，告訴advertiser我將要過來連你，請做好準備。Advertiser根據connect_req命令信息做好接收準備，connect_req包含如下關鍵信息：

Transmit window offset，定義如圖6所示

Transmit window size，定義如圖6所示

connect_req數據包完整定義如下所示

圖7

connect_req其實是在告訴advertiser，手機將在Transmit Window期間發送第一個同步包（P1）給你，請在這段時間里把你的射頻接收窗口打開。設備B收到P1后，T_IFS時間后將給手機回復數據包P2（ACK包）。一旦手機收到數據包P2，連接即可認為建立成功。當然，實際情況會比較復雜，手機有可能收不到P2，這個時候手機將持續發送同步包直到超時時間（supervision timeout）到，在此期間只要設備B回過一次ACK包，連接即算成功。所以一旦P1包發出，主機（手機）即認為連接成功，而不管有沒有收到設備的ACK包。這也是為什么在Android或者iOS系統中，應用經常收到連接成功的回調事件（該回調事件就是基于P1包有沒有發出，只要P1包發出，手機即認為連接成功，而不管有沒有收到設備的ACK包），但實際上手機和設備并沒有成功建立連接。后續手機將以P1為錨點（原點），Connection Interval為周期，周期性地給設備B發送數據包（Packet），Packet除了充當數據傳送功能，它還有如下兩個非常重要的功能：

同步手機和設備的時鐘，也就是說，設備每收到手機發來的一個包，都會把自己的時序原點重新設置，以跟手機同步。

告訴設備你現在可以傳數據給我了。連接成功后，Bluetooth LE通信將變成主從模式，因此把連接發起者（手機）稱為Master或者Central，把被連接者（之前的Advertiser）稱為Slave或者Peripheral。Bluetooth LE通信之所以為主從模式，是因為Slave不能“隨性”給Master發信息，它只有等到Master給它發了一個packet后，然后才能在規定的時間把自己的數據回傳給Master。

連接失敗

有如下幾種典型的連接失敗情況：

如圖5所示，如果slave在transmit window期間沒有收到master發過來的P1，那么連接將會失敗。此時應該排查master那邊的問題，看看master為什么沒有在約定的時間把P1發出來。

如果master在transmit window期間把P1發出來了，也就是說master按照connect_req約定的時序把P1發出來了，但slave沒有把P2回過去或者沒有在超時時間內把P2回過去，那么連接也會失敗。此時應該排查slave這邊的問題，看一看slave為什么沒有把P2回過去

如果master把P1發出來了，slave也把P2回過去了，此時主機或者從機還是報連接失敗，這種情況有可能是軟件有問題，需要仔細排查master或者slave的軟件。

還有一種比較常見的連接失敗情況：空中射頻干擾太大。此時應該找一個干凈的環境，比如屏蔽室，排除干擾后再去測試連接是否正常。

Connection events

連接成功后，master和slave在每一個connection interval開始的時候，都必須交互一次，即master給slave發一個包，slave再給master發一個包，整個交互過程稱為一個connection event或者gap event。藍牙芯片只有在connection event期間才把射頻模塊打開，此時功耗比較高，其余時間藍牙芯片都是處于idle狀態的，因此藍牙芯片平均功耗就非常低，以Nordic nRF52810為例，每1秒鐘Master和Slave通信1次，平均功耗約為6微安左右。Master不可能時時刻刻都有數據發給slave，所以master大部分時候都是發的空包（empty packet）給slave。同樣slave也不是時時刻刻都有數據給master，因此slave回復給master的包大部分時候也是空包。另外在一個connection event期間，master也可以發多個包給slave，以提高吞吐率。綜上所述，連接成功后的通信時序圖應該如下所示：

圖8：連接成功后的通信時序圖（每個connection event只發一個包）

圖9：連接成功后的通信時序圖（ connection event可能發多個包）

圖10：connection event細節圖

Slave latency

圖10中出現了slave latency（slave latency = 1），那么什么叫slave latency？

如前所述，在每一個connection interval開始的時候，Master和Slave必須交互一次，哪怕兩者之間交互的是empty packet（空包），但如果slave定義了slave latency，比如slave latency = 9，此時slave可以每9個connection interval才回復一次master，也就是說slave可以在前面8個connection interval期間一直睡眠，直到第9個connection interval到來之后，才回復一個packet給master，這樣將大大節省slave的功耗，提高電池續航時間。當然如果slave有數據需要上報給master，它也可以不等到第9個connection interval才上報，直接像正常情況進行傳輸即可，這樣既節省了功耗，又提高了數據傳輸的實時性。

GAP層角色總結

對上面提到的手機和設備B，在Bluetooth LE通信過程中，隨著時間的推移，他們的狀態在發生變化，兩者的關系也在發生變化，為此藍牙spec根據不同的時間段或者狀態給手機和設備B取不同的名字，即GAP層定義了如下角色：

advertiser。 發出廣播的設備

observer或者scanner。可以掃描廣播的設備

initiator。能發起連接的設備

master或者central。連接成功后的主設備，即主動發起packet的設備

slave或者peripheral。連接成功后的從設備，即被動回傳packet的設備

圖通過時間把observer，initiator和central串起來了，其實這三個角色是相互獨立的，也就是說一個設備可以只支持observer角色，而不支持initiator和central角色。同樣，下圖也把advertiser和peripheral串起來了，其實advertiser和peripheral也是相互獨立的，即一個設備可以只作為advertiser角色，而不支持peripheral角色。

圖11：GAP層角色

審核編輯 黃宇