2.2 藍牙協議體系結構

藍牙技術規范的目的是使符合該規范的各種應用之間能夠互通。為此，本地設備與遠端設備需要使用相同的協議棧。

不同的應用可以在不同的協議棧上運行。但是，所有的協議棧都要使用藍牙技術規范中的數據鏈路層和物理層。完整的藍牙協議棧如圖2.6所示，在其頂部支持藍牙使用模式的相互作用的應用被構造出來。不是任何應用都必須使用全部協議，相反，應用只會采用藍牙協議棧中垂直方向的協議。圖2.6顯示了數據經過無線傳輸時，各個協議如何使用其他協議所提供的服務，但在某些應用中這種關系是有變化的，如需控制連接管理器時，一些協議如邏輯鏈路控制應用協議（L2CAP）、二元電話控制規范（TCS Binary）可使用連接管理協議（LMP）。完整的協議包括藍牙專用協議（LMP和L2CAP）和藍牙非專用協議（如對象交換協議OBEX和用戶數據報協議UDP）。設計協議和協議棧的主要原則是盡可能利用現有的各種高層協議，保證現有協議與藍牙技術的融合以及各種應用之間的互通性，充分利用兼容藍牙技術規范的軟硬件系統。藍牙技術規范的開放性保證了設備制造商可自由地選用藍牙專用協議或常用的公共協議，在藍牙技術規范基礎上開發新的應用。

藍牙協議體系中的協議由SIG分為4層：

• 藍牙核心協議——Baseband、LMP、L2CAP、SDP；
• 電纜替換協議——RFCOMM；
• 電話傳送控制協議——TCS Binary、AT Commands；
• 所采用的協議——PPP、UDP/TCP/IP、OBEX、vCard、vCal、IrMC、WAE。

除上述協議層外，藍牙規范還定義了主機控制器接口（HCI），它為基帶控制器、連接管理器提供命令接口，并且可通過它訪問硬件狀態和控制寄存器。HCI位于L2CAP的下層，但HCI也可位于L2CAP上層。藍牙核心協議由SIG制定的藍牙專利協議組成，絕大部分藍牙設備都需要藍牙核心協議（包括無線部分），而其他協議根據應用的需要而定。總之，電纜替換協議、電話控制協議和被采用的協議構成了面向應用的協議，允許各種應用運行在核心協議之上。

2.2.1 藍牙核心協議

1）基帶協議（Baseband）

基帶和鏈路控制層確保了微微網內各藍牙設備單元之間由射頻構成的物理連接。藍牙的射頻系統是一個跳頻擴展頻譜系統，其任一分組在指定時隙、指定頻率上發送，它使用查詢和尋呼進程來同步不同設備間的發送跳頻和時鐘。藍牙提供了兩種物理連接方式及其相應的基帶數據分組：同步面向連接和異步無連接，而且在同一射頻上可實現多路數據傳送。ACL只用于數據分組，SCO適用于音頻及音頻與數據的組合，所有音頻與數據分組都附有不同級別的前向糾錯（FEC）或循環冗余校驗（CRC），而且可進行加密。此外，不同數據類型（包括連接管理信息和控制信息）都被分配了一個特殊通道。

2）音頻（Audio）

音頻數據可以在藍牙設備間傳送，使得各種使用模式成為可能。面向連接的音頻分組只需經過基帶傳輸，不通過L2CAP。音頻模式在藍牙系統內相對簡單，只需開通音頻連接，就可傳送音頻。

3）連接管理協議（LMP）

連接管理協議（LMP）負責藍牙各設備間連接的建立。它通過連接的發起、交換、核實，進行身份驗證和加密，通過協商確定基帶數據分組大小；它還控制無線設備的電源模式和工作周期，以及微微網內藍牙單元的連接狀態。

4）邏輯鏈路控制和適配協議（L2CAP）

邏輯鏈路控制和適配協議（L2CAP）位于基帶層之上，向上層協議提供服務，可以認為它與LMP并行工作，它們的區別在于L2CAP為上層提供服務，與此同時，負荷數據從不通過LMP消息進行傳遞。

L2CAP向上層提供面向連接的和無連接的數據服務，它采用了多路技術、分割和重組技術、群提取技術。L2CAP允許高層協議及應用以最大為64KB的長度收發數據包。

