藍(lán)牙的配對和連接的建立過程

藍(lán)牙的建立過程是一個(gè)復(fù)雜的過程，即使有過相當(dāng)一段工作和使用經(jīng)驗(yàn)的人，如果不仔細(xì)去了解還是理解不全。

平時(shí)我們用藍(lán)牙耳機(jī)聽音樂，和不同的設(shè)備共享文件，打電話等，都有一個(gè)配對--連接--傳輸數(shù)據(jù)的過程。

配對，其實(shí)就是一個(gè)認(rèn)證的過程。

?

1. 為什么不配對便無法建立連接？

任何無線通信技術(shù)都存在被監(jiān)聽和破解的可能，藍(lán)牙SIG為了保證藍(lán)牙通信的安全性，采用認(rèn)證的方式進(jìn)行數(shù)據(jù)交互。同時(shí)為了保證使用的方便性，以配對的形式完成兩個(gè)藍(lán)牙設(shè)備之間的首次通訊認(rèn)證，經(jīng)配對之后，隨后的通訊連接就不必每次都要做確認(rèn)。所以認(rèn)證碼的產(chǎn)生是從配對開始的，經(jīng)過配對，設(shè)備之間以PIN碼建立約定的link key用于產(chǎn)生初始認(rèn)證碼，以用于以后建立的連接。

所以不配對，兩個(gè)設(shè)備之間便無法建立認(rèn)證關(guān)系，無法進(jìn)行連接及其之后的作，所以配對在一定程度上保證了藍(lán)牙通信的安全，當(dāng)然這個(gè)安全保證機(jī)制是比較容易被破解的，因?yàn)楝F(xiàn)在很多個(gè)人設(shè)備沒有人機(jī)接口，所以PIN碼都是固定的而且大都設(shè)置為通用的0000或者1234之類的，所以很容易被猜到并進(jìn)而建立配對和連接。

?

2. 藍(lán)牙的連接過程

現(xiàn)在的藍(lán)牙芯片供應(yīng)商提供的技術(shù)支持能力相當(dāng)強(qiáng)大，有完整的硬件和軟件解決方案。對于應(yīng)用而言，提供了固件用于實(shí)現(xiàn)底層協(xié)議棧，提供了profile庫及源代碼規(guī)范了各種應(yīng)用，開發(fā)人員只要專注于應(yīng)用程序開發(fā)就可以了。對于藍(lán)牙底層的一些東西往往不甚了了。以前我也是這樣子的，最近在做一個(gè)自動(dòng)搜索以實(shí)現(xiàn)自動(dòng)連接的應(yīng)用，發(fā)現(xiàn)還是需要了解一些底層的機(jī)制的。 我們可以很容易的進(jìn)行作在一個(gè)手機(jī)和免提設(shè)備之間建立連接，那么這個(gè)連接是怎么建立起來的呢？ 首先，主設(shè)備（master,即發(fā)起連接的設(shè)備）會(huì)尋呼（page）從設(shè)備（slave,接收連接的設(shè)備），master會(huì)已跳頻的方式去尋呼slave,slave會(huì)固定間隔地去掃描（scan）外部尋呼，即page scan，當(dāng)scan 到外部page時(shí)便會(huì)響應(yīng)response該page,這樣兩個(gè)設(shè)備之間便會(huì)建立link的連接，即ACL鏈路的連接。當(dāng)ACL 鏈路連接建立后，主設(shè)備會(huì)發(fā)起channel的連接請求，即L2CAP的連接，建立L2CAP的連接之后，主設(shè)備采用SDP去查詢從設(shè)備的免提服務(wù)，從中得到rfcomm的通道號(hào)，然后主設(shè)備會(huì)發(fā)起rfcomm的連接請求建立rfcomm的連接。然后就建立了應(yīng)用的連接。 即link establish->channel establish->rfcomm establish->connection

?

3. 廣播數(shù)據(jù)分析

3.1. 發(fā)送廣播數(shù)據(jù)包的叫廣播發(fā)起者（advertisers），在廣播通道接收廣播數(shù)據(jù)包但沒意向連接廣播發(fā)起設(shè)備的叫掃描者（?scanners），?需要連接到另一個(gè)設(shè)備的設(shè)備叫做?initiators，它監(jiān)聽可連接的廣播數(shù)據(jù)包。如果advertiser正在使用一個(gè)可連接的廣播事件，?initiator在收到連接數(shù)據(jù)包的物理通道上發(fā)起一個(gè)連接請求，如果advertiser接受這個(gè)連接請求則這個(gè)廣播事件結(jié)束，并且開始一個(gè)新的連接事件。一旦連接建立，initiator成為主設(shè)備，advertiser成為從設(shè)備。連接事件被用于在主從設(shè)備之間傳輸數(shù)據(jù)包。 連接過程： 廣播者:廣播包使用ADV_IND PDU標(biāo)志； 掃描者：發(fā)送掃描請求(SCAN_REQ PDU)請求關(guān)于廣播者的信息一個(gè)SCAN_REQ PDU（包含了掃描者的設(shè)備地 址），?在同一信道上回復(fù)一個(gè)SCAN_RSP PDU； 發(fā)起者： 發(fā)起者發(fā)送連接請求（CONNECT_REQ PDU）請求進(jìn)入連接態(tài)，廣播者確認(rèn)即可以連接上。

