實(shí)戰經(jīng)驗 | 關(guān)于連接參數更新進(jìn)程后導致斷連的問(wèn)題分析

01 引言

通?？蛻?hù)在做低功耗藍牙模塊設計的時(shí)候，如果藍牙模塊在實(shí)際使用場(chǎng)景中和手持移動(dòng)設備(如手機等)綁定使用的話(huà)，往往會(huì )非常注意藍牙模塊與不同品牌、不同型號的手機的兼容性測試。這些測試項目可能包括長(cháng)時(shí)間連接狀態(tài)的保持，頻繁建立連接，或主動(dòng)斷連后再次建立連接等場(chǎng)景。本文描述的問(wèn)題是客戶(hù)在其兼容性測試中發(fā)現的一個(gè)比較典型的問(wèn)題，即當從設備在與手機端處于連接狀態(tài)下，從設備啟動(dòng)連接參數更新進(jìn)程后，會(huì )導致斷連的問(wèn)題。由于是兼容性測試，測試設備，特別是作為主設備的手機來(lái)自不同的供應商，在兼容低功耗藍牙協(xié)議的基礎上，某些細節部分的差異難以避免。所以，本文只論述了該客戶(hù)問(wèn)題的分析過(guò)程及得出的結果，并不期望涵蓋所有類(lèi)似場(chǎng)景下導致斷連的原因。

02 連接參數更新進(jìn)程簡(jiǎn)述

低功耗藍牙的核心規范中有規定，當主從設備建立連接后，可以通過(guò)啟動(dòng)特定的進(jìn)程改變當前連接的相關(guān)參數，如連接間隔(ConnInterval)，從設備延遲(SlaveLatency)和監控超時(shí)(SupervisionTimeout)等。 

低功耗藍牙的核心規范中定義了幾個(gè)不同的連接參數更新流程，有的流程主設備和從設備都可以啟動(dòng)，有的流程只能由從設備或主設備啟動(dòng)。為避免引入過(guò)多對本文關(guān)注話(huà)題的無(wú)用信息，我們在這里只介紹一種由從設備啟動(dòng)的連接參數更新的流程。即由從設備通過(guò)調用L2CAP 層的命令的方式啟動(dòng)的連接參數更新流程。 

流程圖如圖 1 所示。流程圖的前提條件是主從設備端之間已建立連接，從設備希望改變當前已建立連接的連接參數。 

整個(gè)流程的步驟解析如下： 

第一步：從設備發(fā)起 Connection Parameter Update Request，提交新的連接參數給主設備，希望主設備可以采用這些參數。主設備接收到從設備的 Request 后，會(huì )根據自身當前條件(是否能支持這些連接參數)決定是否接受請求。如果接受，則執行第二步；如不接受，則直接跳到第四步拒絕該 Request。 

第二步：主設備接受請求，給從設備發(fā)送鏈路層數據包LL_CONNECTION_UPDATE_REQ，該數據包中包含了主設備在分析了從設備在第一步中提交連接參數后，決定最終使用的目標連接參數，并約定在后續的特定連接事件開(kāi)始使用新的連接參數。 

第三步：從設備在接收到 LL_CONNECTION_UPDATE_REQ 數據包后發(fā)送一個(gè)鏈路層的空包作為響應，并結束當前連接事件。 

第四步：主設備發(fā)送 L2CAP 層的 Connection Parameter Update Response 命令，作為對第一步中 Request 命令的回復，回復中的相關(guān)標志標明是接受(Accept)還是拒絕(Reject)之前的 Request 命令。如果是接受，則主從設備雙方會(huì )在第二步中LL_CONNECTION_UPDATE_REQ 數據包中所指定的后續特定連接事件中開(kāi)始使用新的連接參數，并成功完成連接參數更新過(guò)程。

圖1.連接參數更新流程

03 客戶(hù)可能的測試邏輯和問(wèn)題現象描述

客戶(hù)使用智能手機和 ST 的 BlueNRG LP 作為測試的主從設備?？蛻?hù)的兼容性測試中需要使用預設連接間隔和監控超時(shí)時(shí)間。為了在測試過(guò)程中可以實(shí)時(shí)調整相關(guān)參數，需要手機端作為主設備通過(guò)私有邏輯將新的連接參數通過(guò)低功耗藍牙連接發(fā)送給從設備( BlueNRGLP ), 并由從設備啟動(dòng)上述的更新流程，以完成連接參數的更新并繼續執行后續的其他測試項。 

問(wèn)題現象： 

