BLE中的吞吐率分析
说明
吞吐速率是表示通信数据传输能力地关键指标。通过多年的发展，蓝牙技术的通信速率越来越来越高，吞吐率越来越大。随着蓝牙5.0协议的发布，最新的低功耗蓝牙最高支持2M的PHY，也就是2Mbps。但是实际应用中大多数BLE用户发现自己的蓝牙的数据吞吐率最高只有几百k甚至几十kbps，和宣传的1M/2M速率效果远远不及。本篇博客将对BLE中影响吞吐率的因素进行分析，并给出BLE吞吐率的计算方法和优化方向。
影响吞吐率的因素
PHY-1M/2M/LE Coded
PHY协议是蓝牙底层对通信速率基本的规定。在早期蓝牙协议中，规定了低功耗蓝牙以1Mbps的速率进行数据通信，即每秒传输一千个bit，速率为1kbps,我们称为1M PHY。随着蓝牙5.0的提出，新增了2M PHY的支持，即以2Mbps的速率进行通信。其中1M PHY为强制要求，2M PHY为可选功能。
这里注意是bps，即bit per second。换算为Byte per second需要除八，1Mbps=125KBps，2Mbps=250KBps。
LE Coded为蓝牙扩频技术的应用，通过使用不同的扩频因数（S=2 or S=8）将数据进行扩频通信。该技术会导致吞吐率极大的降低，但是会提高通信的抗干扰能力，从而增长通信距离。当扩频因数S=2时，速率为500kbps;当扩频因数S=8时，速率为125kbps。
相关LE Coded技术可参考我另外一篇博客，这里不作详细介绍。
连接间隔
一般情况下通信速率可以直接代表吞吐率，但前提是数据在通信周期中是一直都在收发的。但我们知道，在低功耗蓝牙中，数据只有在连接事件中才会进行收发，大部分时间都在为了低功耗而进行休眠。
在连接事件中才进行数据的收发，连接事件的间隔事件称为连接间隔。这个时间以7.5ms为单位，以最低7.5ms、15ms、22.5ms、30ms递增直到最高2S。连接间隔越短，占用的带宽越大，实际的数据吞吐率也就越能接近收发机的通信速率（1M/2M PHY）。但是间隔越短势必也会使得收发机工作时间越长，因此功耗也就越高。实际应用中需要设计者对其进行权衡和取舍。
数据包交换
我们知道，在蓝牙连接事件内，主机和从机轮流交换数据包以实现数据收发。哪怕没有数据要交换，也会至少相互交换一个空包用于保持连接。
但如果有很多数据交换，那就会一直交换直到数据交换完。如果一次连接事件交换不完数据，那就等下一次连接事件继续交换，直到数据传输完成。
一般来讲连接间隔越长，那么每个连接事件里能用于进行主从设备进行数据包交换的时间就越多，设备就可以进行更多次的数据包交换，这样即使连接间隔较长也能保证高数据吞吐率。但是实际上由于设备硬件堆栈空间的限制或者操作系统的设定，一般的蓝牙设备可能单个连接事件内只允许交换有限次数的数据包就会停止，直到下一次连接间隔才会继续进行数据交换。
帧间隔时间
在连接时间内，主从机进行数据包交换，交换包之间有一段固定的间隔时间，称为帧间隔时间IFS，该时间固定为150us。
开销
一般来讲，通信时候的数据包并非完全都是有效信息，有一部分内容是用于协议自身的开销，例如设备地址，校验码、前导码（如果启用加密认证，还需加上MIC）之类。
而用户真正传递的数据被放在PDU段中的ATT Payload中。在计算数据吞吐率时，仅以传输的ATT Payload作为有效载荷，其他内容对于实际用户而言是无用的。在交换数据包时候，交换的次数越多，开销花的时间越多。为了提高数据传递效率，提高有效载荷的长度是很有意义的。如果数据能在一包内就传输完成，就不需要传第二包，再花费更多的开销时间。
DLE功能
在4.2版本前的蓝牙，PDU中的Payload段的大小规定为为0-27byte，其中L2CAP Header和ATT Header固定占用7byte,所以有效负载的长度为0-20byte。
在4.2版本后，为了提高数据传输能力，新增数据长度扩展（DLE）功能，可以允许Payload超出27byte限制，最大可设置为251byte。即有效载荷ATT Payload的长度可以增加到244byte。
如果实际数据量没有那么多，达不到有效载荷的最大长度的话，会有多少发多少。例如要传100byte数据，就传100byte数据，并不要求一定发满244byte。
ATT MTU
ATT MTU 确定发射器和接收器可以处理的最大数据量，以及它们可以保存在缓冲区中的数据量，他表征了设备可以收发多大长度ATT Data段。ATT MTU最小为23byte，即4.2版本以前蓝牙ATT Data段最大的长度。4.2版本后ATT MTU并没有上限，这个根据硬件厂商自身的堆栈大小而决定，一般典型值为512byte。
ATT MTU参数影响着连接事件内可交换的数据包数量。例如ATT MTU选择为247，开启DLE将刚好使得一个包就能把堆栈所有的数据传输完，蓝牙事件只需进行一次数据交换、只付出1个包的开销时间。如果不开启DLE，那么一包只能包含20byte有效载荷，需要进行至少十多次交换才能传完数据，也就是需要付出十多次的花销时间。这样对比，传输效率将会由于开销增加而降低，吞吐率也随之降低。
同理如果MTU设置为512，那么DLE功能开启了也无法一个包发完数据，需要再进行一次数据包交换。但MTU设的大可以让用户在软件端一次性写入更多的数据进入堆栈，不需要自己手动进行分包，厂商协议栈会自行处理。
GATT操作类型
在GATT协议栈，操作方式的不同也会影响到数据吞吐率。一般无响应要求的比有响应要求的吞吐率更高，例如
- write with respond 和 write without respond
- notification 和 indication
比如Notification无需对方应答
而Indication需要应答
有响应要求的，从机将返回响应包，响应包会导致额外的开销。
吞吐率计算示例
在了解上述相关影响吞吐率的因素后，我们便可以开始进行吞吐率的理论计算：
在开始计算前，我们先规定通信的空中包为常见的非编码格式，且不带加密（即不带MIC），使用1M PHY进行通信，操作方式为Write without Respond。
可以看到，一个基本的非编码的包格式如上，其中包括：
- Preamble：1字节（1M PHY）/2字节（2M PHY）
- Access Address：4字节
- PDU：2-257字节
- MIC：4字节（可选，启用加密时才会用）
- CRC：3字节
其中PDU为数据段，长度最小为2byte，最大257byte。其中ATT Payload为有效载荷，为传输的有效数据。
1. 空包传输时间计算
首先我们需要计算传输一个空包要花费的时间，对于一个空包，其ATT Data长度为0，即PDU只有2byte。
- 则一个空包的总长度为：
1 byte（1M PHY Preamble）+4 byte（Access Address）+2 byte（PDU）+3 byte（CRC）=10 byte =80 bit
- 所需传输时间为
1M PHY：80 bit / 1Mbps ≈ 80 us
如果使用2M PHY，则preamble为2byte，包总长为11byte/88bit，需要的传输时间为
=88 bit / 2Mbps ≈ 44 us
2. 数据包传输时间计算
然后我们计算数据包的传输时间，这里我们按一个数据包能传输的最大长度的PDU来计算，根据DLE的使能，可以分为两种情况
- 不使能DLE，即Payload段最大长度为27btye，PDU长度则为29byte：
1 byte（1M PHY Preamble）+4 byte（Access Address）+29 byte（PDU）+3 byte（CRC）=37 byte =296bit
所需传输时间为：296bit / 1Mbps ≈ 296us
- 使能DLE，即Payload段最大长度为251byte。PDU长度为253byte：
1 byte（1M PHY Preamble）+4 byte（Access Address）+253 byte（PDU）+3 byte（CRC）=261 byte =2088 bit
所需传输时间为：2088 bit / 1Mbps ≈ 2088 us
注意不带加密的数据包是不需要MIC段的，因此PDU不需要额外加四byte
3. 数据包交换时间计算
当用户以Write without Respond方式传输数据时，主机给从机发送数据，从机无需进行应答。
- 在使能DLE情况下，进行一次数据包交换的时间为：
主机给从机发数据包时间 + IFS + 从机给主机发空包时间 + IFS = 2088us + 150us + 80us + 150us =2468us
一次能传输244byte ATT payload
- 在不使能DLE功能，进行一次数据包交换的时间为：
80us + 150us + 296us + 150us = 676 us
一次能传输20byte ATT payload
注意:
- 如果是带响应的方式传输数据，将多一轮从机向数据发送响应包的数据交换，这会使吞吐率大大降低。
- 倘若由于厂商性能限制，ATT MTU并不能设置大于247的话，即便使能了DLE功能，也需要根据MTU设定值重新计算数据包传输时间。
4. 数据包交换次数计算
一个连接间隔内的主从数据包交换次数的计算并非简单的连接间隔时间处于数据包交换时间。由于硬件厂商的堆栈大小设计差异，IOS和安卓系统对蓝牙协议栈实现不同，这个次数往往不是那么好计算。不过话虽如此，我们还是大致能计算出一个理论值作为参考标准。
假设最小连接间隔为7.5ms，并且ATT MTU设置为247，硬件堆栈无限制：
- 不使能DLE功能，，则可以进行：
7500us / 676us ≈ 11.1
也就是11次左右。可以进行传输的有效数据为
11 * 20 byte = 220 byte
- 使能DLE功能，则可以进行：
7500us / 2468us≈ 3.03
也就是3次左右。可以进行传输的有效数据为
3 * 244 byte = 732 byte
这里要注意，由于信号在空间中传输也是要花时间的，距离越远所需时间越长，因此往往实际可用的数据交换时间是比理论要少的。例如上述理论计算上述开启DLE功能可以交换3次，但可能实际上交换两次后剩下的时间就不够第三次了。那么在这段连接事件里就只会进行两次数据包交换。
5.吞吐率计算
基于上述结论我们可以得出，当连接间隔为7.5ms，ATT MTU为247时：
- 使能DLE功能，吞吐率约为：
传输有效数据量 / 单位传输时间 = 732byte / 7.5ms =97.6kBps,即780.8kbps
- 不使能DLE功能，吞吐率约为
220byte / 7.5ms =29.3kBps，即234.6kbps
至此，我们就得到了1M PHY，7.5ms连接间隔，Write without Respond方式通信的理论吞吐率计算。
注意，1Kbyte = 1000byte，1Bps为1byte/s，1bps为1bit/s。
基于nRF52开发板的测试结果
目前各家BLE厂商都推出了自己平台的测试例程和测试报告，这里我们以nRF52开发平台为例，对蓝牙吞吐率进行测试实践，用以和理论计算做对比。
这些测试基于Nordic Semiconductor提供的演示应用程序运行，并在此博客文章中进行了介绍吞吐量和远程演示
该示例的源代码可在此处的 GitHub 页面上找到。
示例 1（PHY：1 M，ATT MTU = 23 Byte，DLE：使能，连接间隔：7.5 ms）
- 测试结果：
吞吐量：232.29 Kbits/s
- 理论计算：
将 MTU 设置为 23 字节时，DLE 不会真正影响数据吞吐量和数据包大小。
因此吞吐率的计算结果为前面计算得到的234.6kbps。可以看到，计算值和测量值非常接近。
示例 2（PHY：2 M，ATT MTU = 23 Byte，DLE：使能，连接间隔：7.5 ms）
- 测试结果：
吞吐量：307.96 Kbits/s
- 理论计算：
2M PHY会使得数据包的Preamble多一个字节，因此数据包的大小要全部加1
- 空包长度变为：
2 byte（2M PHY Preamble）+4 byte（Access Address）+2 byte（PDU）+3 byte（CRC）=11 byte =88 bit
传输时间为88bit / 2Mbps = 44us
- 数据包长度边为：
2 byte（2M PHY Preamble）+4 byte（Access Address）+29 byte（PDU）+3 byte（CRC）=38 byte =304bit
传输时间为304 / 2Mbps = 152us
- 数据包交换时间变为：
152us +150us + 44us + 150us = 496us
- 数据包交换次数变为：
7.5ms / 496us = 15.12
- 吞吐率计算，交换次数取15次，ATT payload为20byte:
15 * 20 byte = 300 byte
300byte / 7.5ms = 40 kBps = 320 kbps
倘若交换次数取14次，则吞吐率算得299kbps。可以看到实际上的数据包交换次数为理论值14次和15次的中间值，说明实际的数据包交换次数的分布概率是14和15次各占50%左右。
示例 3（PHY：1 M，ATT MTU = 158 Byte，DLE：使能，连接间隔：7.5 ms）
- 测试结果：
吞吐量：478.36 Kbits/s
- 理论计算：
-
空包传输时间为80us
-
数据包长度边为：
1 byte（1M PHY Preamble）+4 byte（Access Address）+164 byte（PDU）+3 byte（CRC）=172 byte =1376bit
传输时间为1376 / 1Mbps = 1376us
- 数据包交换时间变为：
1376us +150us + 80us + 150us = 1756us
- 数据包交换次数变为：
7.5ms / 1756us = 4.27
- 吞吐率计算，交换次数取4次，ATT payload为155byte:
4 * 155 byte = 620 byte
620byte / 7.5ms = 82.7 kBps = 661.3 kbps
倘若交换次数取3次，则吞吐率算得496kbps。这里可以看到虽然理论算的4次，但实际基本都是只进行了3次交换。
示例 4（物理层：2 Mbps，ATT MTU = 247 Byte，DLE：使能，连接间隔：7.5 ms）
- 测试结果：
吞吐量：992.07 Kbits/s
- 理论计算：
2M PHY会使得数据包的Preamble多一个字节，因此数据包的大小要全部加1
- 空包长度变为：
2 byte（2M PHY Preamble）+4 byte（Access Address）+2 byte（PDU）+3 byte（CRC）=11 byte =88 bit
传输时间为88bit / 2Mbps = 44us
- 数据包长度边为：
2 byte（2M PHY Preamble）+4 byte（Access Address）+253 byte（PDU）+3 byte（CRC）=262 byte =2096bit
传输时间为2096 / 2Mbps = 1048us
- 数据包交换时间变为：
1048us +150us + 44us + 150us = 1392us
- 数据包交换次数变为：
7.5ms / 1392us = 5.38
- 吞吐率计算，交换次数取5次，ATT payload为244byte:
5 * 244 byte = 1220 byte
1220byte / 7.5ms = 162.7 kBps =1301.33 kbps
倘若交换次数取4次，则吞吐率算得1041kbps。这里可以看到虽然理论算的5次，但实际基本都是只进行了4次交换，甚至有时候可能只进行了3次。
示例 5（物理层：2 Mbps，ATT MTU = 247 Byte，DLE：使能，连接间隔：50 ms）
- 测试结果：
吞吐量：1322.33 Kbits/s
- 理论计算：
示例5和示例4区别只在于连接间隔变长，数据包交换时间不变，只需重新计算交换次数即可：
- 数据包交换次数变为：
50ms / 1392us = 35.92
- 吞吐率计算，交换次数取35次，ATT payload为244byte:
35 * 244byte = 8540byte
8540byte / 50ms = 170.8kBps = 1366.4kbps
结果与实际接近，说明基本上就是按35次进行数据交换。
示例 6（物理层：2 Mbps，ATT MTU = 247 Byte，DLE：使能，连接间隔：400 ms）
- 测试结果：
吞吐量：1371.82 Kbits/s
- 理论计算：
同示例5:
- 数据包交换次数变为：
400ms / 1392us = 287.35
- 吞吐率计算，交换次数取287次，ATT payload为244byte:
287 * 244byte = 70028 byte
70028 byte / 400 ms = 175.07kBps = 1400.56kbps
结果与实际接近，说明基本上就是按287次进行数据交换。
如何优化吞吐率
根据我们上述理论计算和实际测试，在研究如何提高吞吐率时候可以考虑如下优化方向：
- 使能 DLE
只对支持4.2版本及以后的蓝牙协议的设备有效。 - 使用2M PHY
只对支持5.0版本及以后的蓝牙协议的设备有效，这个功能还能降低功耗。 - 使用notification和Write without Respond
无需应答将使数据包交换次数大大减少，降低无效开销。
- ATT MTU 设置大于247
这将使每次数据包交换都能携带最多的有效负载数据。
-
合理选择连接间隔
合理的选择连接间隔，使尽可能多地产生数据包交换。这个理论计算的结果并不准确，还是应该通过实际测试来摸清硬件设备的性能。另外过长的连接间隔会导致响应速度慢，而过短地连接间隔也会导致功耗急剧上升，需要设计者权衡响应速度和功耗之间地关系。
总结
相关地理论计算往往和实际有一定偏差，干扰、重传、通信距离、设备性能等因素也会对吞吐率产生一定影响。但不管怎么样，这至少给予了我们一个参考预期，让我们对实际结果进行分析研究。
参考资料
- Nordic Throughput and long-range demo
- Maximizing BLE Throughput on iOS and Android
- Maximizing BLE Throughput Part 2: Use Larger ATT MTU
- Question: How do I calculate throughput for a BLE link?
- Question: How to calculate effective throughput in nRF52
- [Bluetooth 5 speed: How to achieve maximum throughput for your BLE application](蓝牙 5 速度：如何实现最大吞吐量 (novelbits.io))