BLE 是 Bluetooth Low Energy，或稱Bluetooth LE的縮寫，也可以說是藍芽的低功耗版本，是 藍牙技術聯盟沿用經典藍牙的規範內容 推出的，基於通用屬性規範（GATT） 推出的一些應用profile，BLE 4.0 是 BT 4.0 低功耗的分支，不向下相容於 BT 3.0。
以下先列出藍牙不同版本，與傳輸速度的比較關係。
藍牙版本 => 傳輸速度
BT 4.0 => 24M bps
BLE 4.0 => 125K bps
BT 4.2 => 24M bps
BLE 4.2 => 1M bps
BT 5.0 => 24M bps
BLE 5.0 => 2M bps 在有效傳輸距離上將是 4.2 LE 版本的4倍，傳輸速度將是 4.2 LE 版本的2倍。
BT 5.2 => 48M bps
BLE 5.2 => 2M bps 是基於BLE 5.0 多了 LE Audio
1.1 BT 5.0 與 BT 5.2 的不同
在BLUETOOTH 5.2 與 之前 5.0 最大的不同點有3個 :
(1) BT 5.2 提供同步通道 (ISOC - isochronous channels) - 這是一項全新的功能，支持面向連接和無連接的通信。此功能主要設計用於支持 LE Audio，這是最新的音頻技術。所以 BT 5.2 本身的 規格書中，就已經包含了 LE Audio 的一些考量，例如一些壓縮性質的音頻編碼及解碼。 同步通道 它允許將有時間限制的數據傳輸到一個或多個設備以進行時間同步處理。
所以它可以通過連接使用或以 廣播方式 到可傳輸範圍內所有的設備。音頻源可以將同步播放的音頻傳輸到小型私人設備組（個人音頻共享）或公共空間（例如出入境大廳）中無限大小的大型設備集合。可做為音樂分享或機場音箱廣播與助聽器廣播的應用。 LE Audio 建立在 LE Sync 的新通道之上，它將為接收器提供新標準可只接收所需的音頻，預計多語言音頻廣播系統將成為一種可能性。同步的傳輸也可以確保一對多的音訊傳輸，每個接收到的裝置之間，音樂是同步的，不會有時間上的延遲。
BT 5.0 並無此同步通道規劃。
(2) BT 5.2 提供了原始屬性協議 (ATT) 的升級版本，稱為增強屬性協議 EATT ( Enhanced Attribute Protocol )，比 ATT 更高效、更安全。
如『圖1.1.1』( 註1 )
EATT 允許來自不同應用程序的 ATT 數據包與L2CAP ( Logical Link Control and Adaptation Protocol ) 數據包交叉，並允許在連接期間更改 ATT 最大傳輸單元 MTU ( Maximum Transmission Unit )。 總體而言，這些更改可以通過暫時減少一個應用程序對堆棧的使用以在多個應用程序同時使用藍牙低功耗 (LE) 堆棧時阻止另一個應用程序的使用，從而增強和改善設備上的用戶體驗。 這可以減少一個或多個應用程序的端到端延遲並改善用戶響應體驗。
為了支持 EATT，定義了一個新的 L2CAP 模式。 這種新模式稱為基於 L2CAP 的增強型信用流程控制模式 ( Enhanced Credit Flow Control mode ) 。 此模式提供流量控制，因此允許應用程序將協議視為可靠的。 與之前未增強的 ATT 相比，EATT 具有安全優勢，因為它只能用於加密連接。這種新模式是在 BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3.4, Part A page 1044。而BT 5.0 不允許連接期間再次修改 MTU，而 BT 5.2 是可以在傳輸期間，再次修改 MTU，可減少大量的時間，無需像在 BT 5.0 必須要停止傳輸之後，才能修改 MTU ，之後才能傳輸新的 MTU 的過程。
圖 1.1.1 ( 註1 )
(3) BT 5.2 具有 LE Power Control憑藉這些進步和效率提升，BT 5.2 提供了更快的配對能力以及更長的電池壽命。這種新的低功率控制允許設備動態優化連接設備之間的傳輸功率。信號品質高，則下降傳輸功率，若信號回質低，則提高傳輸功率。
低功耗藍牙接收器可以即時監控信號強度並請求連接設備的傳輸功率水平的變化，通常是為了在信號質量和低功耗方面保持最佳信號強度。
LE 電源控制具有以下 3 大優勢：
- 通過在連接的設備之間執行動態電源管理，降低發射機的總功耗，以達到省電的目的。
- 通過將接收器信號強度保持在接收器支持的最佳範圍內來提高可靠性，以降低傳輸的錯誤率。
- 在使用 2.4 GHz 頻率範圍的環境中提高與其他無線設備的共存性，不會與現行裝置發生太多的干擾。
LE功率控制的3種應用場景：
- 調整兩個設備（TX 或 RX）的發射功率並相互通知，可互相了解發射功率，來計算可使用的時間。
- 根據兩個設備可接受的最佳功率值調整自己的發射功率，以達到最佳傳輸且省電的目的，且可避免因設備使用太高的功率，影響附近的 2.4 GHz 頻率的裝置。
- 可監測路徑損耗（Path Loss），可做到動態切換頻段，並且建立白名單和黑名單的機制。
1.2 LE 同步傳輸通道的協議數據單元
BT 5.2 提供同步通道 (ISOC - isochronous channels) 的協議數據單元(Protocol Data Unit) ，如『圖1.2.1』( 註1 ) 。
這是為了 LE Audio 而先建立的標準，所以其它與 BT 5.0 類似的傳輸模式，就沒有再做比較，同步通道主要用來傳送等時同步的數據串流 ( 音頻串流 )，聲音是需要同步的，若沒有同步，有些音頻資料會失去意義，例如左右聲道的內容若是不同步，人耳接收到的感覺會完全不同，同步通道的封包主要是分成3個部份 封包頭Header ，內含資料Payload 和 訊息完整性檢測MIC ( Messages Integrity Check )，當Payload不加密或者Payload長度為0時，MIC 欄位是不存在的，因為沒加密或沒資料，就無需檢測的機制，所以就沒存在的必要。
圖 1.2.1 ( 註1 )
在此基礎之下，又分成 連接或是廣播的同步傳輸通道的 PDU。
(1) 連接的同步傳輸通道的 PDU。
協議數據單元的差異在 Header，連接的同步的 Header 如圖1.2.2，是圖1.2.1 的前 16 bits Header。
圖 1.2.2 ( 註1 )
以下是 Header 內容說明，如『圖1.2.3』( 註1 ) =>。
圖 1.2.3 ( 註1 )
LLID =>是表示 CIS ( Connected Isochronous Stream ) 的 payload 內容的類型，分成以下 4 種 :
0b00 : 不是一個完整 frame 的 連接同步數據串流 ( CIS ); 服務資料單元 ( SDU - Service Data Unit) 的結束片段 或是一個完整的 SDU。
0b01 : 不是一個完整 frame 的 連接同步數據串流 ( CIS ); 開始或是繼續分段的 SDU。
0b10 : 一個完整 frame 的 連接同步數據串流 ( CIS ); 一個或多段的 SDU。
0b11 : 保留未使用。
NESN =>是表示 下一個預期的序列號
SN =>是表示 目前的序列號
CIE =>是表示 關閉同步的事件，定義在 Section 4.5.13.4. 中， 設置為 1 將不會在當前 CIS 事件的剩餘子事件中傳輸，在Master or Slave 端可以用此來結束同步事件傳輸。
NPI =>是表示 指示數據包是否為 CIS 數據 PDU 或 CIS 為空的PDU。
Length => 是表示 payload和 MIC ( 如果有的話 ) 的大小（以Byte (octets) 為單位）。
協議數據單元的差異在 Header，連接的同步的 Header 如『圖1.2.4』( 註1 ) ，是圖1.2.1 的前 16 bits Header。
(2) 廣播的同步傳輸通道的 PDU
圖 1.2.4 ( 註1 )
以下是 Header 內容說明，如『圖1.2.5』( 註1 ) =>。
圖 1.2.5 ( 註1 )
LLID =>是表示 BIS ( Broadcast Isochronous Stream ) 的 payload 內容的類型，分成以下 4 種 :
0b00 : 不是一個完整 frame 的 廣播同步數據串流 ( BIS ); 服務資料單元 ( SDU - Service Data Unit) 的結束片段 或是一個完整的 SDU。
0b01 : 不是一個完整 frame 的 廣播同步數據串流 ( BIS ); 開始或是繼續分段的 SDU。
0b10 : 一個完整 frame 的 廣播同步數據串流 ( BIS ); 一個或多段的 SDU。
0b11 : BIG ( Broadcast Isochronous Group ) Control PDU。它的 payload 會不一樣，如『圖1.2.6』( 註1 ) 。
圖 1.2.6 ( 註1 )
CCSN =>是表示 控制子事件序列號
CSTF =>是表示 控制子事件傳輸的旗標
Length => 是表示 payload和 MIC ( 如果有的話 ) 的大小（以Byte (octets) 為單位）
整體來說在 BLE 5.2 的同步通道傳輸是 LE Audio 實現的關鍵，不論是廣播 ( Broadcast Isochronous Group - BIG)或是連接 ( Connected Isochronous Group - CIG ) 都可以一次對多個裝置同步傳輸，" 使用 LC3 -- Low Complexity Communication Codec 來做為音頻的編解碼" ( 『詳細的 LC3 出處』( 註2 ) 有一份 LC3 規格書來說明此架構 ) ，來讓人聽的見和聽的清楚，並且比 BT Audio 更加的省電。
- 註 1 : 作者 : Bluetooth SIG Proprietary ; 出處 : BLUETOOTH CORE SPECIFICATION Version 5.2=> https://www.bluetooth.com/specifications/specs/core-specification-5-2/ ( 圖片皆由 此 規格書為基礎修改而成 )
- 註 2 : 作者 : Bluetooth SIG Proprietary ; 出處 : LC3 => https://www.bluetooth.com/learn-about-bluetooth/recent-enhancements/le-audio/#lc3
評論