雖然基帶協議提供了SCO和ACL兩種連接類型，但L2CAP只支持ACL連接，不支持SCO連接。

5）服務發現協議（SDP）

發現服務在藍牙技術框架中起到至關重要的作用，它是所有使用模式的基礎。使用SDP，可以查詢到設備信息、服務和服務類型，從而在藍牙設備間建立相應的連接。

1.藍牙基帶層協議

1）基帶

基帶就是藍牙的物理層，它負責管理物理信道和鏈路中除了錯誤糾正、數據處理、調頻選擇和藍牙安全之外的所有業務。基帶在藍牙協議棧中位于藍牙射頻之上，基本上起鏈路控制和鏈路管理的作用，比如承載鏈路連接和功率控制這類鏈路級路由等。基帶還管理異步和同步鏈路、處理數據包、尋呼、查詢接入和查詢藍牙設備等。基帶收發器采用時分復用TDD方案（交替發送和接收），因此除了不同的跳頻之外（頻分），時間都被劃分為時隙。在正常的連接模式下，主單元會總是以偶數時隙啟動，而從單元則總是從奇數時隙啟動（盡管可以不考慮時隙的序數而持續傳輸）。

2）ACL和SCO鏈路

基帶可以處理兩種類型的鏈路：SCO（同步連接）和ACL（異步無連接）鏈路。SCO鏈路是微微網中單一主單元和單一從單元之間的一種點對點對稱的鏈路。主單元采用按照規定間隔預留時隙（電路交換類型）的方式可以維護SCO鏈路。SCO鏈路攜帶語音信息。主單元可以支持多達三條并發SCO鏈路，而從單元則可以支持兩條或者三條SCO鏈路。SCO數據包永不重傳。SCO數據包用于64kbps語音傳輸。ACL鏈路是微微網內主單元和全部從單元之間點對多點的鏈路。在沒有為SCO鏈路預留時隙的情況下，主單元可以對任意從單元在每時隙的基礎上建立ACL鏈路，其中也包括了從單元已經使用某條SCO鏈路的情況（分組交換類型）。只能存在一條ACL鏈路。對大多數ACL數據包來說都可以應用數據包重傳。

3）藍牙編址

藍牙有4種基本類型的設備地址，見表2.1。

表2.1 藍牙設備地址

4）藍牙數據包

微微網信道內的數據都是通過數據包傳輸的。通常的數據包格式如表2.2所示。

表2.2 標準的藍牙數據包

訪問碼（Access Code）用于時序同步、偏移補償、尋呼和查詢。訪問碼分為3類：信道訪問碼CAC、設備訪問碼DAC和查詢訪問碼IAC。信道訪問碼標識微微網（對微微網唯一），而設備訪問碼則用于尋呼及其響應。查詢訪問碼用于查詢。數據包包頭包含了數據包確認、亂序數據包重排的數據包編號、流控、從單元地址和報頭錯誤檢查等信息。數據包的數據部分可以包含語音字段、數據字段或者兩者皆有。數據包可以占據一個以上的時隙（多時隙數據包），而且可以在下一個時隙中持續傳輸。數據部分還可以攜帶一個16位長的CRC碼用于數據錯誤檢測和錯誤糾正。SCO數據包則不包括CRC。有5種普通類型數據包、4種SCO數據包和7種ACL數據包。

5）糾錯

糾錯方式有3種：1/3速率FEC、2/3速率FEC和ARQ。采用1/3速率FEC則每個位被重復三遍作為冗余；2/3方式則采用一個生成多項式把10位代碼編碼為15位代碼。在ARQ方式下，數據包被重傳，直到最終收到確認（或者超時）。藍牙使用快速的無編號確認，通過設置適當的ARQN值來使用正確認和負確認。如果傳輸超時，藍牙丟棄數據包并處理下一個數據包。

6）流控與同步

藍牙建議在ACL和SCO鏈路中采用先入先出（FIFO）隊列處理數據包的收發。鏈路管理器（Link Manager）填充這些隊列，鏈路控制器負責自動清空隊列。

