淺談BLE吞吐量

原文鏈接：http://jdhblog.com/2020/01/02/%E6%B5%85%E8%B0%88BLE%E5%90%9E%E5%90%90%E9%87%8F/

怎樣才能提高BLE吞吐量？一文讀懂BLE的吞吐量。

 

前言

減少連接間隔是唯一提高BLE傳輸速率方法嗎？ATT_MTU會影響傳輸速率嗎？長包指的是什麼？這篇文章就是解答這些問題的，有不對的地方，歡迎斧正。

由於影響吞吐量的因素有許多，而篇幅有限，以下條件先不考慮：

1. 加密數據包

加密數據包會影響LL PDU的長度。

1. att protocol以外的l2cap channel

比如smp這種對吞吐量沒有需求的channel就不考慮。

1. link layer丟包重發

同一個LL packet發多遍當然會影響吞吐量，這裏假設射頻環境很好，不會有這個影響。

1. le coded phy

只考慮1M和2M

1. cpu處理速度的影響

假設cpu處理速度足夠快，不會被其他中斷影響協議棧的行爲。

1. hci通訊接口的吞吐量限制

hci接口有uart/spi/ram等多種通訊方式，不同通訊方式本身也會有速率限制，這裏不考慮這個限制。

1. 多鏈路

多鏈路分時複用radio，吞吐量會被降低，這裏只考慮單鏈路情況。

目錄

• 1. BLE協議棧框架
• 2. GATT
• 3. ATT PROTOCOL
  • 3.1. Write Command format
  • 3.2. Handle Value Notification format
  • 3.3. ATT_MTU的定義
• 4. L2CAP SPEC
  • 4.1. SDU(Service Data Unit)
  • 4.2. B-frame
  • 4.3. MTU(Maximum Transmission Unit), min 23
  • 4.4. MPS(Maximum PDU payload Size), max 65535
  • 4.5. Segmentation and Reassembly
  • 4.6. Fragmentation and Recombination
• 5. LINK LAYER
  • 5.1. Link layer packet
    • 5.1.1. ble4.0
    • 5.1.2. ble4.2
  • 5.2. BLE連接傳輸原理說明
• 6. PHY LAYER
  • 1M PHY和2M PHY的差異
• 7. 總結
• 8. 參考資料

1. BLE協議棧框架

 

手機下傳write without repsonse的一個procedure數據流向：

gatt(client) -> l2cap -> hci(option) -> link layer -> phy -> phy -> link layer -> hci(option) -> l2cap -> gatt(server)

設備上傳notification的一個procedure數據流向：

gatt(server) -> l2cap -> hci(option) -> link layer -> phy -> phy -> link layer -> hci(option) -> l2cap -> gatt(client)

2. GATT

gatt規定ATT_MTU默認支持不能小於23，ATT_MTU理論最大65535（因爲MTU Exchange Request裏面表示ATT_MTU大小的MTU size field只有2個字節）。

gatt要求l2cap channel默認配置參數如下：

表格中MTU是一個默認值，表示此時此刻att protocol channel的L2CAP payload支持的最大傳輸單元是23字節，但並不代表local設備最大接收能力。連接之後可以通過exchange mtu procedure來更新ATT_MTU，所以協商ATT_MTU過程相當於協商MTU的過程，與BR/EDR的差異是BR/EDR通過l2cap channel configuration procedure來配置MTU，而不是exchange mtu procedure。

3. ATT PROTOCOL

3.1. Write Command format

用於gatt的write without response。

3.2. Handle Value Notification format

用於gatt的notifications。

3.3. ATT_MTU的定義

ATT_MTU is defined as the maximum size of any packet sent between a client and a server. A higher layer specification defines the default ATT_MTU value. ATT_MTU is a negotiated value.

連接之後，client可以向server發起mtu exchange procedure，即client告訴server自己的最大接收能力ATT_MTU（client’s local att protocol channel MTU），server也會告訴client自己的最大接收能力ATT_MTU（server’s local att protocol channel MTU），最後取兩者的最小值爲這條通道的ATT_MTU（actual att protocol channel MTU）。

4. L2CAP SPEC

4.1. SDU(Service Data Unit)

