详解BLE连接建立过程

同一款手机，为什么跟某些设备可以连接成功，而跟另外一些设备又连接不成功？同一个设备，为什么跟某些手机可以建立连接，而跟另外一些手机又无法建立连接？同一个手机，同一个设备，为什么他们两者有时候连起来很快，有时候连起来又很慢？Master是什么？slave又是什么？什么又是Connection event和slave latency？希望这篇文章能帮助你回答上述问题。

BLE连接示例

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

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

上述即为大家直观感受到的“连接”，那么手机要与设备Nordic_HRM建立连接，具体包含哪些流程？他们为什么可以连接成功？下面给大家一一道来。

广播（advertising）

在手机跟设备B建立连接之前，设备B需要先进行广播，即设备B（Advertiser）不断发送如下广播信号，t为广播间隔。每发送一次广播包，我们称其为一次广播事件（advertising event），因此t也称为广播事件间隔。虽然图中广播事件是用一根线来表示的，但实际上广播事件是有一个持续时间的。

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

设备B不断发送广播信号给手机（Observer），如果手机不开启扫描窗口，手机是收不到设备B的广播的，如下图所示，不仅手机要开启射频接收窗口，而且只有手机的射频接收窗口跟广播发送的发射窗口匹配成功，手机才能收到设备B的广播信号。由于这种匹配成功是一个概率事件，因此手机扫到设备B也是一个概率事件，也就是说，手机有时会很快扫到设备B，比如只需要一个广播事件，手机有时又会很慢才能扫到设备B，比如需要10个广播事件甚至更多。

建立连接（connection）

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

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

图5：连接建立过程

注：图中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，定义如图5所示
Transmit window size，定义如图5所示
connect_req数据包完整定义如下所示

connect_req其实是在告诉advertiser，手机将在Transmit Window期间发送第一个同步包（P1）给你，请在这段时间里把你的射频接收窗口打开。设备B收到P1后，T_IFS时间后将给手机回复数据包P2。一旦手机收到数据包P2，连接即可认为建立成功。后续手机将以P1为锚点（原点），Connection Interval为周期，周期性地给设备B发送Packet，Packet除了充当数据传送功能，它还有如下两个非常重要的功能：

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

连接失败

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

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

Connection events

连接成功后，master和slave在每一个connection interval开始的时候，都必须交互一次，即master给slave发一个包，slave再给master发一个包，整个交互过程称为一个connection event。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 = 2），那么什么叫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定义了图11所示的角色。图11通过时间把observer，initiator和central串起来了，其实这三个角色是相互独立的，也就是说一个设备可以只支持observer角色，而不支持initiator和central角色。同样，图11也把advertiser和peripheral串起来了，其实advertiser和peripheral也是相互独立的，即一个设备可以只作为advertiser角色，而不支持peripheral角色。

图11：GAP角色