嘉义市网站建设_网站建设公司_改版升级_seo优化

一、介绍

This section of the Bluetooth Specification defines the Logical Link Control and Adaptation Layer Protocol, referred to as L2CAP. L2CAP provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability and segmentation and reassembly operation. L2CAP permits higher level protocols and applications to transmit and receive upper layer data packets (L2CAP Service Data Units, SDU) up to 64 kilobytes in length. L2CAP also permits per-channel flow control and retransmission.

Logical Link Control and Adaptation Protocol(L2CAP)协议对上层协议提供面向连接和无连接的数据服务，支持协议多路复用、数据包的分段重组以及服务质量管理，通俗的话来说就是:L2CAP是蓝牙协议栈中的"超级快递枢纽"。

1. 协议多路复用- 一个超级物流中心，把不同快递公司的包裹（RFCOMM、SDP等上层协议）都集中处理，然后通过同一条高速公路（ACL链路）运送给不同收件人。
2. 数据包的分段重组- 你要给朋友寄一个超大快递（64kg），但快递公司的小盒子容量有限（8kg）。L2CAP会把这个大快递拆成小盒子寄出，到达指定地点后再把小盒子重新拼成完整的大快递。
3. 服务质量管理- 快递公司会根据包裹重要性安排不同运输方式：普通包裹走普通快递，重要快递走加急通道，特殊文件走专车专线。

接下来这张图出自Corespec，用于展示L2CAP层的架构组件及其与其他层级、内部模块的交互逻辑:

图中包含三层，对应着在L2CAP层的不同抽象层级：

• Upper layer（上层）：指L2CAP层之上的应用层或相关协议层，像 RFCOMM、OBEX 都属于这一层级，它的主要作用是传递上层的业务数据到L2CAP层，这类数据也被称为Service Data Units（SDUs）。
• L2CAP layer（L2CAP 层）：本文主要介绍的层级，它负责数据的分段重组、封装转发、传输控制等，是“上层需求”与“底层传输”之间的适配层。
• Lower layer（下层）：代表 L2CAP 之下的底层接口（如HCI层），负责处理物理链路的帧传输（如分片、重组），这类数据被称为Protocol Data Units(PDUs)，最终将数据传递给Controller。

L2CAP协议关键特性

协议/通道多路复用

• Protocol/channel multiplexing

L2CAP supports multiplexing over individual Controllers. An L2CAP channel shall operate over one Controller. An L2CAP channel cannot move between Controllers.

During channel setup, protocol multiplexing capability is used to route the connection to the correct upper layer protocol.

For data transfer, logical channel multiplexing is needed to distinguish between multiple upper layer entities. There may be more than one upper layer entity using the same protocol.

L2CAP允许多个上层协议或多个连接实例在同一条物理链路（ACL 链路）上并发通信，通过 Channel ID（CID） 构造的逻辑链路实现逻辑隔离与数据路由。

1. CID

如何理解CID这个场景?

简单来说，这个CID就像生活中常见的外卖柜：

逻辑链路 = 外卖柜的某一排格子

CID = 某排格子里的单个柜子编号，而且有些编号还绑定了固定用途：

比如0x0001、0x0002、0x0007这三个编号的外卖柜，他是被设计者特地预留出来作为管理员专用的柜子，普通的外卖不允许放在这些柜子中；0x0040~0xFFFF才允许被私人使用，只有每次"寄存"/"拿取"外卖时这个柜子才属于你，一旦你将外卖"拿走"，你对这个柜子的使用权就结束了，下一次使用需要重新与协商这次服务使用的是哪个柜子。而且外卖柜里面是什么外卖不由柜子的编号决定，而是由你下的外卖单决定。

我们来看一下corespec中是如何定义这个CID的
BR/EDR经典蓝牙(ACL-U logical links)：

BLE低功耗蓝牙(LE-U)：

了解了L2CAP的CID的基础概念，我们趁热打铁来看一下L2CAP的协议/通道多路复用的机制：

