概要：

邏輯鏈路控制和適配協議(L2CAP),支持高層協議多路復用、數據分段和重組,并且支持傳送服務質量信息。 本文件主要針對協議狀態自動機、分組格式及構成相關內容進行描述。

L2CAP層次結構(L2CAP architectural blocks)：

基帶規范定義了兩種鏈路類型：同步面向連接鏈路(SCO)和異步無連接鏈路(ACL)。SCO 鏈路采用保留帶寬支持實時語音通信。ACL鏈路支持最佳通信。L2CAP規范僅定義ACL鏈路而不支持 SCO鏈路。
下面介紹L2CAP的幾大功能：

1.協議復用

L2CAP應支持協議復用，因為基帶協議不支持任何 ‘類型’ 域，而這些類型域則用于標識要復用的更高層協議。L2CAP必須能夠區分高層協議，例如，服務搜索協議，RFCOMM，和電話控制等。

2.分段與重組

與其它有線物理介質相比, 由基帶協議定義的分組在大小上受到限制。輸出與最大基帶有效載荷(DH5分組中的341字節)關聯的最大傳輸單位( MTU )限制了更高層協議帶寬的有效使用，而高層協議要使用更大的分組。大 L2CAP分組必須在無線傳輸前分段成為多個小基帶分組。同樣,收到多個小基帶分組后也可以重新組裝成大的單一的 L2CAP 分組。在使用比基帶分組更大的分組協議時,必須使用分段與重組( SAR )功能。

3.服務質量

L2CAP 連接建立過程，允許交換有關兩藍牙單元之間服務質量的信息。每個L2CAP設備必須監視由協議使用的資源并保證服務質量（QoS）的完整實現。

4.組

許多協議包括地址組的概念。基帶協議支持微微網, 微微網為能夠使用同一時鐘進行同步工作的一組設備。L2CAP 組概念可以實現在微微網上的有效協議映射。如果沒有組概念，為有效管理組，高層協議就必須直接與基帶協議和鏈路管理器打交道。

協議設計的依據：

1.使用鏈路管理器協議在兩單元間建立ACL鏈路。基帶提供數據分組的有序傳輸,但也可能有個別分組損壞或重復。任兩臺設備之間只會有一條ACL鏈路。

2.基帶通常提供全雙工信道。但這并不是說所有L2CAP 通信都是雙向的。多點傳送和單向通信(例如，視頻)并不要求雙工信道。

3.通過使用基帶層提供的機制，L2CAP提供了一條可靠的信道。當收到請求和重發數據時，基帶通常要執行數據完整性校驗，直到數據成功確認或發生超時。由于可能會丟失確認報文，所以甚至在數據成功發送后也會發生超時。基帶協議使用長度為1位的序列號,該序列號用于刪除重復發送的分組。由于所有廣播的L2CAP數據分組的首段都以同一序列位為起始位, 如果需要提供可靠傳輸,就應禁止使用基帶廣播分組。

L2CAP適用范圍：

1.L2CAP 不傳輸由 SCO鏈路所指定的音頻數據。 2.L2CAP 不能進行可靠信道傳輸或保證數據完整性,即：L2CAP不會重發或數據校驗。 3.L2CAP 不支持具有可靠性的廣播信道。 4.L2CAP 不支持一個全局組名的概念。

鏈路主要操作

邏輯鏈路控制和適配協議( L2CAP )是以信道概念為基礎的。通過信道識別符引用每條 L2CAP 信道的端點。

1.信道標識符

信道標識符(CIDs)是表示邏輯信道本地端設備的名字。從 0x0001 到0x003F 的標識符保留用于特定的 L2CAP 功能。空標識符( 0x0000 )則定義為一個非法標識符，并且不得用于目標端。可以根據實際應用目的和情況,以合適方式自由管理其余的CID。但在本地設備與多個遠端設備存在多個并發L2CAP信道的情況下,同一CID不得重新用作本地L2CAP信道端。
上圖是對CID命名空間的定義和劃分進行的總結。 CID的指定與特定設備有關，一臺設備可以獨立于其他設備指定CID(如果它不使用在下表列出的保留CID的話)。這樣,即使通過連接到一個本地設備的多個遠程設備, 將同一CID值指定給(遠程)信道端，本地設備仍然能夠將遠端CID與每一不同的遠程設備聯系起來。

