BLE数据传输丢包的分析

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

对于蓝牙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进程的时候经常会造成蓝牙连接链路不同步断开)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,688评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,559评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,749评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,581评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,741评论 3 271
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,684评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,122评论 2 292
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,847评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,441评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,939评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,333评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,783评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,275评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,830评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,444评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,553评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,618评论 2 249

推荐阅读更多精彩内容

  • 从三月份找实习到现在,面了一些公司,挂了不少,但最终还是拿到小米、百度、阿里、京东、新浪、CVTE、乐视家的研发岗...
    时芥蓝阅读 41,986评论 11 349
  • 个人认为,Goodboy1881先生的TCP /IP 协议详解学习博客系列博客是一部非常精彩的学习笔记,这虽然只是...
    贰零壹柒_fc10阅读 5,010评论 0 8
  • 简介 用简单的话来定义tcpdump,就是:dump the traffic on a network,根据使用者...
    保川阅读 5,900评论 1 13
  • 高中同学聚会之老生重弹 时光飞逝,如白驹过隙。转眼数十年如白驹过隙,弹指一挥间,我们,从天真懵懂的少年,迈入了...
    焰归来阅读 437评论 3 6
  • 向地平线以内 升起的太阳 和煦而饱满的阳光 映着 闪电一样掠过的 骄傲和泪水 倚在季节眉头 等待召唤的光辉 像一匹...
    倾慕的荸荠阅读 129评论 0 0