LE AUDIO---Chapter 2. The Bluetooth? LE Audio architecture

?2.1 The use cases

?2.1.1 Hearing aid requirements - the use cases

?2.1.1.1 Basic telephony

?2.1.1.2 Low latency audio from a TV

?2.1.1.3????Adding more users

?2.1.1.4??Adding more listeners to support larger areas

?2.1.1.5 Coordinating left and right hearing aids

?2.1.1.6 Help with finding broadcasts and encryption

?2.1.1.7 Practical requirements

?2.1.2 Doing everything that HFP and A2DP can do

?2.1.3 Evolving beyond HFP and A2DP

?2.1.4 Addressing future audio applications

?2.1.5 Core requirements to support the hearing aid use cases

?2.2 The Bluetooth LE Audio architecture

?2.2.1 Profiles and Services

?2.2.2 The Generic Audio Framework

?2.2.3 Stream configuration and management – BAPS

?2.2.4 Rendering and capture control

?2.2.5 Content control

?2.2.6 Transition and coordination control

2.2.7 Top level Profiles?

?2.2.8 The Low Complexity Communications Codec (LC3)

?2.3 Talking about Bluetooth LE Audio

?2.3.1 Acronyms

?2.3.2 Initialisms

?2.3.3 Irregular pronunciations

????????藍牙規范的開發遵循著一套明確的流程。其始于一項新工作提案，該提案會梳理用例并評估任何新功能的市場需求。新工作提案通常由一個小型研究小組制定，小組成員由幾家期望該功能的公司組成，之后提案會被分享給其他感興趣的各方進行評估。在這一階段，藍牙技術聯盟（Bluetooth SIG）會詢問其他成員是否有興趣協助開發該功能并制作原型，以此判斷是否有足夠的支持力度推動其實現。

????????一旦展示出這種程度的承諾，藍牙技術聯盟（Bluetooth SIG）董事會會對其進行審查，并將其分配給一個小組，以將初始提案轉化為一系列需求，并進一步充實用例內容。這些需求會經過審核，以確保它們在不破壞現有藍牙技術架構的前提下融入其中，隨后便開啟開發工作。當規范基本完成后，多家成員公司的實施團隊會開發原型，并在互操作性測試活動中相互測試，以檢驗這些功能是否有效且符合最初的需求。這也能很好地檢驗規范是否清晰易懂、沒有歧義。任何遺留問題會在該階段得到解決，待問題解決且所有功能驗證通過后，規范便會被采納并發布。只有到了這一階段，各公司才被允許生產產品、進行認證并開始銷售。

????????盡管我們在這個過程中始終試圖避免規范膨脹，但幾乎總是失敗，因此新功能往往會被添加到原有功能中。這在藍牙LE音頻的演進過程中尤為明顯，它從一個用于助聽器的相對簡單的解決方案，發展到如今的形式，為未來二十年的藍牙音頻產品提供了工具包。為了幫助理解為何最終形成了二十多個新規范，回顧從最初用例到最終架構確定的歷程會很有幫助。

?2.1 The use cases

????????在藍牙LE音頻發展的最初幾年，我們看到有四大波用例和需求推動其演進。它最初源于助聽器行業的一系列用例，這些用例主要聚焦于拓撲結構、功耗和延遲。隨著越來越多的公司加入，其范圍不斷擴大，經歷了以下幾個需求階段：

?? 助聽器需求

?? 實現HFP和A2DP所能完成的所有功能

?? 超越HFP和A2DP的演進

?? 滿足未來音頻應用需求

?2.1.1 Hearing aid requirements - the use cases

?????????助聽器的拓撲結構相較于藍牙經典音頻配置文件有了重大進步，因此我們將從這里開始介紹。

?2.1.1.1 Basic telephony

?????????圖2.1展示了助聽器的兩種電話通信用例，使助聽器能夠與手機連接。這是一項重要需求，因為將手機靠近耳朵里的助聽器時，常常會造成干擾。

????????最左側的簡單拓撲結構是從手機到助聽器的音頻流，并支持返回流，主要用于電話通信。該拓撲可配置為使用助聽器上的麥克風捕捉返回語音，也可讓用戶直接對著手機講話，這與免提配置文件（HFP）的功能并無不同。但從一開始，助聽器需求就包含音頻流雙向獨立且可由應用程序配置的概念。換言之，從手機到助聽器的流與從助聽器到手機的返回流可分別配置和控制，可單獨開啟或關閉。圖2.1右側的拓撲結構則超越了A2DP或HFP的能力范圍——手機向左右助聽器分別發送獨立的左右音頻流，還可選擇性添加來自各助聽器麥克風的返回流，這帶來了藍牙經典音頻配置文件無法實現的復雜性，需要向兩個獨立音頻設備發送單獨的同步流。

?2.1.1.2 Low latency audio from a TV

????????這一需求的一個有趣延伸源于以下事實：助聽器可能會繼續接收環境聲音以及藍牙音頻流。許多助聽器不會堵塞耳朵（“堵塞”是行業術語，指像耳塞一樣堵住耳朵），這意味著佩戴者總是聽到環境聲音和放大聲音的混合。由于助聽器內環境聲音的處理延遲極小——不到幾毫秒，這不會造成問題。然而，在圖2.2所示的情況下就會成為問題：部分家庭成員通過電視揚聲器收聽聲音，而助聽器使用者則既聽到來自電視的環境聲音，又通過藍牙連接聽到相同的音頻流。?

