BLE中的L2CAP层基本功能分析

发布时间 2023-06-19 16:53:42作者: 不回本不改名

逻辑链路(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,不过现在都是集成的,很少会带这个功能了。