L2CAP多路复用通过唯一的固定信令通道（CID=0x0001）协商创建多个动态数据通道（CID ≥ 0x0040），每个通道绑定一个上层协议实例；数据传输时，L2CAP 依据动态 CID(柜子编号) 将 PDU(外卖) 路由到正确的上层实体——协议类型由协商时的 PSM (外卖单)决定，而非 CID（柜子编号）本身。

2. PSM

这里又引入了一个新名词 -PSM，它的全称是Protocol/Service Multiplexer，它的作用就只有一个：因为蓝牙设备的L2CAP层会同时承载多个上层协议，PSM就相当于给每个上层服务分配唯一的"服务编号"。

这里我给出常见的几个PSM号：

想要知道更多的PSM定义可以去官网查找:https://www.bluetooth.com/specifications/assigned-numbers/

可以发现这里的PSM取值都为奇数，不仅如此，实际上corespec对此还有更严格的规定，PSM至少由2字节组成，其中的最高字节必须是偶数，而其余字节必须是奇数！这其实也是SIG的设计，可以用于简单的区分该PSM是否合法。

纸上谈兵这么多，我们可以打开实际抓到的数据包来相验证一下：我习惯用Ellisys Bluetooth Analyzer来看抓到的btsnoop数据包，这里打开我们抓到的log，我们随便选择一组L2CAP Connection的交互来看：

可以看到这次交互由一组Request&&Response组成，先看到这里的L2CAP Connection Request：

我们可以看到，在这个Request数据包里的PSM是SDP，Source CID是0x0040，也就是Central端(主机)告诉对端：“我想跟你进行SDP通信，请开一个通道，这是我为此次SDP通信分配的通道号0x0040！”

再看看对端是怎么回应的，对端回应的数据包就是这里的L2CAP Connection Response：

在Response数据包中，这里出现了两种CID，一个是Destination CID，一个是Source CID。

Source CID我们在前面的Request数据包就提过了，这是主机为此次通信分配的通道号；这里的Destination CID其实是从机端的回复：“好的(Connection successful)，已收到你的通道号0x0040(Source CID)，我分配的对应通道号是0x006D(Destination CID)，你发数据时目标CID使用0x006D。”

我们也可以在后续L2CAP的SDP交互中印证我们的说法:

上述这个过程其实就是完美符合了经典蓝牙(BR/EDR)建立L2CAP实体并通过CID进行交互的过程，几乎所有的上层协议都是以这种形式进行的交互，在Corespec中，这部分内容被叫做L2CAP传输模型:

3. 操作模式

L2CAP 信道可按照为每个 L2CAP 信道所选定的方式，工作在多种不同模式中的一种。我们用一句话来介绍这些操作模式：

• Basic L2CAP mode (BR/EDR and some LE fixed channels only)

最简单模式，无重传、无流控，数据"尽力而为"传输，常用于经典蓝牙(BR/EDR)和一些LE的混合通道

• Flow Control mode (BR/EDR only)

提供单项流控，但不重传丢包，仅用于经典蓝牙，现已基本启用

• Retransmission mode (BR/EDR only)

支持自动重传(ARQ)和顺序交付，用于保证可靠性，仅用于经典蓝牙，效率较低，已被ERTM取代

• Enhanced Retransmission mode (BR/EDR only)

改进版重传模式，支持选择性重传和更大窗口，其机制类似于TCP，适用于经典蓝牙

• Streaming mode (BR/EDR only)

无重传、无确认，保留序列号以检测乱序，适用于经典蓝牙，常用于实时音频/视频流

• LE Credit Based Flow Control mode (LE only)

基于Credit机制进行流控：发一包扣 1 分，收方可补充信用，仅适用于BLE

• Enhanced Credit Based Flow Control mode (BR/EDR and LE)

支持多通道共享信用池，更灵活的流控和优先级管理，同时支持经典蓝牙和BLE

数据包的分段重组

• Segmentation and reassembly

With the frame relay service offered by the Resource Manager, the length of

transport frames is controlled by the individual applications running over L2CAP.

Many multiplexed applications are better served if L2CAP has control over the PDU

length. This provides the following benefits:

a. Segmentation will allow the interleaving of application data units in order to

satisfy latency requirements.

b. Memory and buffer management is easier when L2CAP controls the packet size.

