圖3 A2DP框架具體模塊劃分

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

圖4 協(xié)議間的消息傳遞

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

圖5 SEP在AVDTP模塊中的狀態(tài)機

整個通信過程各個狀態(tài)之間的躍遷靠下列消息來觸發(fā)：
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
在空閑狀態(tài)下，發(fā)送A消息之前，空閑狀態(tài)下要發(fā)出一系列動作，包括連接請求、發(fā)現(xiàn)請求和獲取SNK能力請求等。從空閑態(tài)到配置態(tài)的躍遷過程，本協(xié)議棧統(tǒng)稱為流設置過程。

在打開狀態(tài)下發(fā)送C消息之后，就進入了流控狀態(tài)，此時通過H消息就可以發(fā)送從SRC到SNK的媒體流數(shù)據(jù)包。

在通信過程中的任何狀態(tài)下，都可以通過發(fā)送F消息，進入中止態(tài)，進而回到?jīng)]有連接任何遠程SEP的空閑狀態(tài)。

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