來源 | HaaS技術社區

1、LE Audio介紹

1.1、LE Audio傳輸協議

2019年底，藍牙官方組織SIG發佈了藍牙5.2版本的核心協議，其中增加了一個重要的特性---LE Audio。

藍牙的應用協議都是從應用層到物理層完整包含的協議，LE Audio也不例外。但藍牙5.2核心協議僅僅定義了藍牙LE的鏈路層傳輸Audio的方式，上層協議以及完整的LE Audio規範遲遲未出，近日，藍牙官方組織釋放了LE Audio較為完整的規範文檔。

1.2、LE Audio完整應用

本次Sig組織定義瞭如下規範和協議，這些規範協議連同核心協議組成了LE Audio的完整應用

Basic Audio Profile(BAP)

基礎音頻規範，LE Audio的關鍵規範，定義了各類角色以及每個角色需要支持的能力，以及如何使用如下各服務完成音頻應用的傳輸。LE Audio支持點對點音頻模式和廣播音頻模式，2種模式下，會使用不同的服務。

Published Audio Capabilities Service(PACS)

已發佈音頻能力服務，此服務定義了本設備支持的音頻能力，包括但不限於支持的編解碼器個數以及各編解碼能力，通過此項服務，可獲取設備的音頻能力。

Audio Stream Control Service(ASCS)

音頻流控制服務，此服務定義了一套操作指令，用於建立配置以及關閉音頻流。

Broadcast Audio Scan Service(BASS)

廣播音頻掃描服務，此服務用於廣播音頻發佈者告知周邊接收器廣播音頻參數，這個服務僅在廣播音頻類

Low Complexity Comunication Codec(LC3)

用於LE Audio的音頻編解碼器，顧名思義，此編碼器屬於低複雜度的音頻編碼器。LC3編碼器可選參數範圍很大，應用範圍從8KHz單聲道語音到48KHZ多聲道音樂均支持，同時相比經典藍牙音頻規範使用的編碼器SBC，同碼率下音質有很大的提升。

2、LE Audio詳解

2.1、BAP規範

BAP規範作為LE Audio的基礎音頻規範，其位於如下藍牙協議層。

BAP規範根據支持的點對點音頻和廣播音頻，定義瞭如下角色

Unicast Role	Unicast Server	點對點音頻從設備
Unicast Role	Unicast Client	點對點音頻主設備
Broadcast Role	Broadcast Source	廣播音頻發射設備
	Broadcast Sink	廣播音頻接收設備
	Broadcast Assistant	廣播音頻協助設備
	Scan Delegator	廣播音頻掃描設備

每類角色支持的服務如下（注： X代表不支持，M代表必須支持，O代碼可選支持）

BAP Role Service Role	Unicast Server	Unicast Client	Broadcast Source	Broadcast Sink	Scan Delegator	Broadcast Assistant
ASCS Client	X	M	X	X	X	X
ASCS Server	M	X	X	X	X	X
PACS Client	X	M	X	X	X	O
PACS Server	M	X	X	M	X	X
BASS Client	X	X	X	X	X	M
BASS Server	X	X	X	X	M	X

當2個設備處於對應角色時，即可通過BAP定義的操作步驟完成服務的連接以及音頻傳輸服務。

以Unicast Server和Unicast Client為例，其步驟如下

Unicast Client通過GATT服務發現操作發現Unicast Server的PACS服務並得知音頻參數。
Unicast Client通過GATT服務發現操作發現Unicast Server的ASCS服務並得知當前狀態。

Unicast Client如發現其音頻參數匹配且Server的狀態處於IDLE狀態，即可連接音頻服務。
Unicast Client通過ASCS定義的操作碼，配置音頻編解碼參數和音頻傳輸參數，然後開啟音頻。

Unicast Client通過核心協議5.2定義的方式，根據配置參數，在鏈路層開啟CIS音頻傳輸流。
Unicast Sink通過ASCS操作碼，通知Unicast Source已可接收音頻。

Unicast Source開啟LC3編解碼器，並將編碼後的音頻流通過CIS傳輸到Unicast Sink。
Unicast Sink接收音頻流，解碼並播放。

2.2、PACS服務

PACS服務用於點對點音頻，定義了設備的音頻能力，其服務定義如下。

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Sink PAC	C.1	Read	Notify	Encryption required
Sink Audio Locations	C.2	Read	Notify, Write	Encryption required
Source PAC	C.1	Read	Notify	Encryption required
Source Audio Locations	C.3	Read	Notify, Write	Encryption required
Available Audio Contexts	M	Read, Notify	None	Encryption required
Supported Audio Contexts	M	Read	Notify	Encryption required

其中，Source PAC為音頻發送能力屬性，當設備支持音頻發送時才需要定義，其格式如下：