????????SCAN_REQ_PDU載荷如下圖所示，由ScanA(掃描設(shè)備地址)和AdvA組成(廣播設(shè)備地址)，ScanA是掃描設(shè)備的公共或隨機(jī)地址(由TxAdd確定)，AdvA是廣播設(shè)備的公共或隨機(jī)地址(由RxAdd確定)。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖 -? 掃描請求PDU載荷

　　廣播報(bào)文的報(bào)頭中的TxAdd指示了掃描設(shè)備使用的是公共地址(Public Address)還是隨機(jī)地址(Random Address)。

TxAdd = 0：公共地址。 TxAdd = 1：隨機(jī)地址。 　　RxAdd指示了廣播設(shè)備使用的是公共地址(Public Address)還是隨機(jī)地址(Random Address)。

RxAdd = 0：公共地址。 RxAdd = 1：隨機(jī)地址。 3.2.?掃描響應(yīng)

　　SCAN_RSQ_PDU載荷如下圖所示，由AdvA(廣播設(shè)備地址)和ScanRspData組成(掃描響應(yīng)數(shù)據(jù))，AdvA是廣播設(shè)備的公共或隨機(jī)地址(由TxAdd確定)。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖 - 掃描響應(yīng)PDU載荷

　　廣播報(bào)文的報(bào)頭中的TxAdd指示了廣播設(shè)備使用的是公共地址(Public Address)還是隨機(jī)地址(Random Address)。

TxAdd = 0：公共地址。 TxAdd = 1：隨機(jī)地址。 　　廣播報(bào)文的長度域指示了載荷的字節(jié)數(shù)(AdvA和ScanRspData)。

3.3.?SCAN_REQ和SCAN_RSP解析

3.3.1. 捕獲SCAN_REQ

　　按照《藍(lán)牙4.0BLE抓包(一)》中的描述進(jìn)行抓包，下面是我們捕獲一個(gè)心率計(jì)的SCAN_REQ包。

???????????????????????????????????????????????????圖4：捕獲的SCAN_REQ包

3.3.2. 分析SCAN_REQ

　　為了方便分析，我們先取出這個(gè)SCAN_REQ包實(shí)際傳輸?shù)臄?shù)據(jù)，如圖3中所示。心率計(jì)完整的廣播報(bào)文如下：

　　D6 BE 89 8E?83?0C?7F 0F 72 DD DF 68?DA B5 E9 D2 CC F3?BD BF 27

　　在分析數(shù)據(jù)之前，再次說明：廣播包含掃描請求和掃描響應(yīng)，所以掃描請求和掃描響應(yīng)得包格式遵循廣播包的格式。

?????分析報(bào)文時(shí)，需要注意一下報(bào)文各個(gè)域的字節(jié)序。

3.3.2.1.?接入地址

　　D6 BE 89 8E：接入地址，對廣播來說是固定值。注意一下這里的字節(jié)序，接入地址傳輸時(shí)是低字節(jié)在前的。

3.3.2.2. PDU

????1).?83：廣播報(bào)文報(bào)頭。

bit0~bit3是0011，說明廣播類型是SCAN_REQ，即掃描請求。 bit7(RxAdd)是1：說明廣播設(shè)備使用的是隨機(jī)地址。 bit6(TxAdd)是0：說明掃描設(shè)備使用的是公共地址。 ????2).?0C：長度，表示SCAN_REQ報(bào)文的長度是12個(gè)字節(jié)。

????3).?7F?0F 72 DD DF 68：掃描設(shè)備的公共地址(報(bào)頭里的TxAdd指示了這個(gè)地址是公共地址)。這里使用的實(shí)驗(yàn)設(shè)備是[艾克姆科技]的EN-nRF51DK開發(fā)板和小米3手機(jī)，掃描設(shè)備是小米3手機(jī)，在圖3中可以看到該公共地址對應(yīng)的是Xiao_mico_72。

????4).?DA B5 E9 D2 CC F3：廣播設(shè)備的地址(報(bào)頭里的RxAdd指示了這個(gè)地址是隨機(jī)地址)。

3.3.2.3. 校驗(yàn)?

