[BLE] 藍牙的通訊封包格式與 ARQ 機制
參考資料:
其中, Preamble 是用以辨別封包的開始,
大小為 8 個 bits, 分成兩種型態: 01010101, 10101010
Access Address, 則根據廣播封包或是通訊封包而不同,
廣播封包的位址固定為: 0x8E89BED6,
通訊封包則根據建立連線的對象而改變.
CRC 則是用以保護 PDU 的資料傳輸.
在這篇文章中, 我們先專注在通訊封包的格式,
進入 PDU 封包後, 我們可以列出更詳細的資料格式:
其中, header 一共有 16 bits,
前 8 個 bits 的資訊為 LL header (Link Layer), 後 8 個 bits 為資料長度,
詳細說明如下:
- https://www.cnblogs.com/iini/p/8977806.html
- http://leconiot.com/download/cc2640r2f/ble_stack_app/app_examples/exchange_mtu/exchange_mtu.html
- http://www.wowotech.net/bluetooth/le_encryption.html
- https://www.cnblogs.com/hzl6255/p/4127138.html
- http://www.wowotech.net/bluetooth/ble_connection.html
- https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/
在藍牙通訊中, 我們可以先看一下整體的封包格式,
在這一篇文章中, 我們將先看到 PDU 這一層,
之後若有時間, 會繼續說明 L2CAP 和 ATT 的機制.
在 BLE 中, 基本的通訊單元稱為 PDU (Protocol Data Unit), 如下圖所示:
大小為 8 個 bits, 分成兩種型態: 01010101, 10101010
Access Address, 則根據廣播封包或是通訊封包而不同,
廣播封包的位址固定為: 0x8E89BED6,
通訊封包則根據建立連線的對象而改變.
CRC 則是用以保護 PDU 的資料傳輸.
在這篇文章中, 我們先專注在通訊封包的格式,
進入 PDU 封包後, 我們可以列出更詳細的資料格式:
其中, header 一共有 16 bits,
前 8 個 bits 的資訊為 LL header (Link Layer), 後 8 個 bits 為資料長度,
詳細說明如下:
- LLID (2): 指示接下來的封包為 L2CAP, 或是 LL control PDU
- NMSN (1), SN (1), MD (1): BLE 的 ARQ 和 Flow Control 機制 (之後會說明)
- RFU (3): 保留字元 (Reserved for Future Use)
- Data Length (8): 表示資料長度 (0-255)*
雖然資料長度最長為 255, 但要扣掉 MIC 4 個 bits,
因此有效長度為 251 bits.
* 在 BLE 4.1 以前, Data Length 只有 5 個 bits, 因此有效長度為 27 bits.
可以以下表顯示:
先說明簡單的部分, MD 代表 More Data,
也就是之後還有資料要送,
通常在一個 Connection Interval 內可以送 6 個封包,
此數值將影響實際可到達的 throughput, 通常在晶片中的 SDK 會規範,
其運作模式如下圖:
接下來, 我們來說明 NESN 和 SN 怎麼交互進行 ARQ 的機制,
傳收資料的兩端為: 傳送端和接收端,
同時, 傳收兩端都會紀錄下對於本地端的 NESN 和 SN 數值,
對於接收端而言, 當成工收到一個封包時, 將 NESN 加 1,
對於傳送端而言, 完成傳送後, 將本地端的 SN 加 1,
當下一個封包回收時, 若收到的 NESN != 本地端的 SN, 則代表成功傳送,
其狀態轉換可以以下圖表示:
(SN' 和 NESN' 代表本地的 SN 和 NESN 狀態)
簡單來說, NESN' 代表期待收到的封包編號,
SN' 代表 (上次) 傳送出去的封包編號,
因此, 當成功收到封包時 (期待收到的封包編號==收到的封包編號),
將 NESN' 加 1, 並在下次封包更新,
當對方傳送的 NESN 和 SN' 相同時, 代表封包遺失 (對方期待的封包編號不變),
傳送端此時需要重新傳送封包,
相對的, 若期待收到的封包編號和收到的封包編號不一致,
代表錯誤重傳, 此時就直接將封包丟棄.
考慮到上述的 ARQ 機制, BLE 的封包必須是一來一回,
因此, 就算是其中一端沒有資料要傳送,
也必須要回傳一個空的封包, 作為 ACK 或是 NACK.
(2019/12/19 補充)
在一般的認知中, 我們通常說 notification 有重傳, indication 沒有重傳,
但是在 BLE 的 LL (Link Layer) 中, 重傳並沒有停止條件,
每一個封包都會重傳直到成功送達, 或是中止於連線中斷.
- https://devzone.nordicsemi.com/f/nordic-q-a/35574/bluetooth-5-retransmission-on-nrf52832
- https://devzone.nordicsemi.com/f/nordic-q-a/1884/about-acknowledgement-and-retransmission
在一般的認知中, 我們通常說 notification 有重傳, indication 沒有重傳,
但是在 BLE 的 LL (Link Layer) 中, 重傳並沒有停止條件,
每一個封包都會重傳直到成功送達, 或是中止於連線中斷.
留言
張貼留言