2.設備間操作(OPERATION BETWEEN DEVICES)

上圖說明了CID在不同設備對等L2CAP實體間通信中的使用方式。 面向連接的數據信道提供了兩設備間的連接，而CID則用于標識信道的每一端。無連接信道限制數據向單一方向的流動。這些信道用于支持一個信道“組”，在該信道“組”里發送端CID用于表示一個或多個遠程設備。因此保留了一些CID以備將來特殊用途使用。信號信道是一個保留信道的實例，固定的CID=0x0001。該信道用于創建和建立面向連接的數據信道，并可對這些信道的特性變化進行協商。L2CAP實體必須支持信號信道。另一CID則保留用于呼入的無連接數據通信,無連接的接收信道CID=0x0002.

信道標識類型圖示：

3.層間操作(OPERATION BETWEEN LAYERS)

L2CAP的實施應遵循上圖總體體系結構, 并可在高層協議和低層協議間傳送數據。本文列出了一些L2CAP應用必須實現的服務。每個應用都必須支持一組用于L2CAP 應用間通信的信號指令。L2CAP應用還應準備從低層接受某類型的事件, 并可向高層生成事件。事件如何在層間傳遞則根據實際應用情況而定。

4.MODES OF OPERATION

L2CAP channels may operate in one of five different modes as selected for each L2CAP channel. The modes are: ? Basic L2CAP Mode (equivalent to L2CAP specification in Bluetooth v1.1) 1 ? Flow Control Mode ? Retransmission Mode ? Enhanced Retransmission Mode ? Streaming Mode ? LE Credit Based Flow Control Mode

5.MAPPING CHANNELS TO LOGICAL LINKS

L2CAP映射運行在控制器物理鏈接之上的通道到控制器的邏輯鏈接。所有的邏輯鏈接都運行在本地控制器和遠程控制器的單一物理鏈接之上。每一個BR/EDR物理鏈接都有一個ACL-U邏輯鏈接，每一個LE-U物理鏈接都有一個LE邏輯鏈接但是AMP物理鏈接可能有多個AMP-U邏輯鏈接。

運行在兩個BR/EDR設備物理鏈接上的通道都應該被映射到一個單一的ACL-U邏輯鏈接。運行在兩個AMP設備上的物理鏈接上的通道都應該被映射到一個單一的AMP-U邏輯鏈接，然而在兩個控制器之間的每一個通道都必須到他自己的一一對應的AMP-U邏輯鏈接。運行在兩個LE設備上的物理鏈接上的通道應該被映射到一個單一的LE-U邏輯鏈接。

對于BR/EDR控制器，由L2CAP實現權限控制(創建和授權邏輯鏈接)。對于AMP控制器，L2CAP通知控制器創建和授權邏輯鏈接，最終由控制器實現創建和授權邏輯鏈接。

數據包格式

1.面向鏈接的通道

1.1BASIC L2CAP?MODE

1.2?RETRANSMISSION/FLOW CONTROL/STREAMING MODES

1.3?LE CREDIT?BASED FLOW CONTROL MODE

2.沒有連接的通道

1.1BASIC L2CAP?MODE

3.信號包格式(SIGNALING PACKET FORMATS)

命令負載格式：

Code具體見【BLUETOOTH SPECIFICATION Version 4.1 [Vol 3] page 60 of 668】
SDP請求鏈接數據包：

00000010??00110010 ?00000000??00001100 ?00000000? 00001000 ?00000000 ?00000001 ?00000000 ?0000001000000001 ?00000100 ?00000000??00000001 ?00000000??01000001 ?00000000

每種顏色對應的域如下：

總結

以上是生活随笔為你收集整理的蓝牙核心-L2CAP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。