[BLE] BLE 5.0 的最大 throughput 計算

在上一篇文章中, 介紹了 BLE 5.0 的新功能,
其中, 其中有一項是 2Mbps 的物理層傳輸速率,
然而, 我們真實量測的網速為在 MAC 層的網路速度,
我們在計算 BLE 5.0 真實的 throughput 時,
必須考慮其 MAC 層的機制, 才能找出真實傳送時的速度.
(事實上, 還要計入個層封包的 header 冗餘, 才能反映真實速度)

在 BLE 5.0 中, 影響 throughput 的 MAC 層因素包括下列四點:

• 每一個 Connection Interval 中的封包數量上限
• 封包間隔時間 (Inter Frame Space, IFS) 的長度 (150 ns)
• 用以回應 ARQ 的空封包
• MAC 層的 header 冗餘

首先, 我們先看 MAC 層的冗餘, BLE 封包格式如下:

https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/

在 BLE 4.2 之後, payload 長度為 244 bytes,
在使用 2M PHY 時, 對應的 PDU 長度為 266 (2+4+257+3) bytes,
換句話說, 傳送一個封包中, 資料佔 244/266 的比例.

接下來, 我們要回答在一個 Connection Interval 內可以傳幾個封包,
這個問題來自於兩個限制:
第一, Connection Interval 必須高於所有封包 + IFS 的總時長
第二, 來自硬體 (BLE 晶片) 以及作業系統的限制,
當需要設計一個高速應用時, 要特別注意此來自於裝置與作業系統的限制,
並根據需求選擇適合的 Connection Interval 長度.

在接下來的討論中, 我們先忽視第二點限制,
來考慮所有封包所產生的總時間長度,
在 BLE 中, 下一個回傳的封包為傳送的封包的 ACK,
考慮到一個單向的 BLE 應用 (只有 master -> slave 的資料回報),
此時回傳的封包為一個空封包 (沒有 payload),
因此, 一次資料交換的流程為: IFS + data packet + IFS + empty packet,
如下圖所示:

https://thinkingiot.blogspot.com/2015/12/ble-data-rate-1.html

其中, data packet 的時間長度為:
266*8 / 2Mbps = 2128 bits / 2 Mbps = 1064 us
空封包 (empty packet) 的時間長度為:
22*8 / 2Mbps = 88 bits / 2Mbps = 44 us (payload 至少兩個 bytes)
再加上兩個 IFS 的時間 (150 us),
一次封包交換的時間為: 1064 + 150 + 44 +150 = 1452 us.

在這裡我們可以得到一個無視 Connection Interval 設定的最大 throughput,
也就是假設 Connection Interval 為此時間的倍數, 此時, throughput 為:
244 bytes / 1452 us = 244 * 8 bits / (1452 * 10^-6) sec ~= 1344352 bps ~= 1.34 Mbps,
低於 PHY 層設定的 2Mbps, 因為我們計入了 MAC 層的 overhead.

當我們考慮 Connection Interval 時, 例如: 30 ms,
我們可以得到 30*1000 / 1452 = 20.66,
無條件捨去後, 得知在一個 Connection Interval 一共可傳 20 個封包,
因此, throughput 為: 20*244 bytes / 30 ms = 20*244*8 / (30*10^-3) = 1301333 bps,
約略為 1.3 Mbps, 又更低一些, 因為 Connection Interval 的一些時間浪費.

在上述計算中, 我們並沒有考慮傳輸錯誤以及上層冗餘的影響,
但是, MAC 層的傳送速率就已經是 PHY 宣稱的速率的 7 成不到,
因此, 在設計有效的資料量時, 必須考慮 MAC 層的冗餘,
才可以有效評估 BLE 網路的容量.

本文主要參考: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/