当前位置：首页 > news >正文

蓝牙L2CAP协议概述

news 来源：原创 2025/5/8 16:14:22

蓝牙中的 L2CAP（逻辑链路控制与适配协议，Logical Link Control and Adaptation Protocol） 是蓝牙协议栈中的核心层之一，位于基带层（BR/EDR）或链路层（LE）之上，为上层协议（如RFCOMM、ATT、GATT等）提供统一的适配接口。它的核心作用是抽象底层物理链路差异，支持不同类型的数据传输需求（如可靠连接、无连接广播、低功耗传输等）。

个人理解，它实际上就是用来操作controller中baseband层的逻辑链路的；所以叫做逻辑链路控制与适配协议。它的操作核心就是通道，它基于底层的逻辑链路，创建多个通道，用于不同的上层协议，每个通道有自己的通道号。其中有一些通道号已经被固定用于特殊用途。

HCI层实际上可以认为是controller的体现，这一层没有任何的自主对远端设备发起的行为（要么是controller发起，然后通过HCI层报给上层，要么是上层发起，通过HCI层控制controller进行），因此实际上没有HCI链路一说，在BTHOST中，与远端设备有关的最底层就是L2CAP层，这一层需要与对方的L2CAP层进行通信。或者也可以把controller建立的链路视为HCI的链路。

L2CAP通道可以在为每个L2CAP通道选择的几种不同模式中运行。
包括：
基本L2CAP模式（仅限BR/EDR和部分LE固定信道）
流量控制模式（仅限BR/EDR）
重传模式（仅限BR/EDR）
增强重传模式（仅限BR/EDR）
流传输模式（仅限BR/EDR）
基于信用的流量控制模式（仅限LE）
增强基于信用的流量控制模式（BR/EDR和LE）

一些概念

L2CAP channel，在两个设备之间的逻辑通道，通过CID区分
SDU, L2CAP跟上层通信使用的数据包，服务数据单元
PDU，L2CAP跟下层通信使用的数据包，协议数据单元
L2CAP有基础模式，增强重传模式，流模式，重传模式，流控模式
基础模式主要用Basic information frame（B-frame）；它是PDU的开头，包含长度和CID
Control frame（C-frame）；它是包含L2CAP信令信息的PDU,仅用在信令通道上
segmentation和reassembly，SDU的拆包组包，主要用于非基础模式；
fragmentation和recombination，PDU的拆包组包，他们可能会用在所有模式下

• Basic L2CAP Mode（(equivalent to L2CAP specification in Bluetooth v1.1) 默认模式，在未选择其他模式的情况下，用此模式。
• Flow Control Mode，此模式下不会进行重传，但是丢失的数据能够被检测到，并报告丢失。
• Retransmission Mode，此模式确保数据包都能成功的传输给对端设备。
• Enhanced Retransmission Mode，此模式和重传模式类似，加入了 Poll-bit 等提高恢复效率。
• Streaming Mode，此模式是为了真实的实时传输，数据包被编号但是不需要 ACK 确认。设定一个超时定时器，一旦定时器超时就将超时数据冲掉。
• LE Credit Based Flow Control Mode，被用于 LE 设备通讯。
• Enhanced Credit BasedFlow Control Mode

ACL-U APB-U LE-U等术语是ctrller的baseband层里逻辑链路描述中的。

L2CAP将通道映射到控制器的逻辑链路，逻辑链路在控制器的物理链路上运行。本地控制器和远程控制器之间的所有逻辑链路都运行在单个物理链路上。每个BR/EDR物理链路有一条ACL-U逻辑链路，每个LE物理链路有一条LE- U逻辑链路。两台设备之间BR/EDR物理链路上的所有信道都应映射到单个ACL-U逻辑链路上。通过两个设备之间的LE物理链路的所有通道应被视为单个LE- U逻辑链路。

L2CAP是基于包的，但遵循基于通道的通信模型。通道表示远程设备中L2CAP实体之间的数据流。通道可以是面向连接的，也可以是无连接的。除了L2CAP无连接通道（CID Ox0002）和两个L2CAP信令通道（CID Ox0001和Ox0005）之外的所有通道都是面向连接的。除信息负载字段外，所有L2CAP层报文字段都使用小端字节顺序。封装在L2CAP信息负载中的高层协议的端序是特定于协议的。

如果在逻辑链路类型的控制标识符（CID）上接收到的数据报文（PDU）未被分配或未被预留用于该逻辑链路类型，则接收方应忽略该 PDU。在所有的 L2CAP 数据报文单元中，PDU 长度字段表示整个 L2CAP 数据报文单元的字节大小（不包括基本 L2CAP 头部的 4 个字节）。因此，一个数据报文单元的长度不能超过 65539 个字节。在包含“信息负载”字段的协议数据单元中，该字段中的字节数量（即负载大小）不应超过对端设备针对该信道的最大传输单元（MPS）。

