BLE L2CAP 层 - 分段与碎片
BLE L2CAP layer - segmentation vs fragmentation
伙计们，我有两个问题要问你们：
- BLE L2CAP中segmentation + reasembly和fragmentation + recombination有什么区别？经过一番研究，我无法理解。
- 除了硬写的 BL 核心规范，我在哪里可以找到关于 BLE 中 L2CAP 的一些理论？
首先，请注意 L2CAP 最初是经典蓝牙的重要组成部分。 L2CAP for Bluetooth Classic 支持广泛的功能，例如连接请求、可靠的数据包传输、不可靠的数据包传输、重传、流量控制、通道多路复用、数据包分段、各种信令等
创建 BLE 时，需要通道多路复用（用于 SMP 和 GATT），以及在通过 HCI 和 Link 层传输时对数据包进行分段的方法。最简单的决定似乎是将 BLE“鞋拔”到 L2CAP 规范中。
这意味着 95% 的 L2CAP 与 BLE 无关且无效。仅考虑 BLE 时，阅读 L2CAP 规范也可能非常困难，因为并不总是清楚特定部分是仅指经典蓝牙、BLE 还是两者。
也就是说，分段和重组用于经典蓝牙和 BLE，指的是 L2CAP 帧必须如何拆分成更小的片段以适应较低层的数据包长度限制。 BLE 的较低层是 HCI 和 Link 层。
一个 L2CAP 帧总是包含一个 4 字节的 header，其中包含一个 2 字节的长度和一个 2 字节的通道 ID。将帧拆分为多个片段时，下层数据包中的附加位 header 指示数据包是新帧的开始还是前一帧的延续。对于每个连接，属于特定帧的所有片段都必须在较低层上按顺序发送，即不允许将帧的 GATT 片段与帧的 SMP 片段交错。这是因为在后续数据包中没有额外指示此片段属于哪个帧，因此必须始终假定为前一个。对于 Link 层，此信息保存在 Link 层数据包 header 的 LLID 字段中。共有三种可能的设置：
- LL 数据 PDU：L2CAP 消息的延续片段，或空 PDU。
- LL 数据 PDU：L2CAP 消息的开始或没有分段的完整 L2CAP 消息。
- LL 控制 PDU。
LL 控制 PDU 实现 Link 层控制协议，与 L2CAP 无关。这些数据包不直接通过 HCI 发送。
HCI 层类似地使用了一种称为数据包边界标志的东西。数据包的HCI包header包括连接句柄和包边界标志。
控制器或主机都可以重组 L2CAP 片段。虽然对于主机来说当然是强制性的，但它对于控制器来说是可选的。重组只是通过累积片段直到总长度等于根据 header 的长度来完成。这意味着 start/continuation header 在 BLE 中实际上是多余的，因为 BLE 仅使用可靠传输，但仍可用作检测边界错误的方法。
支持 LE 数据长度扩展的控制器，例如可以通过 HCI 从主机接收多个小片段，并将它们重新组合成一个大的 Link 层数据包。如果远程设备不支持 LE 数据长度扩展，控制器也可能从主机接收到一个大的 L2CAP 数据包，然后将其分成多个片段以通过 Link 层发送。
现在开始分段和重组。这是蓝牙经典中使用的一个术语，能够支持大数据包，并将它们与其他数据包复用。
分段和重组的一个问题是，一个大数据包将以一个块的形式发送，在传输该数据包时保留整个 link，因为一个帧中的所有片段都必须按顺序发送。因此，L2CAP 使用术语 SDU“服务数据单元”来描述更高层（大）数据包。这个数据包可以被“分割”成几个更小的 L2CAP I-Frames，然后照常发送，如果需要，可能使用分段和重组。之前的问题现在已经解决，因为来自一个 SDU 的 I-Frames 可以与来自另一个 SDU 的 I-Frames 交错。 L2CAP 接收主机然后将“重组”I-Frames 到原始的 SDU 中。因此可能存在多个未完成的传入不完整 SDU。
在蓝牙 4.2 中，创建了面向蓝牙 L2CAP 连接的通道作为除 GATT 之外的另一种发送数据的方式。这是 L2CAP 中的全新部分，但借鉴了经典蓝牙的思想。这个想法也是为了能够交错来自不同通道的大数据包 (SDU)。还实现了流量控制机制。就像在经典蓝牙中一样，每个 SDU 被分成多个帧，这次称为 K-frames。每个 K-frame 包含信道标识符，因此接收方知道该帧属于哪个未决 SDU。但请注意，如果您仔细阅读规范，您会发现这次该机制不称为 Segmentation & Reassembl.事实上，它根本不叫任何东西。分段和重组术语仅针对各种蓝牙经典模式明确定义，即使 BLE L2CAP CoC 的原理相同。
我希望我上面写的内容足以满足 BLE 的 L2CAP 理论。否则我能推荐的最好的是蓝牙核心规范。但是，如果您阅读了 L2CAP 章节，请首先尝试确定您正在阅读的部分中是否包含“LE”一词，否则它可能不相关。如果它包含“BR/EDR”，它可能不相关。
蓝牙规范版本 4.2 [第 3 卷，A 部分] 第 140 页
...
分段和重组操作仅在增强版中使用
Retransmission mode、Streaming mode、Retransmission mode、Flow
控制模式.
因此 BLE l2cap 中不使用分段和重组。
蓝牙核心规范 5.2 版 |第 3 卷 A 部分第 1031 页
2.4 操作模式
L2CAP 通道可以在为选择的几种不同模式之一中运行
每个 L2CAP 通道。
这些模式是：
• 基本 L2CAP 模式
• 流量控制模式
• 重传模式
• 增强重传模式
• 流媒体模式
• 基于 LE 信用的流量控制模式
• 增强的基于信用的流量控制模式
蓝牙核心规范 5.2 版 |第 3 卷 A 部分第 1032 页
LE Credit Based Flow Control Mode 用于 LE L2CAP connection-oriented
使用基于信用的 L2CAP 数据方案进行流量控制的通道（即不
信令数据包）。
蓝牙核心规范 5.2 版 |第 3 卷 A 部分第 1131 页
分段和重组操作仅在增强版中使用
Retransmission mode、Streaming mode、Retransmission mode、Flow
控制模式.
我不太看新报纸))
我觉得 5.2 够新了吧？
此外，我必须指出，实际实现，例如TI、英飞凌（赛普拉斯），完全证实了这一点，即符合规范。
不谢。))
伙计们，我有两个问题要问你们：
- BLE L2CAP中segmentation + reasembly和fragmentation + recombination有什么区别？经过一番研究，我无法理解。
- 除了硬写的 BL 核心规范，我在哪里可以找到关于 BLE 中 L2CAP 的一些理论？
首先，请注意 L2CAP 最初是经典蓝牙的重要组成部分。 L2CAP for Bluetooth Classic 支持广泛的功能，例如连接请求、可靠的数据包传输、不可靠的数据包传输、重传、流量控制、通道多路复用、数据包分段、各种信令等
创建 BLE 时，需要通道多路复用（用于 SMP 和 GATT），以及在通过 HCI 和 Link 层传输时对数据包进行分段的方法。最简单的决定似乎是将 BLE“鞋拔”到 L2CAP 规范中。
这意味着 95% 的 L2CAP 与 BLE 无关且无效。仅考虑 BLE 时，阅读 L2CAP 规范也可能非常困难，因为并不总是清楚特定部分是仅指经典蓝牙、BLE 还是两者。
也就是说，分段和重组用于经典蓝牙和 BLE，指的是 L2CAP 帧必须如何拆分成更小的片段以适应较低层的数据包长度限制。 BLE 的较低层是 HCI 和 Link 层。
一个 L2CAP 帧总是包含一个 4 字节的 header，其中包含一个 2 字节的长度和一个 2 字节的通道 ID。将帧拆分为多个片段时，下层数据包中的附加位 header 指示数据包是新帧的开始还是前一帧的延续。对于每个连接，属于特定帧的所有片段都必须在较低层上按顺序发送，即不允许将帧的 GATT 片段与帧的 SMP 片段交错。这是因为在后续数据包中没有额外指示此片段属于哪个帧，因此必须始终假定为前一个。对于 Link 层，此信息保存在 Link 层数据包 header 的 LLID 字段中。共有三种可能的设置：
- LL 数据 PDU：L2CAP 消息的延续片段，或空 PDU。
- LL 数据 PDU：L2CAP 消息的开始或没有分段的完整 L2CAP 消息。
- LL 控制 PDU。
LL 控制 PDU 实现 Link 层控制协议，与 L2CAP 无关。这些数据包不直接通过 HCI 发送。
HCI 层类似地使用了一种称为数据包边界标志的东西。数据包的HCI包header包括连接句柄和包边界标志。
控制器或主机都可以重组 L2CAP 片段。虽然对于主机来说当然是强制性的，但它对于控制器来说是可选的。重组只是通过累积片段直到总长度等于根据 header 的长度来完成。这意味着 start/continuation header 在 BLE 中实际上是多余的，因为 BLE 仅使用可靠传输，但仍可用作检测边界错误的方法。
支持 LE 数据长度扩展的控制器，例如可以通过 HCI 从主机接收多个小片段，并将它们重新组合成一个大的 Link 层数据包。如果远程设备不支持 LE 数据长度扩展，控制器也可能从主机接收到一个大的 L2CAP 数据包，然后将其分成多个片段以通过 Link 层发送。
现在开始分段和重组。这是蓝牙经典中使用的一个术语，能够支持大数据包，并将它们与其他数据包复用。
分段和重组的一个问题是，一个大数据包将以一个块的形式发送，在传输该数据包时保留整个 link，因为一个帧中的所有片段都必须按顺序发送。因此，L2CAP 使用术语 SDU“服务数据单元”来描述更高层（大）数据包。这个数据包可以被“分割”成几个更小的 L2CAP I-Frames，然后照常发送，如果需要，可能使用分段和重组。之前的问题现在已经解决，因为来自一个 SDU 的 I-Frames 可以与来自另一个 SDU 的 I-Frames 交错。 L2CAP 接收主机然后将“重组”I-Frames 到原始的 SDU 中。因此可能存在多个未完成的传入不完整 SDU。
在蓝牙 4.2 中，创建了面向蓝牙 L2CAP 连接的通道作为除 GATT 之外的另一种发送数据的方式。这是 L2CAP 中的全新部分，但借鉴了经典蓝牙的思想。这个想法也是为了能够交错来自不同通道的大数据包 (SDU)。还实现了流量控制机制。就像在经典蓝牙中一样，每个 SDU 被分成多个帧，这次称为 K-frames。每个 K-frame 包含信道标识符，因此接收方知道该帧属于哪个未决 SDU。但请注意，如果您仔细阅读规范，您会发现这次该机制不称为 Segmentation & Reassembl.事实上，它根本不叫任何东西。分段和重组术语仅针对各种蓝牙经典模式明确定义，即使 BLE L2CAP CoC 的原理相同。
我希望我上面写的内容足以满足 BLE 的 L2CAP 理论。否则我能推荐的最好的是蓝牙核心规范。但是，如果您阅读了 L2CAP 章节，请首先尝试确定您正在阅读的部分中是否包含“LE”一词，否则它可能不相关。如果它包含“BR/EDR”，它可能不相关。
蓝牙规范版本 4.2 [第 3 卷，A 部分] 第 140 页
...
分段和重组操作仅在增强版中使用 Retransmission mode、Streaming mode、Retransmission mode、Flow 控制模式.
因此 BLE l2cap 中不使用分段和重组。
蓝牙核心规范 5.2 版 |第 3 卷 A 部分第 1031 页
2.4 操作模式 L2CAP 通道可以在为选择的几种不同模式之一中运行 每个 L2CAP 通道。 这些模式是： • 基本 L2CAP 模式 • 流量控制模式 • 重传模式 • 增强重传模式 • 流媒体模式 • 基于 LE 信用的流量控制模式 • 增强的基于信用的流量控制模式
蓝牙核心规范 5.2 版 |第 3 卷 A 部分第 1032 页
LE Credit Based Flow Control Mode 用于 LE L2CAP connection-oriented 使用基于信用的 L2CAP 数据方案进行流量控制的通道（即不 信令数据包）。
蓝牙核心规范 5.2 版 |第 3 卷 A 部分第 1131 页
分段和重组操作仅在增强版中使用 Retransmission mode、Streaming mode、Retransmission mode、Flow 控制模式.
我不太看新报纸)) 我觉得 5.2 够新了吧？
此外，我必须指出，实际实现，例如TI、英飞凌（赛普拉斯），完全证实了这一点，即符合规范。
不谢。))