|
4 L2CAP Protocol
4.1 功能介绍
经过Link Layer的抽象之后，两个BLE设备之间可存在两条逻辑上的数据通道：一条是无连接的广播通道，海阔凭鱼跃嘛；另一条是基于连接的数据通道，是一个点对点（Master对Slave）的逻辑通道。
广播通道暂且不说，这个数据通道（简称逻辑通道，Logical Channel），要怎么使用，还有一些疑问，如：
1）Logical Channel只有一条，而要利用它传输数据的上层应用却不止一个（例如协议框架中的ATT和SMP），怎么复用？
2）Logical Channel所能传输的有效payload长度最大只有251bytes，怎是否意味着上层应用每次只能传输少于这个长度的数据？（显然不能！）
3）Logical Channel仅提供了简单的应答和流控机制，如果传输的数据出错怎么办？
等等…
以上问题，都是由L2CAP，一个介于应用程序（Profile、Application等）和Link Layer之间的protocol负责，这也是它的缩写（Logical Link Control and Adaptation Protocol）的意义所在。它提供的功能主要包括：
1）Protocol/channel multiplexing，协议/通道的多路复用；
2）Segmentation and reassembly，上层应用数据（L2CAP Service Data Units，SDUs）的分割（和重组），生成协议数据单元（L2CAP Packet Data Units，PDUs），以满足用户数据传输对延时的要求，并便于后续的重传、流控等机制的实现；
3）Flow control per L2CAP channel，基于L2CAP Channel的流控机制；
4）Error control and retransmissions，错误控制和重传机制；
5）Support for Streaming，支持流式传输（如音频、视频等，不需要重传或者只需要有限重传）；
6）Fragmentation and Recombination，协议数据单元（PDUs）的分片（和重组），生成符合Link Layer传输要求的数据片（长度不超过251）；
7）Quality of Service，QoS的支持。 4.2 Protocol/channel multiplexing
所谓的multiplexing（多路复用），还是很好理解的：
可用于传输用户数据的逻辑链路只有一条，而L2CAP需要服务的上层Profile和Application的数目，肯定远不止这个数量。因此，需要使用多路复用的手段，将这些用户数据map到有限的链路资源上去。
至于multiplexing的手段，简单又直接（可以说是“协议”的标配）：
1）数据发送时，将用户数据分割为一定长度的数据包（L2CAP Packet Data Units，PDUs），加上一个包含特定“ID”的header后，通过逻辑链路发送出去。
2）数据接收时，从逻辑链路接收数据，解析其中的“ID”，并以此判断需要将数据转发给哪个应用。
这里所说的ID，就是多路复用的手段，L2CAP提供两种复用手段：
4.2.1 基于连接的方法（这里的连接为L2CAP connection，不要和Link Layer的connection混淆了）
这里的连接，是指基于L2CAP的应用程序，在通信之前，先建立一个基于Logical Channel的虚拟通道（称作L2CAP channel，和TCP/IP中的端口类似）。L2CAP会为这个通道分配一个编号，称作channel ID（简称CID）。
L2CAP channel建立之后，就可以把CID放到数据包的header中，以达到multiplexing的目的。这些基于CID实现的多路复用，就称作channel multiplexing（基于通道的多路复用）。
那CID是怎么确定的呢？有一些固定用途的L2CAP Channel，其CID是固定值，另外一些则是动态分配的，具体如下： 
有关CID的具体数值可参考：Core_v4.2.pdf, Volume 3, Part A - Logical Link Control and Adaptation Protocol Specification
4.2.2 无连接的方法
另外，为了提高数据传输的效率，方便广播通信等应用场景，L2CAP在提供基于连接的通信机制之外，也提供了无连接的数据传输方法。基于这种方法，CID不存在了，取而代之的是一个称作Protocol/Service Multiplexer(PSM)的字段。
由于Protocol multiplexing只允许在BR/EDR controller中使用，就不再详细介绍了。 4 L2CAP Protocol
4.1 功能介绍
经过Link Layer的抽象之后，两个BLE设备之间可存在两条逻辑上的数据通道：一条是无连接的广播通道，海阔凭鱼跃嘛；另一条是基于连接的数据通道，是一个点对点（Master对Slave）的逻辑通道。
广播通道暂且不说，这个数据通道（简称逻辑通道，Logical Channel），要怎么使用，还有一些疑问，如：
1）Logical Channel只有一条，而要利用它传输数据的上层应用却不止一个（例如协议框架中的ATT和SMP），怎么复用？
2）Logical Channel所能传输的有效payload长度最大只有251bytes，怎是否意味着上层应用每次只能传输少于这个长度的数据？（显然不能！）
3）Logical Channel仅提供了简单的应答和流控机制，如果传输的数据出错怎么办？
等等…
以上问题，都是由L2CAP，一个介于应用程序（Profile、Application等）和Link Layer之间的protocol负责，这也是它的缩写（Logical Link Control and Adaptation Protocol）的意义所在。它提供的功能主要包括：
1）Protocol/channel multiplexing，协议/通道的多路复用；
2）Segmentation and reassembly，上层应用数据（L2CAP Service Data Units，SDUs）的分割（和重组），生成协议数据单元（L2CAP Packet Data Units，PDUs），以满足用户数据传输对延时的要求，并便于后续的重传、流控等机制的实现；
3）Flow control per L2CAP channel，基于L2CAP Channel的流控机制；
4）Error control and retransmissions，错误控制和重传机制；
5）Support for Streaming，支持流式传输（如音频、视频等，不需要重传或者只需要有限重传）；
6）Fragmentation and Recombination，协议数据单元（PDUs）的分片（和重组），生成符合Link Layer传输要求的数据片（长度不超过251）；
7）Quality of Service，QoS的支持。 4.2 Protocol/channel multiplexing
所谓的multiplexing（多路复用），还是很好理解的：
可用于传输用户数据的逻辑链路只有一条，而L2CAP需要服务的上层Profile和Application的数目，肯定远不止这个数量。因此，需要使用多路复用的手段，将这些用户数据map到有限的链路资源上去。
至于multiplexing的手段，简单又直接（可以说是“协议”的标配）：
1）数据发送时，将用户数据分割为一定长度的数据包（L2CAP Packet Data Units，PDUs），加上一个包含特定“ID”的header后，通过逻辑链路发送出去。
2）数据接收时，从逻辑链路接收数据，解析其中的“ID”，并以此判断需要将数据转发给哪个应用。
这里所说的ID，就是多路复用的手段，L2CAP提供两种复用手段：
4.2.1 基于连接的方法（这里的连接为L2CAP connection，不要和Link Layer的connection混淆了）
这里的连接，是指基于L2CAP的应用程序，在通信之前，先建立一个基于Logical Channel的虚拟通道（称作L2CAP channel，和TCP/IP中的端口类似）。L2CAP会为这个通道分配一个编号，称作channel ID（简称CID）。
L2CAP channel建立之后，就可以把CID放到数据包的header中，以达到multiplexing的目的。这些基于CID实现的多路复用，就称作channel multiplexing（基于通道的多路复用）。
那CID是怎么确定的呢？有一些固定用途的L2CAP Channel，其CID是固定值，另外一些则是动态分配的，具体如下：
有关CID的具体数值可参考：Core_v4.2.pdf, Volume 3, Part A - Logical Link Control and Adaptation Protocol Specification
4.2.2 无连接的方法
另外，为了提高数据传输的效率，方便广播通信等应用场景，L2CAP在提供基于连接的通信机制之外，也提供了无连接的数据传输方法。基于这种方法，CID不存在了，取而代之的是一个称作Protocol/Service Multiplexer(PSM)的字段。
由于Protocol multiplexing只允许在BR/EDR controller中使用，就不再详细介绍了。 5 Attribute Protocol
由上面章节的描述可知，在BLE协议栈中：
Physical Layer负责提供一系列的Physical Channel；
基于这些Physical Channel，Link Layer可在两个设备之间建立用于点对点通信的Logical Channel；
而L2CAP则将这个Logical Channel换分为一个个的L2CAP Channel，以便提供应用程序级别的通道复用。到此之后，基本协议栈已经构建完毕，应用程序已经可以基于L2CAP欢快的run起来了。
谈起应用程序，就不得不说BLE的初衷----物联网。物联网中传输的数据和传统的互联网有什么区别呢？抛开其它不谈，物联网中最重要、最广泛的一类应用是：信息的采集。
这些信息往往都很简单，如温度、湿度、速度、位置信息、电量、等等。
采集的过程也很简单，节点设备定时的向中心设备汇报信息数据，或者，中心设备在需要的时候主动查询。
基于信息采集的需求，BLE抽象出一个协议：Attribute protocol，该协议将这些“信息”以“Attribute（属性）”的形式抽象出来，并提供一些方法，供远端设备（remote device）读取、修改这些属性的值（Attribute value）。
Attribute Protocol的主要思路包括：
1）基于L2CAP，使用固定的Channel ID（0x004，具体可参考“图3”）。
2）采用client-server的形式。提供信息（以后都称作Attribute）的一方称作ATT server（一般是那些传感器节点），访问信息的一方称作ATT client。
3）一个Attribute由Attribute Type、Attribute Handle和Attribute Value组成。
Attribute Type用于标示Attribute的类型，类似于我们常说的“温度”、“湿度”等人类可识别的术语，不过与人类术语不同的是，Attribute Type使用UUID（Universally Unique IDentifier，16-bit、32-bit或者128-bit的数值）区分。
Attribute Handle是一个16-bit的数值，用作唯一识别Attribute server上的所有Attribute。Attribute Handle的存在有如下意义：
a）一个server上可能存在多个相同type的Attribute，显然，client有区分这些Attribute的需要。
b）同一类型的多个Attribute，可以组成一个Group，client可以通过这个Group中的起、始handle访问所有的Attributes。
Attribute Value代表Attribute的值，可以是任何固定长度或者可变长度的octet array（理解为字节类型的数组即可）。 4）Attribute可以定义一些权限（Permissions），以便server控制client的访问行为，包括：
访问有关的权限（access permissions），Readable、Writeable以及Readable and writable；
加密有关的权限（encryption permissions），Encryption required和No encryption required；
认证有关的权限（authentication permissions），Authentication Required和No Authentication Required；
授权有关的权限（authorization permissions），Authorization Required和No Authorization Required。
5）根据所定义的Attribute PDU的不同，client可以对server有多种访问方式，包括：
Find Information，获取Attribute type和Attribute Handle的对应关系；
Reading Attributes，有Read by type、Read by handle、Read by blob（只读取部分信息）、Read Multiple（读取多个handle的value）等方式；
Writing Attributes，包括需要应答的writing、不需要应答的writing等。 6 Generic Attribute Protocol
6.1 功能介绍
ATT之所以称作“protocol”，是因为它还比较抽象，仅仅定义了一套机制，允许client和server通过Attribute的形式共享信息。而具体共享哪些信息，ATT并不关心，这是GATT（Generic Attribute Profile）的主场。
GATT相对ATT只多了一个‘G‘，但含义却大不同，因为GATT是一个profile（更准确的说是profile framework）。
在蓝牙协议中，profile一直是一个比较抽象的概念，我们可以将其理解为“应用场景、功能、使用方式”都被规定好的Application。传统的BR/EDR如此，BLE更甚。上面我们讲过，BLE很大一部分的应用场景是信息（Attribute）的共享，因此，BLE协议栈基于Attribute Protocol，定义了一个称作GATT（Generic Attribute）的profile framework（它本身也是一个profile），用于提供通用的、信息的存储和共享等功能。
6.2 层次结构
作为一个Profile framework，GATT profile提出了如下的层次结构： 
由上图可知，GATT profile的层次结构依次是：Profile—>Service—>characteristic。
“Profile”是基于GATT所派生出的真正的Profile，位于GATT Profile hierarchy的最顶层，由一个或者多个和某一应用场景有关的Service组成。
一个Service包含一个或者多个Characteristic（特征），也可以通过Include的方式，包含其它Service。
Characteristic则是GATT profile中最基本的数据单位，由一个Properties、一个Value、一个或者多个Descriptor组成。
Characteristic Properties定义了characteristic的Value如何被使用，以及characteristic的Descriptor如何被访问。
Characteristic Value是特征的实际值，例如一个距离特征，其Characteristic Value就是距离长度。
Characteristic Descriptor则保存了一些和Characteristic Value相关的信息（例如value记录距离长度，那么Descriptor可以是长度单位m/km）。
以上除“Profile”外的每一个定义，Service、Characteristic、Characteristic Properties、Characteristic Value、Characteristic Descriptor等等，都是作为一个Attribute存在的，包括之前所描述的Attribute的所有特征：Attribute
Handle、Attribute Types、Attribute Value和AttributePermissions。 7 Generic Access Profile（GAP）
前面4到6章的内容，都是和基于连接的data channel有关，至于无连接的advertising channel，以及连接建立的过程，好像被我们忽略了。虽然Link Layer已经做出了定义（具体可参考第3章的介绍），但它们并没有体现到Application（或者Profile）层面，毕竟Link layer太底层了。
因此，BLE协议栈定义了一个称作Generic Access（通用访问）的profile，以实现如下功能：
1）定义GAP层的蓝牙设备角色（role）
和3.3中的Link Layer的role类似，只不过GAP层的role更接近用户（可以等同于从用户的角度看到的蓝牙设备的role），包括：
Broadcaster Role，设备正在发送advertising events；
Observer Role，设备正在接收advertising events；
Peripheral Role，设备接受Link Layer连接（对应Link Layer的slave角色）；
Central Role，设备发起Link Layer连接（对应Link Layer的master角色）。
2）定义GAP层的、用于实现各种通信的操作模式（Operational Mode）和过程（Procedures），包括：
Broadcast mode and observation procedure，实现单向的、无连接的通信方式；
Discovery modes and procedures，实现蓝牙设备的发现操作；
Connection modes and procedures，实现蓝牙设备的连接操作；
Bonding modes and procedures，实现蓝牙设备的配对操作。
3）定义User Interface有关的蓝牙参数，包括：
蓝牙地址（Bluetooth Device Address）；
蓝牙名称（Bluetooth Device Name）；
蓝牙的pincode（Bluetooth Passkey）；
蓝牙的class（Class of Device，和发射功率有关）； |