数据格式

L2CAP 的数据格式除非特别声明，否则都是小端

面向连接的基本模式数据格式（B-frame）

在这里插入图片描述
length表示的是information payload的长度
CID表示这包数据是发给哪个通道

无连接的基本模式数据格式（G-frame）

在这里插入图片描述
Length:InFormation payload + PSM 的长度
CID：固定 0x0002
PSM(Protocol/Service Multiplexer):主要就是用于标识协议的

信号封包的数据格式

用于管理 ACL-U 逻辑链路上的通道的信令通道应使用 CID Ox0001，而用于管理 LE-U 逻辑链路上的通道的信令通道应使用 CID Ox0005。信令通道在底层逻辑传输建立且 L2CAP 通信启用后即可使用。图 4.1 展示了包含信令命令（C 帧）的 L2CAP 数据报文的通用格式。
在固定信道 CID Ox0001 上，可以使用单个 C 帧发送多个命令，而在固定信道 CID 0x0005 上，每个 C 帧只能发送一个命令。命令的形式包括请求、响应和指示。
所有 L2CAP 实现都应支持接收有效载荷大小不超过信令最大传输单元（MTU）的 C 帧。C 帧的最小支持有效载荷大小（MTUsig）在表 4.1 中定义。L2CAP 实现不应使用超出对端设备 MTUsig 的 C 帧。如果设备接收到的 C 帧超出了其 MTU 标识值，则应发送一个 L2CAP_COMMAND_REJECT_RSP 数据包，其中包含所支持的 MTU 标识值。实现者应能够处理通过固定通道标识号 Ox0001 发送的 L2CAP 数据包中的多个命令。
在这里插入图片描述

传统蓝牙的 CID 是固定的 0x0001,低功耗的 CID 是固定的 0x0005， information payload 的格式为：
在这里插入图片描述
Code：标示 Signaling command id,如下：

Identifier (1 octet)：用于标示 command 的发送序列，response 必须跟 request 相同
Length (2 octets)：用于标示后续的 data 长度
Data (0 or more octets)：针对不同的 signaling command，后续的 data 是不同的，具体 command具体分析。

l2cap拆包流程

在这里插入图片描述

拆包是一个什么样的标准呢？这个是一个好问题，这个是根据蓝牙初始化的 HCI read buffer size command 中的 acl size 来决定的，也就是说每个 controller是不同的
通过什么来区分是否一包数据拆包了呢？这个问题也非常好，是通过HCI acl format 中的 pb flag 来区分，我们在这里贴下 HCI acl format:
在这里插入图片描述

以下从技术细节、功能特性、分层架构和应用场景展开讲解：

一、L2CAP的核心定位与分层架构

1. 协议栈中的位置

下层依赖：
- 传统蓝牙（BR/EDR）：基于基带层的ACL-U（异步无连接链路）或SCO（同步面向连接链路）传输数据。
- 低功耗蓝牙（LE）：基于链路层的LE-U链路（支持连接态和广播态数据传输）。
上层服务：为SDP（服务发现协议）、RFCOMM（串口仿真）、ATT/GATT（属性协议/通用属性规范）等上层协议提供统一的数据包封装和传输服务。

2. 核心设计目标

跨物理层适配：屏蔽BR/EDR和LE底层链路差异（如包长、传输机制），向上层提供统一接口。
数据分段与重组（Segmentation and Reassembly, SAR）：将上层大尺寸数据分割为底层链路可传输的数据包（如基带层MTU为2745字节，LE链路层MTU默认23字节，需L2CAP重组）。
多信道复用：在单一物理链路上建立多个逻辑信道（Channel ID, CID），支持同时传输多种类型数据（如音频流与控制信令分离）。

二、L2CAP的核心功能特性

1. 服务类型与信道模型

L2CAP支持三种逻辑信道，通过**信道ID（CID）**区分：

信道类型	CID值	传输模式	核心特性	典型应用
信令信道	0x0001	面向连接	必选信道，用于L2CAP层的连接建立、参数协商（如MTU）、错误处理（如断开连接）。	所有L2CAP连接的初始化
面向连接的信道	0x0002+	面向连接（可靠）	支持流量控制、错误重传（通过序列号和ACK/NACK机制），确保数据按序可靠传输。	RFCOMM串口通信、文件传输（OBEX）
无连接信道	0x0000	无连接（不可靠）	支持单播或组播，无需预先建立连接，适合延迟敏感但允许丢包的数据（如广播信令）。	BLE广播数据（如GAP设备发现）

