詳解BLE連接建立過程


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

BLE連接示例

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

  1. 打開安卓設置菜單
  2. 選擇“藍牙”條目
  3. 打開藍牙
  4. 等待系統搜索結果,不出意外的話,設備“Nordic_HRM”會出現在結果列表中
  5. 點擊“Nordic_HRM”,手機將與此設備建立連接

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

廣播(advertising)

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

 

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

 

設備B不斷發送廣播信號給手機(Observer),如果手機不開啟掃描窗口,手機是收不到設備B的廣播的,如下圖所示,不僅手機要開啟射頻接收窗口,而且只有手機的射頻接收窗口跟廣播發送的發射窗口匹配成功,手機才能收到設備B的廣播信號。由於這種匹配成功是一個概率事件,因此手機掃到設備B也是一個概率事件,也就是說,手機有時會很快掃到設備B,比如只需要一個廣播事件,手機有時又會很慢才能掃到設備B,比如需要10個廣播事件甚至更多。

 

 

建立連接(connection)

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

 

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

圖5:連接建立過程

注:圖中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,定義如圖5所示
  • Transmit window size,定義如圖5所示
  • connect_req數據包完整定義如下所示  

connect_req其實是在告訴advertiser,手機將在Transmit Window期間發送第一個同步包(P1)給你,請在這段時間里把你的射頻接收窗口打開。設備B收到P1后,T_IFS時間后將給手機回復數據包P2。一旦手機收到數據包P2,連接即可認為建立成功。后續手機將以P1為錨點(原點),Connection Interval為周期,周期性地給設備B發送Packet,Packet除了充當數據傳送功能,它還有如下兩個非常重要的功能:

  1. 同步手機和設備的時鍾,也就是說,設備每收到手機發來的一個包,都會把自己的時序原點重新設置,以跟手機同步。
  2. 告訴設備你現在可以傳數據給我了。連接成功后,BLE通信將變成主從模式,因此把連接發起者(手機)稱為Master或者Central,把被連接者(之前的Advertiser)稱為Slave或者Peripheral。BLE通信之所以為主從模式,是因為Slave不能“隨性”給Master發信息,它只有等到Master給它發了一個packet后,然后才能把自己的數據回傳給Master。

連接失敗

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

  1. 如圖5所示,如果slave在transmit window期間沒有收到master發過來的P1,那么連接將會失敗。此時應該排查master那邊的問題,看看master為什么沒有在約定的時間把P1發出來。
  2. 如果master在transmit window期間把P1發出來了,也就是說master按照connect_req約定的時序把P1發出來了,但slave沒有把P2回過去,那么連接也會失敗。此時應該排查slave這邊的問題,看一看slave為什么沒有把P2回過去
  3. 如果master把P1發出來了,slave也把P2回過去了,此時主機還是報連接失敗,這種情況有可能是master軟件有問題,需要仔細排查master的軟件。
  4. 還有一種比較常見的連接失敗情況:空中射頻干擾太大。此時應該找一個干凈的環境,比如屏蔽室,排除干擾后再去測試連接是否正常。

Connection events

連接成功后,master和slave在每一個connection interval開始的時候,都必須交互一次,即master給slave發一個包,slave再給master發一個包,整個交互過程稱為一個connection 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,以提高吞吐率。綜上所述,連接成功后的通信時序圖應該如下所示:

 

圖7: 連接成功后的通信時序圖(每個connection event只發一個包)

圖9: 連接成功后的通信時序圖( connection event可能發多個包)

 

圖10:connection event細節圖

Slave latency

圖10中出現了slave latency(slave latency = 2),那么什么叫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,在BLE通信過程中,隨着時間的推移,他們的狀態在發生變化,兩者的關系也在發生變化,為此藍牙spec根據不同的時間段或者狀態給手機和設備B取不同的名字,即GAP層定義了如下角色:

  • advertiser。 發出廣播的設備
  • observer或者scanner。可以掃描廣播的設備
  • initiator。能發起連接的設備
  • master或者central。連接成功后的主設備,即主動發起packet的設備
  • slave或者peripheral。連接成功后的從設備,即被動回傳packet的設備

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

圖11:GAP層角色

 


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com