1.BLE连接讲解

控制器（链路层）

建立连接（connection establishment）

        根据蓝牙spec规定，advertiser发送完一个广播包之后150us（T_IFS），advertiser必须开启一段时间的射频Rx窗口，以接收来自observer的数据包。Observer就可以在这段时间里给advertiser发送连接请求。如下图所示，手机在第三个广播事件的时候扫到了设备B，并发出了连接请求CONN_REQ(CONN_REQ又称为CONNECT_IND)。

 

        如图所示，手机在收到A1广播包ADV_IND后，以此为初始锚点（这个锚点不是连接的锚点），T_IFS时间后给Advertiser发送一个connection request命令，即A2数据包，告诉advertiser我将要过来连你，请做好准备。Advertiser根据connect_req命令信息做好接收准备，connect_req包含如下关键信息：

* Transmit window offset，

* Transmit window size，

* connect_req数据包完整定义如下所示  

LLData内容如下：

Access Address to be used in the connection（连接中使用的地址）

CRC initialization value（CRC校验）

Transmit window size（传输窗口大小）

Transmit window offset（传输窗口偏移）

Connection interval（连接间隔）

Slave latency（连接从机延迟）

Supervision timeout（连接最大超时时间，即监控超时）

Adaptive frequency-hopping channel map（信道映射，即自适应跳频信道图）

Frequency-hop algorithm increment（跳频增加，即调频算法增量）

Sleep clock accuracy（主机睡眠时间精度）

Access Address to be used in the connection（连接中使用的地址）

        由主设备随机生成，但是必须遵循接入地址的规则。如果有多个从设备和主机连接，会随机生成不同的接入地址。

CRC initialization value（CRC校验）

        CRC校验值由主设备随机生成，如果同一区域有两个主设备正在和从设备进行通信，虽然接入地址相同的概率很低，但是如果真的发生了相同的接入地址的情况，那么从设备会错误的接收到干扰数据包，因此，设备继续校验CRC数据，两个值都相同的概率则会微乎其微。

Transmit window（发射窗口）

        当连接请求数据包发送结束后，有一个1.25ms的强制延时（这种强制的延迟为设备提供了喘息的机会，在广播和连接正式确立之间，电池获得了宝贵的恢复时间，为主机准备数据提供时间，保证第一时间发出），紧接着就是Transmit window offset和Transmit window size。发射窗口偏移可以是0到连接间隔之间的任意值，但是必须是1.25ms的整数倍。在Transmit window size期间，从设备打开接收器，等待数据包，如果窗口结束任然没有收到数据，则会等待一个连接间隔后再次尝试。

        注意这里主设备发送了连接请求后，便认为连接已经创建，但是还不能算是完全确立。从设备也同样，认为已经创建，但没有完全确立。只有在收到了数据包确认，才能完全连接确认。连接确认不会改变连接的工作方式，但是会改变链路监控超时的时间，从之前的6个连接间隔，变为了在连接请求中设定的值。

        体现在上面的连接示例图中，则为手机将在Transmit Window期间发送第一个同步包（P1）给你，设备B在这段时间把射频接收窗口打开。设备B收到P1后，T_IFS时间后将给手机回复数据包P2（ACK包）。一旦手机收到数据包P2，连接即可认为建立成功。当然，实际情况会比较复杂，手机有可能收不到P2，这个时候手机将持续发送同步包直到超时时间（supervision timeout），在此期间只要设备B回过一次ACK包，连接即算成功。所以一旦P1包发出，主机（手机）即认为连接成功，而不管有没有收到设备的ACK包。这也是为什么在Android或者iOS系统中，应用经常收到连接成功的回调事件（该回调事件就是基于P1包有没有发出，只要P1包发出，手机即认为连接成功，而不管有没有收到设备的ACK包），但实际上手机和设备并没有成功建立连接。后续手机将以P1为锚点（原点），Connection Interval为周期，周期性地给设备B发送数据包（Packet）。

