Bluetooth 蓝牙介绍(七)：逻辑链路控制和适配协议规范（L2cap 协议）

蓝牙逻辑链路控制和适配协议 (L2CAP) 支持更高级别的协议复用、数据包分段和重组以及服务质量信息的传送。

规范的本部分描述了协议状态机、数据包格式和组成 。

前言

蓝牙规范的这一部分定义了逻辑链路控制和适配层协议，简称 L2CAP。

• L2CAP 为具有协议复用能力和分段和重组操作的上层协议提供面向连接和无连接的数据服务。

• L2CAP 允许更高级别的协议和应用程序传输和接收长达 64 KB 的上层数据包（L2CAP 服务数据单元，SDU）。L2CAP 还允许每个通道的流量控制和重传。

• L2CAP 层提供逻辑信道，称为 L2CAP 信道，它们在一个或多个逻辑链路上复用。

L2CAP 特性

L2CAP 的功能要求包括协议/通道复用、分段和重组 (SAR)、通道流量控制和错误控制。L2CAP 位于下面的较低层级之上：

1. BR/EDR Controller and zero or more AMP Controllers or
2. BR/EDR/LE Controller (supporting BR/EDR and LE) and zero or more AMP Controllers, or
3. LE Controller (supporting LE only)

图 1.1 将 L2CAP 分解为其架构组件。

通道管理器The Channel Manager 提供the control plane functionality并负责所有内部信令internal signaling、L2CAP 对等信令L2CAP peer-to-peer signaling以及高层和底层信令signaling with higher and lower layers。

它执行第 6 节中描述的状态机功能，并使用第 4 节和第 5 节中描述的消息格式。重传和流量控制块使用数据包重传提供通道流量控制和错误恢复。

Resource Manager 负责为Channel Manager、重传和流控块以及那些不需要重传和流控服务的应用数据流提供帧中继服务。它负责协调与多个 L2CAP 通道相关的数据包在低层接口提供的设施上的传输和接收。

• Protocol/channel multiplexing ：协议/通道复用

L2CAP 支持在单个控制器和多个控制器上进行多路复用。**L2CAP channel一次应在一个controller上运行。**在通道建立期间，协议复用能力用于将路由连接到正确的上层协议。

对于数据传输，需要逻辑信道复用来区分多个上层实体。使用相同协议的上层实体可能不止一个。

• Segmentation and reassembly ：分段和重组

通过资源管理器提供的帧中继服务，传输帧的长度由运行在 L2CAP 上的各个应用程序控制。如果 L2CAP 能够控制 PDU 长度，则可以更好地服务于许多多路复用应用程序。

这提供了以下好处：

1. 分段将允许应用程序数据单元的交织以满足延迟要求。
2. 当 L2CAP 控制数据包大小时，内存和缓冲区管理更容易。
3. 可以更有效地通过重传进行纠错。
4. 当 L2CAP PDU 损坏或丢失时被破坏的数据量可以小于应用程序的数据单元。
5. 应用程序与将应用程序数据包映射到低层数据包所需的分段分离

• Flow control per L2CAP channel：每个 L2CAP 通道的流量控制

控制器为通过空中传输的数据提供错误和流量控制，而对于通过 HCI 传输的数据存在 HCI 流量控制。当多个数据流使用单独的 L2CAP 通道在同一个控制器上运行时，每个通道都需要单独的流量控制。L2Cap提供了一种基于窗口的流量控制方案。

• Error control and retransmissions：错误控制和重传

当 L2CAP 通道从一个控制器移动到另一个控制器时，数据可能会丢失。此外，某些应用程序需要的残余错误率远小于某些控制器所能提供的。L2CAP 提供 L2CAP PDU 的错误检查和重传。L2CAP 中的错误检查可防止由于控制器错误地接受包含错误但通过基于控制器的完整性检查的数据包而导致的错误。

L2CAP 错误检查和重传还可以防止由于控制器刷新导致的数据包丢失。在流控制机制将节流重传以及首次传输的意义上，错误控制与流控制一起工作。

• Support for Streaming：支持流媒体

流媒体应用程序（例如音频）以商定的数据速率设置 L2CAP 通道，并且不希望流控制机制（包括控制器中的流控制机制）改变数据流。刷新超时用于保持数据在传输端流动。流模式用于阻止 HCI 和基于控制器的流量控制应用于接收端。

• Fragmentation and Recombination：分片和重组