如果這些RX FIFO隊列全滿，流控就會避免丟棄數據包和防止阻塞。如果數據沒有收到，STOP表示符即被接收方的鏈路控制器插入到返回數據包的包頭中被傳送。當發送方收到STOP表示符，它就凍結其FIFO隊列。如果接收方準備完畢即可發送GO數據包從而再次恢復數據流傳輸。我們已經知道，藍牙收發器采用時分復用（TDD）技術方案，這意味著它可以采用同步方式實現交替地傳送和接收操作。主單元數據包傳輸的平均時間相對于理想的625μs時隙必定不會快于20ppm。平均延遲時間應當小于1ms。微微網由主單元的系統時鐘同步。主單元的藍牙設備地址（BD-ADDR）決定了跳頻序列和信道訪問碼：主單元的系統時鐘確定跳頻序列的相位。主單元通過查詢方式控制信道上的流量。在微微網存在期間主單元從不調節其系統時鐘。從單元為了匹配主單元時鐘采用時序偏移以適應其內部時鐘。藍牙時鐘應該達到31.25μs的精度。為了讓接收方的訪問相關器可以搜索到正確的信道訪問碼并和發送方保持同步，精確接收時間允許有一個20μs的不確定窗口。當從單元從保持狀態返回時，它即可和更大的不確定窗口發生相關直到從單元不再與時隙交疊。休眠的從單元周期性地被喚醒以偵聽來自主單元的信號并重新同步自身的時鐘偏移。

2.鏈路管理協議（LMP）

鏈路管理協議（LMP）和邏輯鏈路控制與適應協議（L2CAP）都是藍牙的核心協議，L2CAP與LMP共同實現OSI數據鏈路層的功能。

LMP負責藍牙設備之間的鏈路建立，包括鑒權、加密等安全技術及基帶層分組大小的控制和協商。它還控制無線設備的功率以及藍牙節點的連接狀態。L2CAP在高層和基帶層之間作適配協議，它與LMP是并列的，區別在于L2CAP向高層提供負載的傳送，而LMP不能，即LMP不負責業務數據的傳遞。

鏈路管理協議（LMP）有以下關鍵作用：

（1）鏈路管理協議（LMP）負責藍牙組件間連接的建立和斷開。在兩個不同的藍牙設備之間建立連接時，該連接由ACL鏈路組成（先傳遞參數），然后就可以建立起一條或多條SCO鏈路。鏈路管理協議（LMP）支持由主、從單元初始化SCO鏈路，支持由主、從單元請求改變SCO鏈路參數；它還提供了一種協商呼叫方案的方法，并支持通過協商確定基帶數據分組大小。

（2）通過監控信道特性、支持測試模式和出錯處理來維護信道。鏈路管理器負責監控無線單元（射頻部分）的信號場強和信號發射功率；鏈路管理器負責監控在DM和DH之間基于質量的信道變化；鏈路管理器還提供支持服務質量（QoS）的能力；每一條藍牙鏈路都具有一個用于鏈路監控的計時器，鏈路管理器利用該計時器對超時進行監控；另外，LMP具有不同藍牙測試模式的PDU，測試模式主要用于對兼容藍牙無線電和基帶的測試（也可用于藍牙設備的鑒權）；鏈路管理器中針對各種錯誤，有相應的出錯處理，還能夠監測鏈接中錯誤消息的數量，一旦超過閉值就將其斷開。

（3）通過連接的發起、交換、核實，進行身份鑒權和加密等安全方面的任務。包括鏈接字（用于身份鑒權）的創建、改變、匹配檢驗；協商加密模式、加密字長度；加密的開始和停止等。

（4）控制微微網內及微微網之間藍牙組件的時鐘補償和計時精度。藍牙的鏈路管理器可以從其他鏈路管理器那里請求時鐘偏移信息（主單元請求，從單元告訴它目前從單元存儲的時鐘偏移，而該時間偏移則是從單元自身在和主單元進行某些數據包交換的過程中得到的）、時隙偏移信息（時隙偏移就是微微網內主單元和從單元傳送的開始時隙之間的時間差，時間差的單位是毫秒）、計時精度信息（時鐘漂移和抖動）。這些信息對微微網內部和微微網間的正常通信是至關重要的，LMP還支持多時隙分組控制。

