藍牙L2CAP協議

L2CAP簡介

L2CAP全稱爲邏輯鏈路與適配協議，其爲高層協議如SDP、RFCOMM的提供了複用接口，並提供數據的分割/重組和高品質服務信息的傳輸。

下面我將基於遠端和協議層級操作、數據包格式、信道命令格式、狀態機進行分別說明。

其整體的結果圖如下：

通用操作

信道標識符

L2CAP傳輸是基於信道的概念，類似於fifo的通信通道，他是一個點對點的通道，每個通道都有一個獨立的信道標識符（channel identifier，CID），以下簡稱CID。學習L2CAP，理解信道是非常重要的，在HCI層的配置信息交互完成之後，信道就會被建立，在ACL鏈路中通常會建立一個信令信道，如CID號爲0x0001，用於發送控制指令。

CID由一個字標識，即兩個bytes，其中0x0000不使用，0x0001--0x003f有固定的用途，具體可以去查相關描述的表格，在0x003f之後的可以動態分配，一般做爲數據傳輸的cid，下面給出特定cid的用途：

上面描述的cid命名空間可用於ACL、ASB和AMP鏈路，下圖中的命名空間則用於LE鏈路：

兩個設備間操作

下圖說明了不同設備之間的L2CAP實體間通信的使用方式。

在面向連接的數據信道（如語音通話數據通道）提供了兩設備間的連接，而CID則用於標識信道的每一端。無連接信道（如短信）限制數據向單一方向的流動。

有一些信道是作爲特殊用途的，如信令信道，固定的CID=0x0001（LE固定爲0x0005）。該信道用於創建和建立面向連接的數據信道，並可對這些信道的特性變化進行協商。當兩端協商好配置信息之後，會動態分配另一個信道，從上一小節我們可以知道0x0040之後都是爲動態分配的信道，這些信道用於上層的數據傳輸。

層級間操作

層級間用請求-確認、指示-回覆模型通訊，即上層通過向下層發出請求，下層處理完成之後會給出確認；同時下層通過指示的方式通知上層，上層處理完之後會給出回覆，其過程如下圖所示：

信道工作模式

邏輯信道可以工作在5種不同的模式下（可以理解爲5種不同的使用場景），最後一種是LE設備特有的：

1. Basic L2CAP Mode(equivalent to L2CAP specification in Bluetooth v1.1) 默認模式，在未選擇其他模式的情況下，用此模式。
2.     Flow Control Mode 此模式下不會進行重傳，但是丟失的數據能夠被檢測到，並報告丟失。
3.     Retransmission Mode 此模式確保數據包都能成功的傳輸給對端設備。
4.     Enhanced Retransmission Mode 此模式和重傳模式類似，加入了Poll-bit等提高恢復效率。
5.     Streaming Mode 此模式是爲了真實的實時傳輸，數據包被編號但是不需要ACK確認。設定一個超時定時器，一旦定時器超時就將超時數據沖掉。
6.     LE Credit Based Flow Control Mode 被用於LE設備通訊。
    

 

數據包傳輸格式

L2cap協議通訊是建立在信道基礎上的數據包，其數據包的類型具體有四種，下面我們將分別做出介紹。

• 面向連接通訊

 首先我們介紹一下面向連接和無連接通訊的區別：面向連接的服務是按順序，保證傳輸質量的，可恢復錯誤和流量控制的可靠的連接；無連接服務是不按順序，不保證傳輸質量的，不可恢復錯誤不進行流量控制的不可靠連接。舉一個簡單的例子說明，打電話是面向連接通訊，短消息則是無連接通訊。

面向連接通訊工作在默認模式下，其的數據格式如下圖：

Length爲數據包的長度，Channel ID（CID）爲上文中介紹的通道標示符。

無連接通訊

 Length爲數據包長度，CID固定爲0x0002，PSM指明上層協議的類型如RFCOMM、SDP、ATT等。

• 在重傳、流控、流模式下的面向連接的通訊

Length爲數據包的長度，Channel ID爲通道標示符，L2CAP SDU Length表示數據單元的長度，FCS（Frame Check Sequence）幀校驗序列，Control字段根據不同的架構和功能分爲三種格式：

 

1）、Standard Control Field Formats

該格式一般用於重傳模式和流控模式，字段描述如下：

 

2）、Enhanced Control Field Formats

該格式一般用於加強重傳模式和流模式，字段描述如下：

 

3）、Extended Control Field Formats

該格式一般用於加強重傳模式和流模式，字段描述如下：

•  X表示留給將來使用，
•     ReqSeq（Receive sequence number）接收的連續數據包的編號
•     TxSeq（Send sequence number）發送的連續數據包的編號
•     R（Retransmission Disable Bit）使能重傳
•     SAR（Segmentation and Reassembly）代表分割重組控制，描述如下：

• S（supervisory function）用來標記S-frame的類型，有四種，如下：

• P（poll）請求一個回覆
• F（final）回覆的時候將其置一

 

• 在LE credit模式下的面向連接的通訊

 

參數類型在上文中已經介紹過了。

信道命令傳輸格式

命令信道是用於建立連接、配置協商、信道管理等作用的信道，固定ACL鏈路用CID=0x0001，LE鏈路用CID=0x0005。當下層連接已建立，且l2cap傳輸使能這兩個信道就能被使用。其通訊機制是request和response的方式，協議包的框架根據上面的描述可以看出，爲默認模式C-freme（control frame）框架，如下圖所示：
 

 

 

其中荷載的字段通用描述爲：

 

