[BLE]详解BLE连接建立过程

转载：

https://www.cnblogs.com/iini/p/8972635.html

BLE连接示例

假设我们有一台手机A（以安卓手机为例），一个设备B（设备名称：Nordic_HRM），如下所示，我们可以通过安卓设置菜单里面的蓝牙界面，让两者连接起来。

1. 打开安卓设置菜单
2. 选择“蓝牙”条目
3. 打开蓝牙
4. 等待系统搜索结果，不出意外的话，设备“Nordic_HRM”会出现在结果列表中
5. 点击“Nordic_HRM”，手机将与此设备建立连接
   

广播（advertising）

在手机A(Observer)跟设备B建立连接之前，设备B需要先进行广播，即设备B（Advertiser）不断发送如下广播信号，t为广播间隔。每发送一次广播包，我们称其为一次广播事件（advertising event），因此t也称为广播事件间隔。虽然图中广播事件是用一根线来表示的，但实际上广播事件是有一个持续时间的，蓝牙芯片只有在广播事件期间才打开射频模块，这个时候功耗比较高，其余时间蓝牙芯片都处于idle状态，因此平均功耗非常低，以Nordic nRF52810为例，每1秒钟发一次广播，平均功耗不到11uA。

上面只是一个概略图，按照蓝牙spec，实际上每一个广播事件包含三个广播包，即分别在37/38/39三个射频通道上同时广播相同的信息，即真正的广播事件是下面这个样子的。

设备B不断发送广播信号给手机（Observer），如果手机不开启扫描窗口，手机是收不到设备B的广播的，如下图所示，不仅手机要开启射频接收窗口，而且只有手机的射频接收窗口跟广播发送的发射窗口匹配成功，而且广播射频通道和手机扫描射频通道是同一个通道，手机才能收到设备B的广播信号。也就是说，如果设备B在37通道发送广播包，而手机在扫描38通道，那么即使他们俩的射频窗口匹配，两者也是无法进行通信的。由于这种匹配成功是一个概率事件，因此手机扫到设备B也是一个概率事件，也就是说，手机有时会很快扫到设备B，比如只需要一个广播事件，手机有时又会很慢才能扫到设备B，比如需要10个广播事件甚至更多。

建立连接（connection establishment）

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

上图的交互流程比较粗略，为此我们引入下图，以详细描述连接建立过程。

注：图中M代表手机，S代表设备B，M->S表示手机将数据包发给设备B，即手机开启Tx窗口，设备B开启Rx窗口；S->M正好相反，表示设备B将数据包发给手机，即设备B开启Tx窗口，手机开启Rx窗口。

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

• Transmit window offset
• Transmit window size
• connect_req数据包完整定义如下所示
  

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

1. 同步手机和设备的时钟，也就是说，设备每收到手机发来的一个包，都会把自己的时序原点重新设置，以跟手机同步。
2. 告诉设备你现在可以传数据给我了。连接成功后，BLE通信将变成主从模式，因此把连接发起者（手机）称为Master或者Central，把被连接者（之前的Advertiser）称为Slave或者Peripheral。BLE通信之所以为主从模式，是因为Slave不能“随性”给Master发信息，它只有等到Master给它发了一个packet后，然后才能在规定的时间把自己的数据回传给Master。

连接失败

有如下几种典型的连接失败情况：

1. 如果slave在transmit window期间没有收到master发过来的P1，那么连接将会失败。此时应该排查master那边的问题，看看master为什么没有在约定的时间把P1发出来。
2. 如果master在transmit window期间把P1发出来了，也就是说master按照connect_req约定的时序把P1发出来了，但slave没有把P2回过去或者没有在超时时间内把P2回过去，那么连接也会失败。此时应该排查slave这边的问题，看一看slave为什么没有把P2回过去
3. 如果master把P1发出来了，slave也把P2回过去了，此时主机或者从机还是报连接失败，这种情况有可能是软件有问题，需要仔细排查master或者slave的软件。
4. 还有一种比较常见的连接失败情况：空中射频干扰太大。此时应该找一个干净的环境，比如屏蔽室，排除干扰后再去测试连接是否正常。

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，以提高吞吐率。综上所述，连接成功后的通信时序图应该如下所示：

图7： 连接成功后的通信时序图（每个connection event只发一个包）

图9： 连接成功后的通信时序图（ connection event可能发多个包）

图10：connection event细节图

Slave latency

图10中出现了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才上报，直接像正常情况进行传输即可，这样既节省了功耗，又提高了数据传输的实时性。

GAP层角色总结

对上面提到的手机和设备B，在BLE通信过程中，随着时间的推移，他们的状态在发生变化，两者的关系也在发生变化，为此蓝牙spec根据不同的时间段或者状态给手机和设备B取不同的名字，即GAP层定义了如下角色：

• advertiser。 发出广播的设备
• observer或者scanner。可以扫描广播的设备
• initiator。能发起连接的设备
• master或者central。连接成功后的主设备，即主动发起packet的设备
• slave或者peripheral。连接成功后的从设备，即被动回传packet的设备
  

通过时间把observer，initiator和central串起来了，其实这三个角色是相互独立的，也就是说一个设备可以只支持observer角色，而不支持initiator和central角色。同样，图11也把advertiser和peripheral串起来了，其实advertiser和peripheral也是相互独立的，即一个设备可以只作为advertiser角色，而不支持peripheral角色。