（5）控制微微網內藍牙組件的工作模式。鏈路管理器還可以控制工作模式轉換過程（強迫或者請求某臺設備把所處工作模式轉換為以下模式之一：保持、呼吸或者休眠）。在休眠模式下，鏈路管理器會負責廣播消息給休眠的設備、處理信號參數以及喚醒休眠的設備等任務。鏈路管理器還會負責解除休眠。

（6）其他功能。包括支持對鏈路管理器協議版本信息的請求、請求命名、主從角色切換等。

3.邏輯鏈路控制與適應協議（L2CAP）

L2CAP支持高層的協議復用、數據包打包重組（SAR）、傳送服務質量（QoS）等。

邏輯鏈路控制與適應協議（L2CAP）有以下關鍵作用：其完成數據的拆裝、基帶與高層協議間的適配，并通過協議復用、分段及重組操作為高層提供數據業務和分類提取，它允許高層協議和應用接收或發送長過64KB的L2CAP數據包。數據重傳和低級別流控由L2CAP協議完成。

邏輯鏈路控制與適應協議（L2CAP）的關鍵作用包括以下內容：

（1）協議復用。L2CAP支持協議復用，因為基帶協議不能識別并支持任何類型段，而這些類型段則用于標識要復用的更高層協議。L2CAP必須能夠區分高層協議，如藍牙服務搜索協議（SDP）、RFCOMM和電話控制（TCS）。在信道上收到的每一個L2CAP分組都指向相應的高層協議。

（2）信道的連接、配置、打開和關閉。L2CAP基于分組，但它實際上遵循的是一個基于信道的通信模型。一條信道代表遠程設備上兩個L2CAP實體間的數據流。信道可以是面向連接的，也可以是無連接的。面向連接的數據信道提供了兩設備之間的連接，無連接的信道限制數據向單一方向流動。但要注意，如果一開始兩個設備之間沒有物理鏈路存在，系統使用LMP命令來產生物理鏈路。

（3）分段與重組。藍牙與其他有線物理介質相比，由基帶協議定義的分組在大小上受到限制。輸出與最大基帶有效載荷口HS分組中的341B關聯的最大傳輸單元（MTU）限制了更高層協議帶寬的有效使用，而高層協議要使用更大的分組。大L2CAP分組必須在無線傳輸前分段成為多個小基帶分組。同樣，收到多個小基帶分組后也可以重新組裝成大的單一的L2CAP分組。在使用比基帶分組更大的分組協議時，必須使用分段與重組功能。實際上，所有L2CAP分組都可以在基帶分組的基礎上進行分段。

（4）服務質量（QoS）。L2CAP連接建立過程允許交換有關兩個藍牙單元之間的服務質量信息。每個L2CAP設備必須監視由協議使用的資源并保證服務質量（QoS）的完整實現。L2CAP還提供QoS授權控制，以避免其他信道違反QoS協定。

（5）組管理。許多協議包含地址組的概念。L2CAP組管理協議提供允許在微微網成員與組之間有效映射的單元組概念。L2CAP組概念可以實現在微微網上的有效協議映射。如果沒有組概念，為了有效管理組，高層協議就必須直接與基帶協議和鏈路管理器打交道。

2.2.2 電話控制協議

1.二元電話控制協議（TCS BIN）

二元電話控制協議（TCS Binary或TCS BIN）是面向比特的協議，它定義了藍牙設備間建立語音和數據呼叫的呼叫控制信令。此外，還定義了處理藍牙TCS設備群的移動管理進程。基于ITU-T推薦書Q.931建議的TCS Binary被定義為藍牙的二元電話控制協議規范。

2.電話控制協議——AT命令集（AT Commands）

藍牙SIG根據ITU-TV250建議和GSM07.07定義了在多使用模式下控制移動電話和調制/解調器的AT命令集（可用于傳真業務）。

被采用的協議有以下幾種。

（1）點對點協議（PPP）。在藍牙技術中，PPP位于RFCOMM上層，完成點對點的連接。

（2）TCP/UDP/IP。TCP/UDP/IP協議是由IEEE制定的，廣泛應用于互聯網通信的協議，在藍牙設備中使用這些協議是為了與互聯網相連接的設備進行通信。藍牙設備均可以作為訪問Internet的橋梁。

