目录

BLE从机更新连接参数失败问题分析和解决... 0

背景介绍.... 2

问题排查和分析.... 2

进一步分析.... 4

解决方案.... 4

总结回溯.... 5

背景介绍

       BLE在动态功耗优化功能调整过程中，有一个BLE从机连接后120秒更新连接参数的机制。BLE从机连接后120秒进行判断连接参数，如果不是预期的参数，那么将发送预期连接参数更新。但是在实际测试过程中，从机更新连接参数经常出现失败，即发送的连接参数后没有更新成功，但是接口没有任何异常。比如，主机连接间隔是100毫秒，从机希望更新到150毫秒，但是从机只发起了150毫秒的更新请求，但是没有更新完成的回调和异常的错误打印，连接间隔依然还是100毫秒。

问题排查和分析

       对于这种情况，首先需要确认连接参数更新接口是否存在缺陷。所以进行下面2种方式进行验证。

1. 从机和主机关系不变，在更新失败后，再次使用CLI命令进行手动更新确认连接参数更新机制。验证发现，手机更新都可以成功，确认底层的连接参数更新接口不存在问题；
2. 主机连接参数功能开启，整个更新连接参数代码相同，但是主机的更新机制不同。在主机连接和本地认证完成后，进行连接参数更新。验证发现，主机连接参数更新也没有失败情况，初步确认整个连接更新代码应该是正常的。

       再次确认下整个从机更新连接参数的机制，因此打开debug信息，确认120秒定时器是否生效，连接参数的接口是否调用，以及相关参数是否正确。测试发现，上述过程都不存在问题，120秒后确实已经调用了底层的连接参数更新接口，同时参数也不存在问题。那么为什么手动更新是正常的，但是这种情况更新经常失败呢？

       怀疑是否和更新的时机有关系，即120秒这个时间点，具体验证如下。

1. 增加打印后120秒后连接参数更新没有失败；
2. 去掉打印后120秒后连接参数更新大概率失败；
3. 时间改成10秒后更新不会失败。

        从上述验证看，确认和120秒更新的时间有关系，改变时间（调整10秒或增加打印）确实可以恢复正常。那么120秒到底是什么原因导致异常呢？从机和主机上HCI的打印开启，确认是否从机正常发送了连接参数更新的请求报文。重新测试验证，发现HCI的日志如下，从机确认发送了连接参数更新，但是最终更新失败。从机发送的连接参数是符合更新预期，但是最终的更新结果显示失败，状态是“Different Transaction Collision”。同时，从机更新失败的情况下，主机上没有任何的HCI的信息，看起来没有收到数据。

 

       对该异常状态找AI分析了下，分析结果是在连接参数过程中有其他数据包存在冲突，怀疑过程中可能主机也在进行连接参数更新等。经过排查和log分析，可以确认应用不存在上述情况，从机也不会同时发送其他数据报文。所以也可以排除业务上不合理的设计导致的问题。这个异常状态也反馈原厂进行咨询，原厂也怀疑存在从机同时收到多个数据导致，出现连接更新，PHY更新，还有信道更新等。

       为了进一步确认是否有其他报文导致，对这个过程进行无线报文抓取和分析，异常部分的无线报文如下。LL_CONNECTION_PARAM_REQ报文是从机发送的连接参数更新请求报文，LL_REJECT_EXT_IND报文是主机回复的报文，说明此时主机拒绝更新连接参数。每次出现异常都是这种情况，所以可以确定问题点就在这里。

       主机发送这个异常命令的标准流程如下，这个是协议的标准流程，在一个事件还没有完成之前，不允许进行下一个事件。

        从上述抓包看，只有信道更新的报文，没有其他报文，难道就是信道更新导致的异常吗？通过抓包分析看，信道更新主机每隔4秒发送一次，也就是从机120秒的时候，刚好和第30次的信道更新一起发送，导致主机可能无法进行连接参数更新。这也能说明之前间隔10秒或者增加打印后不会出现的情况，为了验证这个情况，将定时器修改12秒，同样也是4秒的倍数，验证看确实也会存在同样的问题。如果将120秒改成123秒（不是4的倍数），测试发现确实也不会存在更新失败的情况。

进一步分析

       那么连接参数更新和信道更新的报文相差多少时间会出现问题呢？从上述分析看，已经明确是主机信道更新冲突，那么接下来再详细的分析下无线报文。连接参数更新前面一包信道表更新数据内容如下，数据包的event是1202，instant是1209。Instant表示同步这个信道表的event值，即当主机发送数据的event值是1209时使用本次的信道表。如果没有通信数据的情况下，一个空包event值累加1，这种情况下需要经过8*连接间隔的时间。

       此时，连接间隔的更新请求数据包的event值也是1202，对于主机来说，在刚发送LL_CHANNEL_MAP_IND报文（信道表更新）的时，马上接收到了连接参数更新请求。这情况下，对于主机来说无法处理连接参数更新事件，因为连接中的instant值正在信道更新中使用，需要在1209后才能释放。

       主机拒绝的报文中event值是1203。

       同样，如果连接参数可以正常更新的情况下，整个过程中instant的值是怎么变化的。下面是连接参数前面一包信道更新的报文，event是1161，信道生效在event是1169。

       从机连接参数更新请求的报文和主机回复参数更新报文的详细信息如下。主机连接更新请求时候event是1210，此时信道更新已经完成。主机要求在event是1219时，更新连接参数，即连接间隔150毫秒。

       主机和从机的空包中可以发现，当event是1219时，连接参数进行更新。在该值前，连接间隔是100毫秒，之后连接间隔调整到150毫秒。

解决方案

       上述情况和原厂讨论，这种情况属于正常状态反馈。同时，主机在instant参数尚未释放之前，没办法处理新的需要使用instant的协议，包括连接参数更新，PHY更新，信道更新等。因此有如下几个解决方案和优化建议。

1. 连接参数更新，PHY更新等全部由主机发起，主机主动发起的情况不会存在失败情况。但是实际使用过程中，从机也允许进行相关操作，因此不能从根本上解决问题；
2. 从机依然支持上述的连接参数更新操作，但是第一次需要错开这个4秒一次的信道更新机制，比如定时120秒修改成121等表示4的倍数，验证可以解决问题；
3. 另外从机上需要根据回调函数判断更新结果，增加对应的重发机制。

        下面是标准协议中对上述冲突问题的描述和说明，在实际测试中如果是IOS系统，出现冲突可能直接断开连接。

      

总结回溯

       从一个连接间隔更新失败的问题，逐步对问题进行分解和分析，对BLE底层机制有了更进一步的了解。在之前的设计中，BLE上尚未考虑连接间隔更新等相关操作，如果出现发送成功，回调没有的情况。因此，通过上述的探究和学习，后期对于类似的情况需要全盘在整理下，优化相关机制，将BLE的可靠性再提升一个台阶。