BLE 协议栈：L2CAP 信道详解

前言
一、定义
- [1、L2CAP 信道概述](#1、L2CAP 信道概述)
二、依赖关系
- 1、协议栈依赖
- 2、上层协议依赖
三、信道类型
- 1、信道类型分类
- 2、信道类型详解
四、信道标识符 (CID)
- [1、CID 分配](#1、CID 分配)
- [2、固定信道 CID 详情](#2、固定信道 CID 详情)
五、信道管理
[六、LE Credit Based 信道](#六、LE Credit Based 信道)
[七、动态 CID 分配](#七、动态 CID 分配)
- 1、分配规则
- 2、动态分配示例
八、信道优先级
- [1、BR/EDR 信道优先级](#1、BR/EDR 信道优先级)
- [2、LE 信道优先级](#2、LE 信道优先级)
九、错误处理
- 1、信道错误代码
- 2、错误处理流程

前言

L2CAP（Logical Link Control and Adaptation Protocol，逻辑链路控制与适配协议）是蓝牙协议栈中的核心适配层，而 L2CAP 信道则是实现数据逻辑传输、协议多路复用的基础载体。

一、定义

1、L2CAP 信道概述

核心职责：

提供逻辑数据通道：作为蓝牙上层协议（如 GATT、SDP）与下层链路层之间的桥梁，屏蔽链路层差异，为上层提供统一的逻辑传输接口；
支持多路复用：在单一链路层连接（如 LE 逻辑链路、BR/EDR ACL 链路）上，同时承载多个 L2CAP 信道，实现不同上层协议的数据并行传输，提升链路利用率；
管理信道生命周期：负责信道的建立、配置、维护与关闭，包括参数协商、状态监控、错误处理等，保障数据传输的稳定性与可靠性。

二、依赖关系

1、协议栈依赖

L2CAP 信道的正常工作依赖于下层链路层和 L2CAP 层自身的基本功能，具体依赖关系如下（分层示意）：

plain 复制代码

┌─────────────────────────────────────────────────────────────┐
│  协议栈依赖关系                                              │
│                                                             │
│  L2CAP 信道 ──────────────────────────────────────────┐     │
│      │                                                │     │
│      ├── 依赖 ─> L2CAP 基本功能                        │     │
│      │           ├── 帧头处理（解析/封装 L2CAP 帧头）   │     │
│      │           ├── CRC 校验（确保数据完整性）         │     │
│      │           └── 重传控制（保障数据可靠传输）        │     │
│      │                                                │     │
│      └── 依赖 ─> 下层链路层连接                         │     │
│                  ├── BR/EDR ACL 逻辑链路（经典蓝牙）    │     │
│                  └── LE 逻辑链路（低功耗蓝牙）          │     │
└─────────────────────────────────────────────────────────────┘

补充说明：L2CAP 信道不直接与物理层交互，所有数据传输均通过底层链路层完成；L2CAP 基本功能是信道实现的基础，若帧头处理、CRC 校验等模块异常，会导致信道传输失败。

2、上层协议依赖

不同类型的 L2CAP 信道对应不同的上层协议，上层协议通过指定的信道类型实现数据传输，具体对应关系如下表：

信道类型（CID）	上层协议	说明
0x0004 (ATT)	ATT/GATT	支撑 GATT 服务、特征值的读写与通知传输
0x0005 (LE Signaling)	L2CAP 信令	用于 L2CAP 信道的建立、配置、关闭等信令交互
0x0040-0x007F	SDP/GAP/厂商特定	适配服务发现、设备管理及厂商自定义功能

三、信道类型

1、信道类型分类

根据传输特性和用途，L2CAP 信道可分为三大类，各类别下包含具体细分类型，具体分类如下：
L2CAP 信道
面向连接信道
无连接信道
固定信道
LE Credit Based
增强重传模式
流控模式
BR/EDR 广播
LE 无连接保留
信令信道
ATT 信道

2、信道类型详解

不同信道类型的传输特性、BLE 支持情况及典型用途存在显著差异，具体详解如下表，方便开发者根据应用场景选择合适的信道类型：

信道类型	说明	BLE 支持	典型用途
Connection-Oriented（面向连接）	需先建立逻辑连接，支持流控、重传，传输可靠	支持	GATT 数据传输、固件升级、调试数据传输
Connectionless（无连接）	无需建立连接，直接广播传输，传输效率高但不可靠	否（仅保留，暂未启用）	BR/EDR 设备广播数据、批量数据分发
Fixed Channel（固定信道）	CID 固定分配，用于核心协议交互，不可动态分配	支持	L2CAP 信令交互、ATT 协议数据传输

四、信道标识符 (CID)

CID（Channel Identifier，信道标识符）是 L2CAP 信道的唯一标识，用于区分同一链路层连接上的不同 L2CAP 信道，蓝牙规范对 CID 的分配范围和用途有明确规定，分为固定分配和动态分配两类。

1、CID 分配

不同 CID 范围对应不同的用途，且在 BLE 和 BR/EDR 中的支持情况不同，具体分配如下表：

CID 范围	说明	BLE	BR/EDR
0x0000	Null CID（空信道，用于标识无效信道）	支持	支持
0x0001	L2CAP Signaling（BR/EDR 信令信道）	-	支持
0x0002	Connectionless Reception（无连接接收信道）	-	支持
0x0003	AMP Manager Protocol（AMP 管理协议信道）	-	支持
0x0004	Attribute Protocol（ATT 信道）	支持	支持
0x0005	LE Signaling Channel（BLE 信令信道）	支持	-
0x0006-0x003F	Reserved（保留，暂未分配用途）	-	-
0x0040-0x007F	Dynamically Allocated（动态分配信道）	支持	支持
0x0080-0x00FF	LE Credit Based Connectionless（BLE 无连接信用信道，保留）	保留	-
0x0100-0xFFFF	Dynamically Allocated（动态分配信道，扩展范围）	支持	支持

2、固定信道 CID 详情

固定信道的 CID 由蓝牙规范统一分配，用途固定，不可动态调整，是蓝牙协议正常工作的核心基础，具体分配详情如下：

plain 复制代码

┌─────────────────────────────────────────────────────────────┐
│  固定信道 CID 分配表                                         │
│  ┌─────────────────┬────────────────────────────────────┐   │
│  │ CID             │ 用途                                │  │
│  ├─────────────────┼────────────────────────────────────┤   │
│  │ 0x0004          │ Attribute Protocol (ATT)           │   │
│  │                 │ （属性协议信道，支撑 GATT 交互）     │   │
│  ├─────────────────┼────────────────────────────────────┤   │
│  │ 0x0005          │ LE Signaling Channel               │   │
│  │                 │ （BLE 信令信道，用于信道管理）       │   │
│  ├─────────────────┼────────────────────────────────────┤   │
│  │ 0x0006-0x003F   │ 保留（规范预留，用于后续扩展）        │   │
│  ├─────────────────┼────────────────────────────────────┤   │ 
│  │ 0x0040-0x007F   │ LE Credit Based Flow Control       │   │
│  │                 │ （BLE 信用基于流控信道，动态分配）    │   │
│  ├─────────────────┼────────────────────────────────────┤   │
│  │ 0x0080-0x00FF   │ LE Credit Based Connectionless     │   │
│  │                 │ (保留，暂未启用)                    │   │
│  └─────────────────┴────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────┘

五、信道管理

L2CAP 信道管理是保障数据可靠传输的核心，包括信道状态监控、信道操作（建立、配置、关闭）等，通过状态机实现信道生命周期的规范化管理。

1、信道状态机

L2CAP 信道的生命周期包含多个状态，状态之间的转换由具体操作触发，具体状态机流程如下（适配 BLE 场景）：
初始化
连接建立请求
通道就绪
连接失败
参数更新
断开连接
资源释放
等待信用
信用接收
Closed
Opening
Open
Closing
WaitForCredit

2、信道操作

2.1、信道建立

信道建立是数据传输的前提，主要分为"请求-响应"两步，同时完成参数协商，具体操作如下表：

操作	说明
L2CAP_ConnectReq	由客户端发起，向服务器请求建立 L2CAP 信道，携带 SPSM、MTU、MPS 等参数
L2CAP_ConnectRsp	由服务器响应，告知客户端连接是否成功，若成功则返回协商后的参数
配置参数协商	双方协商 MTU（最大传输单元）、MPS（最大 PDU 载荷）、流控模式等核心参数，确保参数一致

2.2、信道配置

信道建立后，需配置相关参数以适配数据传输需求，核心参数的默认值、说明如下表，开发者可根据实际场景调整：

参数	说明	默认值
MTU	最大传输单元，指单次可传输的最大数据长度	672 (BR/EDR) / 23 (LE)
MPS	最大 PDU 载荷，指单次 PDU 中可携带的有效数据长度	672 (BR/EDR) / 23 (LE)
Flush Timeout	刷新超时，指未被确认的数据被丢弃的时间阈值	0xFFFF (无限制)
QoS	服务质量，用于定义数据传输的优先级和可靠性要求	Best Effort（尽力而为）

2.3、信道关闭

信道关闭分为主动关闭和被动关闭（如链路断开、错误触发），流程规范且有序，确保资源正常释放，具体步骤如下：

步骤	说明
1	发起方发送断开连接请求（L2CAP_DisconnectReq），告知对端即将关闭信道
2	双方停止数据传输，不再向该信道发送新数据，处理缓存中的剩余数据
3	释放信道相关资源，包括 CID 分配、缓存空间、流控信用等
4	对端发送断开连接响应（L2CAP_DisconnectRsp），确认信道关闭，双方信道进入 Closed 状态

六、LE Credit Based 信道

LE Credit Based（低功耗信用基于信道）是 BLE 场景下最常用的面向连接信道，采用信用机制实现流控，适配低功耗、高可靠性的传输需求（如 GATT 数据传输、固件升级），是蓝牙5.2+ 版本中 L2CAP 信道的核心类型。

1、通道建立流程

LE Credit Based 信道的建立需通过"请求-响应"机制，双方协商核心参数并交换初始信用，具体流程如下：
Server Client Server Client SPSM, MTU, MPS, Initial Credits Result, MTU, MPS, Initial Credits 信道建立成功信道建立失败 alt [Connection Accepted] [Connection Rejected] LE Credit Based Connection Request LE Credit Based Connection Response

2、连接请求参数表

客户端发起连接请求时，需携带核心参数，参数的长度、说明及范围如下，确保服务器能够正确识别并响应：

参数	长度	说明	范围
SPSM	2 字节	服务协议/服务多路复用器，标识上层协议类型	0x0023-0xFFFF
MTU	2 字节	最大传输单元，协商单次可传输的最大数据长度	23-65535
MPS	2 字节	最大 PDU 载荷，协商单次 PDU 的有效数据长度	23-65535
Initial Credits	2 字节	初始信用数，用于流控，信用耗尽后需重新申请	0x0001-0xFFFF

3、连接响应参数表

服务器接收连接请求后，根据自身资源和参数支持情况，返回响应参数，具体如下：

参数	长度	说明	范围
Result	2 字节	连接结果，标识连接是否成功及失败原因	0x0000-0x0005
MTU	2 字节	服务器支持的最大传输单元，需与客户端协商一致	23-65535
MPS	2 字节	服务器支持的最大 PDU 载荷，需与客户端协商一致	23-65535
Initial Credits	2 字节	服务器分配的初始信用数，用于客户端向服务器传输数据	0x0001-0xFFFF

4、连接结果代码

连接结果代码（Result）用于标识 LE Credit Based 信道的建立状态，不同代码对应不同的结果说明，便于开发者排查连接失败原因：

结果代码	名称	说明
0x0000	Connection Accept	连接接受，参数协商一致，信道可正常建立
0x0001	Connection Refused - SPSM Not Supported	连接拒绝，服务器不支持客户端请求的 SPSM
0x0002	Connection Refused - No Resources Available	连接拒绝，服务器资源不足（如无可用 CID）
0x0003	Connection Refused - Insufficient Authentication	连接拒绝，认证不足（如未完成蓝牙配对）
0x0004	Connection Refused - Insufficient Authorization	连接拒绝，授权不足（如无权限访问该服务）
0x0005	Connection Refused - Encryption Key Size Too Short	连接拒绝，加密密钥长度不足，不满足安全要求
0x0006	Connection Refused - Invalid SPSM	连接拒绝，SPSM 无效（超出规定范围）

七、动态 CID 分配

动态 CID 分配是指除固定信道外，由设备根据实际需求动态分配 CID 用于数据传输，适用于自定义服务、厂商特定功能等场景，分配需遵循规范的规则，确保信道标识的唯一性。

1、分配规则

动态 CID 的分配需遵循以下规则，避免 CID 冲突，确保数据传输正常：

规则	说明
范围	动态 CID 分配范围为 0x0040-0xFFFF，其中 0x0080-0x00FF 保留用于 LE 无连接信道（暂未启用）
本地唯一	每个设备内的动态 CID 必须唯一，不可重复分配，避免同一设备内不同信道冲突
双向唯一	设备 A 分配给设备 B 的 CID，与设备 B 分配给设备 A 的 CID 可不同，无需对称
保留	0x0080-0x00FF 保留用于 LE 无连接信道，不可用于动态分配的面向连接信道

2、动态分配示例

以下为两个设备之间动态 CID 分配的示例，清晰展示本地 CID 与远程 CID 的对应关系，适配实际应用场景：

复制代码

┌─────────────────────────────────────────────────────────────┐
│  动态 CID 分配示例                                           │
│                                                             │
│  设备 A                                    设备 B            │
│  ┌─────────────────────────────────────────────────────┐    │
│  │ Local CID    │  Remote CID      │  用途             │    │
│  ├───────────────┼──────────────────┼──────────────────┤    │
│  │ 0x0040        │ 0x0050           │  GATT 数据通道    │    │
│  │ 0x0041        │ 0x0051           │  固件升级通道     │    │
│  │ 0x0042        │ 0x0052           │  调试通道         │    │
│  └───────────────┴──────────────────┴──────────────────┘    │
└─────────────────────────────────────────────────────────────┘

八、信道优先级

L2CAP 信道优先级用于定义不同信道的数据传输优先级，确保核心协议（如信令、ATT）的数据优先被处理，避免低优先级数据占用链路资源导致核心功能异常。蓝牙5.2规范中，BR/EDR 和 LE 场景的信道优先级划分不同，具体规则如下：

1、BR/EDR 信道优先级

BR/EDR（经典蓝牙）场景下，信道优先级根据 CID 类型划分，优先级从高到低依次为高、中、低三级，具体分配如下表：

优先级	CID/信道类型	说明
高	0x0001 (L2CAP Signaling)	经典蓝牙信令信道，用于信道建立、配置、关闭等核心信令交互，必须优先处理，确保信道管理正常
中	0x0002 (Connectionless)	无连接接收信道，用于 BR/EDR 设备的广播数据传输，优先级低于信令信道，高于常规数据信道
低	动态分配信道（0x0040-0xFFFF）	包括厂商自定义服务、批量数据传输等常规数据信道，优先级最低，不影响核心信令和广播数据传输

2、LE 信道优先级

LE（低功耗蓝牙）场景下，信道优先级以核心协议交互为核心，高优先级信道主要保障 ATT 协议和 LE 信令的正常运行，具体划分如下表：

优先级	CID/信道类型	说明
高	0x0005 (LE Signaling)	信令优先处理
高	0x0004 (ATT)	属性协议
中	0x0040-0x007F	LE Credit Based
低	其他	厂商特定

九、错误处理

L2CAP 信道在传输过程中可能出现多种错误（如无效 CID、参数异常、信令不识别等），规范定义了统一的错误代码和处理流程，用于快速定位错误原因、恢复信道正常运行，保障数据传输的可靠性。

1、信道错误代码

错误代码	名称	说明
0x0001	L2CAP_COMMAND_NOT_UNDERSTOOD	命令无法识别
0x0002	L2CAP_SIGNALING_MTU_EXCEEDED	信令 MTU 超限
0x0003	L2CAP_INVALID_CID	无效 CID

2、错误处理流程

否
是
否
是
收到 L2CAP PDU
CID 有效?
发送 Command Rejected
参数有效?
发送 Error Response
处理 PDU
记录错误日志
更新信道状态