????????如果兩個音頻信號之間的延遲遠超過30-40毫秒，就會開始被感知為回聲，使聲音更難理解，這與助聽器的設計初衷相悖。30-40毫秒的延遲比大多數現有A2DP解決方案所能提供的延遲要嚴格得多，因此這引入了對極低延遲的新要求。環境聲音30-40毫秒的延遲相當于聲音傳播約10米的時間，這意味著在大多數家庭房間中這不是問題。此外，該延遲也完全在大腦處理唇音同步的能力范圍內，因此無需電視調整視頻渲染延遲，視頻和音頻也會顯得同步。

????????盡管助聽器的帶寬要求相對適中——單聲道語音需7kHz帶寬，立體聲音樂需11kHz帶寬，但現有藍牙編解碼器在滿足該延遲要求的同時，難以輕松滿足這些帶寬需求。這促使我們開展了一項獨立調查，以確定適用編解碼器的性能要求，最終促成了LC3編解碼器的引入，我們將在第5章詳細介紹該編解碼器。

?2.1.1.3????Adding more users

????????聽力損失可能具有家族遺傳性，且常與年齡相關，因此家庭中通常會有不止一人佩戴助聽器。因此，新的拓撲結構需要支持多名助聽器佩戴者。圖2.3展示了兩人的用例，這兩人應體驗相同的延遲。

?2.1.1.4??Adding more listeners to support larger areas

????????該拓撲結構還應具備可擴展性，以便多人收聽，例如在教室、會議中心、劇院或養老院等場景。這一需求將藍牙LE音頻定位為當今感應線圈（telecoil）的補充解決方案，其提供更多功能且安裝更簡便。這需要一個藍牙廣播發射器，能夠廣播單聲道或立體聲音頻流，且范圍內任意數量的助聽器都能接收，如圖2.4所示。

????????圖2.4還表明，有些人僅單耳存在聽力損失，而有些人則雙耳均有聽力損失（且雙耳的聽力損失程度可能不同）。這意味著可同時廣播立體聲信號和單聲道信號。該圖還強調，用戶可能佩戴不同公司的助聽器來應對雙耳聽力差異，或一只耳朵佩戴助聽器、另一只耳朵佩戴消費級耳塞。

?2.1.1.5 Coordinating left and right hearing aids

????????無論組合方式如何，都應能將一對助聽器視為一組單一設備，以便兩者都連接到同一音頻源，并且像音量控制這樣的通用功能能以一致的方式在兩者上起作用。這引入了協調的概念，即來自不同制造商的不同設備將同時接受控制命令并以相同的方式解釋它們。

?2.1.1.6 Help with finding broadcasts and encryption

????????使用感應線圈時，用戶只有一種獲取信號的方式：開啟感應線圈接收器以拾取周圍感應線圈的音頻信號，或關閉接收器。由于一個區域內只能存在一個感應線圈信號，因此用戶無需選擇要接收的信號。但另一方面，這也意味著無法實現同時廣播多種語言等功能。

????????借助藍牙技術，多個廣播發射器可在同一區域內工作。這帶來了顯著優勢，但也引發了兩個新問題：如何拾取正確的音頻流，以及如何防止他人竊聽私密對話。

????????為幫助用戶選擇正確的音頻流，讓用戶能夠獲取可用音頻流的相關信息至關重要，這樣他們就能直接跳轉至偏好選項。該體驗的豐富程度顯然會因廣播流的搜索方式而異——無論是在助聽器、手機還是遙控器上實現搜索，但相關規范需要涵蓋所有這些可能性。許多公共廣播無需保密，因為它們用于強化公共音頻通知，例如下一班公交車的到站時間。然而，其他一些場景則需要隱私保護。在家庭等環境中，用戶不會希望接收到鄰居家的電視音頻。因此，音頻流能夠加密非常重要，這需要具備向授權用戶分發加密密鑰的能力。該過程必須安全，但操作要簡便。

????????除了低延遲外，模擬當前助聽器的使用場景還帶來了其他一些限制。當用戶佩戴兩只助聽器時，無論它們接收的是相同的單聲道還是立體聲音頻流，都需要在25微秒內同步渲染音頻，以確保聲像穩定。這一點對立體聲耳塞同樣適用，但當左右設備可能來自不同制造商時，實現起來頗具挑戰性。值得強調的是，這里的時間單位是微秒而非毫秒，這種同步精度要求比大多數音頻開發人員所習慣的更為嚴苛。

?2.1.1.7 Practical requirements

????????助聽器體積非常小巧，這意味著其按鈕空間極為有限。佩戴者雖涵蓋各年齡段，但部分老年佩戴者的手指靈活性較差，因此將音量調節和連接控制功能集成到其他更易操作的設備上至關重要。這類設備可能是音頻源（通常為用戶的手機），而助聽器用戶也普遍會配備鑰匙扣式的小型遙控器——其優勢在于能即時響應操作：若想調低助聽器音量，只需按下音量鍵或靜音鍵，無需解鎖手機、查找助聽器應用程序再進行控制。后者操作耗時過長，并非多數助聽器用戶青睞的使用體驗。他們需要快速便捷的音量與靜音控制方式，否則可能會直接摘下助聽器，這顯然并非理想的使用狀態。