一些控制器的传输能力可能有限，并且可能需要与 L2CAP 分段创建的不同的片段大小。因此，L2CAP 之下的层可能会进一步对 L2CAP PDU 进行分段和重组，以创建适合每一层能力的分段。在传输 L2CAP PDU 期间，两个对等设备中可能会发生许多不同级别的分段和重组。

HCI 驱动程序或控制器可以对 L2CAP PDU 进行分段，以遵守主机控制器接口传输方案的数据包大小限制。这导致 HCI 数据包有效载荷携带 L2CAP PDU 的开始和继续片段。类似地，控制器可以将 L2CAP PDU 分段以将它们映射到控制器数据包中。这可能导致控制器数据包负载携带 L2CAP PDU 的开始和继续片段。

协议栈的每一层可能会传递不同大小的L2CAP PDU分片，并且每一层创建的分片大小在每个对等设备中可能不同。然而，PDU 在堆栈内被分段，接收 L2CAP 实体仍然重新组合这些分段以获得原始 L2CAP PDU。

• Quality of Service

L2CAP 连接建立过程允许交换有关两个蓝牙设备之间预期的服务质量 (QoS) 的信息。每个 L2CAP 实现都会监控协议使用的资源并确保遵守 QoS 合同。

对于 BR/EDR 或 BR/EDR/LE 控制器，L2CAP 可以通过设置将数据包标记为自动刷新或非自动刷新来支持同步（保证）和异步（尽力而为）数据流在同一 ACL 逻辑链路上HCI ACL 数据包中 Packet_Boundary_Flag 的适当值（参见 [Vol 4] Part E, Section 5.4.2）。

可自动刷新的 L2CAP 数据包根据为 L2CAP 通道映射到的 ACL 逻辑链路设置的自动刷新超时进行刷新（参见 [Vol 4] E 部分，第 6.19 节）。

Nonautomatically-flushable L2CAP 数据包不受自动刷新超时的影响，不会被刷新。可以使用 HCI_Flush 命令刷新所有 L2CAP 数据包（请参阅 [Vol 4] Part E, Section 7.3.4）。

对于 AMP 控制器，L2CAP 将所有异步数据流通过单个逻辑链路（聚合）发送到同一远程设备。L2CAP 将每个同步数据流放置在其自己的逻辑链路上。

前提

该协议的设计基于以下假设：

1. 控制器提供数据包的有序传递，尽管可能存在个别数据包损坏和重复。
   
   对于带有 BR/EDR 或 BR/EDR/LE 控制器的设备，任意两台设备之间只存在一条 ACL-U 逻辑链路。
   
   对于具有给定 AMP 控制器的设备，任意两个设备之间可能存在多个 AMP-U 逻辑链路。
   
   对于带有 BR/EDR/LE 或 LE 控制器的设备，任何两个设备之间不存在超过一个 LE-U 逻辑链路。

2. 控制器总是给人以全双工通信信道的印象。
   
   这并不意味着所有 L2CAP 通信都是双向的。单向流量不需要双工信道。

3. L2CAP 层基于控制器中可用的机制提供具有一定程度可靠性的信道，并且可以在增强的 L2CAP 层中启用额外的数据包分段、错误检测和重传。
   
   一些控制器执行数据完整性检查并重新发送数据，直到成功确认或发生超时。其他控制器将重新发送数据达到一定次数，然后刷新数据。因为确认可能会丢失，所以即使在成功发送数据之后也可能发生超时。
   
   注意：在 BR/EDR 或 BR/EDR/LE 控制器中使用基带广播数据包是不可靠的，所有广播都以相同的序列位开始 L2CAP 数据包的第一段。

4. 控制器为通过空中传输的数据提供错误和流量控制，而对于通过 HCI 传输的数据存在 HCI 流量控制，但某些应用程序需要比某些控制器提供的更好的错误控制。
   
   此外，在控制器之间移动通道需要 L2CAP 流和错误控制。Flow and Error Control 模块提供四种模式。

   1. 增强重传模式和重传模式提供分段、流量控制
   2. L2CAP PDU 重传
   3. 流控模式只提供分段和流控功能
   4. 流模式提供分段和接收端数据包刷新

以下功能不在 L2CAP 的职责范围内：

• L2CAP 不传输为 SCO 或 eSCO 逻辑传输指定的同步数据。
• L2CAP 不支持可靠的广播信道。参考 《BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part A Section 3.2》

术语

• SDU, or L2CAP SDU：服务数据单元Service Data Unit，L2CAP 与上层交换并使用此处指定的程序通过 L2CAP 通道透明传输的数据包。