???BD BF 27：24字節(jié)CRC校驗(yàn)。

3.3.3. 捕獲SCAN_RSP

　　按照《藍(lán)牙4.0BLE抓包(一)》中的描述進(jìn)行抓包，捕獲一個(gè)心率計(jì)的SCAN_REQ包。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?圖 - 捕獲的SCAN_RSP包

3.3.4. 分析SCAN_RSP

　　同樣，在這里我們先取出SCAN_REQ包的數(shù)據(jù)，便于分析。

　　D6 BE 89 8E?44?06?DA B5 E9 D2 CC F3?61 6A 0F

3.3.4.1 接入地址

　　D6 BE 89 8E：接入地址，對廣播來說是固定值。注意一下這里的字節(jié)序，接入地址傳輸時(shí)是低字節(jié)在前的。

3.3.4.2 PDU

????1).?44：廣播報(bào)文報(bào)頭。

bit0~bit3是0100，說明廣播類型是SCAN_RSP，即掃描響應(yīng)。 bit6(TxAdd)是1：說明廣播設(shè)備使用的是隨機(jī)地址。 ????2).?06：長度，表示SCAN_ RSP報(bào)文的長度是6個(gè)字節(jié)。

????3).?DA B5 E9 D2 CC F3：廣播設(shè)備的地址(報(bào)頭里的RxAdd指示了這個(gè)地址是隨機(jī)地址)。

3.3.4.3 校驗(yàn)?

???61 6A 0F：24字節(jié)CRC校驗(yàn)。

3.4.連接請求CONNECT_REQ

在低功耗藍(lán)牙技術(shù)建立連接的過程中，設(shè)備都是成對出現(xiàn)的：master和slave設(shè)備。如果master希望與slave建立連接，master就需要發(fā)起連接請求（ConnectionRequest，CONNECT_REQ）因此master可以稱之為連接發(fā)起者；同時(shí)，slave必須是可連接的并且具有解析連接請求CONNECT_REQ的能力，slave可以稱之為廣播者。圖1是連接請求CONNECT_REQ的幀結(jié)構(gòu)。

圖1 CONNECT_REQ幀結(jié)構(gòu)

其中，InitA是連接發(fā)起者的藍(lán)牙設(shè)備地址，長度為6字節(jié)；AdvA是廣播者的藍(lán)牙設(shè)備地址，長度為6字節(jié)。除了InitA和AdvA之外，幀格式中最為重要的部分則是LLData，這一部分包含了在連接建立過程中所需要使用的有意義的參數(shù)。

為了更好的理解連接請求CONNECT_REQ，我們可以在日常生活中找到類似的一個(gè)例子，幫助我們理解它的含義。讀者們很多應(yīng)該都有過工作經(jīng)驗(yàn)，在開始新的工作之前，都需要和雇主簽署一份勞動(dòng)合同，而CONNECT_REQ就是一份由“雇主”master提供的“勞動(dòng)合同”，只需經(jīng)過“雇員”slave確認(rèn)，這份“合同”就開始生效，低功耗藍(lán)牙技術(shù)的連接也就建立了。接下來我們就對“合同”中的各項(xiàng)條款逐條進(jìn)行分析（如圖2所示）。

圖2 LLData示意圖

（1）接入地址（AA：Access Address）

這份合同的第一條款就是為雇員分配一個(gè)公司內(nèi)部的唯一識(shí)別碼，類似于工號(hào)，雇員可以在公司內(nèi)部使用這一工號(hào)；當(dāng)雇員離開公司之后，唯一識(shí)別碼自動(dòng)失效；即使是這一雇員再次加入到這家公司，他/她的新工號(hào)也與舊的工號(hào)不同。類似的，在兩個(gè)低功耗藍(lán)牙技術(shù)設(shè)備建立連接之前，master設(shè)備負(fù)責(zé)生成接入地址，這一地址類似于一個(gè)4字節(jié)的隨機(jī)數(shù)，當(dāng)連接建立之后，master和slave都使用這一接入地址進(jìn)行通信；當(dāng)連接斷開之后，接入地址自動(dòng)失效。

（2）CRCInit（CRC初始值）

這份“合同”的第二條款是CRCInit，它就是雇員在公司內(nèi)部的一個(gè)密鑰，通過這個(gè)密鑰，雇員可以訪問公司內(nèi)部的資源。對于低功耗藍(lán)牙技術(shù)設(shè)備，master和slave使用CRCIinit來驗(yàn)證數(shù)據(jù)包的完整性。

（3）WinSize和WinOffset