????????助聽器在音量方面還有另一項要求，即音量級別（實際為增益）應在助聽器上實現。其基本原理是：如果音頻流以線路電平傳輸?，就能獲得最大動態范圍來進行處理。對于正在處理聲音的助聽器而言，輸入信號提供盡可能最佳的信噪比非常重要，尤其是當該信號與來自環境麥克風的音頻流混合時。如果在信號源處降低音頻增益，會導致信噪比惡化。

????????助聽器與耳塞或耳機的一個重要區別在于，助聽器多數時候都處于佩戴狀態且持續工作，會放大并適配環境聲音，以幫助佩戴者更清晰地聆聽。用戶不會頻繁取下助聽器并將其放回充電盒中。一對助聽器的日均佩戴時間通常約為9.5小時，部分用戶甚至可能佩戴15小時以上。這與耳塞和耳機截然不同——后者僅在用戶準備接聽/撥打電話或收聽音頻時才會佩戴。耳塞制造商在充電盒設計上頗具巧思，可促使用戶在白天定期為耳塞充電，從而營造出電池續航更持久的假象。而助聽器無法采用這種方式，因此設計者需竭盡全力將功耗降至最低。

????????消耗電量的因素之一是搜索其他設備及維持后臺連接。耳塞會收到明確的觸發信號——當從充電盒取出并佩戴時，多數耳塞還配備光學傳感器以檢測是否在耳內，若置于桌面則會進入休眠狀態。但助聽器始終處于開啟狀態、持續作為助聽設備工作，因此無法獲得同樣明確的藍牙連接啟動信號。這意味著它們需要在等待事件觸發時，與其他設備維持持續的藍牙連接。這些連接的占空比可以較低，但不能過低，否則可能錯過來電，或對啟動音樂流媒體應用的響應過慢。由于助聽器可能連接多種設備（如電視、手機甚至門鈴），此類連接會過度消耗電量，因此需要一種新機制，使其能與多種不同產品快速連接，同時不縮短電池續航，也無需維持持續連接。我們將在3.7節詳細探討這種新型非連接拓撲模型。

?2.1.2 Doing everything that HFP and A2DP can do

????????隨著消費電子行業開始認識到藍牙LE音頻功能的潛力——這些功能解決了他們多年來發現的許多問題——他們務實地提出了第二輪需求，以確保藍牙LE音頻能夠實現A2DP和HFP所能做的一切。他們指出，如果用戶體驗更差，沒有人會愿意使用藍牙LE音頻而不是傳統藍牙音頻。

????????這些需求提高了對新編解碼器的性能要求，并為媒體和電話控制引入了一套更為復雜的需求。最初的助聽器需求包括與手機交互的有限控制功能，因為假定大多數用戶會直接在手機或電視上控制更復雜的功能，尤其是因為助聽器的用戶界面非常有限。許多消費音頻產品體積更大，因此沒有這種限制。因此，新的電話和媒體控制需求被添加進來，以實現更復雜的控制。

?2.1.3 Evolving beyond HFP and A2DP

????????第三輪需求反映出音頻和電話應用已超越HFP和A2DP的范疇。如今許多通話屬于VoIP5（網絡語音通話），且單一設備（無論是筆記本電腦、平板電腦還是手機）同時接入多個不同通話的情況十分常見。藍牙技術需要一種更優的方式來處理來自多種不同載體的通話。同樣，A2DP在制定時并未預見到流媒體及其伴隨的搜索需求——因為當時用戶擁有本地音樂副本，除了選擇本地文件外，很少進行更復雜的操作。如今的產品需要更復雜的媒體控制功能，還需要能夠支持語音命令而不中斷音樂流。

????????當今的手機和會議應用程序復雜多樣，用戶需要處理多種類型的通話以及音頻流，這意味著他們會更頻繁地在設備和應用程序之間進行切換。HFP和A2DP在架構上的固有差異一直使這一過程困難重重，因此形成了一套最佳實踐規則，構成了適用于HFP和A2DP的多配置文件規范（MPS）。然而，MPS本質上只是針對兩種用例的權宜之計。新的藍牙LE音頻架構必須超越這一局限，通過設計融入多配置文件支持，以應對不斷擴展的用例，實現設備與應用程序之間、單播與廣播之間穩健且互操作的過渡。這也導致了對復雜角色切換的摒棄，這種切換在傳統藍牙應用中增加了復雜度。

????????隨著消費領域越來越多人開始了解助聽器的感應線圈和廣播功能的工作原理，他們逐漸意識到廣播技術可能在大眾消費領域有一些非常有趣的應用。其中最受關注的是，人們發現它可以用于音樂分享，例如朋友之間通過手機共享音樂、無聲迪斯科，或是咖啡店和公共場所的“無聲”背景音樂。像為助聽器佩戴者提供出行信息的公共廣播設施，如今配備藍牙耳機的人都能使用。我們將在第11章和第12章詳細探討的“音頻共享”概念由此誕生。

????????潛在的新用例開始激增。如果我們能為兩個耳塞同步立體聲通道，那為何不用于環繞聲呢？各家公司熱衷于確保藍牙LE音頻支持智能手表和腕帶，這些設備可以充當遙控器，甚至成為帶有嵌入式MP3播放器的音頻源。低延遲特性令游戲界興奮不已。微波爐可以告知你晚餐何時烹飪完成（你能判斷出這個想法源自工程師）。隨著企業看到藍牙LE音頻如何使客戶受益、如何契合其產品戰略以及如何影響語音和音樂的未來使用，用例數量持續增長。