（3）對象交換協議（OBEX）。IrOBEx（簡寫為OBEX）是由紅外數據協會（IrDA）制定的會話層協議，它采用簡單的和自發的方式交換目標。假設傳輸層是可靠的，OBEX就能提供諸如HTTP等一些基本功能，采用客戶機/服務器模式，獨立于傳輸機制和傳輸應用程序接口（API）。除了OBEX協議本身以及設備之間的OBEX保留用“語法”，OBEX還提供了一種表示對象和操作的模型。

另外，OBEX協議定義了“文件夾列表”的功能目標，用來瀏覽遠程設備上文件夾的內容。在第一階段，RFCOMM被用作OBEX的唯一傳輸層。將來可能會支持TCP/IP作為傳輸層。

（4）無線應用協議（WAP）。無線應用協議（WAP）是由無線應用協議論壇制定的，它融合了各種廣域無線網絡技術，其目的是將互聯網的內容以及電話業務傳送到數字蜂窩電話和其他無線終端上。

選用WAP，可以充分復用為無線應用環境（WAE）所開發的高層應用軟件，包括能與PC上的應用程序交互的WML和WTA瀏覽器。構造應用程序網關就可以在WAP服務器和PC上的某些應用程序之間進行調節，從而可以實現各種各樣隱含的計算功能，比如遠程控制、從PC到手持機預取數據等。WAP服務器還允許在PC和手持機之間交換信息，帶來信息中轉的概念。WAP框架也使得使用WML和WML Script作為“通用”的軟件開發工具來為手持機開發定制應用程序成為可能。

2.2.3 主機控制接口功能規范

1.通信方式

主機控制器接口（Host Controller Interface，HCI）是通過包的方式來傳送數據、命令和事件的，所有在主機和主機控制器之間的通信都以包的形式進行。包括每個命令的返回參數都通過特定的事件包來傳輸。HCI有數據、命令和事件三種包，其中數據包是雙向的，命令包只能從主機發往主機控制器，而事件包始終是主機控制器發向主機的。主機發出的大多數命令包都會觸發主機控制器產生相應的事件包作為響應。命令包分為6種類型：

（1）鏈路控制命令：鏈路控制命令是允許主機控制器控制與其他藍牙設備的連接。在鏈路控制命令運行時，LM控制藍牙Piocnet與Scatternet的建立與維持。這些命令指示LM創建及修改與遠端藍牙設備的連接鏈路，查詢范圍內的其他藍牙設備，及其他鏈路管理協議命令。

（2）鏈路策略命令：用于改變本地和遠端設備鏈路管理器的工作方式，允許主機以適當的方式管理Piocnet。

（3）主機控制和基帶命令：主機控制器及基帶命令被用來改變與建立諸如聲音設置、認證模式、加密模式的連接相聯系的LM的操作方式。

（4）信息命令：這些信息命令的參數是由藍牙硬件制造商確定的。它們提供了關于藍牙設備及設備的主機控制器，鏈路管理器及基帶的信息。主機設備不能更改這些參數。

（5）狀態命令：狀態命令提供了目前HCI、LM及BB的狀態消息。這些狀態參數不能被主機改變，除了一些參數可以被重置。

（6）測試命令：測試命令能夠測試藍牙硬件各種功能，并為藍牙設備的測試提供不同的測試條件。

2.通信過程

當主機與基帶之間用命令的方式進行通信時，主機向主機控制器發送命令包。主機控制器完成一個命令，大多數情況下，它會向主機發出一個命令完成事件包，包中攜帶命令完成的信息。有些命令不會收到命令完成事件，而會收到命令狀態事件包，若收到該事件則表示主機發出的命令已經被主機控制器接收并開始處理，過一段時間該命令被執行完畢時，主機控制器會向主機發出相應的事件包來通知主機。如果命令參數有誤，則會在命令狀態事件中給出相應錯誤碼。假如錯誤出現在一個返回Command Complete事件包的命令中，則此Command Complete事件包不一定含有此命令所定義的所有參數。狀態參數作為解釋錯誤原因同時也是第一個返回的參數，總是要返回的。假如緊隨狀態參數之后是連接句柄或藍牙的設備地址，則此參數也總是要返回的，這樣可判別出此Command Complete事件包屬于那個實例的一個命令。在這種情況下，事件包中連接句柄或藍牙的設備地址應與命令包種的相應參數一致。假如錯誤出現在一個不返回Command Complete事件包的命令中，則事件包包含的所有參數都不一定是有效的。主機必須根據與此命令相聯系的事件包中的狀態參數來決定它們的有效性。