Parameter	Size (Octets)	Description
Number_of_PAC_records	1	Number of PAC records, [i], for this characteristic
Codec_ID[i]	5	Octet 0: Coding_Format value of the [ith] PAC record. Coding_Format values are defined in Bluetooth Assigned Numbers. Octet 1–2: Company _ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF. Company_ID values are defined in Bluetooth Assigned Numbers. Octet 3–4: Vendor-specific codec_ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF.
Codec_Specific_Capabilities_Length[i]	1	Length of the Codec_Specific_Capabilities value of the [ith] PAC record. Shall be 0x00 if the Codec_Specific_Capabilities value of the [ith] PAC record is empty.
Codec_Specific_Capabilities[i]	Varies	Codec_Specific_Capabilities value of the [ith] PAC record.
Metadata_Length[i]	1	Length of the Metadata field of the [ith] PAC record. Shall be 0x00 if the Metadata value of the [ith] PAC record value is empty.
Metadata[i]	Varies	LTV-formatted Metadata applicable to the [ith] PAC record. Shall exist only if the value of the Metadata_Length field is not 0x00.

Sink PAC為音頻接收能力屬性，當設備支持音頻接收時才需要定義，其格式如下：

Parameter	Size (Octets)	Description
Number_of_PAC_records	1	Number of PAC records, [i], in this characteristic.
Codec_ID[i]	5	Octet 0: Coding Format of the [ith] PAC record. Coding_Format values are defined in Bluetooth Assigned Numbers Octet 1–2: Company_ID value of the [ith] PAC record. Company_ID values are defined in Bluetooth Assigned Numbers Shall be 0x0000 if octet 0 is not 0xFF. Octet 3–4: Vendor-specific codec_ID value of the [ith] PAC record. Shall be 0x0000 if octet 0 is not 0xFF.
Codec_Specific_Capabilities_Length[i]	1	Length, in octets, of the Codec_Specific_Capabilities value of the [ith] PAC record. Shall be 0x00 if the Codec_Specific_Capabilities value of the [ith] PAC record is empty.
Codec_Specific_Capabilities[i]	Varies	Codec_Specific_Capabilities value of the [ith] PAC record.
Metadata_Length[i]	1	Length of the Metadata field of the [ith] PAC record. Shall be 0x00 if the Metadata value of the [ith] PAC record value is empty.
Metadata[i]	Varies	Length-type-value (LTV)-formatted Metadata applicable to the [ith] PAC record. Shall exist only if the value of the Metadata_Length field is not 0x00.

2.3、ASCS服務

ASCS服務用於音頻控制，通過定義的一套操作碼作交互，從而達到控制音頻狀態轉移的目的。

ASCS的服務定義如下

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Sink ASE	C.1	Read, Notify	None	Encryption required
Source ASE	C.1	Read, Notify	None	Encryption required
ASE Control Point	M	Write, WriteWithoutResponse, Notify	None	Encryption required

2.4、BASS服務

BASS為廣播音頻掃描服務，用於告知廣播音頻的一些參數，屬於輔助服務，其定義如下。

Characteristic Name	Requirement	Mandatory Properties	Optional Properties	Security Permissions
Broadcast Audio Scan Control Point	M	Write, Write Without Response	None	Encryption required
Broadcast Receive State	M	Read, Notify	None	Encryption required

2.5、LC3編解碼器

LC3編解碼器用於LE Audio的音頻編解碼，與MP3，AAC類似，屬於頻域編碼，編碼效率遠高於SBC子帶編碼，而10毫秒和7.5毫秒的短幀結構，對於音頻延遲有較大改善。

LC3在頻域上引入了SNS頻域噪聲整形，TNS時域噪聲整形以及熵編碼等技術，其中TNS等技術已用於AAC，這些技術對於音質有提升，整個編碼過程如下：

解碼是編碼的逆過程，如下：

3、LE Audio支持展望

LE Audio作為一個非常重要的特性，發佈至今除少量demo仍未見應用。大規模普及仍依賴於操作系統廠商是否支持，諸如蘋果的IOS以及谷歌的Android，從目前的進展(IOS14以及Android11)來看，仍未看到有支持LE Audio。

但翻看AOSP的代碼，在Android12(android-s-beta版)上，已能發現LE Audio的痕跡，如下

從目前的代碼完整度來看，仍不算完整功能支持，預計在Android12上會完善並開始應用，等手機支持後，相信會有廠商推出支持LE Audio的耳機。

但音頻應用屬於一個通用應用，蘋果以及其他操作系統諸如微軟的windows的支持也極其重要，從這個角度講，LE Audio要大規模普及可能仍需要時間。

低功耗藍牙LE Audio Profile 詳細介紹