主從設備在完成上述流程第四步后，且主設備發(fā)送 Connection Parameter UpdateResponse 命令所給出的響應也是接受的情況下，主從設備在上述流程中第二步LL_CONNECTION_UPDATE_REQ 命令所指定的特定連接事件中開(kāi)始采用新的連接參數時(shí)會(huì )發(fā)生斷連。從設備重新進(jìn)入廣播狀態(tài)。 

客戶(hù)的疑惑點(diǎn)在于主從設備已經(jīng)完成了上述連接參數更新的交互，意味著(zhù)應該可以順利切換到新的連接參數，沒(méi)有道理會(huì )導致后續的斷連，由于作為主設備的智能手機是某大品牌產(chǎn)品，懷疑 BlueNRG 的協(xié)議棧是否存在兼容性問(wèn)題。

04 問(wèn)題分析

根據問(wèn)題復現時(shí)使用低功耗藍牙抓包工具所抓取的 log 數據，做如下分析。

4.1.分析 LL_CONNECTION_UPDATE_REQ 數據包內容

4.1.1. 如圖 2 所示，LL_CONNECTION_UPDATE_REQ 數據包內容，需要重點(diǎn)關(guān)注如下數據：

1. Event counter：29， 表示 LL_CONNECTION_UPDATE_REQ 發(fā)送時(shí)所在的連接事件編號為 29。

2. Instant：35：約定在第 35 個(gè)連接事件中，主從設備開(kāi)始使用新的連接參數。

3. Interval：816(1020msec), 表示新的連接間隔為 1.02 秒。

4. Window Size/Window Offset：第 35 個(gè)連接事件中，主從設備開(kāi)始使用新的連接參數進(jìn)行第一次數據包交互時(shí)，接收、發(fā)送窗口的定時(shí)信息。

圖2.LL_CONNECTION_UPDATE_REQ PDU 抓包數據

4.1.2. 從下圖 3 中獲取從連接事件 29 到從設備進(jìn)入廣播狀態(tài)這個(gè)過(guò)程中每個(gè)連接事件及連接時(shí)間中數據包收發(fā)的時(shí)間戳。

圖3.時(shí)間戳

從圖 3 中可以看出：

1.從連接事件 29 到連接事件 34，連接間隔為 30ms，即舊的連接間隔。

2. 連接事件 35 中主設備的發(fā)包時(shí)間和連接事件 34 的開(kāi)始時(shí)間差大大超過(guò) 30ms，所以可以再次確認是在連接事件 35，主從設備開(kāi)始使用新的連接參數。

3. 從連接事件 35 開(kāi)始及后續的 3 個(gè)連接事件中，只有主設備發(fā)送空包，從設備沒(méi)有發(fā)送空包。

4. 由于新的連接參數的監控超時(shí)時(shí)間在客戶(hù)的測試中為 4 秒，所以從設備沒(méi)有發(fā)送空包的 4 個(gè)連接事件結束后，即發(fā)送了斷連。然后，從設備重新開(kāi)始發(fā)送廣播包。

4.1.3. 如下圖 4，通過(guò)分析抓包 LOG 中各個(gè)連接事件、即數據包發(fā)送的時(shí)間戳后發(fā)現：

1.通過(guò) LL_CONNECTION_UPDATE_REQ 數據包中 transmitWindowOffset 計算出TransmitWindow 的開(kāi)始時(shí)間點(diǎn)應該在 11.477925s

2. 從抓包的 log 信息中發(fā)現，主設備實(shí)際的發(fā)包時(shí)間點(diǎn)在 11.477909s，也就是主設備的發(fā)包時(shí)間先于藍牙協(xié)議中規定的 TransmitWindow 的起始點(diǎn)，導致從設備無(wú)法接收到來(lái)自主設備的空包，從而無(wú)法在同一連接事件(連接事件 35 及后續的 3 個(gè)連接事件)中反饋一個(gè)空包，進(jìn)而導致 4 秒監控超時(shí)，最終導致斷連。從設備退出連接態(tài)后重新進(jìn)入廣播態(tài)。

圖4.連接事件即數據包發(fā)送時(shí)間分析

05 小結

上述問(wèn)題的根本原因是作為主設備的智能手機雖然完成了連接參數更新流程中主從設備之間的交互，但由于其在后續規劃的連接事件，規劃的射頻任務(wù)的時(shí)間點(diǎn)的偏差而導致了斷連。

導致低功耗藍牙斷連的可能原因有很多，上述的情況只是其中一種。本文的意圖是介紹上述問(wèn)題的分析過(guò)程，讀者可以參照本文展現的分析方法、將其運用到類(lèi)似問(wèn)題的解決過(guò)程中。

通過(guò)對抓包 LOG 中的時(shí)間戳的分析，有很大機會(huì )可以幫助找到解決問(wèn)題的突破口。