实战经验 | 关于连接参数更新进程后导致断连的问题分析

01 引言

通常客户在做低功耗蓝牙模块设计的时候，如果蓝牙模块在实际使用场景中和手持移动设备(如手机等)绑定使用的话，往往会非常注意蓝牙模块与不同品牌、不同型号的手机的兼容性测试。这些测试项目可能包括长时间连接状态的保持，频繁建立连接，或主动断连后再次建立连接等场景。本文描述的问题是客户在其兼容性测试中发现的一个比较典型的问题，即当从设备在与手机端处于连接状态下，从设备启动连接参数更新进程后，会导致断连的问题。由于是兼容性测试，测试设备，特别是作为主设备的手机来自不同的供应商，在兼容低功耗蓝牙协议的基础上，某些细节部分的差异难以避免。所以，本文只论述了该客户问题的分析过程及得出的结果，并不期望涵盖所有类似场景下导致断连的原因。

02 连接参数更新进程简述

低功耗蓝牙的核心规范中有规定，当主从设备建立连接后，可以通过启动特定的进程改变当前连接的相关参数，如连接间隔(ConnInterval)，从设备延迟(SlaveLatency)和监控超时(SupervisionTimeout)等。 

低功耗蓝牙的核心规范中定义了几个不同的连接参数更新流程，有的流程主设备和从设备都可以启动，有的流程只能由从设备或主设备启动。为避免引入过多对本文关注话题的无用信息，我们在这里只介绍一种由从设备启动的连接参数更新的流程。即由从设备通过调用L2CAP 层的命令的方式启动的连接参数更新流程。 

流程图如图 1 所示。流程图的前提条件是主从设备端之间已建立连接，从设备希望改变当前已建立连接的连接参数。 

整个流程的步骤解析如下： 

第一步：从设备发起 Connection Parameter Update Request，提交新的连接参数给主设备，希望主设备可以采用这些参数。主设备接收到从设备的 Request 后，会根据自身当前条件(是否能支持这些连接参数)决定是否接受请求。如果接受，则执行第二步；如不接受，则直接跳到第四步拒绝该 Request。 

第二步：主设备接受请求，给从设备发送链路层数据包LL_CONNECTION_UPDATE_REQ，该数据包中包含了主设备在分析了从设备在第一步中提交连接参数后，决定最终使用的目标连接参数，并约定在后续的特定连接事件开始使用新的连接参数。 

第三步：从设备在接收到 LL_CONNECTION_UPDATE_REQ 数据包后发送一个链路层的空包作为响应，并结束当前连接事件。 

第四步：主设备发送 L2CAP 层的 Connection Parameter Update Response 命令，作为对第一步中 Request 命令的回复，回复中的相关标志标明是接受(Accept)还是拒绝(Reject)之前的 Request 命令。如果是接受，则主从设备双方会在第二步中LL_CONNECTION_UPDATE_REQ 数据包中所指定的后续特定连接事件中开始使用新的连接参数，并成功完成连接参数更新过程。

图1.连接参数更新流程

03 客户可能的测试逻辑和问题现象描述

客户使用智能手机和 ST 的 BlueNRG LP 作为测试的主从设备。客户的兼容性测试中需要使用预设连接间隔和监控超时时间。为了在测试过程中可以实时调整相关参数，需要手机端作为主设备通过私有逻辑将新的连接参数通过低功耗蓝牙连接发送给从设备( BlueNRGLP ), 并由从设备启动上述的更新流程，以完成连接参数的更新并继续执行后续的其他测试项。 

问题现象： 

主从设备在完成上述流程第四步后，且主设备发送 Connection Parameter UpdateResponse 命令所给出的响应也是接受的情况下，主从设备在上述流程中第二步LL_CONNECTION_UPDATE_REQ 命令所指定的特定连接事件中开始采用新的连接参数时会发生断连。从设备重新进入广播状态。 

客户的疑惑点在于主从设备已经完成了上述连接参数更新的交互，意味着应该可以顺利切换到新的连接参数，没有道理会导致后续的断连，由于作为主设备的智能手机是某大品牌产品，怀疑 BlueNRG 的协议栈是否存在兼容性问题。

04 问题分析

根据问题复现时使用低功耗蓝牙抓包工具所抓取的 log 数据，做如下分析。

4.1.分析 LL_CONNECTION_UPDATE_REQ 数据包内容

4.1.1. 如图 2 所示，LL_CONNECTION_UPDATE_REQ 数据包内容，需要重点关注如下数据：

1. Event counter：29， 表示 LL_CONNECTION_UPDATE_REQ 发送时所在的连接事件编号为 29。

2. Instant：35：约定在第 35 个连接事件中，主从设备开始使用新的连接参数。

3. Interval：816(1020msec), 表示新的连接间隔为 1.02 秒。

4. Window Size/Window Offset：第 35 个连接事件中，主从设备开始使用新的连接参数进行第一次数据包交互时，接收、发送窗口的定时信息。

图2.LL_CONNECTION_UPDATE_REQ PDU 抓包数据

4.1.2. 从下图 3 中获取从连接事件 29 到从设备进入广播状态这个过程中每个连接事件及连接时间中数据包收发的时间戳。

图3.时间戳

从图 3 中可以看出：

1.从连接事件 29 到连接事件 34，连接间隔为 30ms，即旧的连接间隔。

2. 连接事件 35 中主设备的发包时间和连接事件 34 的开始时间差大大超过 30ms，所以可以再次确认是在连接事件 35，主从设备开始使用新的连接参数。

3. 从连接事件 35 开始及后续的 3 个连接事件中，只有主设备发送空包，从设备没有发送空包。

4. 由于新的连接参数的监控超时时间在客户的测试中为 4 秒，所以从设备没有发送空包的 4 个连接事件结束后，即发送了断连。然后，从设备重新开始发送广播包。

4.1.3. 如下图 4，通过分析抓包 LOG 中各个连接事件、即数据包发送的时间戳后发现：

1.通过 LL_CONNECTION_UPDATE_REQ 数据包中 transmitWindowOffset 计算出TransmitWindow 的开始时间点应该在 11.477925s

2. 从抓包的 log 信息中发现，主设备实际的发包时间点在 11.477909s，也就是主设备的发包时间先于蓝牙协议中规定的 TransmitWindow 的起始点，导致从设备无法接收到来自主设备的空包，从而无法在同一连接事件(连接事件 35 及后续的 3 个连接事件)中反馈一个空包，进而导致 4 秒监控超时，最终导致断连。从设备退出连接态后重新进入广播态。

图4.连接事件即数据包发送时间分析

05 小结

上述问题的根本原因是作为主设备的智能手机虽然完成了连接参数更新流程中主从设备之间的交互，但由于其在后续规划的连接事件，规划的射频任务的时间点的偏差而导致了断连。

导致低功耗蓝牙断连的可能原因有很多，上述的情况只是其中一种。本文的意图是介绍上述问题的分析过程，读者可以参照本文展现的分析方法、将其运用到类似问题的解决过程中。

通过对抓包 LOG 中的时间戳的分析，有很大机会可以帮助找到解决问题的突破口。