????????功能的多樣性意味著完成該規范耗費了大量時間。令人欣慰的是，過去幾年提出的大多數新用例無需我們回溯并重新修訂規范——我們發現這些用例已被現有定義的架構所支持。這表明藍牙LE音頻標準的設計頗具前瞻性，既能支持當下的音頻應用，也能為未來的新型音頻應用提供支撐。

?2.1.4 Addressing future audio applications

????????該規范的制定工作并未停止。藍牙LE音頻規范的發布意味著現在可以設計和制造范圍極為廣泛的創新產品，但相關工作仍在繼續。在未來幾年，我們將看到更多規范被采用，不過目前這些規范仍處于保密狀態。如果您是藍牙技術聯盟（Bluetooth SIG）的會員或推廣會員，可以通過加入助聽器工作組、通用音頻工作組或音頻、電話與汽車工作組來跟進這項工作。采用會員在規范準備好用于原型設計時，將能夠提前獲取這些規范。

?2.1.5 Core requirements to support the hearing aid use cases

????????在定義了拓撲結構和連接的需求后，顯然需要向核心規范中添加大量新功能以支持這些需求。這引發了新一輪的工作，以確定如何在核心規范中最佳地滿足這些新需求。

????????該流程的首要環節是分析能否通過擴展現有藍牙音頻規范來支持新功能，而非在藍牙低功耗（Bluetooth LE）中引入全新的音頻流傳輸能力。若此方案可行，則能實現與當前音頻配置文件的向后兼容性。結論與藍牙LE首次開發時所做的分析類似：這種方式需做出過多妥協，因此更優選擇是基于藍牙?核心4.1版本進行“白紙一張”的全新設計。

????????藍牙?核心規范的提案是實現一項名為等時通道的新功能，該功能可在藍牙低功耗（Bluetooth LE）中與現有ACL通道并行傳輸音頻流。ACL通道將用于配置、設置和控制音頻流，同時傳輸更通用的控制信息，如音量、電話和媒體控制等。等時通道可支持單向或雙向音頻流，并且能與多個設備建立多個等時通道。這將音頻數據平面和控制平面分離，使藍牙LE音頻具有更高的靈活性。

????????音頻連接的穩健性至關重要，這意味著它們需要支持多次重傳，以應對某些傳輸可能受到干擾的情況。對于單播流，存在ACK/NACK確認機制，因此一旦發送方知道數據已被接收，重傳即可停止。對于沒有反饋的廣播，源端需要無條件重傳音頻數據包。在研究穩健性的過程中，顯然可以改進用于保護LE設備免受干擾的跳頻方案?，因此這被添加為另一項要求。

????????廣播需要一些新概念，尤其是在設備無需建立連接即可發現廣播的方式上。藍牙低功耗（Bluetooth LE）通過廣告幀讓設備宣告自身存在。想要建立連接的設備會掃描這些廣告幀，然后與發現的設備連接，以獲取其支持的功能詳情、連接方式——包括傳輸時間、跳頻序列以及具體功能等信息。這需要的信息量遠超普通藍牙LE廣告幀的承載能力。為克服這一限制，核心規范新增了擴展廣告（EA）和周期性廣告序列（PA）功能，允許通過通用數據通道（通常不用于廣告傳輸）的數據包攜帶這些信息。與此同時，規范還為接收設備新增了相關流程，使其能利用這些信息確定廣播音頻流的位置并與之同步。

????????外部設備需協助發現廣播流的這一需求，催生了一項新要求，即該設備需能告知接收端如何連接至該流——本質上是讓接收端能夠向遙控器請求指引并獲取連接路徑。這通過核心規范中名為PAST（周期性廣告同步傳輸）的功能實現，它是簡化廣播獲取流程的關鍵。PAST對助聽器而言是極具實用價值的功能，因為掃描操作會消耗大量電量。通過將掃描任務卸載至其他設備來最大限度減少掃描，是幫助延長助聽器電池續航的有效方式。

????????針對助聽器的需求還促使核心規范增加了其他幾項功能，主要圍繞性能和節能優化。其一，新編解碼器可在主機（Host）或控制器（Controller）中實現。后一種方式更便于硬件集成，通常能效更高。其二，對單次傳輸或接收的最長持續時間設定限制，這直接影響了等時通道（Isochronous Channels）的數據包結構設計。此舉源于多數助聽器使用鋅空一次性電池——因其具備高能量密度優勢，但這種電池化學特性對電流尖峰和高功率持續輸出非常敏感。若不加以限制，電池壽命將大幅縮短。這些約束條件最終塑造了等時通道的整體設計。

????????核心需求的最后兩項補充（在開發后期才加入）是等時適配層（ISOAL）和增強屬性協議（EATT）的引入。

????????ISOAL允許設備將來自上層的服務數據單元（SDU）轉換為鏈路層不同大小的協議數據單元（PDU），反之亦然。之所以需要這樣做，是為了應對以下情況：設備可能正在為新的LC3編解碼器使用推薦的定時設置（該編解碼器針對10ms幀進行了優化），同時又要與以7.5ms定時間隔運行的舊版藍牙設備建立連接。