Identifer 標識數據包，用於匹配請求包和回覆包，Lenght 數據長度，Data 數據荷載（可選），Code爲標識命令的類型，具體描述如下：

 

信道命令分析

下面對信道命令具體的舉幾個例子進行分析：

1）、Command Reject（在core_v5.0的 Vol 3，Part A ，4.1節）

拒絕指令用於回覆指令錯誤其他原因導致的錯誤，其荷載具體的格式如下圖所示：

 

其中code、identifier、length我們已在上文中介紹，reason是拒絕原因，描述如下：

 

Data字段根據reason的不同也會有鎖區別，描述如下：

2）、Connection Request（在core_v5.0的 Vol 3，Part A ，4.2節）

此指令用於在兩個設備間創建一個l2cap 的channel，其荷載具體的格式如下圖所示：

PSM爲Protocol/Service Multiplexer，指明上層協議的類型，source CID爲請求方的CID。

3）、Connection Response（在core_v5.0的 Vol 3，Part A ，4.3節）

此指令用於對創建一個l2cap 的channel請求的回覆，其荷載具體的格式如下圖所示：

 

result 字段代表請求的結果，其值的描述如下：

status字段只有在result=0x0001是纔有效，描述如下：

由於指令比較多，其他指令這裏不在一一敘述，有興趣可以去看藍牙核心規範。

狀態機

L2cap共有12中狀態：

CLOSED：channel未連接

WAIT_CONNECT：發出一個連接請求，收到操作被掛起的回覆

WAIT_CONNECT_RSP：發出一個連接請求，沒有收到回覆

CONFIG：配置項正在協商

OPEN：數據可以傳輸

WAIT_DISCONNECT：發出了一個斷開連接請求，但沒有收到回覆

WAIT_CREATE：發出一個建立通道的請求，收到操作被掛起的回覆

WAIT_CREATE_RSP：發出一個建立通道的請求，但沒有收到回覆

WAIT_MOVE：發出了移除當前通道的請求，收到操作被掛起的回覆

WAIT_MOVE_RSP：發出了移除當前通道的請求，但沒有收到回覆

WAIT_MOVE_CONFIRM：已經對移除通道的請求做了回覆，等待對端的確認

WAIT_CONFIRM_RSP：對移除通道回覆的確認，等待確認回覆

下面是狀態機的轉換圖：

上面就是對l2cap的簡單描述，當然核心規範中還有關於分割/重組、重傳、流控模式的具體操作流程描述，大家有興趣的可以去深入瞭解。下面對抓去的數據進行具體的分析。

L2CAP協議數據分析

分析的log使用手機進行抓取，log會在此文檔的附件中。

其中藍色的部分是hci的數據，上一篇已經說過了，有興趣可以看我的hci協議分析，紅色爲具體的l2cap的數據，在這裏我舉四個例子，附件文檔解析到sdp開始建立爲止。

1）、Master：signaling，Information request

00000010 00000011 00100000 00001010 00000000 00000110 00000000 00000001 00000000 00001010 00000010 00000010 00000000 00000010 00000000

PDU length：00000110 00000000（0x0006=6，包長度爲6，不包括CID）

CID：00000001 00000000（0x0001，signaling）

Code：00001010（0x0a，Information request ）

Identifier：00000010（0x02）

Command Length；00000010 00000000（0x0002=2，數據長度爲2）

data：00000010 00000000（0x0002，Extended features supported）

2）、Slave：signaling，Information response

00000010 00000011 00100000 00010000 00000000 00001100 00000000 00000001 00000000 00001011 00000010 00001000 00000000 00000010 00000000 00000000 00000000 10000000 00000000 00000000 00000000

PDU length：00001100 00000000（0x000c=12，包長度爲12，不包括CID）

CID：00000001 00000000（0x0001，signaling）

Code：00001011（0x0b，Information response）

Identifier：00000010（0x02）

Command Length；00001000 00000000（0x0008=8，數據長度爲8）

Info type：00000010 00000000（0x0002，Extended features supported）

Result：00000000 00000000（0x0000，success）

Extended feature mask：10000000 00000000 00000000 00000000（其描述在覈心規範L2CAP章節的4.12 EXTENDED FEATURE MASK）

3）、Master：signaling，Information request

00000010 00000011 00100000 00001010 00000000 00000110 00000000 00000001 00000000 00001010 00000011 00000010 00000000 00000011 00000000

PDU length：00000110 00000000（0x0006=6，包長度爲6，不包括CID）

CID：00000001 00000000（0x0001，signaling）

Code：00001010（0x0a，Information request ）

Identifier：00000011（0x03）

Command Length；00000010 00000000（0x0002=2，數據長度爲2）

data：00000011 00000000（0x0003，Fixed Channels supported）

4）、Slave：signaling，Information response

00000010 00000011 00100000 00010100 00000000 00010000 00000000 00000001 00000000 00001011 00000011 00001100 00000000 00000011 00000000 00000000 00000000 00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000

PDU length：00010000 00000000（0x0010=16，包長度爲16，不包括CID）

CID：00000001 00000000（0x0001，signaling）

Code：00001011（0x0b，Information response）

Identifier：00000011（0x03）

Command Length；00001100 00000000（0x000c=12，數據長度爲12）

Info type：00000011 00000000（0x0003，Fixed Channels supported）

Result：00000000 00000000（0x0000，success）

Extended feature mask：00000010 00000000 00000000 00000000 00000000 00000000 00000000 00000000（其描述在覈心規範L2CAP章節的4.13 FIXED CHANNELS SUPPORTED）