• Segment, or SDU segment：SDU 的一部分，由分割过程产生。 一个 SDU 可以分成一个或多个段。

• PDU, or L2CAP PDU：Protocol Data Unit协议数据单元，包含 L2CAP 协议信息字段、控制信息 和/或 上层信息数据的数据包。
  
  PDU 总是由基本 L2CAP 报头开始。PDU 的类型有：B-frames、I-frames、S-frames、C-frames、G-frames 和 LE Frames。

• Fragment：PDU 的一部分，由分片操作产生。Fragment/片段仅用于向和从较低层传送数据。它们不用于点对点传输。片段可以是关于 L2CAP PDU 的开始或继续片段。
  
  一个片段不包含超出 PDU 的任何协议信息； 开始和继续片段的区别由较低层协议规定传输。
  
  注意：起始片段总是以 PDU 的基本 L2CAP 标头的第一个八位字节开始，或者它们的长度为零（参见 [Vol 2] Part B，第 6.6.2 节）。

• Recombination：对应于分片的反向过程，导致从分片重新建立 L2CAP PDU。在接收路径中，Controller 和/或 Host可能发生全部或部分重组操作，重组的位置不一定对应发送端发生分片的位置

• Maximum Transmission Unit (MTU)：上层实体能够接受的有效载荷数据的最大大小，以八位字节为单位，即MTU 对应于最大 SDU 大小。

• MaxTransmit：在增强重传模式和重传模式下，MaxTransmit 控制在假设 PDU（和链路）会丢失之前允许 L2CAP 尝试的 PDU 传输次数。最小值为 1（仅允许 1 次传输），在增强重传模式中，值 0 表示无限传输。

注意：将 MaxTransmit 设置为 1 将禁止 PDU 重传。单个 PDU 的故障将导致链路掉线。相比之下，在流量控制模式下，单个 PDU 的故障不一定会导致链路掉线。

常规操作

L2CAP 基于“通道”的概念。 L2CAP 通道的每个端点都由通道标识符 (CID) 引用。

通道标识符

通道标识符 (CID) 是表示设备上逻辑通道端点的本地名称。CID 的范围与逻辑链路有关，如图 2.1 所示。空标识符 (0x0000) 绝不能用作目标端点。

从 0x0001 到 0x003F 的标识符是为特定的 L2CAP 功能保留的。这些通道称为固定通道。至少应支持 L2CAP 信令信道（固定信道 0x0001）或 L2CAP LE 信令信道（固定信道 0x0005）。

如果支持固定通道 0x0005，则应支持固定通道 0x0004 和 0x0006（见表 2.2）。可以支持其他固定信道。

L2CAP_INFORMATION_REQ / L2CAP_INFORMATION_RSP 机制（在第 4.10 节和第 4.11 节中描述）应用于确定远程设备通过 ACL-U 逻辑链路支持哪些固定信道。每个固定通道的特性是在每个通道的基础上定义的。

固定信道特性包括配置参数（例如，可靠性、MTU 大小、QoS）、安全性以及使用 L2CAP 配置机制更改参数的能力。

表 2.1 列出了定义的固定信道，提供了定义相关信道特性的参考，并指定了信道可以运行的逻辑链路。一旦建立了 ACL-U 或 LE-U 逻辑链路，就可以使用固定通道。当建立 ACL-U 或 LEU 逻辑链路时，应为每个支持的固定信道执行通常在创建信道时执行的所有初始化。

固定信道只能在 ACL-U、ASB-U 或 LE-U 逻辑链路上运行，不得移动。

实现可以以最适合该特定实现的方式自由管理剩余的 CID，前提是两个同时活动的 L2CAP 通道不应共享相同的 CID。

每个 ACL-U、ASB-U 和 LE-U 逻辑链路都存在不同的 CID 名称空间。AMP-U 逻辑链路与其关联的 ACL-U 逻辑链路共享 CID 名称空间。

动态分配的 CID 的分配与特定的逻辑链路有关，设备可以独立于其他设备分配 CID。

因此，即使连接到单个本地设备的多个远程设备已将相同的 CID 值分配给（远程）通道端点，本地设备仍然可以唯一地将每个远程 CID 与不同的设备相关联。

此外，即使相同的 CID 值已由相同的远程设备分配给（远程）通道端点，也可以区分这些端点，因为它们将绑定到不同的逻辑链路。

操作模式

L2CAP 通道可以按为每个 L2CAP 通道选择的几种不同模式之一运行：

