實戰(zhàn)經(jīng)驗 | 關(guān)于連接參數(shù)更新進程后導(dǎo)致斷連的問題分析

作者：時間：2024-04-18 來源：STM32單片機

加入技術(shù)交流群
- 掃碼加入
  和技術(shù)大咖面對面交流
  海量資料庫查詢

01 引言

本文引用地址：http://2s4d.com/article/202404/457777.htm

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

02 連接參數(shù)更新進程簡述

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

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

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

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

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

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

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

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

圖片.png

圖1.連接參數(shù)更新流程

03 客戶可能的測試邏輯和問題現(xiàn)象描述

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

問題現(xiàn)象：

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

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

04 問題分析

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

4.1.分析 LL_CONNECTION_UPDATE_REQ 數(shù)據(jù)包內(nèi)容

4.1.1. 如圖 2 所示，LL_CONNECTION_UPDATE_REQ 數(shù)據(jù)包內(nèi)容，需要重點關(guān)注如下數(shù)據(jù)：

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

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

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

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

圖片.png

圖2.LL_CONNECTION_UPDATE_REQ PDU 抓包數(shù)據(jù)

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

圖片.png

圖3.時間戳

從圖 3 中可以看出：

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

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

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

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

4.1.3. 如下圖 4，通過分析抓包 LOG 中各個連接事件、即數(shù)據(jù)包發(fā)送的時間戳后發(fā)現(xiàn)：

1.通過 LL_CONNECTION_UPDATE_REQ 數(shù)據(jù)包中 transmitWindowOffset 計算出TransmitWindow 的開始時間點應(yīng)該在 11.477925s

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

圖片.png