BLE数据传输丢包的分析

Posted 2023-03-14

参考技术A 像所有的网络传输协议一样，应用层能感知到的丢包有可能产生于应用层之下的所有层。

对于蓝牙BLE而言，进一步细化从机到主机的数据传输场景(假设使用的是Notify方式传输)，其数据传输路径为：

1、从机的应用层产生数据。

2、从机将数据从Host上位机转交给Controller下位机。

3、从机Controller通过调制器，将数据在连接事件的射频Tx阶段发出。

4、主机Controller同时开启射频Rx阶段，接收无线电波并通过解调器还原数字信号。

5、主机将数据从Controller下位机转交给Host上位机。

6、主机的应用层接收数据。

根据上面的流程，进一步分析一下可能产生数据丢包的环节。

在步骤2中，Host调用HCI函数将数据提交给Controller发送之前，会先将数据存放在Controller的数据缓冲区中，不同的蓝牙芯片这个缓冲区的大小不同，比如Ti CC2541的射频缓冲区只有4个PDU(4*20字节)的大小。在缓冲区存满后继续调用HCI的Notify等函数会返回缓存区满状态位标识。这是第一个有可能产生丢包的位置，若缓冲区满且开发者没有对此状态位进行校验，则应用层产生的数据会在传递给链路层之前丢失。

在步骤3、4中，从机的Controller在连接事件的Tx阶段，会通过射频依次发送缓冲区数据，并在下一个Rx阶段根据捕获和解析对端主机的数据包，从其链路层报头中读取NESN来确认其在上一个Tx阶段发送的数据包是否被对端主机链路层正确接收。由于链路层数据包序列号校验机制(SN和NESN)和重传机制的存在，基本可以保证数据在物理层和链路层阶段不会产生丢包，这跟互联网的传输层TCP协议校验数据包序列和完整性基本类似。

之所以上面用“基本”二字，是因为这里还是存在第二个有可能产生丢包的位置。由于BLE中使用的CRC校验是弱CRC，其只能保障传输字节的全部偶数位和部分奇数位不产生错误，并无法保证所有数据在传输过程中不出错。那么一个可能性极小的场景是：CRC弱校验通过，但实际上NESN出现了错误，而将本来应该是0的位识别成了1，或者相反。而这个位差错让本来应该是错误的序列号交替变成了正确的。

在步骤5中，主机将数据从Controller向上派发到Host，并转到应用层触发回调通知。这里是第三个可能产生丢包的地方。原因同步骤2，但这里还有一点小区别，就是notify跟indicate的区别(反向传输中的write with/without response也是同理)，其本质区别是数据接收成功的判断标志是以链路层确认为准还是以应用层确认为准。前者是notify采用的方式，而后者是indicate采用的方式。可见如果采用notify做数据传输，链路层到应用层这一步依然是有丢包的可能，比如链路层的数据传输速率大于应用层的回调函数中对数据处理的速率，导致Host中数据缓冲区持续增长，当缓冲区满后，主机的Controller将丢弃无法继续保存的数据，并不会通知对端设备重传。

而indicate方式下，每一个数据包的成功确认都是以应用层回调处理执行完成为标志，而通常数据的逻辑处理是一个耗时的操作，并且由于数据是在连接事件内接受到，但同一个连接事件在开始的时候主从机两端的数据就已经准备好，由于连接事件的持续事件极短，在这段时间内Controller的所有工作都集中在射频的发射上，而不会从Host上位机接受数据和响应，甚至有的蓝牙芯片会有选项在这段时间内直接挂起CPU，以防止其他中断信号同步到达，干扰到射频数据的发送效率。所以在indicate方式下，一个数据包至少要横跨两个甚至更多的连接事件时长才可以确认到达，从而发送下一个数据包，这就是有响应的数据发送方式比无响应要慢的原因。

最后一点，由于android操作系统封装了蓝牙低层驱动和实现，以上的6个步骤即使都正确完成，也只是意味着Bluez或者Bluedroid这一层正确拿到了数据，但App要接收到这些数据还存在一个从操作系统到App的数据派发过程，indicate的数据确认是在App得到数据派发并执行完成回调后确认，但notify会在Bluedroid接受到数据后即完成链路层确认。而Bluedroid向App的数据派发又存在一个缓冲区，当蓝牙连接而App没有运行的情况下缓冲区满依然会产生丢包。(Android好像很难模拟这种情况，ios在通过调试器终止App进程的时候经常会造成蓝牙连接链路不同步断开)