• Basic L2CAP Mode
• Flow Control Mode
• Retransmission Mode
• Enhanced Retransmission Mode
• Streaming Mode
• LE Credit Based Flow Control Mode
• Enhanced Credit Based Flow Control Mode

使用第 7.1 节中描述的配置过程启用这些模式。

• 基本 L2CAP 模式应为默认模式，在没有约定其他模式时使用。
• 增强型重传模式应用于在 AMP-U 逻辑链路上创建的所有可靠信道和 ACL-U 逻辑链路，其操作如第 7.10 节所述。
• 对于通过 ACL-U 逻辑链路创建的可靠信道，应启用增强型重传模式，而不是按照第 7.10 节所述进行操作。
• 流模式应用于在 AMP-U 逻辑链路和 ACL-U 逻辑链路上创建的流应用，其操作如第 7.10 节所述。
• 应为通过 ACL-U 逻辑链路创建的流应用程序启用流模式，该应用程序的操作不如第 7.10 节所述。
• 当两个 L2CAP 实体都支持时，应启用增强重传模式、基于增强信用的流控制模式或流模式。
• 仅当与不支持增强重传模式、基于增强信用的流控制模式或流模式的 L2CAP 实体通信时，才应启用流控制模式和重传模式。

数据包格式

L2CAP 是基于数据包 packet-based 的， 但遵循基于通道channels的通信模型*。通道表示远程设备中 L2CAP 实体之间的数据流。通道可以是面向连接的或无连接的。

除了 L2CAP 无连接通道（CID 0x0002）和两个 L2CAP 信令通道（CID 0x0001 和 0x0005）之外的固定通道被认为是面向连接的。具有动态分配的 CID 的所有通道都是面向连接的。

除信息有效载荷字段外，所有 L2CAP 层数据包字段都应使用小端字节序。封装在 L2CAP 信息负载中的高层协议的字节序是特定于协议的。 参考<BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part A>

