记住一点，软件和硬件分开理解，数据经由物理通道交互，上层通道由各层协议打通。
L2CAP 全称为逻辑链路控制与适配协议(Logical Link Control and Adaptation Protocol)，位于基带层之上，将基带层的数据分组交换为便于高层应用的数据分组格式，并提供协议复用和服务质量交换等功能。
L2CAP 是基于下列假设为依据而设计的：
● 使用链路管理器协议在两单元间建立 ACL 链路。基带提供数据分组的有序传输, 但也可能有个别分组损坏或重复。任两台设备之间只会有一条 ACL 链路。
信道建立在链路的基础上，信道可以有多个，链路只有一条。
● 基带通常提供全双工信道。但这并不是说所有 L2CAP 通信都是双向的。多点传送和单向通信(例如，视频)并不要求双工信道。
● 通过使用基带层提供的机制，L2CAP 提供了一条可靠的信道。当收到请求和重发数据时，基带通常要执行数据完整性校验，直到数据成功确认或发生超时。由于可能会丢失确认报文，所以甚至在数据成功发送后也会发生超时。基带协议使用长度为 1 位的序列号,该序列号用于删除重复发送的分组。由于所有广播的 L2CAP 数据分组的首段都以同一序列位为起始位, 如果需要提供可靠传输,就应禁止使用基带广播分组。
L2CAP 主要对数据进行封装，支持协议复用，统一高层协议数据格式。
L2CAP 特点
● 协议复用：能够区分高层协议，在信道建立时，协议复用功能用来发送请求来连接正确的上层协议;在数据传输时，逻辑信道复用必须能够把用同一个协议的不用几个高层实体的区分出来(一对多情况)。
● 分段与重组：高层协议需传输的数据长度不定，L2CAP 层控制了 PDU 的长度，不仅易于管理而且通过对数据标记分组，允许数据单元的交错，可以满足延时要求，发生错误时的重传也可以更加方便准确。
● 差错控制和重传：
L2CAP 以信道概念为基础，每个信道的端点有信道标识符(channel identifier， CID)来表示。从 0x0001 到 0x003F 的标识符保留用于特定的 L2CAP 功能。空标识符(0x0000)则定义为一个非法标识符， 并且不得用于目标端。可以根据实际应用目的和情况, 以合适方式自由管理其余的 CID。但在本地设备与多个远端设备存在多个并发 L2CAP 信道的情况下,同一 CID 不得重新用作本地 L2CAP 信道端。 下表对 CID 命名空间的定义和划分进行的总结。
| CID | 说明 |
|---|---|
| 0x0000 | 无效标识 |
| 0x0001 | 正在发信号的信道 |
| 0x0002 | 无连接的接受信道 |
| 0x0003-0x003f | 保留(特定功能) |
| 0x0040-0xffff | 动态分配 |
L2CAP 信道有三种类型：面向连接(Connection-Oriented,CO)信道，用于两个连接设备之间的双方通信；无连接(Connection-Less,CL)信道，用来向一组设备进行广播式的数据传输，为单项信道；信令(Signaling)信道，用于创建CO 信道，并可以通过协商过程改变 CO 信道的特性.
BT/BLE 在 L2CAP 层的区别？？ Note
下图说明了 CID 在 L2CAP 实体间通信的使用方式，以及 L2CAP 信道的三种类型工作方式。信令信道是一个保留信道的实例，该信道用于创建和建立面向连接的数据信道，并可对这些信道的特性变化进行协商。
L2CAP 操作模式
根据每个 L2CAP 信道的上层协议，L2CAP 有三种不同的操作模式
(1)基本 L2CAP 模式（这点和版本 1.1 的蓝牙协议里是一样的）
(2)流控制模式
(3)重传模式
在流控制模式和重传模式中，双方传输的数据分组都是被编了号的。数据分组中的序列号码是用来控制缓冲， TxWindow 大小是用来限制需要的缓冲区空间和/或提供一种流控制的方法。另外对于窗口大小（window size）来说，流控制规范的 Token Bucket size 参数可以用来描述缓冲区的大小； 一些特殊的信道不使用流量和差错控制。
在流控制模式下，丢失的数据分组可以被检测出来，并能通知对方丢失，但不进行重传。
在重传模式下，使用一个定时器，把需要重新传输的数据分组传送，来确保所有的数据分组都传输给对方。
数据分组格式
1、面向连接信道
各字段描述如下：
长度： 2个字节，主要指基本 L2CAP 报文头除长度以外的信息净荷的大小，即图中空白部分，其长度可达65535字节。
净荷信息： 静荷信息包含来自上层协议(发出的分组)的净荷或者发送到上层协议（接收的分组）的净荷。 MTU 的值在信道配置时确定。所支持的用于信令分组的 MTU 的最小值为 48 字节。
信道ID： 2个字节，用于标识分组的目标信道终端。
2、无连接数据信道
各字段描述如下：
长度： 2个字节，是信息净荷/有效载荷与 PSM 字段长度的和。
净荷信息/有效载荷： 静荷信息包含来自上层协议(发出的分组)的净荷或者发送到上层协议（接收的分组）的净荷。 MTU 的值在信道配置时确定。所支持的用于信令分组的 MTU 的最小值为 48 字节。
信道ID： 2个字节，CL 信道 ID 固定为0x0002
协议/服务复用(PSM): 一般为 SDP、RFCOMM、TCS 等中介协议复用。小
于 0x1000 的值，0x0001 对应 SDP，0x0003 对应 RFCOMM、0x0005 对应 TCS。主要用于标识何种上层协议。
3、信令信道
上图所示为信令信道的分组格式，其一般用在连接、断开、请求、拒绝等命令,所有信令通道 CID 均为 0x0001。
信令指令分组长度： 2个字节，除L2CAP分组头部分之外的数据长度，即各指令长度之和 (note：各指令长度不定，具体使用，具体分析)
信令指令格式长度： 2个字节，为数据长度(大小不定，最大为65535字节)
标识符： 1个字节，用于请求与应答间的匹配。
信令命令代码： 如下图所示为各代码代表含义
举例说明： 下面是一个 L2CAP 包
Role:Master
Address:11
PDULength: 6 //指令的长度，值为 06 00
ChannelID: 0x0001 (Signaling)//L2CAP 的信令通道，值为 01 00
Code:Information request//信息请求，值为 0a
Identifier:1//标识符，值为 01
CommandLength: 2//命令长度，值为 02 00
InfoType:Extended features supported//02 00 (实际传送数据)
这条指令完整的为：06 00 01 00 0a 01 02 00 02 00
注： 蓝牙分组编码为小端模式。
L2CAP 层接收到数据后的处理流程：
具体分析需要结合源码一起。
详细见蓝牙核心技术概述.pdf 第42页 以及 蓝牙协议及其源码分析 第274页