發表文章

[BLE] L2CAP 協議的介紹

圖片
來自: https://www.novelbits.io/bluetooth-5-speed-maximum-throughput/
我們一樣從 BLE 的封包封裝開始介紹 L2CAP 協定,
在之前的介紹中, 我們介紹了 LL (Link Layer) 層的通訊協定,
在 LL 層的 payload 中, 我們可以加入更上層的封包格式,
在 BLE 協定中, 其中一種上層協定稱為 L2CAP (Logical Link Control and Adaptation Protocol),
L2CAP 中主要負責功能如下:
封包的分段 (Segmentation) 重組與拆解重傳與資料流控制 (Flow Control)封裝 (Encapsulation) 與排程 (Scheduling)QoS 機制的支援 相對於底層封包傳送以 PDU (Packet Data Unit) 為單位,
L2CAP 上層應用可以以 SDU (Service Data Unit) 來傳送資料,
一個 SDU 的大小最大可以為 64 KB,
L2CAP 協定會將一個 SDU 按照 PDU 的大小進行重新切分與重組,
並將一個 Service 虛擬成一個邏輯通道 (L2CAP Channel), 讓上層應用進行存取.
為了完成上述功能, L2CAP 由兩個部分組成: Channel Manager, Resource Manager,
如下圖所示:
 Figure 1.1: L2CAP architectural blocks
in "Logical Link Control and Adaptation Protocol Specification"
對於一個 L2CAP Channel 而言, 對應一個 Channel ID (CID),
一個 CID 對應於一個 P2P 的 BLE 連線,
基於一個 CID, L2CAP 提供 Flow Control 與重傳機制,
對於 L2CAP 底下的 PDU 而言, L2CAP 提供檢查 CRC 和重傳機制,
考慮到 LL 層本身的重傳機制, PDU 會在連線失敗之前不斷重傳,
L2CAP 實際上的 Flow Control 機制為控制 PDU Queue 的排程機制,
也就是決定哪些 PDU 要重新放入 BLE 通訊中等…