• Basic information frame (B-frame) ：B 帧是在基本 L2CAP 模式中用于 L2CAP 数据包的 PDU。它包含一个完整的 SDU 作为其有效载荷，由基本 L2CAP 标头封装。
• Information frame (I-frame) ：I 帧是在增强型重传模式、流模式、重传模式和流控制模式中使用的 PDU。它包含一个 SDU 段和附加协议信息，由基本 L2CAP 头封装。
• Supervisory frame (S-frame) ：S帧是增强型重传模式、重传模式和流量控制模式中使用的PDU。它仅包含协议信息，由基本 L2CAP 头封装，不包含 SDU 数据。
• Control frame (C-frame) ：C 帧是包含在对等 L2CAP 实体之间交换的 L2CAP 信令消息的 PDU。C 帧专门用于 L2CAP 信令信道。
• Group frame(G-frame）：G 帧是专用于无连接 L2CAP 通道的 PDU。它由基本 L2CAP 报头封装，包含 PSM，后跟完整的 SDU。G 帧可用于通过 Active Broadcast 向活动从设备广播数据或将单播数据发送到单个远程设备。
• Credit-based frame (K-frame) ：K 帧是在基于 LE Credit 的流量控制模式中使用的 PDU。它包含一个 SDU 段和附加协议信息，由基本 L2CAP 报头封装。

CONNECTION-ORIENTED CHANNELS IN BASIC L2CAP MODE

图 3.1 说明了在面向连接的信道上使用的 L2CAP PDU 的格式。在 Basic L2CAP 模式下，面向连接通道上的 L2CAP PDU 也称为"B-frame"。

Information payload: 0 到 65535 个八位字节

这包含从上层协议接收到的有效载荷（传出数据包），或传递给上层协议（传入数据包）的有效载荷。 具有动态分配的 CID 的通道的 MTU 是在通道配置期间确定的（参见第 5.1 节）。 信令 PDU 支持的最小 MTU 值如表 4.1 所示。

CONNECTIONLESS DATA CHANNEL IN BASIC L2CAP MODE

图 3.2 说明了无连接数据通道中的 L2CAP PDU 格式。 这里，L2CAP PDU也被称为“G-frame”。

Information payload: 0 到 65535 个八位字节

此参数包含要分发给 微微网(piconet ) 中所有slave设备以用于广播无连接流量的有效载荷信息，或用于通过 L2CAP 无连接通道发送数据的特定远程设备。

CONNECTION-ORIENTED CHANNEL IN RETRANSMISSION/FLOW CONTROL/STREAMING MODES

为了支持流控制、重传和流传输，除了基本 L2CAP 报头之外，还定义了具有协议元素的 L2CAP PDU 类型。

The information frames (I-frames)用于 L2CAP 实体之间的信息传输。The supervisory frames (S-frames)用于acknowledge I-frames (确认帧)和 request retransmission of I-frames（请求重传帧）。图 3.3 说明了这些框架。

CONNECTION-ORIENTED CHANNELS IN LE CREDIT BASED FLOW CONTROL MODE AND ENHANCED CREDIT BASED FLOW CONTROL MODE

为了支持基于 LE 信用的流量控制模式和基于增强信用的流量控制模式，除了基本 L2CAP 标头之外，还定义了具有协议元素的 L2CAP PDU 类型。

在LE Credit Based Flow Control Mode和Enhanced Credit Based Flow Control Mode中，面向连接信道上的L2CAP PDU是一个基于Credit的帧（K-frame），如图3.12所示。

SIGNALING PACKET FORMATS

本节介绍在对等设备上的两个 L2CAP 实体之间传递的信令命令。所有信令command都通过信令信道发送。

管理 ACL-U 逻辑链路信道的信令信道应使用 CID 0x0001，管理 LE-U 逻辑链路信道的信令信道应使用CID 0x0005。一旦设置了低层逻辑传输并启用了 L2CAP 流量，信令信道就可用。

图 4.1 说明了包含信令命令（C 帧）的 L2CAP PDU 的一般格式。多个命令可以在单个 C 帧中通过固定信道 CID 0x0001 发送，而每个 C 帧只能通过固定信道 CID 0x0005 发送一个命令。

Commands 采用请求、响应和指示的形式。所有 L2CAP 实现都应支持有效载荷长度不超过信令 MTU 的 C 帧的接收。表 4.1 中定义了 C 帧（MTUsig）支持的最小有效载荷长度。

L2CAP 实现不应使用超过对等设备的 $MT{U}_{sig}$ 的 Cframe。如果设备接收到超过其 MTU sig 的 Cframe，则它应发送包含支持的 $MT{U}_{sig}$ 的 L2CAP_COMMAND_REJECT_RSP。实现应能够处理通过固定信道 CID 0x0001 发送的 L2CAP 数据包中的多个命令的接收。

注意：信令包的名称有一个表示其类型的后缀：_REQ 表示请求，_RSP 表示响应，_IND 表示指示。

其中Length跟CID不需要额外说明，在signaling command的information payload的格式为：

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

channel ID

通道标识符 (CID) 是表示设备上逻辑通道端点的本地名称。CID 的范围与逻辑链路有关，如图 2.1 所示。

空标识符（0x0000）决不能用作目的地端点。从 0x0001 到 0x003F 的标识符是为特定的 L2CAP 功能保留的。这些频道称为固定频道。

至少应支持 L2CAP Signaling 通道（固定通道 0x0001）或 L2CAP LE Signaling通道（固定通道 0x0005）。

• 如果支持固定通道 0x0005，则应支持固定通道 0x0004 和 0x0006（见表 2.2）。
  

L2CAP_INFORMATION_REQ / L2CAP_INFORMATION_RSP 机制（在第 4.10 节和第 4.11 节中描述）应用于确定远程设备在 ACL-U 逻辑链路上支持哪些固定通道。每个固定通道的特性是在每个通道的基础上定义的。固定信道特性包括配置参数（例如，可靠性、MTU 大小、QoS）、安全性以及使用 L2CAP 配置机制更改参数的能力。

表 2.1 列出了定义的固定信道，提供了对相关信道特性定义位置的参考，并指定了信道可以在其上运行的逻辑链路。一旦建立 ACL-U 或 LE-U 逻辑链路，固定信道就可用。

固定信道只能在 ACL-U、ASB-U 或 LE-U 逻辑链路上运行，不得移动。

实现可以自由地以最适合该特定实现的方式管理剩余的 CID，前提是两个同时活动的 L2CAP 通道不应共享相同的 CID。

• 每个 ACL-U、ASB-U 和 LE-U 逻辑链路都存在不同的 CID 名称空间。
• AMP-U 逻辑链路与其关联的 ACL-U 逻辑链路共享 CID 名称空间。
• 动态分配的 CID 的分配与特定的逻辑链路相关，并且设备可以独立于其他设备分配 CID。

因此，即使连接到单个本地设备的多个远程设备已将相同的 CID 值分配给（远程）通道端点，本地设备仍然可以唯一地将每个远程 CID 与不同的设备相关联。

此外，即使同一远程设备已将相同的 CID 值分配给（远程）通道端点，也可以区分它们，因为它们将绑定到不同的逻辑链路。