使用藍牙 LE 的助聽器音頻支持

通過使用基於連接的 L2CAP 通道 (CoC) 而非藍牙低功耗 (BLE)，助聽器設備 (HA) 可以提高基於 Android 的移動設備的可訪問性。 CoC 使用多個音頻數據包的彈性緩衝區來維持穩定的音頻流，即使存在數據包丟失也是如此。此緩衝區以延遲為代價為助聽器設備提供音頻質量。

CoC 的設計參考了藍牙核心規範版本 5 (BT)。為了與核心規範保持一致，此頁面上的所有多字節值都應讀取為 little-endian。

術語

• Central - 通過藍牙掃描廣告的 Android 設備。
• 外圍設備- 通過藍牙發送廣告數據包的助聽器。

網絡拓撲和系統架構

將 CoC 用於助聽器時，網絡拓撲假設一個中央和兩個外圍設備，一個左一個右，如圖 1 所示。藍牙音頻系統將左右外圍設備視為單個音頻接收器。如果由於單聲道適配或連接丟失而缺少外圍設備，則中央設備會混合左右音頻通道並將音頻傳輸到剩餘的外圍設備。如果中央失去與兩個外圍設備的連接，則中央認為與音頻接收器的鏈接丟失。在這些情況下，中央將音頻路由到另一個輸出。

圖 1.使用 CoC over BLE 將助聽器與 Android 移動設備配對的拓撲

當中央不向外圍設備傳輸音頻數據並且可以保持 BLE 連接時，中央不應斷開與外圍設備的連接。保持連接允許與駐留在外圍設備上的 GATT 服務器進行數據通信。

在配對和連接助聽器時，中心應：

• 跟踪最近配對的左右外圍設備。
• 如果存在有效配對，則假定外圍設備正在使用中。當連接丟失時，中心應嘗試與配對設備連接或重新連接。
• 如果刪除配對，則假設外圍設備不再使用。

在上述情況下，配對是指在操作系統中使用給定的 UUID 和左/右標識符註冊一組助聽器的操作，而不是藍牙配對過程。

系統要求

為了正確實施 CoC 以獲得良好的用戶體驗，中央和外圍設備中的藍牙系統應：

• 實施兼容的 BT 4.2 或更高版本的控制器。強烈建議使用 LE 安全連接。
• 讓中央支持至少 2 個同時具有參數的 LE 鏈路，如音頻數據包格式和時序中所述。
• 讓外設支持至少 1 個 LE 鏈接，參數在音頻包格式和時序中描述。
• 具有基於 LE 信用的流量控制 [BT Vol 3, Part A, Sec 10.1]。設備應在 CoC 上支持至少 167 字節的 MTU 和 MPS 大小，並且能夠緩衝多達 8 個數據包。
• 具有至少 167 字節有效載荷的 LE 數據長度擴展 [BT Vol 6, Part B, Sec 5.1.9]。
• 讓中央設備支持 HCI LE 連接更新命令並遵守非零maximum_CE_Length和minimum_CE_Length參數。
• 讓中央保持兩個 LE CoC 連接到兩個不同外設的數據吞吐量，其中連接間隔和有效負載大小採用音頻數據包格式和時序。
• 讓外設將LL_LENGTH_REQ或LL_LENGTH_RSP幀中的MaxRxOctets和MaxRxTime參數設置為這些規範所需的最小要求值。這讓中央在計算接收幀所需的時間量時優化其時間調度程序。

強烈建議中央和外圍設備支持 BT 5.0 規範中指定的 2MB PHY。中心應在 1M 和 2M PHY 上支持至少 64 kbit/s 的音頻鏈路。不應使用 BLE 遠程 PHY。

CoC 使用標準藍牙機制進行鏈路層加密和跳頻。

ASHA GATT 服務

外圍設備應實現如下所述的助聽器音頻流 (ASHA) GATT 服務器服務。當處於一般可發現模式時，外圍設備應通告此服務，以讓中央識別音頻接收器。任何 LE 音頻流操作都需要加密。 BLE 音頻流包含以下特徵：

分配給服務和特徵的 UUID：

服務 UUID ： {0xFDF0}

除了 ASHA GATT 服務外，外設還應實現設備信息服務，讓中央檢測外設的製造商名稱和設備名稱。

只讀屬性

ReadOnlyProperties 具有以下值：

設備能力

HiSyncID

此字段對於所有雙耳設備必須是唯一的，但對於左右集必須相同。

特徵圖

編解碼器 ID

如果設置了該位，則支持該特定編解碼器。

音頻控制點

當 LE CoC 關閉時，無法使用此控制點。有關過程說明，請參閱啟動和停止音頻流。

ASHA GATT 服務的廣告

服務 UUID必須在廣告數據包中。在廣告或掃描響應幀中，外圍設備必須具有服務數據：