3.HCI流量控制

HCI的流量控制是為了管理主機和主機控制器中有限的資源并控制數據流量而設計的，由主機管理主機控制器的數據緩存區，主機可動態地調整每個連接句柄的流量。

對于命令包的流量控制，主機在每發一個命令之前都要確定當前能發命令包的數目，當然，在開機和重啟時發命令包可以不用考慮接收情況，直到收到命令完成事件包或命令狀態事件包為止。因為在每個命令完成事件包和命令狀態事件包中都有Num_HCI_Command_Packets選項表明當時主機能向主機控制器發送的命令包的數目，而對于每個命令必然會有相應的命令完成事件包和命令狀態事件包，主機就能控制命令包不會溢出。

對于數據包的流量控制，一開始，主機調用Read_Buffer_Size命令，該命令返回的兩個參數決定了主機能發往主機控制器的ACL和SCO兩種數據包的大小的最大值，同時兩個附加參數則說明了主機控制器能接收的ACL和SCO數據包總的數目。而每隔一段時間，主機控制器會向主機發Number_Of_Complete_Packets事件，該事件的參數值表明了對每個連接句柄已經處理的數據包的數目（包括正確傳輸和被丟棄的）。主機根據一開始就知道的總數，減去已經處理的包的數目，則可計算出還能發多少數據包，從而控制數據包的流量。

如有必要，HCI的流量控制也可由主機控制器來實現對主機的控制，可以通過Set_Host_Controller_To-Host_Flow_Control命令來設置，其控制過程基本與主機控制過程類似，只是命令稍有不同。當主機收到斷鏈確認的事件后，就認為所有傳往主機控制器的數據包已經全部被丟棄，同時主機控制器中的數據緩沖區也被釋放了。

2.2.4 RFCOMM協議

RFCOMM是基于ETSI07.10規范的串行線仿真協議。電纜替換協議在藍牙基帶上仿真RS-232控制和數據信號，為使用串行線傳送機制的上層協議（如OBEX）提供服務。

藍牙技術的目的是替代電纜，很明顯最應該替代的似乎就是串行電纜。要有效地實現這一點，藍牙協議棧需要提供與有線串行接口一致的通信接口，以便能為應用提供一個熟悉的接口，使那些不曾使用過藍牙通信技術的傳統應用能夠在藍牙鏈路上無縫地工作。對于熟悉串行通信應用開發的人員來說，無須做任何改動即可保證應用能在藍牙鏈路上正常工作。然而傳輸的協議并不是專門為串口而設計的。

SIG在協議棧中定義了一層與傳統串行接口十分相似的協議層，這層協議就是RFCOMM，它的主要目標是要在當前的應用中實現電纜替代方案。

RFCOMM使用L2CAP實現兩個設備之間的邏輯串行鏈路的連接。需要特別指出的是，一個面向連接的L2CAP信道能將兩個設備中的兩個RFCOMM實體連接起來。在給定的時間內，兩個設備之間只允許有一個RFCOMM連接，但是這個連接可以被復用，所以設備間可以存在多個邏輯串行鏈路。第一個RFCOMM的客戶端在L2CAP上建立RFCOMM連接；已有連接上的其他用戶能夠利用RFCOMM的復用能力，在已有的鏈路上建立新的信道；最后關閉RFCOMM串行鏈路的用戶將結束RFCOMM連接。每個復用鏈路用一個數字來標識，這個數字被稱作數據鏈路連接標識符（DLCI）。

在一個單獨的RFCOMM連接上，規范允許建立多達60個復用的邏輯串行鏈路，但是對于一個RFCOMM實現而言，沒有強制性的規定不能超過這個復用級別。DLCI0為控制信道，DLCI1根據服務器信道概念不能使用，DLCI62～63保留使用。