2. MTU协商机制

传统蓝牙（BR/EDR）：默认MTU为672字节，可通过信令信道协商扩展至2745字节（需基带层支持）。
低功耗蓝牙（LE）：
- 初始MTU为23字节（链路层最大传输单元），但可通过**MTU更新请求（MTU Exchange）**动态协商，最高可达24577字节（蓝牙5.0+支持扩展MTU）。
- 关键作用：例如BLE中ATT协议传输长数据（如传感器原始数据）时，需通过L2CAP扩展MTU减少分段次数，提升传输效率。

3. 服务质量（QoS）支持

BR/EDR场景：通过基带层的ACL链路实现流量控制，L2CAP层可标记数据优先级（如音频流优先于文件传输）。
LE场景：依赖链路层的连接间隔（Connection Interval）和超时参数（Supervision Timeout），L2CAP层通过控制数据包发送频率间接实现QoS（如实时数据用短连接间隔，非实时用长间隔省电）。

4. 错误处理与可靠性

面向连接信道：使用**序列号（SN）和期待序列号（EXSN）**机制，接收方通过ACK/NACK通知发送方重传丢失的数据包（类似TCP的ARQ）。
无连接信道：不保证可靠性，依赖上层协议（如ATT）的重传机制（BLE中若L2CAP层丢包，ATT层需重新发送属性值）。

三、传统蓝牙（BR/EDR）与低功耗蓝牙（LE）的L2CAP差异

1. 底层链路依赖不同

BR/EDR：基于基带层的时分复用（TDD）链路，支持ACL-U（异步数据）和SCO（同步语音，如蓝牙耳机通话）。
LE：基于链路层的连接态（Connection）或广播态（Advertising），L2CAP在连接态通过LE-U链路传输，广播态通过无连接信道传输（如GAP广播包中的L2CAP层数据）。

2. MTU与分段策略

BR/EDR：基带层MTU较大（最大2745字节），L2CAP分段需求较低，适合传输大尺寸数据（如蓝牙文件传输）。
LE：初始MTU极小（23字节），必须依赖L2CAP分段（如将200字节数据分割为9个23字节的包），或通过MTU协商扩展（蓝牙5.0后支持更大MTU，减少分段开销）。

3. 连接建立流程

BR/EDR：需先建立基带层ACL连接，再通过L2CAP信令信道协商信道参数（如MTU、QoS）。
LE：链路层先建立连接（Connection），L2CAP层在连接基础上建立信道（CID），支持更快速的连接初始化（如BLE设备配对后秒级建立L2CAP连接）。

四、L2CAP与上层协议的交互

1. 经典案例：BLE中的ATT/GATT传输

流程：
1. 设备通过链路层建立LE连接；
2. L2CAP层协商MTU（默认23字节，可扩展），创建面向连接的信道（CID=0x0004等）；
3. ATT协议将数据封装为属性协议数据单元（PDU），交由L2CAP层分段（如ATT MTU=23字节时，每个PDU不超过21字节，留2字节给L2CAP头）；
4. L2CAP层将分段后的数据包通过LE-U链路传输，接收方重组后交给ATT层解析。
关键优化：蓝牙5.0引入LE信用量流控（LE Credit-Based Flow Control），L2CAP层可缓存多个未确认的数据包，提升高吞吐量场景效率（如实时传感器数据传输）。

2. 传统蓝牙：RFCOMM与串口仿真

机制：RFCOMM基于L2CAP面向连接的信道，模拟RS-232串口通信，支持多端口复用（如蓝牙鼠标的控制端口和数据端口分离）。
L2CAP作用：为RFCOMM提供可靠的字节流传输，屏蔽基带层的跳频和数据包差异，使上层应用无需关心底层物理链路细节。

3. 服务发现（SDP）

SDP通过L2CAP的信令信道（CID=0x0001）查询设备支持的服务（如是否支持A2DP音频协议），L2CAP负责传输SDP请求/响应数据包，确保信令交互的可靠性。

五、L2CAP的技术挑战与演进

1. 低功耗场景下的效率问题

LE初始MTU小：早期BLE设备因MTU小导致分段开销大（如传输200字节数据需9次交互），蓝牙5.0通过MTU扩展（最大24577字节）和信用量流控优化，传输效率提升50%以上。
功耗平衡：L2CAP层的重传机制可能增加功耗，需在可靠性和省电之间权衡（如智能手表传输心率数据时，允许一定丢包以降低重传频率）。