基于A2DP框架的近距離無線音頻通信研究

隨著藍牙技術在電子產品中的日益普及，藍牙音頻設備也層出不窮，其中具有免提功能的藍牙耳機和藍牙音頻網關的應用是最典型的例子。但免提單元與音頻網關進行音頻傳輸建立起來的SCO連接，僅能支持64Kb/s電信級語音質量的音頻流，這也就限制了藍牙音頻質量的提高，同時也影響了藍牙的娛樂消費市場。為了滿足人們對高質量音頻的需求，進一步擴大藍牙產品市場，藍牙特殊興趣小組SIG組織，在藍牙? 1.1規范的應用框架基礎上又單獨提出了高級音頻分發框架（Advanced Audio Distribution Profile，A2DP）。該框架利用了在L2CAP層建立起來的ACL異步無連接鏈路來傳輸高質量的單聲道或者立體聲音頻數據，有效負載的傳輸速率可以達到300～400Kb/s。

A2DP框架概述
在娛樂消費市場中，A2DP實例化應用就是用音樂播放器把音頻數據通過ACL連接發送到耳機或者音箱上。目前的框架規范中，并不支持同步的一點對多點的廣播式音頻分發，而對于點對點音頻的分發，又存在著兩種不同的角色，一個是信源設備（SRC），這種設備作為發起者將數字音頻流發送到Piconet網中；另一個是信宿設備，是接收信源發出的音頻流的設備。如果藍牙音樂播放器是信源設備，那么與之交互的藍牙耳機就是信宿設備，信源和信宿的區別就在于，它是發起者還是接收者。下面對該框架所涉及的具體協議和其依賴框架進行分析。

1 A2DP應用框架
在典型的藍牙音頻相關框架的整體結構中，A2DP框架所處的位置如圖1所示。
服務發現應用框架（SDAP）所提供的功能，是向其他藍牙設備提供自身所具備的服務，并且能夠使用遠程設備所提供的服務和功能。在實際應用中，幾乎所有框架都支持服務發現協議（SDP）。藍牙音頻視頻遙控應用框架（AVRCP）實現了藍牙設備之間的遙控功能，例如，音樂播放器的前進、后退、停止、播放等控制信令的傳輸。免提功能頭戴式設備應用框架（HFP/HSP），最主要的應用就是實現了藍牙耳機的免提功能和某些藍牙設備的音頻網關功能。

高級音頻分發框架（A2DP）依賴于通用音頻視頻分發框架（GAVDP），GAVDP定義了設置音頻和視頻流傳輸的步驟，而A2DP則進一步定義了音頻流傳輸的參數和步驟細節。

在實際應用中，邏輯鏈路控制適配層協議（L2CAP）要求比較高的可靠性，基帶的廣播數據分組將被禁止使用，因此，L2CAP層并不支持可靠的多點傳輸信道，這也就是A2DP框架不支持多點廣播式音頻分發的主要原因之一。而對于面向高層協議的開發和應用者，L2CAP層協議是透明的，因此這里對A2DP輕型框架具體實現的相關描述，也僅限于L2CAP層以上，A2DP相關的協議及框架如AVDTP、GAVDP等協議模塊的設計。

圖1 藍牙音頻框架整體結構

圖1中的藍牙主機控制接口HCI層，是協議棧中軟硬件的接口。這里所涉及的硬件環境是主機與主機控制器連接模型，HCI層以上的協議（如SDP）在主機上運行，而以下的協議（如傳輸層的藍牙基帶協議等）由藍牙主機控制器硬件來完成，這樣既保證了底層協議傳輸的穩定性，又支持了上層應用協議的可擴展性。一旦在市場條件成熟，藍牙技術的硬件部分就可以被更快的硬件射頻技術所取代，高層傳輸協議經過移植仍然可以沿襲使用，大大縮短藍牙產品的研發周期。