來自上層的數據，不包含任何l2cap的信息，這裏爲ATT的消息。

4.2. B-frame

ATT PROTOCOL的數據就放在b-frame的information payload中，Length field佔2個字節，所以理論payload最大隻有65535字節，因爲受芯片的ram大小限制，實際實現還會再小一點，通過MTU具體實現表現出來。

4.3. MTU(Maximum Transmission Unit), min 23

MTU is not a negotiated value, it is an informational parameter that each device can specify independently and indicates to the remote device that the local device can receive, in this channel, an MTU larger than the minimum required.

l2cap MTU表示每條l2cap channel的最大接收能力，不是一個協商值。

當l2cap channel是att protocol channel的時候，協議棧實現如下：

比如說，local設備的local att protocol channel MTU最大能支持到2048字節，但是peer設備的local att protocol channel MTU只能支持到23字節，經過gatt的mtu exchange procedure之後，取兩者的最小值23爲這條通道的ATT_MTU（即actual att protocol MTU）。儘管這時候att protocol作了長度限制不能超過23字節，但是peer設備要是發送了非法長度數據，att protocol本身是沒有機制去檢測出來的。所以在mtu exchange procedure之後協議棧實現就需要將local設備的att protocol channel MTU更新爲23，那麼當local設備收到一包att protocol消息之後，在l2cap層就可以判定該數據包是合法長度的數據了。

所以att protocol channel MTU也常常被誤認爲是ATT_MTU，但他們還是有點區別的。

4.4. MPS(Maximum PDU payload Size), max 65535

規範規定在Basic L2CAP mode的B-frame的MPS等於MTU。

Note: In the absence of segmentation, or in the Basic L2CAP Mode, the Maximum Transmission Unit is the equivalent to the Maximum PDU payload Size and shall be made equal in the configuration parameters.

4.5. Segmentation and Reassembly

當MPS小於MTU的時候，需要segmentation；但是對於ATT消息, MPS總是等於ATT_MTU，所以ATT消息從不需要segmented，但是可能會因爲鏈路層限制而需要fragmented。

經典藍牙某些場合可能需要用到segmented，不太清楚。

4.6. Fragmentation and Recombination

由於鏈路層的接收限制，l2cap的幀有時候需要拆開發送，用鏈路層包頭的LLID來負責標識拆包和重組。

下面看兩個例子。

如果BLE4.0，ATT_MTU最後client和server協商出來結果是23，那麼發送20字節（ATT_payload）不需要拆包：

1字節前導碼 + 4字節訪問地址 + 2字節鏈路幀頭（其中LLID = 10b，表示一個沒有fragmentation的完整包） + 4字節L2CAP幀頭 + 3字節ATT幀頭 + 20字節的ATT_payload + 3字節CRC

如果BLE4.0，ATT_MTU最後client和server協商出來假設是63，那麼你發送60字節數據（ATT_payload），L2CAP會將它拆成3包（拆包的原因是因爲BLE4.0鏈路層PDU的限制），最終從空中發出去的包長這樣：

1）1字節前導碼 + 4字節訪問地址 + 2字節鏈路幀頭（其中LLID = 10b，表示這是第一個連續包） + 4字節L2CAP幀頭 + 3字節ATT幀頭 + 20字節的ATT_payload + 3字節CRC
2）1字節前導碼 + 4字節訪問地址 + 2字節鏈路幀頭（其中LLID = 01b，表示這是下一包連續包） + 27字節的ATT_payload + 3字節CRC
3）1字節前導碼 + 4字節訪問地址 + 2字節鏈路幀頭（其中LLID = 01b，表示這是最後一個連續包） + 13字節的ATT_payload + 3字節CRC

上面10b、01b中的“b”表示二進制格式，中間的包和最後的包的LLID都是01b，對方怎麼知道什麼時候收完包呢？靠的是第一包的4字節L2CAP幀頭，這裏面會說明後面一共有多少數據待接收。

5. LINK LAYER

5.1. Link layer packet

5.1.1. ble4.0

可以看到LL PDU的長度最大爲39字節，LL PDU又分爲兩種：一種是ADV PDU廣播通道包，最大長度爲39個字節；另一種是DATA PDU數據通道包，最大爲33字節，後者是連接之後通訊的數據包。