????????EATT 是對藍牙低功耗（Bluetooth LE）標準屬性協議（ATT）的增強，允許 ATT 協議的多個實例并發運行。這消除了 ATT 的阻塞限制——在原限制下，每個命令需完成后才能執行下一個命令。

????????擴展廣告功能在藍牙?核心5.0版本中采用。藍牙?核心5.1版本通過周期性廣告對其進行了增強，而藍牙?核心5.2版本則引入了等時通道、增強屬性協議（EATT）和等時適配層（ISOAL）。這些為所有其他藍牙LE音頻規范奠定了基礎。藍牙?核心規范隨后又發布了三個修訂版本——藍牙?核心5.3、5.4和6.0，其中僅包含對等時通道功能的小幅更新，未做重大改動。?

?2.2 The Bluetooth LE Audio architecture

????????藍牙LE音頻架構與之前的所有其他藍牙規范一樣，采用分層構建。圖2.5展示了這一點，該圖顯示了與藍牙LE音頻相關的主要新規范模塊（將現有關鍵模塊標為灰色或虛線）。

????????最底層是核心層，包含射頻和鏈路層（統稱為控制器），負責通過無線發送藍牙數據包。核心層之上是主機層，其任務是告知核心層針對特定應用該執行何種操作。控制器與主機的分離源于歷史原因，這反映了過去藍牙射頻模塊被集成在USB閃存盤或PCMCIA卡中的情況，當時主機作為軟件應用在個人電腦上運行。如今，主機和控制器通常集成在單一芯片中。在手機中，協議棧的大部分可能在手機操作系統中實現，制造商通過自身的應用程序接口（API）向應用開發者開放功能。

????????在主機層中，存在一種名為通用音頻框架（GAF）的新結構。這是一種音頻中間件，包含所有被視為通用的功能，即可能被多個音頻應用使用的特性。核心層和GAF構成了藍牙LE音頻的核心，它們提供了強大的靈活性。最后，在協議棧的頂層，我們有所謂的“頂層”配置文件，這些配置文件為GAF規范添加了特定于應用的信息。

????????僅使用GAF規范就完全可以構建互操作的藍牙LE音頻應用。GAF內的各個規范經過精心定義，以確保基礎級別的互操作性，從而使任意兩款藍牙LE音頻設備都能實現音頻傳輸。頂層配置文件規范主要添加特定類型音頻應用的專屬功能——將GAF中定義為可選的功能設為強制要求，并補充應用專屬的功能邏輯。其設計初衷是讓頂層配置文件相對簡潔，并基于GAF的現有功能構建。在大多數場景下，這些頂層配置文件可視為主要的配置需求集合。

????????乍看之下，藍牙LE音頻架構似乎很復雜，因為通用音頻框架（GAF）內共有18項不同的規范，此外還有擴展的核心層、新的LC3編解碼器以及越來越多的頂層配置文件。但這背后是有邏輯的：每項規范都試圖封裝設置和控制音頻流不同方面的特定要素。在本章的剩余部分，我將簡要解釋每項規范及其相互關聯方式。然后在本書的其余章節中，我們將探討每項規范的具體工作原理及其交互方式。

?2.2.1 Profiles and Services

????????GAF內的所有規范均采用圖2.6所示的標準藍牙LE GATT模型，劃分為配置文件（Profiles）或服務（Services）。

????????在藍牙低功耗（Bluetooth LE）中，配置文件（Profiles）和服務（Services）可被視作為客戶端（Clients）和服務器（Servers）。服務實現在狀態?所在的位置，而配置文件規范則描述狀態的行為方式，包括管理狀態的流程。服務規范定義一個或多個特征（characteristics），這些特征可代表獨立功能或狀態機的各個狀態，也可以作為控制點，促使狀態機的狀態之間發生轉換。配置文件針對這些特征執行操作，對其進行讀取或寫入，并在值發生變化時收到通知。多個設備可各自作為客戶端，對一個服務器進行操作。

????????傳統上，在經典藍牙配置文件（沒有對應服務）中，僅存在單個客戶端與單個服務器的簡單一對一關系，所有內容均在配置文件規范中描述。而在藍牙LE音頻中，一對多拓撲更為常見，尤其是在音量控制和廣播源選擇等功能中，用戶可能擁有多個實現配置文件規范的設備作為客戶端。在大多數情況下，這些客戶端按先來先服務的原則運行。

????????藍牙LE音頻中可使用的不同控制配置文件數量推動了對核心規范的EATT增強。配置文件和服務使用屬性協議（ATT）進行通信，但ATT假定一次僅發生一個命令。如果同時發生多個命令，第二個命令可能會延遲，因為ATT是一種阻塞協議。為解決這個問題，藍牙?核心5.2版本中添加了增強屬性協議（EATT），允許多個ATT實例同時運行。

????????圖2.7概述了藍牙LE音頻架構，為構成通用音頻框架（GAF）的全部18項規范以及當前6項頂層配置文件分別賦予了名稱（更準確地說，是一組字母縮寫）。虛線框表示協同工作的配置文件和服務集合。大多數情況下，配置文件與服務呈一一對應關系，但基本音頻配置文件（BAP）1?和語音控制配置文件（VCP）例外——單個配置文件可作用于三種不同的服務。公共廣播配置文件（PBP）和廣播音頻統一資源標識符（BAU）則屬于特殊情況，因為它們均不對應服務，這是廣播機制的固有特性之一：當不存在連接時，無法實現傳統的客戶端-服務器交互。