外圍設備必須具有指示助聽器名稱的完整本地名稱數據類型。此名稱將用於移動設備的用戶界面，以便用戶選擇正確的設備。該名稱不應指示左聲道或右聲道，因為此信息在DeviceCapabilities中提供。

如果外設將名稱和 ASHA 服務數據類型放在同一幀類型（ADV 或 SCAN RESP）中，則這兩種數據類型（“完整本地名稱”和“ASHA 服務的服務數據”）應出現在同一幀中。這使移動設備掃描儀可以在同一掃描結果中獲取這兩個數據。

在初始配對期間，外設以足夠快的速度進行廣告以讓移動設備快速發現外設並綁定到它們是很重要的。

同步左右外圍設備

為了在 Android 移動設備上使用藍牙，外圍設備負責確保它們同步。左右外圍設備的播放需要及時同步。兩個外圍設備必須同時播放來自源的音頻樣本。

外圍設備可以通過使用附加到音頻有效負載的每個數據包的序列號來同步它們的時間。中央保證要在每個外圍設備上同時播放的音頻數據包具有相同的序列號。序列號在每個音頻包之後遞增 1。每個序列號為 8 位長，因此序列號將在 256 個音頻包之後重複。由於每個連接的每個音頻包大小和採樣率都是固定的，因此兩個外設可以推斷出相對播放時間。有關音頻數據包的更多信息，請參閱音頻數據包格式和時序。

當同步可能需要發生時，中央通過向雙耳設備提供觸發器來提供幫助。每當有可能影響同步的操作時，這些觸發器都會通知每個外圍設備其配對外圍設備的狀態。觸發器是：

• 作為 AudioControlPoint 的«Start»命令的一部分，給出了雙耳設備另一側的當前連接狀態。
• 每當在一個外圍設備上進行連接、斷開連接或連接參數更新操作時，AudioControlPoint 的«Status»命令都會發送到雙耳設備的另一側。

音頻包格式和時序

將音頻幀（樣本塊）打包成數據包可以讓助聽器從鏈路層時序錨點中獲取時序。為了簡化實施：

• 音頻幀應始終與連接間隔及時匹配。例如，如果連接間隔為 20 毫秒，採樣率為 16 kHz，則音頻幀應包含 320 個樣本。
• 系統中的採樣率被限制為 8kHz 的倍數，因此無論幀時間或連接間隔如何，一幀中始終有整數個樣本。
• 一個序列字節應放在音頻幀之前。序列字節應使用迴繞進行計數，並允許外設檢測緩衝區不匹配或下溢。
• 音頻幀應始終適合單個 LE 數據包。音頻幀應作為單獨的 L2CAP 數據包發送。 LE LL PDU 的大小應為：
  音頻有效載荷大小 + 1（序列計數器）+ 6（4 用於 L2CAP 標頭，2 用於 SDU）
• 一個連接事件應該總是足夠大以包含 2 個音頻數據包和 2 個空數據包，以便 ACK 為重新傳輸保留帶寬。請注意，音頻數據包可能會被中央的藍牙控制器分段。外圍設備必須能夠在每個連接事件中接收超過 2 個分段的音頻數據包。

為了給中心一些靈活性，沒有指定 G.722 數據包長度。 G.722 數據包長度可以根據中心設置的連接間隔而改變。

G.722 輸出八位字節格式參考Rec. ITU-T G.722 (09/2012) 第 1.4.4 節“多路復用器”

對於外設支持的所有編解碼器，外設應支持以下連接參數。這是中央可以實施的配置的非詳盡列表。

啟動和停止音頻流

在開始音頻流之前，中央查詢外圍設備並建立一個共同的分母編解碼器。然後流設置通過以下順序進行：

1. PSM 和可選的 RenderDelay 被讀取。這些值可能會被中央緩存。
2. CoC L2CAP 通道打開 - 外設最初應授予 8 個學分。
3. 發出連接更新以將鏈接切換到所選編解碼器所需的參數。中心可能會在上一步中的 CoC 連接之前進行此連接更新。
4. 中央主機和外圍主機都等待更新完成事件。
5. 重新啟動音頻編碼器，並將數據包序列計數重置為 0。在 AudioControlPoint 上發出帶有相關參數的«Start»命令。在流式傳輸之前，中央等待來自外圍設備的先前«Start»命令的成功狀態通知。這種等待使外圍設備有時間準備其音頻播放管道。在音頻流傳輸期間，即使當前的副本延遲可能不為零，副本也應該在每個連接事件中都可用。
6. 外圍設備從其內部隊列（序列號 0）中獲取第一個音頻包並播放它。

中央發出«停止»命令以關閉音頻流。在此命令之後，外圍設備不需要在每個連接事件上都可用。要重新開始音頻流，請按照上述順序，從第 5 步開始。當中央不流音頻時，它仍應為 GATT 服務保持 LE 連接。

外圍設備不應向中央設備發布連接更新。為了節省電量，當外圍設備不流式傳輸音頻時，中央設備可能會向外圍設備發出連接更新。