蓝牙框架介绍

蓝牙框架介绍

1、整体框架图

蓝牙核心技术概述.pdf(入门必备)

蓝牙框架可分为两部分，一部分为蓝牙模块(Bluetooth Module)和蓝牙主机(Bluetooth Host)，其中蓝牙模块主要包含蓝牙底层协议，如射频(RF)、基带(BB)、链路控制(LC)等，一般来说蓝牙模块和蓝牙主机协议开发是分开的，底层协议由芯片设计制造开发定义，上层协议由产品开发设计定义。蓝牙主机与蓝牙模块通信基本都是通过主机控制接口(HCI)，所以对上层协议开发者而言只需要关注高层协议与主机控制接口之间的数据交换。

2、应用层协议栈（个人称呼）

物理链路就是一些数据传输，最终都是通过射频RF进行沟通交互，实际分析需要结合软件架构思路。如 spp<->spp、RFCOMM<->RFCOMM 等。数据收发以及处理要在同一协议层进行分析处理。

1) BR/EDR 协议栈

上图来源，查询请点击Blog

上图可以较为清晰的看出各蓝牙协议(BR/EDR)间的数据传输情况。

HSP/HFP：手机(mobile phone)与耳机之间通信的基本功能，如接听、拒接、挂断等

SCO：音频数据一般有两个通道，同步链路(SCO)和异步链路(ACL)， SCO 主要用来传输对时间要求很高的数据通信，一般通话使用 SCO 通道； ACL 链路就是定向发送数据包，既支持对称连接也支持不对称连接，多用于音乐等数据通信(直接与 HCI 通讯)

SDP：建立通讯通道，一般在建立连接之前进行寻呼、问询、连接。

SPP：模拟串口定义的蓝牙收发协议，使用 RFCOMM 通道通过 L2CAP 建立一个完整的数据通路。

A2DP：A2DP 协议的音频数据在 ACL Link上传输，这与 SCO 上传输的语音数据要区别。A2DP 不包括远程控制的功能，远程控制的功能参考协议 AVRCP、AVDTP、AVCTP 则定义了蓝牙设备之间数据流句柄的参数协商，建立和传输过程以及相互交换的信令实体形式，该协议是 A2DP 框架的基础协议。

GAP：GAP 协议保证不同 Bluetooth 产品可以互相发现并建立连接，定义了蓝牙设备如何发现对方并建立安全/不安全连接，同时还包括链路、信道的建立

RFCOMM：基于 L2CAP 协议，模拟 RS232 串口。
支持多串口仿真。在一次 RFCOMM 会话中，客户和服务器可以分布在通信的两端，每一端的客户都可以独立发起建立通信连接，因此可使用 RFCOMM 服务器信道的概念将 DLCI 值域空间在两个正在进行通信的设备间进行划分。一个数据链接标识( DLCI: 参考帧格式 Address 字段 D + ServerChannel )标识一对客户和服务器之间的持续连接(在两个设备间的 RFCOMM 会话中保持一致 DLCI 长度为 6 bit，在 RFCOMM 中其可用值区间为 2 ~ 61 0为控制信道 1 由于服务器信道概念不能使用 62 - 63 保留)。所以 RFCOMM 支持最大 60 路。

支持多仿真串口和多蓝牙设备，如果蓝牙设备支持多串口仿真，同时通信连接两端允许使用不同 BT 设备，那么 RFCOMM 实体必须能够运行多路复用会话，每个多路复用使用 L2CAP 信道标识符(CID)来区分

参考Blog

2) BLE 协议栈

上图来源，查询请点击Blog

GATT：现有 BLE 连接都是建立在GATT协议之上，GATT 的全名是Generic Attribute Profile，它定义两个 BLE 设备通过Service 和 Characteristic 进行通信。GATT 基于 ATT（Attribute Protocol）协议，把 Service, Characteristic 对应的数据保存在一个查找表中，次查找表使用 16 bit ID 作为每一项的索引。这里需要说明的是，GATT 连接，必需先经过 GAP 协议。