?2.2.2 The Generic Audio Framework

????????現在我們可以了解通用音頻框架（GAF）的組成部分。各種規范之間存在大量交互，這使得很難在它們之間畫出清晰的層次結構或一組關系，但大致可以將它們分為四個功能組，如圖2.8所示。

????????這種分組主要是為了便于解釋。在藍牙LE音頻的實際實現中，大多數規范之間都存在不同程度的交互。僅使用其中少數幾個規范就完全可以打造出可用的產品，但要設計功能豐富且具有互操作性的產品，則需要使用大部分規范。

?2.2.3 Stream configuration and management – BAPS

????????從圖2.8的底部開始，我們看到一組由四項規范組成的集合，統稱為BAPS規范。這四項規范構成了通用音頻框架的基礎。其核心是BAP（基本音頻配置文件），用于設置和管理單播及廣播音頻流。作為一種配置文件，它與以下三種服務協同工作：

?- PACS（已發布音頻能力服務）：用于公開設備的各項能力。

?- ASCS（音頻流控制服務）：定義用于設置和維護單播音頻流的狀態機。

?- BASS（廣播音頻掃描服務）：定義用于發現和連接廣播音頻流以及分發廣播加密密鑰的流程。

????????它們共同負責承載音頻數據的底層等時通道的設置方式，同時還為LC3編解碼器定義了標準的配置集合，以及用于廣播和單播應用的相應服務質量（QoS）設置范圍。

????????針對單播和廣播場景，分別為每個獨立的等時通道定義了狀態機。如圖2.9的簡化狀態機所示，這兩類狀態機均會將音頻流從配置狀態轉換為流傳輸狀態。

????????對于單播場景，狀態機在ASCS規范中定義。該狀態存在于服務器的各個音頻端點內，而客戶端控制則在BAP中定義。對于廣播場景，由于發送方和接收方之間不存在連接，客戶端-服務器模型的概念就顯得有些站不住腳。因此，BAP僅為發送方定義了狀態機，且該狀態機完全由其本地應用控制。在廣播場景中，接收方需要檢測流的存在然后進行接收，但無法影響其狀態。

????????多個單播或廣播等時通道會按組綁定（我們將在第4章探討這一內容）。BAP定義了如何針對廣播流和單播流組合這些通道組及其構成的等時通道。

????????僅使用以下三項規范即可打造藍牙LE音頻產品：用于單播的BAP、ASCS和PACS，而廣播場景僅需BAP（不過若想通過手機或遙控器輔助查找廣播內容，則需添加PACS和BASS）。這類設備的功能會非常有限——僅能完成音頻流的建立、傳輸與停止。但正是憑借這些基礎能力，BAPS系列規范為所有藍牙LE音頻設備提供了互操作性基準。即便兩臺藍牙LE音頻設備采用不同的頂層配置文件，它們仍應能通過BAP建立音頻流。雖然功能可能受限，但性能表現應能滿足基本需求，從而解決了經典藍牙音頻中存在的多配置文件不兼容問題（在經典藍牙中，沒有共同音頻配置文件的設備無法協同工作）。

?2.2.4 Rendering and capture control

?????????建立音頻流后，用戶往往希望控制音量，既包括在耳內渲染的音頻流音量，也涉及麥克風的拾音音量。

????????音量控制是一個頗為復雜的話題，因為存在多個可調節音量的位置——聲源設備、助聽器、耳塞或揚聲器上，或者在其他“遠程控制”設備（如智能手表或獨立控制器）上。在藍牙LE音頻中，音量的最終增益調節是在助聽器、耳塞或揚聲器中完成的，而非在編碼前的輸入音頻流上。基于這一前提，音量控制配置文件（VCP）定義了客戶端如何管理音頻接收器設備的增益。該增益狀態在音量控制服務（VCS）中定義，每個音頻接收器上都有一個VCS實例。音量可以用絕對或相對值表示，也可以靜音。

????????當發起設備發送多個藍牙LE音頻流時（如耳塞、助聽器和揚聲器的應用場景），需要第二種服務。VOCS（音量偏移控制服務）實際上充當平衡控制器11，允許調整多個設備的相對音量。這些設備可能在不同設備上渲染音頻，例如左右獨立的耳塞或揚聲器，也可能在單個設備上，如一副耳機或條形音箱。VOCS與音頻流傳輸正交——它不關心多個流的音頻內容是否相同，其唯一目的是設置多個渲染設備之間的相對增益。

????????音頻輸入控制服務（AICS）認可了如今許多設備能夠支持多個不同音頻流這一事實。AICS 允許用戶控制多個可混合在一起并在耳塞或揚聲器中渲染的不同輸入。圖 2.10 展示了這三種服務如何在具有藍牙、HDMI 和麥克風輸入的條形音箱中使用。

????????對于助聽器而言，其輸入可能包括藍牙音頻流、提供環境音的麥克風音頻流，以及從音頻環路接收信號的感應線圈天線。在任何時刻，佩戴者可能都希望聽到這些不同輸入的組合，而AICS（音頻輸入控制服務）正是為了支持這種靈活性而設計的。