c. Error correction by retransmission can be made more efficient.

d. The amount of data that is destroyed when an L2CAP PDU is corrupted or lost

can be made smaller than the application's data unit.

e. The application is decoupled from the segmentation

根据我收集到的资料来看，在早期的蓝牙架构中，在L2CAP之下、HCI之上还有一个模块叫作Resource Manager，他负责管理ACL链路带宽、控制数据帧长度并提供帧中继服务。在这种模型下，由上层应用直接控制帧长度，L2CAP只是作为透传，这种方式虽然灵活但是混乱；而在现代蓝牙模型下，由L2CAP统一管理PDU长度，这样做的好处有下面几点：

1. 公平调度：L2CAP 可以对多个通道进行轮询或优先级调度
2. 适配底层能力：根据 HCI ACL MTU、Controller 缓冲区等动态调整
3. 避免链路拥塞：防止某个应用独占带宽
4. 支持分段重组：L2CAP 可以把大 SDU 拆成合适大小的 PDU

那L2CAP具体是如何实现L2CAP控制PDU长度的呢？

我们来看一下corespec中L2CAP Protocol Specification的第三部分Data packet format

1. 概述

L2CAP is packet-based but follows a communication model based on channels. A channel represents a data flow between L2CAP entities in remote devices. Channels may be connection-oriented or connectionless. All channels other than the L2CAP connectionless channel (CID 0x0002) and the two L2CAP signaling channels (CIDs 0x0001 and 0x0005) are connection-oriented. All L2CAP layer packet fields shall use little-endian byte order with the exception of the information payload field. The endianness of higher layer protocols encapsulated within L2CAP information payload is protocol-specific.

L2CAP协议基于数据包(PDU)传输，但其采用信道的通信模型。信道代表着L2CAP实体间的数据流，大部分L2CAP通道都是面向连接类型，只有以下三个通道是无连接类型：

所有的L2CAP层的包字段都使用小端字节序(little-endian)，但其信息载荷字段(payload field)的字节序由其上层协议规定。

If a PDU is received on a CID that is not assigned or is reserved for future use on the logical link type, the recipient shall ignore that PDU.

In all L2CAP PDUs, the PDU Length field indicates the size of the entire L2CAP PDU in octets, excluding the 4 octets of the Basic L2CAP header. Therefore a PDU cannot be more than 65539 octets long.

In PDUs that contain an Information Payload field, the number of octets in that field (the payload size) shall not be greater than the peer device's MPS for the channel.

这里对L2CAP数据包做出了一些声明:

1. 如果接收到一个数据包(PDU)且其CID未被分配，或在此逻辑链路类型中，该CID被预留为未来使用，则接收方应忽略此 PDU。
2. 在所有 L2CAP 协议数据单元中，PDU 长度字段标识的是整个L2CAP PDU的字节的大小（单位为octet，即一个八位），且该长度不包含基础 L2CAP 协议头的 4 个字节(2字节长度字和2字节的CID字段)。因此，一个PDU的总长度不能超过 65539 (2¹⁶-1 + 4)个字节。
3. 对于包含信息载荷字段的 PDU，该字段的字节数（即载荷字段大小）不得超过对端设备针对此信道设定的最大分段大小（MPS）。

2. 数据格式

a. 基础模式 面向连接信道(Connection-oriented channels in Basic L2CAP mode)

在corespec中该数据帧也被叫做B-frame，该数据帧由三部分组成:

• 第一部分是PDU Length(2个字节)

对于B-frame来说，该字段值与载荷大小相等，其值最大可达65535。该字段既可用于数据包的重组，同时也可在接收端作为重组后L2CAP数据包的简易完整性校验依据。

• 第二部分是Channel ID（2个字节）

也就是前面提到的CID，用于标识数据包的端点。

• 第三部分是Information payload

该字段的内容为从上层协议接收的数据包（outgoing packet），或待交付给上层协议的数据包（incoming packet）。载荷大小不得超过对端设备为此信道设定的最大传输单元（MTU）。对于采用动态分配信道标识（CID）的信道，其 MTU 会在信道配置阶段确定。

老规矩 我们随便找一个B-frame来看看