实际上，我们在 Android 开发中，可以直接使用设备的 MAC 地址，发起连接，可以不经过扫描的步骤。这并不意味不需要经过 GAP，实际上在芯片级别已经给你做好了，蓝牙芯片发起连接，总是先扫描设备，扫描到了才会发起连接。GATT 连接需要特别注意的是：GATT 连接是独占的。也就是一个 BLE 外设同时只能被一个中心设备连接。一旦外设被连接，它就会马上停止广播，这样它就对其他设备不可见了。当设备断开，它又开始广播。中心设备和外设需要双向通信的话，唯一的方式就是建立 GATT 连接。

参考Blog

ATT：Client 和 Server 之间是通过 ATT PDU来通信的，ATT PDU主要包括4类：读，写，notify 和 indicate。如果一个命令需要 response，那么会在相应命令后面加上 request；如果一个命令只需要 ACK 而不需要 response，那么它的后面就不会带 request。这里要特别强调一点，BLE 所有命令都是“必达”的，也就是说每个命令发出去之后，会立马等 ACK 信息，如果收到了 ACK 包，发起方认为命令完成；否则发起方会一直重传该命令直到超时导致 BLE 连接断开。换句话说，只要你的 BLE 没有断开，那么你之前发送的数据包，不管它是用什么 ATT PDU 来发送的，它肯定被对方收到了。

我估计很多人对此会产生疑问，因为他们经常碰到丢包的情况，其实大家经常碰到的“丢包”，不是空中把包丢了或者包在空中被干扰了，而是大家发送的代码写得有问题，导致你要发送的包没有被安全送达到协议栈射频 FIFO 中，所以以后大家碰到丢包情况，请先检查你的代码，保证你的数据包正确完整安全地送达到协议栈射频 FIFO 中，只要数据包放到了协议栈射频 FIFO 中，蓝牙协议栈就能保证该数据包“必达”对方。

既然每个 ATT 命令都必达对方，那么还需要 request 做什么？如果一个命令带有 request 后缀，那么发起方就可以收到命令的 response 包，这个 response 包在应用层是有回调事件的，而前述的 ACK 包在应用层是没有回调事件的。所以采用 request/response 方式，应用层可以按顺序地发送一些数据包，这个在很多应用场合是非常有用的。相反，如果你对应用层数据包的顺序没有要求，那么就可以不使用 request/response 形式。另外 Request/response 有一个副作用：大大降低通信的吞吐率，因为 request/response 必须在不同的连接间隔中出现，也就是说，你在间隔 1 中发送了一个 request 命令，那么 response 包必须在间隔 2 或者稍后间隔中回复，而不能在间隔1中回复，这就导致两个连接间隔最多只能发一个数据包，而不带 request 后缀的 ATT 命令就没有这个问题，在同一个连接间隔中，你可以同时发多个数据包，这样将大大提高数据的吞吐率。

常用的带 request 的命令：所有 read 命令，writerequest，indication 等，而常用的不带 request 的命令有 write command，notification 等。

参考Blog

拓展：SBC 是一种音频解码系统，附属于 A2DP 协议，专门为蓝牙 AV 应用程序设计。在 BES2300 中用来做音频数据的处理，只有在播放音乐或者一些系统声音才会打开 SBC 通路，这也是可接触的最底层音频数据通路。

3、 L2CAP 与 HCI

1) L2CAP 只支持 ACL 数据传输，不支持 SCO 数据。 SCO 数据直接与 HCI 层进行数据交互。(猜测为了数据实时性更好)

2) 协议复用：底层传输协议没有提供对高层协议的复用机制，因而 L2CAP 支持高层协议复用， L2CAP 层可以区分其上的 SDP、 RFCOMM、 TCS 等

To be continue