展開DATA PDU，前2個字節爲幀頭，後4個字節爲MIC（用於加密），就算不加密這4個字節也不能用於傳輸上層數據，即payload最多能容納27字節的上層數據（上層指的是l2cap層）。

The Length field of the Header indicates the length of the Payload and MIC if included. The length field has the range of 0 to 31 octets. The Payload field shall be less than or equal to 27 octets in length. The MIC is 4 octets in length.

 

5.1.2. ble4.2

後來因爲27字節payload實在太少了，所以在ble4.2引入了新的特性，即LE data length extension（數據長度擴展，業內也叫長包）。

可以看到LL PDU的長度最大爲257字節，LL PDU又分爲兩種：一種是ADV PDU廣播通道包，最大長度爲257個字節；另一種是DATA PDU數據通道包，最大爲257字節，後者是連接之後通訊的數據包。

展開DATA PDU，前2個字節爲幀頭，後4個字節爲MIC（用於加密），就算不加密這4個字節也不能用於傳輸上層數據，即payload最多能容納251字節的上層數據（上層指的是l2cap層）。

The Length field of the Header indicates the length of the Payload and MIC if included. The length field has the range of 0 to 255 octets. The Payload field shall be less than or equal to 251 octets in length. The MIC is 4 octets in length

 5.2. BLE連接傳輸原理說明

上圖爲 BLE 連接傳輸的一個例子，其中每個 Connection Event 包含 6 個主機和 6 個從機的 Link Layer Packet，一個 Connection Interval 只有一個 Connection Event；如果每個 Link Layer Pakcet 限制最多包含 20 字節用戶數據，那麼上圖例子中每次 Connection Interval， BLE主機最多可以發送 120 字節用戶數據， BLE 從機最多可以發送 120 字節用戶數據。而這個
Connection Interval 就是我們常說的“連接間隔”。所以可知， BLE鏈路層傳輸速率的快慢主要由以下因素決定：

1. Connection Interval 的大小；
2. 每個 Connection Event 可以發送多少個 Link Layer Packet；
3. 每個 Link Layer Packet 可以負載多少用戶數據；
4. 相鄰 Link Layer Packet之間的時間間隔T_IFS。

6. PHY LAYER

 

上圖爲1M PHY和2M PHY在2404頻點發送數據0b1010的對比圖。

BLE的調製方式爲GFSK，BLE定義在信道中傳輸的是二進制符號（波形），即1個符號（波形）表示1個比特，其中相對頻點正偏代表數字基帶信號1，相對頻點負偏的代表數字基帶信號0。

之所以速率提高了，本質應該是2M PHY的碼長變小了，即發送一個符號（波形）所需的時間變小了。

BLE規範原文：A binary one shall be represented by a positive frequency deviation, and a binary zero shall be represented by a negative frequency deviation.
1M PHY：
The mandatory symbol rate is 1 megasymbol per second (Msym/s), where 1 symbol represents 1 bit therefore supporting a bit rate of 1 megabit per second (Mb/s), which is referred to as the LE 1M PHY
2M PHY：
An optional symbol rate of 2 Msym/s may be supported, with a bit rate of 2 Mb/s, which is referred to as the LE 2M PHY.

1M PHY和2M PHY的差異

• 1M PHY的正偏和負偏至少需要達到185Khz，2M PHY的正偏和負偏至少需要達到370Khz
• 2M PHY的比特率是1M PHY的兩倍，即2M PHY傳輸完0b1010的時間是1M PHY的一半

7. 總結

提高吞吐量的途徑有以下幾種方式：

• GATT

  • client用write without response而不要用write characteristic value
  • server用notification而不要用indication
  • ATT_MTU儘可能大（這樣可以減少L2CAP的幀頭數量，通過Fragmentation來儘可能佔據帶寬，提高吞吐量）

• L2CAP

  • NULL（應用層沒啥可以做的）

• LINK LAYER

  • 減少連接間隔（connection interval）
  • 增大連接事件（connection event）
  • 啓用數據包擴展特性（link layer packet）