liwen01 2025.11.08
前言
我们简单分析这样的一个应用场景：一个智能手表和一副蓝牙耳机，它们通过蓝牙都连接到了一个手机上。
智能手表 需要的功能有：
-
实时显示手机来电/消息提醒（低延迟信号传输） -
同步健康数据（如心率、步数、睡眠等） -
播放控制音乐（音频控制命令） -
手表固件升级（OTA 数据传输，数据量较大）
蓝牙耳机 需要的功能有：
-
音乐播放/电话控制（控制命令） -
电话语音通信（语音通话） -
音乐播放（音乐数据流）
在上面场景中，有各种数据：消息提醒、健康数据、音乐控制、固件升级包、语音通话 等等，它们对数据的实时性和可靠性(是否需要重传)要求都不一样。
在手机端，手机蓝牙需要解决的问题有：区分不同的应用、传输大文件、保证数据实时性和可靠性。
为了解决上面的问题，蓝牙就有了 L2CAP（Logical Link Control and Adaptation Protocol）逻辑链路控制适配协议。
L2CAP 主要是为了实现： 多协议共存、大数据流畅、高可靠性传输 三大目标。
在上面场景中，手机端的整体框架如下：
手机（Central）
│
├── ACL Link #1 → 智能手表（Peripheral #1）
│ ├── L2CAP 通道 #1：ANCS（来电/消息提醒）
│ ├── L2CAP 通道 #2：GATT（健康数据同步）
│ ├── L2CAP 通道 #3：AVRCP 控制（音乐控制命令）
│ └── L2CAP 通道 #4：OTA（固件升级）
│
└── 蓝牙耳机（Peripheral #2）
├── ACL Link #2
│ ├── L2CAP 通道 #1：A2DP（音乐数据流）
│ ├── L2CAP 通道 #2：AVRCP（播放/电话控制）
│
└── SCO / eSCO Link #3
└── HFP（实时语音通话）智能手表和蓝牙耳机是手机蓝牙的两个外设，这两外设与手机又建立了几个不同的链接，每个链接下，又有多个L2CAP 通道。
（一）L2CAP的体系架构
L2CAP 的核心任务是：让上层应用的数据能高效、安全、有序地在蓝牙链路上传输。
首先我们要知道蓝牙都有哪些链路，以及 L2CAP 在蓝牙协议栈中的作用和位置。
（1）L2CAP的链路类型
在蓝牙中，主要有三种链路：ACL、SCO、ISO
ACL（Asynchronous Connection-Less Link）：异步、无连接 数据链路，用于在主从设备间传输通用数据信息
SCO（Synchronous Connection-Oriented Link）：同步、有连接 链路，专门为语音传输（音频）设计
ISO（Isochronous Link）：蓝牙低功耗（LE）引入的新型同步链路，支持LE Audio 和多设备广播音频
在 L2CAP 中，它只处理 ACL 链路， 也是数据传输的主力通道。 SOC 和 ISO 实时性要求高的同步数据，并不经过 L2CAP 。
从蓝牙的核心系统架构图中看，L2CAP 位于蓝牙的 Host 中， 除了上面说的处理 ACL 链路的数据，它还要处理与 controller 间通讯的 C/E 数据。
（2）L2CAP 位置与功能
L2CAP 位于上层应用和控制器 HCI 之间的位置
上层（Upper Layer）：如 ATT、SM、SDP、RFCOMM、AVDTP 等；
下层（Lower Layer / HCI）：即控制器（Controller），包括基带（Baseband）与链路管理（Link Manager）。
L2CAP主要功能：
L2CAP 在主机层负责：实现数据的分段与重组、流量控制、重传控制、多通道管理与协议复用 等。
它为上层协议提供逻辑信道服务，并适配底层物理链路。
上图中，有三种数据包：
SDU（Service Data Unit）：上层应用交给 L2CAP 的数据包
PDU（Protocol Data Unit）：L2CAP 封装后的逻辑数据包
Fragments（数据片段）：L2CAP PDU 在传输前进一步分片以适配底层链路
（二）L2CAP 的 Channel 与 CID
L2CAP 通道（Channel）是蓝牙协议栈中的虚拟数据管道。
它在物理 ACL 链路上，为不同的上层协议（如 GATT、RFCOMM、A2DP）提供独立的传输通道，并负责数据分片、重组和流控。
每个通道由一个 Channel Identifier（CID） 唯一标识，通信双方都有各自的 CID（Local CID / Remote CID）
（1）L2CAP Channel 的作用
多路复用（Multiplexing） ：在同一条 ACL 链路上，可以存在多个 L2CAP Channel。每个上层协议（如 SDP、ATT、RFCOMM）都对应一个独立的通道。
分片与重组（Segmentation & Reassembly） ：将大于底层包最大长度（MTU）的数据分割为多个片段发送，并在接收端重组。
流量控制和 QoS：不同通道可以有不同的优先级、延迟要求或传输模式。
协议隔离：不同上层协议的数据不会相互干扰。
（2）L2CAP Channel 的种类
在 L2CAP 中，有三种通道类型：Signaling Channel、Connectionless Channel、Connection-oriented Channels 。
（A）Signaling Channel（信令信道）： 每个设备至少有一个信令信道（CID=0x0001），它用于传输 L2CAP 的控制信息
-
比如：连接请求（ Connection Request）、配置请求（Configuration Request）、断开请求（Disconnection Request）。
（B）Connection-oriented Channel（面向连接的信道）：这是最常用的信道类型，它在两个设备之间建立后，进行单播（unicast）双向通信，每个连接的两端会各自分配一个 CID
-
常用于传输如 ATT（GATT 层）、RFCOMM、SDP 等高层协议的数据。
（C）Connectionless Data Channel（无连接数据信道）：这种信道不需要事先建立连接，适合一对多的广播通信；所有设备共享一个公共的 Connectionless Channel CID（0x0002）；
-
典型应用是：SDP (Service Discovery Protocol) 的广播
（3）L2CAP Channel 的 CID
在L2CAP中，每一条逻辑信道（channel）都有一个唯一的通道标识符 CID。
L2CAP 的 CID 类似于 TCP/IP 中的 端口号（Port Number），用于区分不同的上层协议或应用连接。
（A）CID 的取值范围与分类：
CID 是一个长度为2字节的数值，范围是 0x0001 ~ 0xFFFF。但并不是这2个字节里的所有值都能随便用。
蓝牙规范中，有部分CID值是固定的，剩余的是可以动态分配。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在最开始场景中，手机端的CID分配结构图可能如下：
手机（Central）
│
├── ACL Link #1（到智能手表）
│ ├── CID0x0005 → L2CAP Signaling
│ ├── CID0x0004 → ATT / GATT / ANCS
│ ├── CID0x0043 → AVRCP 控制
│ └── CID0x0045 → OTA 通道（Credit-Based）
│
└── ACL Link #2（到蓝牙耳机）
├── CID0x0001 → L2CAP Signaling
├── CID0x0041 → A2DP 音频分发
├── CID0x0043 → AVRCP 控制
└── SCO Link → HFP 通话（无 L2CAP）在上面示意图中，我们看到连接到蓝牙耳机和智能手表的两条链路，它们都使用了同一个 CID 0x0043 。这是否会相互冲突呢？
这就需要聊到 CID 的作用范围了。
（B）CID 的作用范围：
CID 的唯一性是针对每条物理链路（ACL Link）而言的，而不是整个设备的全局唯一。
上面场景中虽然蓝牙耳机和智能手表两个都用了 CID = 0x0043，但由于它们位于不同的物理链路上（handle 不同），所以他们并不会冲突。
在底层数据包中，每个 ACL 数据帧都会带上对应的 Connection Handle，上层栈据此就能区分属于哪条链路
（4）L2CAP Channel、CID 与 Handle 的关系
对于文章最开始的应用场景，如果再加上物理链路 Handle，手机端的链路结构就变成了下面这样：
手机（Central）
│
├── [ACL Link #1] Handle = 0x0001 → 智能手表（Peripheral #1）
│ ├── L2CAP CID0x0041：ANCS（来电/消息提醒）
│ ├── L2CAP CID0x0042：GATT（健康数据同步）
│ ├── L2CAP CID0x0043：AVRCP 控制（音乐控制命令）
│ └── L2CAP CID0x0044：OTA（固件升级）
│
└── 蓝牙耳机（Peripheral #2）
├── [ACL Link #2] Handle = 0x0002
│ ├── L2CAP CID0x0041：A2DP（音乐数据流）
│ ├── L2CAP CID0x0043：AVRCP（播放/电话控制）
│
└── [SCO / eSCO Link #3] Handle = 0x0003
└── HFP（实时语音通话）手机共维护了 3 条物理链路（Handle=0x0001、0x0002、0x0003）。
每条 ACL 链路可承载多个 L2CAP Channel，而每个 Channel 在本链路内用 CID 唯一标识。
（三） L2CAP 信道工作模式
L2CAP 主要支持的工作模式有：Basic Mode、Enhanced Retransmission Mode、Streaming Mode、LE Credit Based Flow Control Mode、Enhanced Credit Based Flow Control Mode
（1）Basic Mode
Basic Mode 的特点是：无信令交互、无分片确认、一发一收，效率高、延迟低。就像普通公路，无交通管制，车来车往需要各自小心；
所有 ATT、SDP、SM（Security Manager）等协议都基于此模式
（2）Enhanced Retransmission Mode
ERTM 的特点是：顺序传输保证、选择性重传机制（Selective Retransmission、流量控制（Flow Control）、超时与窗口机制（TxWindow）
就像 带红绿灯的城市干道，保证每辆车都安全到达，但速度略慢；
它目前在 BR/EDR 经典蓝牙中仍广泛使用。主要应用于：AVCTP（A/V Remote Control）、OBEX（文件传输）以及需要可靠性的自定义 Profile
（3）Streaming Mode
Streaming Mode 的特点是：不重传丢失数据（适合实时流），但有流控、若包丢失，直接丢弃，不会阻塞后续传输。
就像高速公路，允许几辆车抛锚，但流量顺畅；
它主要应用于：A2DP 音频流、实时视频传输（如 BT 视频扩展）
（4） LE Credit Based Flow Control Mode
LE Credit Mode 的特点是：专为 BLE 使用、不再使用复杂的重传机制、发送端需消耗“信用（Credit）”，接收端通过增加信用控制流量、每个连接有唯一 CID (0x0040 ~ 0x007F)。
他主要应用于：BLE 数据通道（如 GATT 以外的自定义服务）
（5）Enhanced Credit Based Flow Control Mode
Enhanced Credit Mode 是蓝牙5.2引入的模式，是 BR/EDR 与 LE 共用的新一代模式、支持多个 L2CAP 信道并行传输；运行于 ISO 链路 上。
它像多轨高速列车系统，可并行传输多路数据，还能同步。
它的出现，是为了替代传统的 ERTM / Streaming 模式
它支持：流控、分片/重组、可选可靠性、多流同步（用于音频同步等场景）。
（四） L2CAP 状态机
上面介绍的各种模式和各种通道，它们在 L2CAP 中又是如何相互协调工作的呢？
在 L2CAP 中是通过状态机来管理 逻辑信道（L2CAP Channel）的生命周期。 比如控制信道状态从创建、配置、数据传输到释放的转移。
这里需要注意，状态机只应用于双向的CID信道。
（1）状态机三要素
状态机的三要素是：状态、事件、动作
状态（State）：当前信道所处的阶段，如 CLOSED、OPEN 等
事件（Event）：触发状态变化的外部或内部动作，如收到请求、超时等。
动作（Action）：在特定事件发生后执行的操作，如发送响应、设置计时器等
（2）状态机工作原理
L2CAP 状态机的运行是基于事件驱动机制：
状态 + 输入事件 → 动作（Action）+ 下一个状态（Next State）比如典型的工作流程：
CLOSED → WAIT_CONNECT_RSP → WAIT_CONFIG → OPEN → WAIT_DISCONNECT_RSP → CLOSEDCLOSED 状态: 说明信道尚未建立或已释放。
WAIT_CONNECT_RSP 状态: 说明在等待远端回应 Connection Response。
WAIT_CONFIG 状态：说明连接已建立，双方开始进行 配置协商（Configuration）。
OPEN 状态：说明信道已建立并配置完成，可以进行 数据传输
WAIT_DISCONNECT_RSP 状态 ：说明已发出断开请求，等待远端回应。
它整体的流程如下：
（3）状态机种类
L2CAP 协议不是只有一个状态机，而是包含多个功能性的状态机，每个状态机负责不同的部分。
其中，最核心的就是信道状态机，它控制一个逻辑信道（CID）的完整生命周期，从创建 → 配置 → 传输 → 断开。
在这些状态机中，它们又是怎么相互工作的呢？
下面我们举例一个信道状态（Channel State）与信令通道状态机（Signaling Channel State）之间的工作关系。
当一个事件（例如 “Disconnection Request”）到来时：
-
先由 Signaling Channel 状态机 解析； -
找到目标通道（根据 CID）； -
转发到对应的 Channel 状态机； -
状态机执行动作（如释放资源）并切换状态； -
需要回应（Response），则由信令通道状态机发送回应。
也就是：Signaling Channel 管理控制流，Channel State Machine 管理数据流。
（五）L2CAP 数据包格式
从整体看，L2CAP的数据包就是：Header + Payload。但是，在 L2CAP 中的不同连接模式下，它们的报文格式都不相同。
所以L2CAP 存在多种数据包格式。
（1）Basic L2CAP Data Packet
Basic L2CAP Data Packet 是最基础、最常见的 L2CAP 数据格式，应用于 BR/EDR 和 LE-U 的普通数据通道。
它不支持分片、重组、重传和流控，所以它简单高效。
它的数据包格式如下：
| Length (2B) | CID (2B) | Payload (N bytes) |-
Length：表示从 CID开始到数据结束的字节数（不含Length字段自身）。 -
CID：标识此数据属于哪个 L2CAP 信道（例如 0x0040 → ATT，0x0004 → SDP）。 -
Payload：上层协议数据（如 SDP、RFCOMM、ATT、SMP 等）。
（2）L2CAP Signaling Packet（信令包）
它用于 L2CAP 层的控制与管理，不是上层数据的传输。常见命令包括：建立信道、参数配置、断开信道、测试链路。
所有控制流程都通过此信令信道（CID=0x0001）完成。它的数据格式如下：
| Length (2B) | CID (2B) | Code (1B) | Identifier (1B) | Command Length (2B) | Command Data (N bytes) |-
CID：固定为 0x0001（L2CAP Signaling Channel）。 -
Code：表示信令命令类型（如 0x02：Connection Request，0x03：Connection Response）。 -
Identifier：用于匹配请求与响应。 -
Command Length：命令参数长度。 -
Command Data：命令的具体参数内容（如目标 CID、MTU、PSM 等）。
上面Code 表示不同的信令命令类型，在L2CAP中，它们定义如下：
（3）Enhanced Retransmission / Flow Control Mode Packet
它是用于 BR/EDR L2CAP 连接导向信道（Connection-oriented Channel）。
支持：有序传输、分片与重组（SAR）、重传与确认机制、流控管理
它的数据格式如下：
| Length (2B) | CID (2B) | Control (2B) | Payload (N bytes) |Control 字段结构（16位） 包含以下子字段：
-
SAR(2 bits)：分片控制（00: unsegmented, 01: start, 10: continuation, 11: end） -
ReqSeq(7 bits)：期望接收的下一个序号 -
Final(1 bit)：标识是否为最后一帧 -
TxSeq(6 bits)：当前包的序号
Payload：是分片后的 L2CAP SDU 内容。
（4）LE Credit-Based L2CAP Data Packet
它仅用于 Bluetooth Low Energy（LE-U） 物理链路，它控制流量通过 Credit 机制 实现，而不是基于重传。
它无需复杂分片控制字段，效率高，常用于 LE Audio、LE Mesh、GATT over L2CAP 等新型 LE 应用。
数据格式如下：
| Length (2B) | CID (2B) | SDU Data (N bytes) |-
CID：动态分配的 LE 信道（范围：0x0040 ~ 0x007F）。 -
SDU Data：上层协议数据（完整 SDU，不分片）。
（5）LE Credit-Based Control Packet（信贷控制命令包）
它是 LE 信令信道（CID = 0x0005） 的命令格式，只在 LE 信令信道（0x0005） 上传输
用于建立、配置和管理 LE Credit-Based Channel
它的命令格式如下：
| Code (1B) | Identifier (1B) | Length (2B) | Command Parameters (N bytes) |Code：命令类型（如 0x14：LE Credit Based Connection Request）。
Command Parameters：命令参数，例如：
-
LE PSM（LE Protocol/Service Multiplexer） -
Source CID/Destination CID -
MTU,MPS,Initial Credits等。
（6）数据包中的 SDU、PDU、MTU、MPS
-
SDU 是上层传下来的完整消息，
-
PDU 是实际发送出去的数据片段
-
MTU 限制了 SDU 的最大尺寸
-
MPS 限制了单个 PDU 的大小
它们的定义如下：
它们间的结构图如下：
┌────────────────────────────────────────────┐
│ 上层协议数据（如 ATT、RFCOMM、SDP） │
│ ↑ ↓ │
│ L2CAP Service Interface │
│ ↑ ↓ │
│ L2CAP SDU（Service Data Unit） │ ← 最大长度受 MTU 限制
│ │ │
│ [Segmentation 分段处理] │
│ ↓ │
│ ┌──────────────┬──────────────┬──────────┐ │
│ │ L2CAP PDU #1 │ L2CAP PDU #2 │ L2CAP PDU #3 │ ← 每个长度 ≤ MPS
│ └──────────────┴──────────────┴──────────┘ │
│ ↓ │
│ 发送到链路层（HCI ACL / LE Link） │
└────────────────────────────────────────────┘结尾
这里介绍了作为蓝牙协议栈多路复用与数据调度中心的 L2CAP (逻辑链路控制与适配协议)。
下一篇我们将简介蓝牙的应用协议，然后再实例分析蓝牙配网过程工作原理。
