助聽器 (HA) 裝置可透過藍牙低功耗 (BLE) 使用連線導向 L2CAP 管道 (CoC)，在 Android 行動裝置上提升無障礙功能。CoC 會使用數個音訊封包的彈性緩衝區，即使發生封包遺失情形，也能維持穩定的音訊串流。這個緩衝區會以延遲為代價，為助聽器裝置提供音訊品質。
CoC 的設計參考了 藍牙核心規格第 5 版 (BT)。為符合核心規格，本頁面上的所有多位元組值都必須以小端序讀取。
術語
- 中央
- 透過藍牙掃描廣告的 Android 裝置。
- 周邊裝置
- 透過藍牙傳送廣告封包的助聽器。
網路拓撲和系統架構
使用 CoC 助聽器時，網路拓撲會假設有一個中央裝置和兩個周邊裝置 (左側和右側各一)，如圖 1 所示。藍牙音訊系統會將左右兩側的周邊裝置視為單一音訊接收器。如果因單聲道設定或連線中斷而缺少周邊裝置，中央裝置會混音左右聲道，並將音訊傳輸至其餘周邊裝置。如果中央裝置與兩個周邊裝置的連線都中斷，中央裝置就會視為與音訊接收器的連結中斷。在這種情況下，中樞會將音訊傳送至其他輸出裝置。
圖 1. 拓撲圖：使用 CoC over BLE 將助聽器與 Android 行動裝置配對。
如果中央裝置未將音訊資料串流至周邊裝置，且可以維持 BLE 連線，中央裝置就不應與周邊裝置中斷連線。維持連線可讓資料與周邊裝置上的 GATT 伺服器通訊。
配對及連線助聽器時，中央裝置必須：
- 追蹤最近配對的左右周邊裝置。
- 如果配對有效，請假設周邊設備正在使用中。連線中斷時，中央裝置必須嘗試連線或重新連線至配對裝置。
- 刪除配對後，系統會假設周邊裝置不再使用。
在上述情況中，「配對」是指在 OS 中註冊一組助聽器，並提供 UUID 和左右標示的動作，而非藍牙配對程序。
系統需求
如要正確導入 CoC，提供良好的使用者體驗，中央和周邊裝置的藍牙系統必須：
- 實作符合規範的 BT 4.2 以上版本控制器。強烈建議使用 LE 安全連線。
- 中央支援至少 2 個同步 LE 連結，且參數如「音訊封包格式和時間碼」所述。
- 周邊裝置至少支援 1 個 LE 連結，且參數如「音訊封包格式和時間碼」所述。
- 具有以 LE 信用為基礎的流量控制機制 [BT Vol 3, Part A, Sec 10.1]。 裝置必須支援 CoC 上至少 167 位元組的 MTU 和 MPS 大小，且能夠緩衝最多 8 個封包。
- 具有 LE 資料長度擴充功能 [BT Vol 6, Part B, Sec 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 服務
周邊裝置必須實作下述助聽器音訊串流 (ASHA) GATT 伺服器服務。周邊裝置必須在一般可探索模式中宣傳這項服務，讓中央裝置辨識音訊接收器。所有 LE 音訊串流作業都必須加密。BLE 音訊串流包含下列特徵：
| 特徵 | 屬性 | 說明 |
|---|---|---|
| ReadOnlyProperties | 閱讀內容 | 請參閱「ReadOnlyProperties」。 |
| AudioControlPoint | 撰寫和撰寫但不回覆 | 音訊串流的控制點。請參閱 AudioControlPoint。 |
| AudioStatusPoint | 讀取/通知 | 音訊控制點的狀態報告欄位。請參閱「AudioStatusPoint」。 |
| 音量 | 撰寫但不回覆 | 介於 -128 和 0 之間的位元組，表示要套用至串流音訊訊號的衰減量，範圍從 -48 dB 到 0 dB。設定為 -128 時，系統會解讀為完全靜音，也就是說，最低非靜音音量為 -127，相當於衰減 -47.625 dB。在設定 0 時，串流的軌對軌正弦音調必須代表助聽器上相當於 100 dBSPL 的輸入。中央裝置必須以名義全音階串流，並使用這個變數在周邊裝置中設定所需的呈現層級。 |
| LE_PSM_OUT | 閱讀內容 | 用於連線音訊通道的 PSM。可從動態範圍 [BT Vol 3, Part A, Sec 4.22] 中挑選 |
指派給服務和特徵的 UUID：
服務 UUID：{0xFDF0}
| 特徵 | UUID |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| AudioStatus | {38663f1a-e711-4cac-b641-326b56404837} |
| 音量 | {00e4ca9e-ab14-41e4-8823-f9e70c7e91df} |
| LE_PSM_OUT | {2d410339-82b6-42aa-b34e-e2e01df8cc1a} |
除了 ASHA GATT 服務外，週邊裝置也必須實作裝置資訊服務，讓中央裝置偵測週邊裝置的製造商名稱和裝置名稱。
ReadOnlyProperties
ReadOnlyProperties 的值如下：
| 位元組 | 說明 |
|---|---|
| 0 | 版本 - 必須為 0x01 |
| 1 | 請參閱「DeviceCapabilities」。 |
| 2-9 | 請參閱 HiSyncId。 |
| 10 | 請參閱「FeatureMap」。 |
| 11-12 | RenderDelay。這是指從周邊裝置收到音訊影格，到周邊裝置算繪輸出內容的時間 (以毫秒為單位)。這些位元組可用於延遲影片，以便與音訊同步。 |
| 13-14 | 保留供日後使用。初始化為零。 |
| 15-16 | 支援的轉碼器 ID。這是支援的轉碼器 ID 的位元遮罩。位元位置中的 1 對應至支援的轉碼器。舉例來說，0x0002 表示支援 16 kHz 的 G.722。其他位元必須設為 0。 |
DeviceCapabilities
| 位元 | 說明 |
|---|---|
| 0 | 裝置側 (0：左側，1：右側) |
| 1 | 指出裝置是單獨接收單聲道資料，還是屬於一組裝置 (0：單聲道，1：雙聲道)。 |
| 2 | 裝置是否支援 CSIS (0：不支援，1：支援) |
| 3-7 | 已保留 (設為 0) |
HiSyncID
所有雙耳裝置的此欄位都不得重複，但左右耳機必須相同。
| 位元組 | 說明 |
|---|---|
| 0-1 | 製造商的 ID。這是 BTSIG 指派的公司 ID。 |
| 2-7 | 識別助聽器組的專屬 ID。左右兩側周邊裝置的 ID 必須相同。 |
FeatureMap
| 位元 | 說明 |
|---|---|
| 0 | 是否支援 LE CoC 音訊輸出串流 (是/否)。 |
| 1-7 | 保留 (設為 0)。 |
轉碼器 ID
如果已設定位元，則表示支援該特定轉碼器。
| ID / 位元數 | 轉碼器和取樣率 | 必要位元率 | 影格時間 | 必須在中央 (C) 或周邊 (P) 裝置上執行 |
|---|---|---|---|---|
| 0 | 保留 | 保留 | 保留 | 保留 |
| 1 | G.722 @ 16 kHz | 64 KB/秒 | 變數 | C 和 P |
|
2 到 15 號保留。 0 也已保留。 |
||||
AudioControlPoint
LE CoC 關閉時，無法使用這個控制點。如需程序說明，請參閱「啟動及停止音訊串流」。
| Opcode | 引數 | GATT 子程序 | 說明 |
|---|---|---|---|
1 «Start» |
|
撰寫回應，並預期透過 AudioStatusPoint 特徵取得額外狀態通知。 |
指示周邊裝置重設轉碼器，並開始播放第 0 個影格。編解碼器欄位會指出要用於這項播放作業的編解碼器 ID。
舉例來說，16 kHz 的 G.722 編碼器欄位為「1」。 音訊類型位元欄位表示串流中存在的音訊類型：
周邊裝置不得在收到 «Stop» opcode 前要求更新連線。
|
2 «Stop» |
無 | 撰寫回應，並預期透過 AudioStatusPoint 特徵取得額外狀態通知。 | 指示周邊裝置停止算繪音訊。停止後應啟動新的音訊設定序列，才能再次算繪音訊。 |
3 «Status» |
|
撰寫但不回覆 |
告知已連線的周邊裝置，其他周邊裝置的狀態已更新。連結的欄位會指出更新類型：
|
AudioStatusPoint
音訊控制點的狀態報告欄位
| 運算碼 | 說明 |
|---|---|
| 0 | 狀態正常 |
| -1 | 不明指令 |
| -2 | 違法參數 |
ASHA GATT 服務的廣告
服務 UUID 必須位於廣告封包中。在廣告或掃描回應框架中，周邊裝置必須具備服務資料：
| 位元組偏移 | 名稱 | 說明 |
|---|---|---|
| 0 | 廣告長度 | >= 0x09 |
| 1 | 廣告類型 | 0x16 (服務資料 - 16 位元 UUID) |
| 2 到 3 項 | 服務 UUID |
0xFDF0 (little-endian) 注意：這是暫時 ID。 |
| 4 | 通訊協定版本 | 0x01 |
| 5 | 功能 |
|
| 6-9 | 截斷的 HiSyncID | HiSyncId 的四個最重要的位元組。這些位元組應是 ID 中最隨機的部分。 |
周邊裝置必須具有「完整本機名稱」資料型別，指出助聽器的名稱。這個名稱會顯示在行動裝置的使用者介面上，方便使用者選取正確的裝置。名稱不得指出左或右聲道，因為這項資訊已在 DeviceCapabilities 中提供。
如果周邊裝置將名稱和 ASHA 服務資料類型放在相同框架類型 (ADV 或 SCAN RESP) 中，則這兩種資料類型 (「完整本機名稱」和「ASHA 服務的服務資料」) 必須出現在相同框架中。這樣一來，行動裝置掃描器就能在同一個掃描結果中取得這兩項資料。
在初始配對期間，周邊裝置必須以足夠快的速率播送廣告，行動裝置才能快速探索周邊裝置並與其繫結。
同步處理左右周邊裝置
如要在 Android 行動裝置上使用藍牙，周邊裝置必須確保同步。左側和右側周邊裝置的播放內容必須同步。兩個周邊裝置必須同時播放來源的音訊樣本。
周邊裝置可以透過音訊酬載各封包前置的序號，同步處理時間。中央裝置會確保要在每個周邊裝置上同時播放的音訊封包，具有相同的序號。每個音訊封包後，序號會遞增 1。每個序號長度為 8 位元，因此序號會在 256 個音訊封包後重複。由於每個連線的音訊封包大小和取樣率都是固定的，因此這兩個周邊裝置可以推斷相對播放時間。如要進一步瞭解音訊封包，請參閱「音訊封包格式和時間碼」。
中央裝置會在可能需要同步處理時，提供觸發條件給雙耳裝置，協助進行同步。每當有作業可能影響同步作業時，這些觸發條件就會通知每個周邊裝置配對周邊裝置的狀態。觸發條件包括：
-
在 AudioControlPoint 的
«Start»指令中，會提供雙耳裝置另一端的目前連線狀態。 -
每當一個周邊裝置有連線、中斷連線或連線參數更新作業時，AudioControlPoint 的
«Status»指令會傳送至雙耳裝置的另一端。
音訊封包格式和時間碼
將音訊影格 (樣本區塊) 封裝到封包中，可讓助聽器從連結層時間錨點衍生時間。為簡化實作程序：
- 音訊影格的時間長度應一律與連線間隔相符。 舉例來說，如果連線間隔為 20 毫秒，取樣率為 16 kHz，則音訊影格必須包含 320 個樣本。
- 系統中的取樣率會限制為 8 kHz 的倍數，確保無論影格時間或連線間隔為何，影格中一律會有整數個樣本。
- 音訊影格前必須加上序列位元組。序列位元組必須以環繞方式計數，並允許周邊裝置偵測緩衝區不符或溢位。
-
音訊影格一律必須符合單一 LE 封包。音訊影格必須以個別的 L2CAP 封包傳送。LE LL PDU 的大小必須為：
音訊酬載大小 + 1 (序號計數器) + 6 (L2CAP 標頭為 4，SDU 為 2) - 連線事件的大小應足以容納 2 個音訊封包和 2 個空白封包，以保留頻寬供 ACK 進行重傳。請注意，音訊封包可能會遭到中央藍牙控制器分割。週邊裝置必須能在每個連線事件中接收超過 2 個音訊封包片段。
為提供中央一些彈性，系統不會指定 G.722 封包長度。G.722 封包長度可能會根據中央設定的連線間隔而變更。
G.722 輸出八位元格式參照Rec. ITU-T G.722 (09/2012) 第 1.4.4 節「Multiplexer」。
對於周邊裝置支援的所有轉碼器，周邊裝置必須支援下列連線參數。以下僅列舉部分中央裝置可實作的設定。
| 轉碼器 | 位元率 | 連線間隔 | CE 長度 (1M/2M PHY) | 音訊酬載大小 |
|---|---|---|---|---|
| G.722 @ 16 kHz | 64 KB/秒 | 20 毫秒 | 5000/3750 us | 160 個位元組 |
開始及停止音訊串流
開始音訊串流前，中樞會查詢周邊裝置，並建立共同的編碼器。接著，串流設定會依序進行下列步驟：
- 系統會讀取 PSM，並視需要讀取 RenderDelay。這些值可能會由中央裝置快取。
- CoC L2CAP 通道已開啟 - 周邊裝置必須先授予 8 個信用額度。
- 系統會發出連線更新，將連結切換至所選轉碼器所需的參數。中央可能會在先前步驟中的 CoC 連線之前，執行這項連線更新。
- 中央和周邊主機都會等待更新完成事件。
-
重新啟動音訊編碼器，並將封包序號計數重設為 0。
在 AudioControlPoint 上發出含相關參數的
«Start»指令。中央裝置會等待周邊裝置傳送先前«Start»指令的成功狀態通知，然後再開始串流。這段等待時間可讓周邊裝置準備音訊播放管道。在音訊串流期間，即使目前的副本延遲時間可能不為零，副本也應在每個連線事件中可用。 - 周邊裝置會從內部佇列中取出第一個音訊封包 (序號 0) 並播放。
中央會發出「停止」指令來關閉音訊串流。執行這項指令後，周邊裝置就不必在每個連線事件中都可用。如要重新啟動音訊串流，請從步驟 5 開始，按照上述順序操作。即使中央裝置未串流音訊，仍應維持 GATT 服務的 LE 連線。
周邊裝置不得向中央裝置發出連線更新。 為節省電力，中央裝置可能在未串流音訊時，向周邊裝置發布連線更新。