首先需要再次明确的是，L2CAP数据包的结构性字段(比如这里的Length和CID)均采用小端模式，而payload的大小端则由所L2CAP包所承载的协议来决定。

这个B-frame中前两个字节代表着Length，且其采用小端字节序，还原结果为 0x0014 = 20 bytes，这与Ellisys右边给我们解析出来的一致；同理接下来这两个字节代表着CID，还原后的结果为0x006D，这就是我们在前面的config阶段为SDP协议申请的CID；后面的20bytes都是payload，也就是SDP包所携带的有效数据。

b. 基础模式 无连接信道(Connectionless data channel in Basic L2CAP mode)

在corespec中该数据帧也被叫做G-frame，该数据帧由四部分组成:

• 第一部分是PDU Length（2个字节）

对于G-frame来说，该字段值等于Information payload的大小加上PSM字段的大小。

• 第二部分是Channel ID（固定为0x0002）

这里的CID是固定的0x0002，这是所有无连接传输专用的CID。

• 第三部分是PSM（最少2个字节）

该字段是Protocol/Service Multiplexer的取值，除了部分SIG已经分配的标准PSM(已知协议)，厂商也可自定义PSM用于动态分配(厂商可在SDP协议中注册)，但也需要满足“高位非零、符合奇偶规则”

虽然这里说的是“至少2字节”，但实际所有的标准和常见用法几乎都是2字节的，理论上支持4字节，但笔者目前也没见过4字节的PSM。

• 第四部分是Information payload（0-65533字节）

该参数包含需分发的载荷信息，其传输场景分为两类：

一是通过广播无连接业务，向微微网内所有从设备进行分发；

二是通过 L2CAP 无连接信道，向特定远端设备发送数据。

如果使用的PSM超过了最小长度(2字节)，那么该字段的最大长度也应该做响应的缩减。

c. 重传/流控/流传输模式 面向连接信道(Connection-oriented channel in Retransmission/Flow Control/Streaming modes)

可以看到这里有两种数据包:

The information frames (I-frames) are used for information transfer between L2CAP entities.

I-frame（information frame，信息帧）

The supervisory frames (S-frames) are used to acknowledge I-frames and request retransmission of I-frames.

S-frame（supervisory frame，监控帧）

为了支持流控、重传和流传输，L2CAP定义了比基础L2CAP头部更复杂的PDU类型，这些PDU包含额外的协议字段，如上图3.3所示。接下来我们详细讲讲这个数据格式。

相较于基础模式只发数据，若想要实现可靠传输或流控，就必须采用"带控制信息的高级帧"。

• 第一部分是 PDU Length（2个字节）

对于I-frame和S-frame来说，这个字段的值等于Control、L2CAP SDU长度(若存在)、Payload和帧校验序列(若存在)所占字节数之和。

其中S-frame的PDU Length取值只能是2、4或6字节(S-frame 没有 information Payload字段)。

• 第二部分是 Channel ID（2个字节）

就是CID，前面说过很多了。

• 第三部分是 Control（标准\增强：2个字节 拓展：4个字节）

The Control Field identifies whether the frame is an S-frame or I-frame and contains various information about the frame. There are three different Control Field formats: the Standard Control Field, the Enhanced Control Field, and the Extended Control Field. Which format is used is determined by the mode and is not indicated within the frame.

该字段可用于区分该数据帧是S-frame还是I-frame（Control字段的最后一个bit位），并包含了与该帧相关的各类控制信息。Control字段共有三种不同格式：

1. 标准控制字段(the Standard Control Field)：适用于重传模式与流量控制模式

I-frame：

S-frame：

1. 增强控制字段(the Enhanced Control Field)：适用于增强重传模式与流传输模式

I-frame：

S-frame：

1. 拓展控制字段(the Extended Control Field)：适用于拓展窗口协商成功

I-frame：

S-frame：

• Type

该位用于区分当前帧是I-frame还是S-frame，0 → I-frame 1 → S-frame

• Send Sequence Number -TxSeq

可靠模式下为了支持排序和重传，此字段的值用于给每个 I-frame 进行编号。

• Receive Sequence Number -ReqSeq