????????音量服務的一個重要特性是，它們會將任何變化通知給運行語音控制配置文件（VCP）的客戶端設備。這確保了所有潛在的音量控制器都能實時更新其狀態變化，無論該變化是通過藍牙鏈路發生，還是由音頻接收器上的本地音量控制觸發。這確保了它們都對音量狀態有同步的認知，因此用戶可以從任何一個控制器進行更改，而不會因對當前音量水平的狀態認知過時，導致出現任何意外影響。

????????麥克風控制配置文件（MICP）和麥克風控制服務（MICS）是一對互補的規范，負責控制助聽器和耳塞內置的麥克風。如今，這類設備通常配備多個麥克風。助聽器既要拾取環境音（這是其主要功能），也要處理通過藍牙接收的音頻。隨著耳塞的功能日益復雜，我們越來越多地看到其內置了類似的環境音采集功能，某種程度的“透聽”模式也愈發流行——該模式會將環境音與藍牙音頻流混合。

????????MICP（麥克風控制配置文件）與AICS（音頻輸入控制服務）及MICS（麥克風控制服務）協同工作，用于控制多個麥克風的整體增益和靜音功能。這些規范通常用于控制將通過藍牙流傳輸的捕獲音頻，但也可更廣泛地應用。圖2.11展示了這些服務的使用方式。

?2.2.5 Content control

????????在明確了音頻流的設置與管理方式以及音量和麥克風輸入的處理方式后，我們接下來討論內容控制。我們所收聽的內容由藍牙規范之外的系統生成，可能是流媒體音樂、直播電視、電話通話或視頻會議。內容控制規范的作用是允許對音頻流進行啟動、停止、應答、暫停和選擇等操作。這些控制類型此前已嵌入到HFP（免提配置文件）以及與A2DP（高級音頻分發配置文件）配套的AVRCP（音頻/視頻遠程控制配置文件）中。在藍牙LE音頻中，它們被拆分為兩組規范：一組用于各種形式的電話通信，另一組用于媒體控制。其核心區別在于：電話通信控制關注通話狀態（通常反映電話服務的狀態），而媒體控制則作用于音頻流的狀態（包括播放時間、播放方式和選擇方式）。由于這些控制與音頻流解耦，因此可用于協助控制狀態轉換，例如在接聽電話時暫停音樂播放，并在通話結束后恢復播放。對于這兩組規范，相關服務駐留在主音頻源設備上（通常是手機、電腦、平板電腦或電視），而配置文件則在接收音頻流的設備（如助聽器或耳塞）上實現。與渲染和捕獲控制類似，多個設備可作為客戶端，因此電話和媒體狀態可通過智能手表進行控制，而不必局限于耳塞或作為耳塞控制的補充。

????????媒體控制服務（MCS）駐留在音頻媒體源設備上，用于反映音頻流的狀態。該狀態機允許使用媒體控制配置文件（MCP）的客戶端將每個媒體源在播放、暫停和搜索狀態之間進行轉換。最簡單的情況下，它可讓耳塞實現播放和停止控制。然而，MCS的功能遠不止于此，它提供了當今用戶期望從內容播放器中獲得的所有功能。它還提供更高級別的功能，例如用戶可以搜索曲目、修改播放順序、設置分組以及調整播放速度。該服務定義了可用于識別曲目的元數據結構，并利用現有對象傳輸服務（OTS）允許客戶端在服務器（或更常見的是服務器背后的應用程序）上執行媒體搜索。所有這些意味著，運行媒體控制配置文件的功能復雜設備能夠重現音樂播放器的各種控制功能。

????????電話控制采用類似的處理方式，借助駐留在通話相關設備（通常為手機、電腦或筆記本電腦）上的電話承載服務（TBS），配套的呼叫控制配置文件（CCP）通過寫入TBS實例中的狀態機來實現對通話的控制。TBS和CCP已突破免提配置文件（HFP）的局限性，這反映了我們如今使用多種形式電話通信的現狀。其不再僅聚焦于傳統電路交換和蜂窩承載，而是通過支持多種不同類型的承載服務，全面適配基于PC和網絡的通信及會議應用。TBS通過通用狀態機公開通話狀態，支持多線通話、呼叫處理與合并、來電顯示、帶內/帶外環鈴音選擇，并提供信號強度等通話信息。

????????TBS和MCS都認可服務器設備上可能存在多個媒體源和多種不同通話應用這一事實。為了適應這一點，兩者都可以多次實例化——每個應用實例對應一次實例化。這使得具有互補配置文件的客戶端能夠分別控制每個應用。或者，也可以使用服務的單個實例，由媒體或通話設備通過其特定實現將配置文件命令導向正確的應用。TBS和MCS的單實例變體分別稱為通用電話承載服務（GTBS）和通用媒體控制服務（GMCS），它們分別包含在TBS和MCS規范中。我們將在第9章更詳細地探討這些內容。

?2.2.6 Transition and coordination control

????????接下來我們討論過渡與協調控制規范。其目的是將其他規范銜接起來，為頂層配置文件提供向下調用的途徑，使其無需關注具體的設置細節。

????????等時通道的一大增強功能是能夠向多個不同設備流式傳輸音頻，并實現精確同步渲染。其最常見的應用場景是向左右耳塞、揚聲器或助聽器流式傳輸立體聲音樂。渲染的拓撲結構和同步由核心規范和BAP處理，但要確保控制操作（如調節音量或連接切換）協同發生則并非如此。而這正是協調集標識配置文件（CSIP）和協調集標識服務（CSIS）的用武之地。?