2 A2DP框架協議棧
A2DP是音頻傳輸框架，它通過藍牙傳輸層和對等設備，把音頻數據流從音頻信源（SRC）到音頻信宿（SNK）進行分發，因此該框架所包含的協議棧也分為兩個部分，具體表現如圖2所示。

圖2 A2DP框架協議棧

基帶協議（Baseband Protocol）、鏈路管理協議（LMP）、邏輯鏈路控制和適配協議（L2CAP）及服務發現協議（SDP），在藍牙核心協議規范中都有定義。而藍牙音頻視頻分發傳輸協議AVDTP則定義了藍牙設備之間數據流句柄的參數協商、建立和傳輸過程以及相互交換的信令實體形式，該協議是A2DP框架的基礎協議。

輕型A2DP框架協議實現
這里所提出的A2DP框架協議的實現集中在音頻信源端，并未設計信宿端。之所以定義為輕型的，是因為在A2DP規范1.0基礎之上，實現了此規范所規定的強制性功能，即在信源端僅僅實現了高級音頻分發的基本功能，如立體聲音頻的傳輸，只支持低復雜度子帶編解碼（SBC）標準，而對其他編解碼標準并未涉及；在A2DP模塊的實現中并未包括任何的編解碼能力，這是在用戶層上實現的，是上層應用程序在設置階段，通過配置協商來做相應的編碼，解碼和音頻內容的轉換工作；AVDTP模塊的功能不包括校驗和報告，也不包括媒體多路復用，校驗和報告通道的建立。

1 協議模塊劃分
A2DP框架協議劃分了3個模塊：A2DP模塊、GAVDP模塊和AVDTP模塊，另外還包括測試協議棧所需要的Audio應用程序測試模塊。對于GAVDP，雖然該功能模塊包括音頻/視頻兩種數據流的傳輸與分發，但是由于這里側重對音頻流進行討論，所以視頻流相關模塊（VDP）并未實現。圖3是具體實現模塊劃分圖。

圖3 A2DP框架具體模塊劃分

2 消息傳遞機制
該輕型框架模塊協議層之間的交互是通過消息傳遞機制來實現的，消息的種類可分為以下4種。
①請求消息REQ
該消息是上層協議向下層協議主動發出的請求。
②確認消息CFM
上層協議發出的每個REQ消息，都會收到下層協議發上來的確認。
③指示消息IND
該消息是下層協議向上層協議主動發起的告知。
④響應消息REP
對于每個下層協議主動發上來的IND消息，上層協議都對此消息進行響應。

圖4 協議間的消息傳遞