接收方通过该字段来对发送方所发送的包进行确认，同时该字段的值总是指向"下一个期望接收的帧"的序列号(Txseq)。

• Retransmission Disable Bit - R

R 位用于实现流控，它是一个标志位，用于防止发送方在接收方忙时仍不断重传，避免浪费带宽或加剧拥塞。当接收方在内部接受缓冲区满时将 R 位置1，发送方收到 R=1 后，必须停止重传，但是不对新数据发送做额外限制。

需要注意的是:ReqSeq 和 R 位的功能是相互独立的，前者表示重传什么，后者影响是否重传。

• Segmentation and Reassembly - SAR

SAR位用于指示当前 I-frame 是否属于一个被分段的 SDU。它由2个比特位组成，对于分段的 SDU, SAR 位还指明当前I-frame 携带的 SDU的哪部分(开头、中间、结尾)，这使得接收方能正常的将多个 I-frame 重新组装成新的 SDU，当 SAR = Start 时，该 I-frame 必须包含一个额外字段: L2CAP SDU Length。

下面是SAR的编码表：

• Supervisory function - S

S位标记了 S-frame 的类型，它由两个bit位组成，所以也可以指代四种类型: RR (Receiver

Ready), REJ (Reject), RNR (Receiver Not Ready) and SREJ (Selective Reject)。

下面是 S 的编码表：

• Poll - P && Final - F

这两位放一起聊吧，因为他们是合作关系，P 位和 F 位作用于链路状态探测、同步和活性检测，该机制是发送方主动获取接收方最新状态的可靠手段。

P 位：

F 位：

• 第四部分是 L2CAP SDU Length（0个字节 or 2字节）

仅用于当一个L2CAP SDU被拆分成多个 I-frame 时，第一个片段必须用 SAR = 01 标记为 SDU 起始帧，其他任何帧中不允许包含它，其值应等于整个 SDU 的字节总数，且不能超过对端设备在通道上声明的MTU。

• 第五部分是 Information Payload

该帧携带的有效数据载荷，该 Payload 的最大长度等于通道协商的 MPS 值，通常来说 MPS 会远小于 MTU (因为 MTU 是 SDU 级，MPS 是 PDU 级)。

• 第六部分是 Frame Check Sequence（2字节）

FCS 是一个 16 位（2 字节） 的校验码，用于检测 L2CAP PDU 在传输过程中是否出错，经典蓝牙通常默认启用 FCS ，以增强可靠性，FCS的生成算法采用 CRC-16，生成多项式为 g(D) = D16 + D15 + D2 + 1，需要注意的是 FCS 校验并不针对自身。

总结如下:

d.基于信用流控模式与增强型基于信用流控模式面向连接信道(Connection-oriented channel in Retransmission/Flow Control/Streaming modes)

To support LE Credit Based Flow Control mode and Enhanced Credit Based Flow

Control mode, an L2CAP PDU type with protocol elements in addition to the Basic

L2CAP header is defined. In LE Credit Based Flow Control mode and Enhanced Credit

Based Flow Control mode, the L2CAP PDU on a connection-oriented channel is a

Credit-based frame (K-frame) as illustrated in Figure 3.12.

为了支持这两种新的流控模式，corespec定义了一种扩展的L2CAP PDU类型，它在基础的L2CAP头之上增加了新的协议字段，以实现基于信用模式的帧，它也被称作 K-frame。

• 第一部分是PDU Length(2个字节)

对于K-frame来说，该字段值与载荷大小相等，其值最大可达65535。该字段既可用于数据包的重组，同时也可在接收端作为重组后L2CAP数据包的简易完整性校验依据。

• 第二部分是Channel ID（2个字节）

也就是前面提到的CID，用于标识数据包的端点。

• 第三部分是L2CAP SDU Length（2个字节）

每个SDU的第一个K-frame必须包含一个2字节的 L2CAP SDU Length字段，该字段表示整个 SDU 的总字节数，且此值不能超过对端设备在该信道上协商的MTU。后续的K-frame不得包含此字段。

• 第四部分是Information Payload

就是该K-frame所携带的有效数据载荷。