使用藍牙 LE 的助聽器音訊支援

透過在低功耗藍牙 (BLE) 上使用面向連線的 L2CAP 通道 (CoC)，助聽器裝置 (HA) 可以提高 Android 行動裝置上的可存取性。 CoC 使用多個音訊資料包的彈性緩衝區來維持穩定的音訊串流，即使存在資料包遺失也是如此。此緩衝器以延遲為代價為助聽設備提供音訊品質。

CoC 的設計參考了藍牙核心規格版本 5 (BT)。為了與核心規格保持一致，該頁上的所有多位元組值應以小端方式讀取。

術語

• Central - 透過藍牙掃描廣告的 Android 裝置。
• 週邊設備 - 透過藍牙發送廣告資料包的助聽器。

網路拓撲和系統架構

當 CoC 用於助聽器時，網路拓撲假設有一個中央設備和兩個外圍設備（一左一右），如圖1所示。藍牙音訊系統將左右週邊視為單一音訊接收器。如果因單聲道配合或連接遺失而導致外圍設備遺失，則中央設備會混合左右音訊通道並將音訊傳輸到其餘外圍設備。如果中央設備失去與兩個週邊設備的連接，則中央設備認為與音訊接收器的連結遺失。在這些情況下，中央設備會將音訊路由到另一個輸出。

圖 1.使用 CoC over BLE 將助聽器與 Android 行動裝置配對的拓撲

當中央設備未將音訊資料傳輸至週邊且可保持 BLE 連線時，中央裝置不應與週邊裝置斷開連線。維持連線允許與駐留在外圍設備上的 GATT 伺服器進行資料通訊。

配對和連接聽力設備時，中心應：

• 追蹤最近配對的左右外圍設備。
• 如果存在有效配對，則假設週邊設備正在使用中。當連線遺失時，中心應嘗試連線或重新連線配對裝置。
• 如果刪除配對，則假設週邊設備不再使用。

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

系統需求

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

• 實施相容的 BT 4.2 或更高版本的控制器。強烈建議 LE 安全連線。
• 中央支援至少 2 個同步 LE 連結，其參數如音訊資料包格式和時序所述。
• 讓週邊裝置支援至少 1 個 LE 連結，其參數在音訊資料包格式和時序中描述。
• 具有基於 LE 信用的流量控制 [BT 第 3 卷，A 部分，第 10.1 節]。設備應支援 CoC 上至少 167 位元組的 MTU 和 MPS 大小，並能夠緩衝最多 8 個資料包。
• 具有 LE 資料長度擴展 [BT 第 6 卷，B 部分，第 5.1.9 節]，有效負載至少為 167 位元組。
• 讓中央設備支援 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 伺服器服務。當處於一般可發現模式時，外圍設備應通告此服務，以使中央設備識別音訊接收器。任何 LE 音訊串流操作都需要加密。 BLE 音訊串流具有以下特徵：

分配給服務和特徵的 UUID：

服務 UUID ： {0xFDF0}

除了ASHA GATT服務外，週邊還應實現設備資訊服務，以便中心檢測週邊裝置的製造商名稱和設備名稱。

只讀屬性

ReadOnlyProperties 具有以下值：

設備能力

同步ID

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

特徵圖

編解碼器 ID

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

音訊控制點

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

音訊狀態點

音訊控制點的狀態報告字段

ASHA GATT 服務廣告

服務UUID必須位於通告資料包中。在廣告或掃描回應影格中，外設必須具有服務資料：

週邊設備必須具有完整的本地名稱資料類型，用於指示助聽器的名稱。該名稱將在行動裝置的使用者介面上使用，以便使用者可以選擇正確的裝置。該名稱不應指示左聲道或右聲道，因為該資訊是在DeviceCapability中提供的。

如果週邊裝置將名稱和ASHA 服務資料類型放在同一幀類型（ADV 或SCAN RESP）中，則這兩種資料類型（「完整本機名稱」和「ASHA 服務的服務資料」）應出現在同一幀中。這使得行動裝置掃描器可以在同一掃描結果中取得這兩個資料。

在初始配對期間，重要的是外圍設備以足夠快的速度進行通告，以便讓行動裝置快速發現週邊設備並與其綁定。

同步左右外圍設備

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

週邊設備可以透過使用音訊有效負載的每個資料包前面的序號來同步其時間。中央設備保證在每個週邊設備上同時播放的音訊資料包具有相同的序號。每個音訊資料包後序號加一。每個序號都是 8 位元長，因此序號將在 256 個音訊資料包後重複。由於每個連接的每個音訊資料包大小和取樣率都是固定的，因此兩個週邊可以推斷出相對播放時間。有關音訊資料包的更多信息，請參閱音訊資料包格式和時序。

當需要同步時，中央設備會透過向雙耳設備提供觸發器來提供協助。每當存在可能影響同步的操作時，這些觸發器都會通知每個週邊其配對的周邊的狀態。觸發器是：

• 作為 AudioControlPoint 的«Start»命令的一部分，給出了雙耳設備另一側的當前連接狀態。
• 每當一個週邊設備上有連接、斷開連接或連接參數更新操作時，AudioControlPoint 的«Status»指令就會傳送到雙耳設備的另一側。

音訊資料包格式和時序

將音訊幀（樣本區塊）打包到資料包中可以讓助聽器從連結層定時錨點取得定時。為了簡化實施：

• 音訊幀應始終與連線間隔及時匹配。例如，如果連接間隔為20ms，取樣率為16kHz，則音訊幀應包含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 連線。

外圍設備不得向中央設備發出連線更新。為了節省電力，中央設備可以在不傳輸音訊時向外圍設備發出連接更新。