[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-r…

[BLE] BLE 5.0 的三項改良

圖片
本篇文章來源為: https://www.novelbits.io/bluetooth-5-advertisements/

BLE 5.0 號稱有三大改良:
網速從 1Mbps 提升至 2Mbps傳輸範圍提升 4 倍廣播封包的 throughput 提升 8 倍 不過, 這些改良並不是同時完成, 和 BLE 4.2 相比, BLE 5.0 提供了兩種新的 PHY 層格式, 分別是對應高傳輸率的 2Mpbs (LE 2M),
以及透過錯誤更正碼保護對應高傳輸範圍的 PHY 層協議 (LE coded),
其中, 三種 PHY 層的協定如下圖所示:
來自: https://www.novelbits.io/bluetooth-5-advertisements/
在上表中, 我們可以看到, 當使用 LE coded 來延伸傳輸距離時,
傳輸速率並沒有提升, 反而是下降,

另一方面, 在廣播封包 (advertising) 部分, 和 BLE 4.2 相比,
新增了一種新的 Adverting, 稱為: Extended Advertisements,
和舊有的 Adverting (Legacy Advertisements) 相比,
新的規格可以使用所有的頻帶 (不只是 36, 37, 38),
也因此, 可以提供較寬頻的廣播通訊,

此功能應該是應對於 BLE Mesh 的技術,
考慮到 BLE Mesh 是以 Advertising 封包傳送,
其有效 throughput 並不高, BLE 5.0 可以針對此部分進行提升,
其基本想法也是在 {36, 37, 38} 上發送起始的封包,
並在 {0-36} 將剩餘封包傳輸,
因此, 此類的 Advertising 封包傳送機制,
就非常類似於舊有 BLE 中的一般封包傳送,
只不過, 現在傳送的對象是一整群的定閱使用者.

[BLE] 藍牙的通訊封包格式與 ARQ 機制

圖片
參考資料:
https://www.cnblogs.com/iini/p/8977806.htmlhttp://leconiot.com/download/cc2640r2f/ble_stack_app/app_examples/exchange_mtu/exchange_mtu.htmlhttp://www.wowotech.net/bluetooth/le_encryption.htmlhttps://www.cnblogs.com/hzl6255/p/4127138.htmlhttp://www.wowotech.net/bluetooth/ble_connection.htmlhttps://www.novelbits.io/bluetooth-5-speed-maximum-throughput/ 在藍牙通訊中, 我們可以先看一下整體的封包格式, 

在這一篇文章中, 我們將先看到 PDU 這一層, 之後若有時間, 會繼續說明 L2CAP 和 ATT 的機制.
在 BLE 中, 基本的通訊單元稱為 PDU (Protocol Data Unit), 如下圖所示:

其中, Preamble 是用以辨別封包的開始,
大小為 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 PDUNMSN (1), SN (1), MD (1): BLE 的 ARQ 和 Flow Control 機制 (之後會說明)RFU (3): 保留字元 (Reserved for Future Use)Data Length (8): 表示資料長度 (0-255)* 雖然資料長度最長為 255, 但要扣掉 MIC 4…

[5GNR] 3GPP URLLC 的進展

圖片
[摘錄自 簡均哲博士 於交大的演講]

URLLC 為 3GPP 在 5G 標準中定義的一種型態,
全名為: Ultra-Reliable and Low Latency Communications,
分成兩項: Reliable (可靠性) 以及 Low Latency (低延遲),
主要應用的範圍可以是: AR/VR, 或是車聯網的應用,

在 3GPP R15 至 R16 的演進中, 可以總結於下圖:
URLLC R15 和 R16 的技術演進
在這張圖中, 說明了 R15 和 R16 的技術差異,
其中, 相較於 R15 URLLC 的標準,
在 R16 中, 除了延遲的縮減從 10ms 到 1ms 之外,
特別著重在傳送效率以及高可靠性上, 增加其適合的應用場域.

URLLC 使用以下的技術來達成低延遲與高可靠性:

更彈性的傳送架構: 引入 mini-slot 和不同優先權, 彈性配置傳送資源預先的資源保留: 為突發的傳送需求, 提供預先的傳送資源配置冗於的傳送機制: 同一筆資料來自於多個來源, 傳送多次, 來保證可靠性 透過上述技術, URLLC 可以用於以下的 Use Cases R15: AR/VR 的低延遲傳輸R16: Factory automation, Transport Industry, Electrical Power Distribution 下圖列出三個應用案例的需求:
相較 R15 專注在一個 UE, 且在單純的 URLLC 下通訊, 在 R16 中, 更重視多個 UE 之間的資源分配,
或是在 URLLC 和 eMBB (Enhanced Mobile Broadband, eMBB) 共存的環境,
可以用於像是工廠自動化這種複雜的環境,

為了解上述問題, R16 希望可以把 URLLC 和 eMBB 分開,
並賦予優先權, 使 URLLC 的傳輸可以較快被服務.
同時, 也要增加 UE 的能力, 使 UE 有較好的能力 monitor 通道的 DCI,
可以較快取得傳輸的機會,

在增加冗餘保證可靠性的改善上, URLLC 有兩種做法:
第一, 可以用較低的 code rate 來傳送, 降低封包錯誤機率,
此方法有較高的通道使用效率, 但是延遲較長
第二, 對於較短的資訊, 則用重複的方式來確保可靠性,
此方法有時造成傳送資源的浪…

[BLE] 不同的 Advertising 種類與用途

圖片
在 BLE 通訊協定中,
BLE 裝置透過 Advertising 告知周邊 BLE 裝置自己的存在,
其中, 考慮到 WiFi 的干擾,
Advertising 封包在以下 3 個 bluetooth channel 上廣播:
channel 37 (2402 MHz), channel 38 (2426 MHz), 和 channel 39 (2480 MHz),
我們可以利用下圖來了解其中干擾的關係:

來自: https://www.infsoft.com/technology/sensors/bluetooth-low-energy-beacons
對於 connection 之後的資料傳輸,
則使用其他 bluetooth channel 進行通訊,
並藉由展頻通訊 (跳頻) 的方法, 對抗 WiFi 通訊產生的干擾,

透過不同的通訊目標, BLE 設計了 4 種不同的 advertising 的方式,
如下表所示:
Advertising PDUDescriptionMax Adv Data LenMax Scan Res LenAllow ConnectADV_INDUsed to send connectable undirected advertisement31 bytes31 bytesYesADV_DIRECT_INDUsed to send connectable directed advertisementN/AN/AYesADV_SCAN_INDUsed to send scannable undirected advertisement31 bytes31 bytesNoADV_NONCONN_INDUsed to send non-connectable undirected advertisement31 bytesN/ANo(來自: Bluetooth Low Energy Scanning and Advertising)
Advertising Data (Adv Data) 代表在 advertising 封包中自帶的資訊,
在 BLE 中, 此資料的長度為 31 bytes.
更多的資訊可以透過 Scan Request (Scan Res) 像發送端要求,
若發送端有支援, 則可以附加額外 31 bytes 的資訊.

[BLE] State Machine and GAP Roles

圖片
在一般 BLE 裝置中, 不同的連線階段也扮演不同角色,
一般來說, 可以分成這四種 GAP Roles:

GAP RoleDescriptionBROADCASTERA device that only sends advertising events.OBSERVERA device that only receives advertising events.PERIPHERALA device that accepts the establishment of an LE physical link using the connection establishment procedure.CENTRALA device that supports the Central role initiates the establishment of a physical connection. (來自: Bluetooth Low Energy Scanning and Advertising)
其中, Broadcaster 和 Observer 為一對, 進行 adverting 通訊,
Peripheral 和 Central 為一對, 進行資料傳輸,
為了表示此 4 種 GAP 腳色, BLE 可以表示為以下狀態機 (State Machine) 的轉換:

來自: https://iot.electronicsforu.com/expert-opinion/improving-battery-life-in-bluetooth-low-energy-connected-things-part-2/
其中, 我們可以看到 Connection 和 Advertising 分屬不同的狀態,
以 one-hot state machine 的概念來說, 在一個時間內應只屬於一個狀態,
至於上述 4 個 GAP Role 則使用了狀態機不同的部分,
如下圖所示:

來自: https://iot.electronicsforu.com/expert-opinion/improving-battery-life-in-bluetooth-low-energy-connected-things-part-2/
其中, Peripheral 和 Central 此對連線, 多…