????????當兩個或多個藍牙LE音頻設備需要協同使用時，它們被稱為“協調集”，并可通過協調集標識服務（CSIS）實現彼此關聯。這使得其他配置文件（尤其是通用音頻配置文件CAP）能夠將它們視為單一實體。該機制引入了“鎖定（Lock）”和“優先級（Rank）”概念，以確保在音頻連接切換時（無論是切換至新的單播流還是廣播流），協調集中的設備成員始終同步響應。這可避免新連接僅應用于集合中的部分設備——例如電視連接至右耳塞，而手機連接至左耳塞的情況。設計為協調集成員的設備通常在制造過程中即配置為集合成員。

????????未配置為協調集成員的多個設備仍可在GAF中作為臨時集使用。在這種情況下，它們需要由應用程序單獨配置。這意味著這些設備無法利用CSIS的鎖定功能，可能導致臨時集中的設備成員建立不同的連接。

????????通用音頻配置文件（CAP）引入了“指揮官（Commander）”角色，該角色整合了可用于遠程控制藍牙LE音頻流的功能。指揮官角色是對以往藍牙規范的重大革新，它允許通過額外設備來影響音頻體驗，從而實現了音頻設備的泛在化分布式遠程控制設計。這一功能在加密廣播場景中尤為實用——當與廣播發射機配合使用時，它為用戶提供了獲得私密收聽體驗的途徑。我們將在第8章和第12章中詳細探討這些內容。

????????CAP（通用音頻配置文件）利用CSIS（協調集標識服務）和CSIP（協調集標識配置文件）將設備關聯起來，確保相關流程同時應用于這兩者。它還引入了“上下文類型（Context Types）”和“內容控制ID（Content Control IDs）”的概念，使應用程序能夠基于對控制設備、音頻數據用例以及可用應用程序的了解，就流設置和控制做出決策。這用于告知不同流之間的過渡，無論是由設備上的不同應用程序觸發，還是由不同設備發起的音頻連接請求所導致。此功能的許多部分都基于藍牙LE音頻中引入的新概念，這些內容將在第3章中詳細解釋。

2.2.7 Top level Profiles?

????????最后，在通用音頻框架（GAF）規范之上，我們有頂層配置文件，這些配置文件為特定音頻用例提供了額外要求。目前，這些頂層配置文件包括： - **助聽接入配置文件和服務（HAP 與 HAS）**：覆蓋助聽器生態系統的應用場景； - **電話與媒體音頻配置文件（TMAP）**12：規定了更高質量編解碼器設置的使用，以及更復雜的媒體和電話控制功能； - **游戲音頻配置文件（GMAP）**：專為游戲場景的低延遲音頻需求而設計； - **公共廣播配置文件（PBP）**：幫助用戶選擇具有全球互操作性的廣播流； - **廣播音頻統一資源標識符（BAU）**：定義如何通過二維碼等帶外方式協助廣播助手定位廣播內容。 PBP 和 BAU 規范的特殊之處在于沒有配套服務，這是由廣播的性質決定的——在廣播場景中，不存在任何用于客戶端-服務器交互的連接。

?2.2.8 The Low Complexity Communications Codec (LC3)

????????盡管不屬于通用音頻框架（GAF）的一部分，但藍牙LE音頻規范包含了一種名為LC3的新型高效編解碼器，它是藍牙LE音頻流的強制編解碼器。LC3為電話語音、寬帶和超寬帶語音以及高質量音頻提供了出色的性能，并且是BAP（藍牙音頻配置文件）中的強制編解碼器。每款藍牙LE音頻產品都必須支持LC3編解碼器以確保互操作性，但制造商也可根據需求添加額外的專有編解碼器。LC3將音頻編碼為單流，因此立體聲會被編碼為獨立的左聲道和右聲道流。這意味著GAF可以將單播流配置為僅向耳塞傳輸該耳塞所需的音頻。發送音樂的廣播發射機通常會在其廣播中包含獨立的左聲道和右聲道音頻流，而各個設備只需接收并解碼與它們想要渲染的流相關的數據即可。

?2.3 Talking about Bluetooth LE Audio

????????編寫二十多個規范催生了大量新縮寫，包括用于指代每個具體規范名稱的縮寫。隨著時間的推移，各工作組形成了不同的稱呼方式——有的作為首字母縮略詞（按單詞發音），有的作為首字母縮寫（按字母發音），偶爾也會混合使用。下表匯總了最常用縮寫的當前發音，以幫助您理解任何討論藍牙LE音頻的內容。

?2.3.1 Acronyms

?????????以下縮寫均按單詞發音，或按字母與單詞組合發音：

?2.3.2 Initialisms

????????其余縮寫僅按組成縮寫的單個字母發音，例如：CCP 讀作“see - see - pee”，LC3 讀作“el - see - three”。

????????藍牙LE音頻中最常見的首字母縮寫包括：ACL、AD、ASCS、BMR、BMS、BR/EDR、CCID、CCP、CG、CSS、CT、CTKD、EA、FT、GMCS、GSS、GTBS、HA、HCI、IA、IAC、IAS、IRC、IRK、LC3、MCP、MCS、MTU、NSE、PA、PBA、PBK、PBP、PBS、PDU、PTO、RFU、RTN、SDP、SDU、TBS、UI、UMR、UMS、UUID、VCP和VCS。這些術語的解釋均收錄于術語表中。