BLE中L2CAP层基本功能分析
逻辑链路（Logical Link）
在明白L2CAP之前要先明白其中L2代表的logic link是什么意义，在spec中的下述章节对这些概念进行了基本解释
Vol 1: Architecture & Terminology Overview
Part A: Architecture
3 Data transport architecture
由于历史发展的原因，传统蓝牙将数据传输的方式方法抽象为一条条数据链路（data link），每条链路代表着一种使用着某种传输逻辑（Logic）和传输实体（Physic）的链路。并由L2CAP(Logical Link Control and Adaption Protocol，逻辑链路控制与适配协议)进行管理和控制。在spec中的下述章节对这些概念进行了更具体地说明解释。
Vol 2: Core System Package [BR/EDR] Controller volume
Part B: Baseband Specification
在传统蓝牙中，将数据传输分为逻辑层和物理层。其中
物理层包括：
- Physical Transport：物理传输，指传输的物理方法。蓝牙技术只使用一种无线电调制方法，即GFSK调制。
- Physical Channels：物理通道，指传输的物理信道。蓝牙使用2.4G频段分为多个频段进行通信，传统蓝牙和低功耗蓝牙对信道划分有一定区别。
- Physical Link：物理链路，物理通信方法的抽象化指代。指的是一种使用何种调制方法，在哪一个频段进行通信的物理通信方法。
逻辑层包括：
- Logical Transports：逻辑传输，指传输的逻辑方法。蓝牙主要以ASL（asynchronous connection-oriented）和SCO（synchronous connection-oriented）两种方法，主要区别为SCO不带重传，效率高，适用于传输音频数据；ASL带重传，质量好，适用于传一般数据。
- Logical Links：逻辑链路，逻辑传输方法的抽象化指代。根据传输的内容在逻辑传输的基础上做了更进一步区分。
这里spec中的逻辑连接（logical）和物理连接（physical）的概念比较难以理解。一般来讲:
- logical是偏理论流程的，指的是数据传输时的交互逻辑。例如数据发送到对端后，对端是否要进行应答，确认是否已经顺利接收到。或者当有很多数据要发给对方是，是否要分包，分开多次发送接收来避免对端一次性收太多数据会死机，等等这些交互的逻辑方法。
- 而physical是偏实体的，指的是数据传输的物理方法。例如数据是通过人面对面说话来传递，还是写在纸上传给对方，还是用无线电发送给对方，等等这些交互的物理方法。
基于这个分层思想，蓝牙协议创造了许多逻辑连接（Logical）来供各种要求不同的上层应用数据传输需求。逻辑连接并非什么有形存在的东西，只是一种通信方式的定义罢了。它的存在体现在数据交互过程的逻辑思想，体现在数据包的字段结构的涉及思想中。
L2CAP介绍
OSI 7层模型是通信的基本模型，蓝牙的协议层次和OSI 7层模型也是可以一一对应的。蓝牙的LL层和PHY层和OSI模型的数据链路层和物理层基本一一对应，而在LL层之后则区别较大。
首先对于蓝牙这种拓扑结构为最简单的一对一直连应用，它没有也不需要OSI定义的网络层来为它进行组网和传输路径规划。而到传输层这以块，蓝牙则设计的相对复杂一些。在蓝牙协议中，它主要通过L2CAP协议来共同实现OSI传输层所需求的作用。
在LL协议中，实现了逻辑连接（logic link）建立，硬件地址寻址，CRC校验等功能。而在L2CAP层中，通过对LL层建立的逻辑连接进行控制和适配，来实现不同应用常见对数据传输中对分包、组包、流控、重传等功能需求。
L2CAP的主要功能包括：
- Protocol/channel multiplexing：协议/通道复用
Logical Link是有限的，但要用它来传输数据的上层协议却不止一个（例如ATT和SMP协议），multiplexing便是用过复用的方法来解决这个问题。类似于电脑上IP用同一个，但端口号可以有很多个，不用的应用协议用不同的端口来进行通信。
- Segmentation and reassembly：分段和重组。针对上层数据的处理。
上层的数据可能有很多，但底层设备的处理能力是有限的，分段便是将上层庞大的数据进行切割，让底层方便处理。而重组便是反过来，将底层分散的数据重新组合，传回给上层协议。
- Flow control per L2CAP channel：每个L2CAP通道的流控
当多个数据流通过不同的逻辑通道流经同一个控制器的时候，每一个通道需要单独的流控制
- Error control and retransmissions：差错控制和重传
对数据传输出现错误时进行重传，保证数据准确
- Support for Streaming：流传支持
音频类型的流媒体数据不希望进行流控，需要特别的控制机制
- Fragmentation and Recombination：分割和重组。针对下层数据的处理
主要针对早期一些数据处理能力弱的Controller，对上层数据再次进行分割处理。
- Quality of Service：服务质量
用于确定双发设备的服务质量是可靠的（Guaranteed）还是尽力而为的（Best Effort），这个跟高速传输应用比较相关，用于确认设备的传输能力。
L2CAP在BLE中的实现
L2CAP协议支持很多功能，但BLE用的是简化版本，和前面说的没太大关系，可以把前面讲的都忘掉。对于BLE，L2CAP他基本只使用了通道复用（channel multiplexing）功能
L2CAP包格式
对于LE，L2CAP只使用了Basic Mode的帧格式，该帧被包裹在LL层空口包里的PDU里。而内部的Information payload则包含更上层的数据。
B帧结构包括：
- Length：帧长
- Channel ID：通道ID
- Information payload：信息载荷
CID
可以看到L2CAP Header中有一个Channel ID字段。该字段用于解决上层协议复用同一个链路的问题。通过CID作为标识位来区分payload部分内容类型，方便设备进行处理。
如上所示，CID长16bit，每一个CID和对应的Payload类型如下：
- 0x0000：不用
- 0x0004：对应ATT层数据的类型
- 0x0005：对应L2CAP层的信令数据
- 0x0006：对应SMP层类型的数据
- 0x0020-0x003E：对于LE，该部分为SIG预留，用户不可使用
- 0x0040-0x007F：COC应用动态分配
可以看到对于ATT和SMP协议已经绑定死了固定两个CID，这个是专门留个他们使用的。我们主要看另外的LE Signaling和COC两个是什么
LE Signaling
信令通道（Signaling channel）为两个L2CAP实体之间传递信令的通道，L2CAP协议使用信令来控制两个设备之间L2CAP层的连接建立，配置更新等功能。信令的帧格式如下：
信令使用的帧格式如上图所示，可以看到和B帧的格式一致，只是在payload端做了更进一步的细分。其中：
- Code：为信令编号，对于整个L2CAP协议，支持的信令如下：
可以看到，对于BLE（即CID为0x05）,支持的信令会有一定裁剪。只剩下连接参数更新和COC通道建立和断开这三类指令。并且需要注意Disconnect信令只针对建立起来的COC通道，而并非针对整个蓝牙连接事件。对于蓝牙连接事件，GAP协议和LL协议有专门的termination procedure和command。
- Identifier：标识符。用于匹配对应的request和respond，避免重复发送request时会重复respond。
- Length：仅表示data端长度，不包括上述字节。
- Data：数据段，根据信令类型决定该段的有无。
Connection Parameter Update
在LL层和GAP层，连接参数更新有专门的一套procedure，但只有主设备可以直接发起这套连接参数更新procedure。对于从设备，如果要发起连接参数更新，需要先在L2CAP层向主机发起协商，在得到主机同意后，再由主机走LL层和GAP的Procedure来发起参数更新。大致区别如下：
相关连接参数更新涉及到LL、GAP、L2CAP三个层次的交互，这里只是简单介绍下。相关说明有空可以再专门分析下
LE Credit Based Connection
在面向连接的信道（Connection Oriented Channel）通信的帧叫做LE frame，Credit代表发送一个LE frame的权限。接收设备给与发送设备一个credit，则发送设备就可以给接收设备发送一个LE帧。如果发送设备发送超过credit的帧，接收设备就会关闭通道，这种连接就叫做LE Credit Based Connection。而面向连接的信道（Connection Oriented Channel）则是专门用于这种连接的通道（Channel）。
该功能设计的初衷在于LE默认支持ATT和SDP的通道过于固定，为了未来能支持其他更多的协议，就新增了这一功能。该COC信道最大优势是可以通过配置MTU和MPS使得应用层可以发送长包数据，以便提高系统吞吐率，典型的应用为Internet Protocol Support Profile（IPSP）以及Object Transfer Profile（OTP）。一般应用用的比较少，如果有考虑高吞吐的私有协议才会使用该功能，有空可以再专门分析下
SDU、MTU和MPU
在L2CAP中有几个名词要特别说明下：
- SDU：Service Data Unit,上层协议传给L2CAP层的数据包，内容中不包含任何与L2CAP有关信息。
- MTU：Maximum Transmission Unit ，上层协议能支持的SDU包的最大长度，不论是收还是发。
- MPS：Maximum PDU payload Size，L2CAP层能支持的最大PDU大小。
这里一般会关注的分包问题，对于上层的数据包和L2CAP层的数据包，当出现MTU大于MPS时候，需要L2CAP层对上层SDU进行拆包成一个个小PDU，这个就是传统蓝牙的Segmentation and reassembly功能。但在BLE中，一般L2CAP只实现Basic Mode，只使用B帧，规定MPS和MTU大小一样。因此在BLE中，L2CAP不实现分包组包功能（COC应用除外）。
这个是由于在BLE中，常规数据通信上层都是走ATT协议，而在ATT协议中有专门的ATT_MTU来规定SDU的大小。另外对于以前老的Host和controller分离的接口，为了适应HCI的能力，L2CAP可能还涉及Fragmentation and Recombination，不过现在都是集成的，很少会带这个功能了。