合同的第三條款中規(guī)范了雇員首次來公司報(bào)到的時(shí)間以及今后每次工作的時(shí)長。WinSize和WinOffset在低功耗藍(lán)牙技術(shù)連接中，也做了類似的定義。WinOffset定義了在CONNECT_REQ命令之后的一個(gè)通信窗口的偏移量，如圖3所示。在slave設(shè)備收到CONNECT_REQ之后，slave設(shè)備需要占用一些時(shí)間、根據(jù)LLData參數(shù)進(jìn)行一些相關(guān)的配置，因此，WinOffeset為slave設(shè)備進(jìn)行此種作提供了時(shí)間，transmitWindowOffset= WinOffset×1.25 ms。WinSize定義了設(shè)備每次開啟收發(fā)機(jī)的窗口時(shí)間，無論是master還是slave，它們都遵循WinSize的定義，窗口時(shí)間transmitWindowSize=WinSize×1.25 ms。

因此，在CONNECT_REQ之后，第一個(gè)由master發(fā)送到slave的數(shù)據(jù)幀，我們稱之為“錨點(diǎn)”（如圖3所示），因?yàn)橹蟮乃械倪B接事件都以這一時(shí)刻為基準(zhǔn)，呈現(xiàn)周期性變化。從紅色框圖中我們可以看到，第一個(gè)數(shù)據(jù)幀的時(shí)刻不能早于（1.25ms+transmitWindowOffset），同時(shí)也不能晚于（1.25 ms + transmitWindowOffset + transmitWindowSize）。

圖3 發(fā)起連接時(shí)序圖

（4）Interval， Latency & Timeout

一般情況下，人們的工作時(shí)間是朝九晚五，一周工作五天。但是在低功耗藍(lán)牙技術(shù)的連接機(jī)制當(dāng)中，我們采用了更加靈活的“彈性工作制”。對于低功耗藍(lán)牙技術(shù)連接的彈性工作制，這里有三個(gè)參數(shù)需要了解，Interval，Lantency和Timeout。

圖4 連接事件時(shí)序圖

在連接建立之后，master和slave之間的數(shù)據(jù)交互我們可以稱之為連接事件，連接事件的發(fā)生周期（connInterval）則是由Interval參數(shù)來進(jìn)行設(shè)定，connInterval= Interval×1.25 ms， connInterval的取值范圍則是在7.5 ms至4 s秒之間。因此，在確定了錨點(diǎn)之后，master和slave將按照connInterval確定的時(shí)間間隔進(jìn)行數(shù)據(jù)的交互，如圖4所示。

但是，對于低功耗藍(lán)牙技術(shù)，低功耗的特性是需要特別考慮的，而且在實(shí)際的應(yīng)用當(dāng)中，不需要在每次connInterval都產(chǎn)生連接事件，因此引入了參數(shù)Lantancy，可以有效的減少連接事件的產(chǎn)生，connSlaveLatency= Latency。connSlaveLatency 定義了slave設(shè)備可以忽略多少個(gè)連續(xù)的連接事件，其不需要在這些被忽略的連接事件中偵聽來自master的數(shù)據(jù)包，這也意味著slave設(shè)備不需要在每個(gè)連接事件產(chǎn)生的時(shí)刻都喚醒并打開射頻接收機(jī)進(jìn)行偵聽，所以可以有效減少slave設(shè)備的功耗。這也是低功耗藍(lán)牙技術(shù)能夠?qū)崿F(xiàn)其低功耗特性的一個(gè)重要的原因。

Timeout參數(shù)定義了連接超時(shí)的長度，connSupervisionTimeout= Timeout×10 ms，其取值范圍在100 ms至32 s之間。不論是master還是slave，在其收到一個(gè)數(shù)據(jù)幀之后，如果等待了connSupervisionTimeout時(shí)長都沒有下一個(gè)數(shù)據(jù)幀到來，則可以認(rèn)為連接已經(jīng)斷開。在這里要強(qiáng)調(diào)的是，connSupervisionTimeout必須大于（1 + connSlaveLatency） × connInterval × 2，否則，slave設(shè)備即使是在Lantency狀態(tài)，也會(huì)被誤認(rèn)為是連接超時(shí)，導(dǎo)致連接誤斷開。

（5）ChM & Hop

我們都知道，藍(lán)牙使用的是跳頻技術(shù)，當(dāng)連接建立之后，master和slave設(shè)備就需要利用某種機(jī)制來在預(yù)先設(shè)定的信道圖譜上、按照預(yù)先設(shè)定的跳頻跨度進(jìn)行跳頻工作，信道圖譜就來自ChM參數(shù)，每跳的跨度則來自于Hop參數(shù)。Hop是一個(gè)整數(shù)，取值范圍在5至16之間。下面的公式提供了跳頻的工作方式：

———————————————— 版權(quán)聲明：本文為CSDN博主「偏執(zhí)灬」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。 原文鏈接：https://blog.csdn.net/sinat_23338865/article/details/52189538