Connection events（连接事件）

        连接成功后，master和slave在每一个connection interval开始的时候，都必须交互一次，即master给slave发一个包，slave再给master发一个包，整个交互过程称为一个connection event或者gap event。蓝牙芯片只有在connection event期间才把射频模块打开，此时功耗比较高，其余时间蓝牙芯片都是处于idle状态的，因此蓝牙芯片平均功耗就非常低，以Nordic nRF52810为例，每1秒钟Master和Slave通信1次，平均功耗约为6微安左右。Master不可能时时刻刻都有数据发给slave，所以master大部分时候都是发的空包（empty packet）给slave。同样slave也不是时时刻刻都有数据给master，因此slave回复给master的包大部分时候也是空包。另外在一个connection event期间，master也可以发多个包给slave，以提高吞吐率。连接事件的进行始终位于一个频率，每个数据包会在上个数据包发完之后等待150us。综上所述，连接成功后的通信时序图应该如下所示：

只发一个包：

发多个包：

时序图细节：

Slave latency（连接从机延迟）

        上图中出现了slave latency（slave latency = 1），那么什么叫slave latency？

        如前所述，在每一个connection interval开始的时候，Master和Slave必须交互一次，哪怕两者之间交互的是empty packet（空包），但如果slave定义了slave latency，比如slave latency = 9，此时slave可以每9个connection interval才回复一次master，也就是说slave可以在前面8个connection interval期间一直睡眠，直到第9个connection interval到来之后，才回复一个packet给master，这样将大大节省slave的功耗，提高电池续航时间。当然如果slave有数据需要上报给master，它也可以不等到第9个connection interval才上报，直接像正常情况进行传输即可，这样既节省了功耗，又提高了数据传输的实时性。不难理解从设备延迟必须短于监控超时时间，如果监控超时使用了32s的最大值，对于间隔为100ms的链路，从设备延时必须小于319。但是，建议至少给从设备留出6次侦听的机会。

Adaptive frequency-hopping channel map（信道映射，即自适应跳频信道图）

        自适应调频信道图用来标记信道的好坏，由于共有37个数据信道，所以数据的长度为37位。如果该位为1则表示信道良好，如果为0则不可用于数据通信。

Frequency-hop algorithm increment（跳频增加，即调频算法增量）

        该数即是在信道不好的情况下，用于跳频的数值，一般是5-16之间的随机数，太小和太大都不合适，更不能为0，否则频率不会变化。

以下是一个连接包的数据抓取：

举例:

上图是一个完整的CONNECT_REQ报文，被解析后如下图所示（连接请求也是广播报文的一种）

发送数据（sending data）

        在连接建立之后，设备之间便通过数据报文进行通信。

管理连接

        再发送数据的报头分析中，有对逻辑链路标识符（LLID）的描述，如果是11，则是用于管理连接。下面对管理连接进行解释。

        两个设备一旦连接，便可以收发数据和管理连接。管理连接包含下面七个链路层控制规程。

1.更新连接参数

2.改变自适应跳频信道图

3.加密链路

4.重加密链路

5.交换功能位

6.交换版本信息

7.终止链路

连接参数更新（链路层）

        建立连接之后过一段时间之后，连接请求的连接参数可能不再适应当前的使用的服务。出于提高效率，需要进行参数更新。主设备向从设备发送连接更新请求（LL_CONNECTION_UPDATE_REQ），当中携带了新的参数，这些参数不需要进行协商，从设备或者接收，或者断开连接。

        连接更新请求中的参数和连接请求时的参数不完全相同，具体参数内容如下：

1.传输窗口大小

2.传输窗口偏移量

3.连接间隔

4.从设备延迟

5.监控超时

6.瞬时

        瞬时这个参数为连接更新的新参数，主设备为连接更新选定一个未来的时间点，用于连接更新的开始时刻。这样做是为了解决报文重传的问题。只要数据包的重传次数足够，在这个瞬时之前完成传输，那么就不会有问题。但是这个重传报文没能完成传输，则可能丢失。

        由于低功耗蓝牙没有时钟，那么瞬时时刻是怎么计算的？答案是计算连接事件的个数。连接请求之后的首个传输事件为0，所以瞬时实际上是一个事件计数器。主设备应该至少保证六次数据的发送机会。也就是说，如果从设备延迟为500ms，那么瞬时通常被设定在3s之后的一个时刻。

        到达瞬时，从设备打开侦听发送窗口，和建立连接时那样。一旦该过程结束，新的连接间隔，监控超时，从设备延迟值将投入使用。

