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

Bluetooth LE連接示例

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

打開安卓設(shè)置菜單

選擇“藍(lán)牙”條目

打開藍(lán)牙

等待系統(tǒng)搜索結(jié)果，不出意外的話，設(shè)備“Nordic_HRM”會(huì)出現(xiàn)在結(jié)果列表中

點(diǎn)擊“Nordic_HRM”，手機(jī)將與此設(shè)備建立連接

圖1

上述即為大家直觀感受到的“連接”，那么手機(jī)要與設(shè)備Nordic_HRM建立連接，具體包含哪些流程？他們?yōu)槭裁纯梢赃B接成功？下面給大家一一道來。

廣播（advertising）

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

圖2

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

圖3

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

圖4

建立連接（connection establishment）

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

圖5

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

圖6：連接建立過程

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

如圖所示，手機(jī)在收到A1廣播包ADV_IND后，以此為初始錨點(diǎn)（這個(gè)錨點(diǎn)不是連接的錨點(diǎn)），T_IFS時(shí)間后給Advertiser發(fā)送一個(gè)connection request命令，即A2數(shù)據(jù)包，告訴advertiser我將要過來連你，請(qǐng)做好準(zhǔn)備。Advertiser根據(jù)connect_req命令信息做好接收準(zhǔn)備，connect_req包含如下關(guān)鍵信息：

Transmit window offset，定義如圖6所示

Transmit window size，定義如圖6所示

connect_req數(shù)據(jù)包完整定義如下所示

圖7

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

同步手機(jī)和設(shè)備的時(shí)鐘，也就是說，設(shè)備每收到手機(jī)發(fā)來的一個(gè)包，都會(huì)把自己的時(shí)序原點(diǎn)重新設(shè)置，以跟手機(jī)同步。

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

連接失敗

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

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

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

如果master把P1發(fā)出來了，slave也把P2回過去了，此時(shí)主機(jī)或者從機(jī)還是報(bào)連接失敗，這種情況有可能是軟件有問題，需要仔細(xì)排查master或者slave的軟件。

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

Connection events

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

圖8：連接成功后的通信時(shí)序圖（每個(gè)connection event只發(fā)一個(gè)包）

圖9：連接成功后的通信時(shí)序圖（ connection event可能發(fā)多個(gè)包）

圖10：connection event細(xì)節(jié)圖

Slave latency

圖10中出現(xiàn)了slave latency（slave latency = 1），那么什么叫slave latency？

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

GAP層角色總結(jié)

對(duì)上面提到的手機(jī)和設(shè)備B，在Bluetooth LE通信過程中，隨著時(shí)間的推移，他們的狀態(tài)在發(fā)生變化，兩者的關(guān)系也在發(fā)生變化，為此藍(lán)牙spec根據(jù)不同的時(shí)間段或者狀態(tài)給手機(jī)和設(shè)備B取不同的名字，即GAP層定義了如下角色：

advertiser。 發(fā)出廣播的設(shè)備

observer或者scanner。可以掃描廣播的設(shè)備

initiator。能發(fā)起連接的設(shè)備

master或者central。連接成功后的主設(shè)備，即主動(dòng)發(fā)起packet的設(shè)備

slave或者peripheral。連接成功后的從設(shè)備，即被動(dòng)回傳packet的設(shè)備

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

圖11：GAP層角色

審核編輯 黃宇