實戰經驗|關于連接參數更新進程后導致斷連的問題分析

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

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

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

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

整個流程的步驟解析如下：?

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

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

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

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

圖1.連接參數更新流程

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

問題現象：?

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

客戶的疑惑點在于主從設備已經完成了上述連接參數更新的交互，意味著應該可以順利切換到新的連接參數，沒有道理會導致后續的斷連，由于作為主設備的智能手機是某大品牌產品，懷疑 BlueNRG 的協議棧是否存在兼容性問題。

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

4.1.分析 LL_CONNECTION_UPDATE_REQ 數據包內容

4.1.1. 如圖 2 所示，LL_CONNECTION_UPDATE_REQ 數據包內容，需要重點關注如下數據：

1. Event counter：29， 表示 LL_CONNECTION_UPDATE_REQ 發送時所在的連接事件編號為 29。
2. Instant：35：約定在第 35 個連接事件中，主從設備開始使用新的連接參數。
3. Interval：816(1020msec), 表示新的連接間隔為 1.02 秒。
4. Window Size/Window Offset：第 35 個連接事件中，主從設備開始使用新的連接參數進行第一次數據包交互時，接收、發送窗口的定時信息。

圖2.LL_CONNECTION_UPDATE_REQ PDU 抓包數據

4.1.2. 從下圖 3 中獲取從連接事件 29 到從設備進入廣播狀態這個過程中每個連接事件及連接時間中數據包收發的時間戳。

圖3.時間戳

從圖 3 中可以看出：

1. 從連接事件 29 到連接事件 34，連接間隔為 30ms，即舊的連接間隔。
2. 連接事件 35 中主設備的發包時間和連接事件 34 的開始時間差大大超過 30ms，所以可以再次確認是在連接事件 35，主從設備開始使用新的連接參數。
3. 從連接事件 35 開始及后續的 3 個連接事件中，只有主設備發送空包，從設備沒有發送空包。
4. 由于新的連接參數的監控超時時間在客戶的測試中為 4 秒，所以從設備沒有發送空包的 4 個連接事件結束后，即發送了斷連。然后，從設備重新開始發送廣播包。

4.1.3. 如下圖 4，通過分析抓包 LOG 中各個連接事件、即數據包發送的時間戳后發現：

1. 通過 LL_CONNECTION_UPDATE_REQ 數據包中 transmitWindowOffset 計算出TransmitWindow 的開始時間點應該在 11.477925s
2. 從抓包的 log 信息中發現，主設備實際的發包時間點在 11.477909s，也就是主設備的發包時間先于藍牙協議中規定的 TransmitWindow 的起始點，導致從設備無法接收到來自主設備的空包，從而無法在同一連接事件(連接事件 35 及后續的 3 個連接事件)中反饋一個空包，進而導致 4 秒監控超時，最終導致斷連。從設備退出連接態后重新進入廣播態。

圖4.連接事件即數據包發送時間分析

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

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

通過對抓包 LOG 中的時間戳的分析，有很大機會可以幫助找到解決問題的突破口。