協議間的消息傳遞如圖4所示。
采用基于消息傳遞機制的實現方法的優點如下：
①協議層之間交互通過固定的消息接口，即使上下層協議模塊升級，也不會影響本層協議模塊的功能，有很好的移植性和可復用性。
②各層協議都是異步通信，可以大大降低擁塞情況的發生。
③協議棧進程可以在上層管理一個消息隊列，統一進行消息收發，當消息向下傳遞過程中遭到拒絕時，可以實現消息的重傳功能。
④與每層協議都用一個單獨的任務來實現相應功能相比，采用消息機制的方法節省了系統調度時間，更具有實時性，同時避免了死鎖的發生。
3 重要數據結構
①消息結構體
消息結構體分為3個域：發送模塊Id、接收模塊Id、消息枚舉類型。具體定義如下：
typedef struct
{
?BT_ModuleId　sender;
?BT_ModuleId　receiver;
?BT_Primitive????? primitive;
} BT_Header；
②流端點結構體
流端點SEP存在于應用層中，而應用層又在AVDTP中注冊它的SEP，使其他設備可以發現和連接。SEP在3個模塊—A2DP、GAVDP、AVDTP中有著不同的結構體類型，以適應本層協議的特殊作用。以A2DP模塊為例，其SEP結構體具體定義如下：
typedef struct
{
GAVDP_Handle? streamHandle;
BT_U8???? *codecInfoElement;
BT_U8?? lengthInfoElements;
AVDT_MediaCodecType???? codecType;
ChannelConfig?? configuration;
AVDT_ResponseCode??? pendingRspCode;
BT_TimerId?? resendTimerId;
} StreamEndPoint；
4 各模塊主要功能及消息接口
各模塊是通過自己的消息函數來接收不同的枚舉消息，并轉向各自的消息處理函數，下面具體分析每個模塊所實現功能。
①A2DP模塊
A2DP模塊實現了通過GAVDP管理SEP和SEP能力的功能，并且在SRC和SNK之間為音頻流文本設置和配置了流通道。根據A2DP模塊的通信流程把它的消息接口分為6種類型：流設置消息，它又可分為對等流端點發現和流配置兩個步驟；流通道釋放消息；開始/掛起流消息；配置/重新配置消息；發現/得到能力消息；媒體流開始消息。
②GAVDP模塊
GAVDP模塊從多個使用者角度出發，管理本地流SEP和SEP能力的注冊，處理從遠程設備發來的發現查詢請求和得到能力請求，同時基于用戶注冊的SEP信息，自動發送響應。
由于GAVDP模塊的功能是上層A2DP模塊的細化，因此可以將GAVDP的消息接口和A2DP模塊的接口類型作一致性設計，兩者消息接口類型基本相同。
③AVDTP模塊
AVDTP模塊負責建立一個到遠程藍牙設備的AVDTP信令通道，并借助于AVDTP協議發送所有的信令命令，同時為媒體流建立傳輸通道，必要的話為校驗和報告也建立通道，另外還支持信令和媒體消息的分段。AVDTP模塊數據通信最基本的流程為SEP發現→獲取SNK能力→數據流配置→數據流建立→數據流開始→數據流掛起→數據流重新配置→數據流釋放。相應的SEP在AVDTP模塊中的狀態機如圖5所示。

圖5 SEP在AVDTP模塊中的狀態機

整個通信過程各個狀態之間的躍遷靠下列消息來觸發：
A：AVDT_SET_CONFIGURATION _REQ
B：AVDT_OPEN_REQ
C：AVDT_START_REQ
D：AVDT_SUSPEND_REQ
E：AVDT_CLOSE_REQ
F：AVDT_ABORT_REQ
G：AVDT_RECONFIGURE_REQ
H：AVDT_MEDIA_REQ
在空閑狀態下，發送A消息之前，空閑狀態下要發出一系列動作，包括連接請求、發現請求和獲取SNK能力請求等。從空閑態到配置態的躍遷過程，本協議棧統稱為流設置過程。

在打開狀態下發送C消息之后，就進入了流控狀態，此時通過H消息就可以發送從SRC到SNK的媒體流數據包。

在通信過程中的任何狀態下，都可以通過發送F消息，進入中止態，進而回到沒有連接任何遠程SEP的空閑狀態。

測試及結論
該輕型協議棧的實現與測試，可以基于CSR先進的BlueCore4藍牙芯片來完成。該芯片支持藍牙2.0+EDR規范，并提供2.1Mb/s的數據傳輸速率，比標準藍牙快3倍，可實現更快速的連接，同步支持多個藍牙鏈路，以及音頻流等更寬帶寬的新興應用。最上層的音頻應用程序實現了一個簡單的具有處理SBC格式編解碼信息的播放器，該應用程序和部分高層協議棧通過交叉編譯，下載到硬件平臺主機端。而播放器程序是通過調用本協議棧提供的API，進行音頻數據流分發。對于音頻數據的接收端SNK，采用摩托羅拉HT820立體聲耳機進行測試，在長時間播放音頻數據的情況下，仍然會存在音頻停頓的現象。使用一種截獲空中藍牙信號并進行協議分析的工具Airsniffer，抓取流媒體傳輸數據包，經分析，音頻數據并未丟失，而是流控機制存在問題，需要進一步完善。