主机

属性协议（Attribute Protocol /ATT）

属性协议是非常简单的协议，客户端（两个设备连接后，需要获取服务端的数据的设备为客户端，提供数据的为服务端）通过它可以发现并获取属性服务器上的属性。它由六中基本操作构成：请求（request）、响应（response）、命令（command）、指示（indication）、确认（confirmation）、通知（notification）。

请求（request）、响应（response）

对应的PDU参数和例子：

命令（command）

指示（indication）、确认（confirmation）

通知（notification）

请求（request）和响应（response）-- 交换MTU请求（Exchange MTU）

        BLE中，默认MTU为23字节，如果需要更长的MTU值，则需要协商新的MTU，客户端和服务器，二者提供的接收MTU中较小的那个成为使用的MTU。

请求（request）和响应（response）-- 查找信息请求（Find information）

        查找信息请求和回复用来查找一系列属性的句柄和类型信息，这是唯一一个能让客户端发现任意属性类型的消息。

 查找信息请求包含两个句柄:起始句柄与结束句柄。它们定义了该请求用到的属性句柄的范围。为了找到所有数值的属性，该请求的起始句柄将是0x0001，结束句柄设为OxFFFF。通常，响应只能包含该范围内的部分;因此，为了查找所有的属性，必须使用一连串的查找信息请求，相邻的请求中的起始、结束句柄前后相接。

        查找信息响应包含句柄-类型对。它有两种可能的格式，对应于低功耗蓝牙使用的两种长度的UUID:对于16位UUID的格式允许在一个查找信息响应中包含至多5个属性句柄-类型对;对于128位UUID的格式只能在响应中包含一个句柄-类型对。显然，当MTU比默认值大时，包含的柄-类型对的数量也将随之增加。

        对于响应，另一个有的地方是同一个响应报文不能同时包含 16位与28位的UUID否则，每一个柄-类型对就要消耗一个额外的字节，使得默认MTU 响应中所能包含的16位UUID的数量减为4个。此外，标准属性服务器中的绝大多数 UUID都是16位的也极少会在一个响应中同时包含 16位与128位UUID此没有必要提供这种灵活性。

通用属性规范（The Generic Attribute Profile/GATT）

服务（service）发现

    有四种基本对象需要发现，客户端首先要发现首要服务，发现首要服务后隶属于该首要服务的其他信息都可以被发现。发现服务有三种途径：发现所有首要服务，按服务UUID发现首要服务，查找包含服务。

        1.发现所有首要服务，客户端可以使用按组类型读取请求，请求的句柄范围设为0x0001-0xFFFF，并把属性类型设为首要服务。

        2.按服务UUID发现首要服务，客户端可以使用按类型值查找请求，比如客户想要使用某个服务，但是不想列出其他服务的情况下。请求的句柄范围设为0x0001-0xFFFF，并把属性类型设为首要服务，并把数值设为想要获取的类型。

        3.查找包含服务，发现首要服务后，就能发现其他的次要服务和引用服务，客户端可以使用按类型读取请求（类型：0x2802）来查找一个包含声明，

特性（Characteristic）发现

        发现服务后，便可以发现每一个服务的特性。要获取完整的特性，需要发现特性和特性描述符。

        1.发现服务的所有特性。使用按类型读取请求（类型：0x2803），将句柄设置为该服务的句柄范围，并把类型设为特性。

        2.发现所有特性描述符。发现了特性声明后，便可以发现每一个特性的描述符。使用查找信息请求，将句柄范围设为该特性的句柄范围。

客户端发起规程

        对于特征，客户端可以执行四种操作：读取特征值，写入特征值，读取特征值描述符，写入特征值描述符。

服务器发起规程

        有两种GATT规程是由服务器发起的：通知，指示。

属性协议数据单元（ATT PDU）到GATT规程的映射