目錄
引言
一、廣播及連接建立
1.1 廣播類型
1.2 掃描/連接請求與響應
1.2.1 廣播流程說明
1.2.1.1?廣播流程示例圖
1.2.1.2?廣播信息設置
1.2.1.3 信道廣播
1.2.1.4 信道切換
1.2.1.5 廣播間隔
1.2.1.6 接收窗口與理論最小傳輸時間
1.2.2 掃描/連接流程說明
1.2.2.1 掃描/連接流程示例圖
1.2.2.2 掃描請求和掃描
1.2.2.3 掃描間隔和掃描窗口
1.2.2.4 掃描請求(可選)
1.2.2.5 掃描響應(可選)
1.2.2.6 連接建立流程
二、數據信道交互中涉及的參數
2.1?Access Address 詳解
2.2?CRCinit 詳解
2.3?Interval詳解
2.4?Timeout?詳解
2.5?ChM詳解
2.6 Hop詳解
2.7?SCA詳解
引言
上一篇講解了廣播報文以及數據報文的幀格式,這一章我們來講廣播、連接及掃描的流程
一、廣播及連接建立
1.1 廣播類型
BLE協議中將發送廣播方稱為從機,接收廣播并可以選擇是否發起掃描請求/連接請求的稱為主機。
對于主機,BLE協議針對不同用途定義了如下幾種不同的廣播報文類型:
報文類型 | 是否可掃描 | 是否可連接 | 用途說明 |
---|---|---|---|
通用廣播指示(ADV_IND) | 是 | 是 | 用于從機主動廣播其存在,支持主機進行掃描與連接。 |
定向連接指示(ADV_DIRECT_IND) | 否 | 是 | 用于快速連接已知主機(如配對過的主機)。 |
不可連接指示(ADV_NONCONN_IND) | 否 | 否 | 用于僅廣播信息、不接受連接或掃描。 |
可掃描指示(ADV_SCAN_IND) | 是 | 否 | 允許設備被掃描,但不允許連接。相比不可連接指示(ADV_NONCONN_IND),可以攜帶更多信息,通常用于展示信息后被查詢更多內容。 |
由表格可知,從機不同廣播報文類型主要是對掃描請求以及連接請求的支持情況不一樣,因此我們重點講解基于通用廣播指示(ADV_IND)的掃描和連接請求流程。
1.2 掃描/連接請求與響應
1.2.1 廣播流程說明
1.2.1.1?廣播流程示例圖
1.2.1.2?廣播信息設置
上圖為通用廣播指示(ADV_IND)的報文格式示意圖,由圖可知其中大部分內容已被協議固定,我們重點關注以下內容:
① 發送地址類型
此字段用來標識廣播報文發送者的地址類型。
- 0:公共地址,即MAC地址
- 1:隨機地址,由從機動態生成
②Payload
6字節廣播地址:根據從機廣播的設計方案,填充MAC地址或者隨機地址。
31字節(至多)數據:根據從機設計填充數據內容。
1.2.1.3 信道廣播
當從機設置好廣播信息并發起廣播后,每一輪廣播會在三個廣播信道中依次進行,每一個信道廣播完畢后會等待一個固定時間T_IFS(固定150us),這是BLE規范定義的收發切換保護時間,因為BLE本質上是半雙工通信,收發不能同時進行。
T_IFS的存在給予了雙方硬件和協議處理層一個穩定的時間窗口來切換狀態(Rx→Tx或Tx→Rx)。
1.2.1.4 信道切換
BLE協議標準推薦每一輪廣播按照37→38→39的順序進行,同一輪廣播中,三個信道的切換間隔不是固定的,主要取決于設備的調度機制和射頻切換時間。
一般來說,設備會盡快在 3 個信道上發送廣播數據,間隔可能在微秒到毫秒級,但不會有嚴格的固定值。
1.2.1.5 廣播間隔
每兩輪周期廣播的間隔時間叫做廣播間隔,這個時間是可配置的,通常在20ms到10.24s之間(具體范圍受 BLE 版本和設備類型限制)。這個時間決定了廣播的頻率,也影響設備被發現的速度和功耗,另外有的廠商會在每輪廣播(三個信道都廣播完畢稱為一輪)結束后插入一個0~幾百us的隨機延遲。
低功耗設備(如 Beacon)通常設定較長的廣播間隔(如 1s),而希望被快速發現的設備(如配對模式下的耳機)可能會使用較短的廣播間隔(如 50ms)。
此外,為了減少碰撞概率,部分廠商會等待廣播間隔 + 一定時間延遲再開始下一輪。
1.2.1.6 接收窗口與理論最小傳輸時間
對于從機,在某一個信道完成廣播并等待T_IFS間隔后,還需要在此信道維持Rx狀態一段時間,以便于接收可能到來的主機的掃描或連接請求,那么應該等待多長時間呢?
先附上連接請求和掃描請求的幀格式圖:
由圖可知,掃描請求包長至多22字節,連接請求包長至多44個字節。因此可計算接收窗口大小:
① 1M PHY模式
????????掃描請求:Rx_Period = 22Byte × 8bit / 1Mbps/s ≈ 176 us
????????連接請求:Rx_Period = 44Byte × 8bit / 1Mbps/s ≈ 352?us
② 2M PHY模式
????????掃描請求:Rx_Period = 22Byte × 8bit / 2Mbps/s ≈ 88 us
????????連接請求:Rx_Period = 44Byte × 8bit / 2Mbps/s ≈ 176us
若接收周期內沒有收到連接或掃描請求,則會切換至下一信道繼續廣播。實際工程上設置的接收窗口會比計算值大不少,以預留足夠的冗余時間。
注意:
從機每次在某個信道廣播后,必須在T_IFS間隔內從Tx模式切換到Rx模式;而主機則是確認要發起連接或掃描才會從Rx模式切換Tx模式。
1.2.2 掃描/連接流程說明
1.2.2.1 掃描/連接流程示例圖
從機發送完廣播后,在IFS時間內切換到接收模式,在IFS結束開始等待主機報文(即從機等待接收周期)。BLE主機掃描到從機廣播后,如果需要發起連接或掃描,則在IFS時間內切換到發送模式。并在IFS時間結束后發送連接或掃描請求。
主機收到第一幀來自從機的數據信道包后,連接即建立。在此之后的數據信道包交互,就是基于interval的通信:
- 主機 interval 起點 = 收到從機數據包時刻?
- 從機 interval 起點 = 收到主機數據包時刻?
- IFS 等待時間在發送/接收模式切換之間,且必須強制等待
1.2.2.2 掃描請求和掃描
在講解掃描流程之前,我們先要區分清楚掃描請求和掃描:
① 掃描請求
這個掃描請求是可選的,其主要意義是使主機可以在建立連接之前,向從機請求查詢更多信息,再決定是否要進行連接。(對于不可連接指示(ADV_NONCONN_IND)以及可掃描指示(ADV_SCAN_IND)而言,掃描單純是為了獲取更多信息。由于BLE的低功耗特性,掃描的設計使得從機可以盡可能縮短廣播的報文長度,從而降低功耗。)
② 掃描
掃描指的是主機按照掃描間隔和掃描窗口,周期性的在廣播信道上檢索從機發出的廣播報文,并決定是否發起連接的流程。
1.2.2.3 掃描間隔和掃描窗口
① 掃描間隔
主機周期性按照掃描間隔在各個廣播信道之間切換。
② 掃描窗口
主機切換到廣播信道后,在廣播信道等待廣播報文的最長時間。如主機收到廣播報文后,若決定發起連接,需要在T_IFS后立即返回(在從機接收周期內返回)。
注意:
從掃描和廣播的機制可知:主機檢測到從機的廣播報文是一個概率事件,要想提高主機掃考到從機的成功率,需要合理地設計各個參數,尤其是:廣播間隔、接收周期、掃描間隔、掃描窗口。
1.2.2.4 掃描請求(可選)
如果主機接收到廣播包后需要獲取更多信息,則可以先發起掃描請求,掃描請求包格式如下:
如圖,掃描請求中需要填充如下內容:
① 接收和發送地址類型
② 掃描者地址(主機地址)和 廣播者地址(從從機的廣播報文中拷貝而來)
1.2.2.5 掃描響應(可選)
從機接收到主機的掃描請求后,可以選擇是否回復。若選擇需要回復,掃描響應格式如下:
如圖,掃描響應中需要填充如下內容:
① 發送地址類型
② 廣播者地址和掃描者地址(來自于掃描請求)
③ 掃描響應數據(至多31字節)
1.2.2.6 連接建立流程
連接請求的報文格式如下:
其中22字節的LL data格式如下:
字段名 | 字段大小 | 字段說明 |
---|---|---|
Access Address | 4字節 | 鏈路層連接訪問地址:連接建立后,數據信道所有包的標識符(類似TCP連接的端口號) |
CRCinit | 3字節 | 數據信道包的CRC校驗初始值,主設備隨機生成 |
Winsize | 1字節 | TransmitWindowSize = WinSize * 1.25 ms(主設備發送首個數據包的時間窗口) |
WinOffset | 2字節 | TransmitWindowOffset = WinOffset*1.25ms (從廣播結束到首個連接事件的延遲) |
Interval | 2字節 | ConnInterval = Interval *1.25ms(主設備發送連接事件的間隔) |
Latency | 2字節 | 從機最多可以連續跳過(不響應)多少次主機的連接事件 |
Timeout | 2字節 | 規定多長時間沒通信連接會斷開,Timeout >(1+Latency)*(ConnInterval) |
ChM | 5字節 | 哪些信道可以使用(信道映射,標記37個數據信道的可用性,每bit代表1個信道) |
Hop | 5bit | 跳頻增量(范圍5-16),用于計算下一個信道:next_ch = (curr_ch + Hop) % 37。 |
SCA | 3bit(和Hop公用一個字節) | 主設備時鐘精度信息(主設備睡眠時鐘精度(0=250ppm,7=500ppm),影響從設備的時序容差) |
當主機在自身的掃描窗口內,檢測到從機的廣播報文并解析后,如果主機需要發起連接請求,則主機需要在T_IFS時間內完成從Rx模式到Tx模式的切換,并在從機的接收窗口內發送出連接或掃描請求。
從機接收到連接請求后,以下來自主機請求的參數會參與接下來的流程建立流程:
① Winsize
Winsize用于計算主機從成功發起連接請求后,到發出第一個數據信道包的時間窗口長度,如下:
TransmitWindowSize = WinSize * 1.25 ms
從機若在這個窗口期間沒有收到主機發來的數據包,則連接失敗。
注意:
1)窗口的計時起點:Tstart?= 從機收到主機連接請求的時刻 + 1.25ms +?TransmitWindowOffset 。
即從機需要在[Tstart?,Tstart +?TransmitWindowSize ] 時間窗口內收到第一幀來自主機的數據包。
這里的1.25ms是BLE協議硬性規定,即使WinOffset 為0,也需要等待1.25ms。
2)TransmitWindowSize 和?TransmitWindowOffset 只針對第一個連接事件!
② WinOffset
WinOffset用于計算TransmitWindowOffset = WinOffset*1.25ms ,Transmit Window Offset代表著收到連接請求后,開始進行數據包窗口計時的偏移量。如下圖:
③ Latency
一旦從機接收到主機的數據包,理論上就應該對數據包予以回復。但是Latency擴展了這一邏輯,該參數定義了從機最多可以連續忽略多少個主機連接事件。在Latency達到最大值之后從機必須對主機的數據包進行回復。如果Latency為0則表示從機必須監聽并回復每個連接事件。
而一旦從機第一次對主機的數據包進行回復,主機就會認為連接成功建立。
二、數據信道交互中涉及的參數
2.1?Access Address詳解
連接建立后,數據信道所有包的標識符都會包含此字段。
2.2?CRCinit詳解
數據信道包的CRC校驗初始值,主設備隨機生成。此值參與后面所有數據信道包的CRC計算。
2.3?Interval詳解
當主機認為建立完畢后,會周期給從機發送連接事件(連接事件發生在數據信道),后續所有的數據通信都是基于連接事件。
主機發送連接事件的周期固定,由ConnInterval參數決定:
ConnInterval = Interval *1.25ms(主設備發送連接事件的間隔)
從機也是根據ConnInterval定時監聽來自主機的連接事件。雙方在連接建立(即從機接收到主機的第一個連接事件并進行響應)后,約定以ConnInterval為周期進行通信,并在通信的剩余間歇進入低功耗狀態。
從這個角度而言,連接建立后,BLE其實是固定周期進行數據交互的。
2.4?Timeout詳解
用于規定從機多長時間沒收到主機的連接事件后,連接會自動斷開,Timeout >(1+Latency)*(ConnInterval)
2.5?ChM詳解
哪些信道可以使用(信道映射,標記37個數據信道的可用性,每bit代表1個信道)
2.6?Hop詳解
跳頻增量(范圍5-16),用于計算下一個使用的數據信道:下一個信道 = (當前信道+ Hop) % 37。
2.7?SCA詳解
SCA用于BLE休眠場景下的時鐘同步,如果你的項目是給BLE供常電,不用過于深入。
想了解更多嵌入式技術知識,請點擊閱讀我的其他文章
煙花的文章鏈接集合-CSDN博客
如果你覺得內容對您有幫助,別忘了點贊、收藏和分享支持下哦!