蓝牙5速度：如何为BLE应用程序实现最大吞吐量

介绍

在有关Bluetooth 5的系列的第二篇文章中，我们介绍了提高2倍速度的新功能以及BLE应用程序的吞吐量的总体概述（上一篇文章全面介绍了Bluetooth 5的新功能，更具体地说，涵盖了增加的广告容量功能）。

首先，我们需要了解，公布的速度（1 Mbps和新的2 Mbps）只是理论上的速度，在降低应用程序吞吐量时会降低速度。这是由于多种原因，我们将在下一部分中进行介绍。

蓝牙5“ 2倍速”功能需要硬件更新，因此较旧的设备/芯片/模块将不支持此功能。同样重要的是要注意，为了实现更高的吞吐量，您将需要两个BLE设备相互通信以支持新的LE 2M PHY（这使得以更高的速率传输数据成为可能）。

新的LE 2M PHY和原始的LE 1M PHY都被称为未编码PHY，因为它们每数据位使用1个符号表示（与使用2个符号或8个符号的新LE编码PHY相比）每位数据的符号表示）。

另一个需要注意的重要事项是，在使用较高速度的PHY时，实际上可以实现较低的功耗（假设您传输的数据量相同）。这是因为减少了无线电接通时间而没有增加发射功率。反过来，这也改善了与2.4 GHz频谱内其他无线技术的共存（也由于减少了无线电接通时间）。

在这篇文章中，我们将介绍：

• BLE期望的实际吞吐量是多少？
• 蓝牙5的新型2M PHY用于数据传输
• 影响/确定数据吞吐量的因素有哪些？
• 您如何计算应用程序数据吞吐量？
• 如何最大程度地提高数据吞吐量？
• 使用两个nRF52系列开发套件测试，测量和计算数据吞吐量

为什么不可能达到BLE的理论速度？

1 Mbps（LE 1M PHY），2 Mbps（LE 2M PHY），125 kbps和500 kbps的数据速率（分别使用S = 8和S = 2的LE编码PHY）是无线电的速率传输数据，但是由于以下原因，这对于应用程序吞吐量而言是无法实现的：

• 每个连接间隔的数据包数限制
• 数据包之间的帧间间隔（IFS）延迟（150 us）
• 即使没有可用数据传输，也需要从设备发送空数据包
• 数据包开销–并非数据包中的所有字节都用于有效负载

为了更好地理解这些因素并了解影响应用程序吞吐量的因素，我们必须更深入地研究数据包格式。下图显示了LE 1M PHY和2M PHY数据包的外观：

我们感兴趣的部分（以及真正定义应用程序数据的部分）是ATT Payload。从图中可以看出，Bluetooth Low Energy中的每一层都有大量开销字节。

• 在4.0和4.1中，最大ATT有效负载为20个字节。
• 在4.2和5.0中，一项称为数据长度扩展（DLE）的新功能允许ATT有效负载保存多达244个字节的数据。

蓝牙5速度：利用新的2M PHY达到2倍速度

了解在蓝牙5中使用新的LE 2M PHY的局限性非常有用：

• 不能用于传输主要广告（在主要频道上）。
• 可用于与数据包在相同通道上发送的辅助“辅助包”（37个通道：0-36）。
  要了解有关主要和次要广告的更多信息，请参阅我以前的博客文章：Bluetooth 5 Advertisements：您需要了解的所有内容。
• LE 1M是强制性的，而LE 2M是可选的。因此，并不是所有声称支持蓝牙5的芯片都可以处理更高的吞吐量。
• 广告和发现可以在LE 2M PHY上进行，然后使用LE 2M PHY在辅助广告通道上进行连接

应用程序数据从一台设备到另一台设备的传输通常发生在两台设备之间的连接期间。连接的设备可以通过PHY Update Procedure协商使用其他PHY  。建立连接后，它可以由从设备或主设备启动，但主设备将最终决定每个方向使用哪个PHY（基于从设备的请求和主设备支持的PHY）。

影响/确定数据吞吐量的因素

有一些因素会影响BLE应用程序的数据吞吐量。最常见的是：

• 使用的PHY（LE 1M与LE 2M与LE编码（S = 2或S = 8））
• 连接间隔
• 每个连接间隔的最大数据包数
• ATT最大传输单位（ATT MTU）
• 数据长度扩展（DLE）
• 操作类型：有响应写与无响应写，指示与通知
• 帧间间隔（IFS）：后续数据包之间的时间间隔（150 us）
• 传输空数据包
• 数据包开销–并非数据包中的所有字节都用于应用程序有效负载

让我们更详细地研究每个。

物理层

蓝牙5中基本上有三个PHY：原始1 Mbps PHY，新的2 Mbps和编码PHY（S = 2或S = 8）。所使用的PHY将直接影响您可以实现的最大数据吞吐量，因为它决定了通过空中发送数据包的实际原始数据速率。

每个连接事件的连接间隔和最大数据包

连接间隔有效地确定在一个连接事件期间可以发送多少个数据包。值越高，在一个连接事件中可以发送的数据包越多（某些设备达到特定限制）。

了解有关连接间隔的更多信息：BLE连接间隔和事件

但是，每个连接事件的数据包数量取决于设备和BLE堆栈，因此它受到限制，并且在特定设备上的设备和堆栈版本之间会有所不同。此值还取决于设备的操作，因此无线电可能必须参加其他事件，并且每个连接事件发送的数据包数量可能未达到堆栈允许的最大值。例如，该数字在iOS和Android之间有所不同，并且还取决于设备上运行的OS版本。

有时，根据用例动态更新连接参数很有用。但是，请记住，由主机决定是否接受这些建议或更新参数以适应这些建议。

数据长度扩展（DLE）

此功能允许数据包大小容纳更大量的有效负载（最大251个字节，而禁用时为27个字节）。蓝牙规范的版本4.2中引入了此功能。

ATT最大传输单位（ATT MTU）

ATT MTU确定发送方和接收方可以处理的最大数据量，以及它们可以保存在缓冲区中的最大数据量。

MTU值会影响开销数据量（特别是3个字节的ATT头）。允许的最小ATT MTU为27个字节。这最多允许20个字节的ATT负载（3个字节用于ATT头，4个字节用于L2CAP头）。

每个规格的MTU值没有上限，但使用的特定堆栈可能有其自身的局限性。例如，如果启用DLE，则最多可以传输251 – 4 = 247个字节（扣除L2CAP标头的大小）。考虑了ATT头（3个字节）之后，剩下的244个字节用于实际的ATT有效载荷数据。如果MTU至少为247个字节，则MTU将适合一个单个数据包。如果MTU大于247个字节，则MTU将跨越多个数据包，从而导致吞吐量下降（由于数据包开销和数据包之间的时序）。

有效的MTU由客户端和服务器支持的ATT MTU的最小值确定。例如，如果客户端支持100字节的ATT MTU，并且服务器响应它支持150字节的ATT MTU，则客户端将决定从其上用于连接的ATT MTU为100字节。

操作类型：有响应写与无响应写，指示与通知

如果需要高吞吐量，那么我们可以使用无响应或通知的写入将数据从客户端传输到服务器，再从服务器传输到客户端。这些操作消除了其他设备确认数据接收并在发送下一个数据块之前做出响应的需要。

帧间间隔（IFS）：连续数据包之间的时间延迟（150 us）

根据蓝牙规范：

4.1.1帧间空间

同一通道索引上两个连续数据包之间的时间间隔称为帧间空间。它定义为从前一个数据包的最后一个比特的末尾到后一个数据包的第一个比特的开始的时间。
帧间空间指定为“ T_IFS”，并且应为150μs。

传输空数据包

如果接收数据的设备没有要发送的数据，则根据蓝牙规范，它仍然需要发送一个空数据包。

数据包开销

正如我们在数据包格式图中看到的那样，数据包包含一些开销数据，这些数据不会计入您的应用程序数据（ATT数据）。基本上，这些字节将占用您的传输数据速率的一部分，而不考虑作为应用程序数据的一部分发送的任何字节。

计算您的应用程序数据吞吐量

最大的问题是：我们如何计算应用程序吞吐量？

如前所述，有一些变量会影响数据吞吐量：

• 蓝牙版本和使用的PHY
• DLE：数据长度扩展–是否启用
• ATT MTU值
• 连接间隔
• 每个连接事件的最大数据包数
• 操作（带响应的写与不带响应的写，以及通知与指示）
• 帧间间隔（IFS）：150微秒

蓝牙版本和PHY确定原始数据传输速率。例如，如果我们使用的是蓝牙版本4.2和LE 1M PHY，则传输速率为1 Mbps。另一方面，如果我们使用S = 8的Bluetooth 5 LE编码PHY，则数据速率将降至125 kbps。

DLE，ATT MTU，连接间隔，每个连接间隔的最大数据包数，Operation和IFS都决定了实际数据传输所用的无线电时间的一部分。

数据包格式在实际要传输的数据中有很大的作用。LE 1M PHY和LE 2M PHY都具有相似的数据包格式。LE编码PHY的数据包格式有很大不同，因此我们将分别研究这两种情况。

LE 1M PHY和LE 2M PHY计算

返回参考LE未编码PHY的数据包格式：

每个PHY的开销量略有不同。对于1M PHY，前同步码为1字节，对于2M PHY，前同步码为2字节。MIC字段是一个可选字段，仅用于加密连接。为简单起见，我们仅考虑未加密的连接–对于加密的情况，它仅增加4个字节的开销。

对于LE编码PHY，数据包格式如下所示（从Bluetooth 5.0规范第6卷第B部分第2.2节）：

计算吞吐量的步骤（以Mbps为单位）：

为了简单起见，我们假设以下内容：

• 未启用加密（数据包中不包含MIC字段）
• 我们对一个方向（例如，主站到从站）的吞吐量感兴趣，因此我们假设另一个方向仅传输空数据包
• 没有响应的写入（这将有助于在传输大量数据时最大化吞吐量

脚步：

1. 确定正在使用的PHY并记下原始数据传输的速率，
   例如1M PHY-> 1 Mbps，编码PHY和S = 8-> 125 kbps
2. 确定从接收器发送一个数据包和空包所花费的时间。
   一个数据包可以发送的时间将包括以下时间：

    

   Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据包的时间+ IFS。
   
   空数据包传输时间可以计算如下：

   传输空数据包的时间=空数据包大小/原始数据速率

   
   空数据包将包含以下字段：

   前导码+访问地址+ LL标头+ CRC。

   对于1M PHY，前同步码将为1字节，因此空数据包的总大小= 1 + 4 + 2 + 3字节= 10字节= 80位。
   
   （对于2M PHY，空包的大小将为 88位， 因为Premable为2字节而不是1字节）。

   基于此，传输空的1M PHY数据包的时间将为：

   传输空数据包的时间=空数据包大小/原始数据速率= 80位/每秒1兆位= 80微秒

   
   数据包将包含包格式图中列出的所有字段，但MIC字段除外（禁用加密）。

   数据包传输时间=数据包大小/原始数据速率

   
   如果启用了DLE，并且ATT MTU等于一个数据包中允许的最大字节数：247字节，那么我们可以计算出 数据包大小为：

   数据包大小= 1 + 4 + 2 + 4 + 247 + 3字节= 265字节= 265 * 8位= 2088位

   传输数据包的时间= 2088位/ 1 Mbps = 2,088微秒

   
   Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据包的时间+ IFS = 80 + 2 * 150 + 2088 = 2,468微秒
   
   为了进行比较，在2M PHY的情况下，它是：

   Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据数据包的时间+ IFS = 88/2 + 2 * 150 +（2 + 4 + 2 + 4 + 247 + 3）* 8/2 = 1,392微秒
   
   当启用DLE并且ATT MTU设置为小于247时，我们最终会产生更多开销（因为现在大于ATT MTU的数据被拆分为更多数据包）。例如，假设我们将ATT MTU设置为158，那么为了传输244个字节的应用程序数据，我们将需要两个数据包而不是一个数据包，由于字节开销的增加和增加，导致吞吐量下降数据包之间的IFS。在另一种情况下，我们可能禁用了DLE（有效负载大小最大为27个字节），而ATT MTU大于27个字节。在这里，这还将导致需要为相同数量的数据发送更多的数据包，从而导致吞吐量下降。

   注意：LE编码PHY可以使用与我们上面使用的计算数据和空包大小相同的方法。

3. 找出在一个连接间隔内可以发送多少个数据包
   这种计算并不总是纯数学的-您将需要考虑所使用的堆栈和设备的限制。iOS和Android具有随操作系统版本而变化的最大值，因此并非总是很容易确定。也就是说，在MCU上，供应商的SDK通常会在其文档中列出最大数量。反复试验并弄清楚您的特定设备支持的内容也很有帮助。

    

   确定最大值后，就可以计算出在所选连接间隔内适合的最大理论数据包数量。例如，如果我们的连接间隔为7.5毫秒（规范允许的最小值），则对于上面的示例（使用1M PHY，启用了DLE）：

   每个连接间隔的最大数据包数= [连接间隔/ Data_Packet_Time]，其中[]舍入到最大整数（整数）每个连接间隔的最大数据包数= [7.5 * 1,000微秒/ 2,468微秒] = 3个数据包

   通常，此数字不切实际，因为在连续连接事件中发送的数据包之间存在时间延迟。因此，对于我们的示例，我们将使用2个数据包而不是3个数据包。

4. 一旦确定了每个连接间隔可以传输的最大数据包数量，就可以计算数据吞吐量：数据吞吐量=每个连接间隔的数据/连接间隔=每个连接间隔的数据包数量*每个连接间隔的数据大小数据包/连接间隔
   = 2 * 244 * 8位/ 7.5毫秒= 520533位/秒〜= 508 kbps

测试和计算两个nRF52开发套件之间的数据吞吐量

在本节中，我们将运行多个数据传输测试，使用我们之前描述的过程来计算吞吐量，然后将它们与开发板上运行的应用程序报告的测量吞吐量进行比较。这些测试基于Nordic Semiconductor提供的演示应用程序运行，并在此博客文章中进行了介绍：吞吐量和远程演示。

该示例的源代码可以在GitHub页面上找到。

情况1（PHY：1 Mbps，ATT MTU = 23字节，DLE：使能，连接间隔：7.5毫秒）

固件报告的数据吞吐量：

时间：经过36.11秒。
吞吐量：232.29 Kbits / s。
发送了1048580字节的ATT有效负载。

计算的数据吞吐量：

将MTU设置为23字节，DLE并不会真正影响数据吞吐量和数据包大小。

传输数据包的时间=数据包大小/原始数据速率= 1 + 4 + 2 + 4 + 23 + 3字节/ 1 Mbps = 37 * 8位/ 1 Mbps = 296微秒

Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据包的时间+ IFS = 80 + 150 + 296 + 150微秒= 676微秒

每个连接间隔的最大数据包数= [连接间隔/ Data_Packet_Time] = [7.5毫秒/ 676微秒] = [11.09] = 11个数据包
每个连接间隔传输的总数据= 11 * 20字节= 11 * 20 * 8位= 1760位

数据吞吐量=每个连接间隔/连接间隔传输的总数据= 1760位/ 7.5毫秒= 234.67 Kbits / s
如我们所见，计算值和测量值非常接近。

情况2（PHY：2 Mbps，ATT MTU = 23字节，DLE：使能，连接间隔：7.5毫秒）

固件报告的数据吞吐量：

时间：经过27.23秒。
吞吐量：307.96 Kbits / s。
发送了1048580字节的ATT有效负载。

计算的数据吞吐量：

传输数据包的时间=数据包的大小/原始数据速率= 2 + 4 + 2 + 4 + 23 + 3字节/ 2 Mbps = 38 * 8位/ 2 Mbps = 152微秒

Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据包的时间+ IFS = 44 + 150 + 152 + 150微秒= 496微秒

每个连接间隔的最大数据包数= [连接间隔/ Data_Packet_Time] = [7.5毫秒/ 512微秒] = [15.12] = 15个数据包
每个连接间隔传输的总数据= 15 * 20字节= 15 * 20 * 8位= 2400位

数据吞吐量=每个连接间隔/连接间隔传输的总数据= 2400位/ 7.5毫秒= 320 Kbits / s
如我们所见，计算值和测量值非常接近。

情况3（PHY：1 Mbps，ATT MTU = 158字节，DLE：启用，连接间隔：7.5毫秒）

固件报告的数据吞吐量：

时间：过去17.53秒。
吞吐量：478.36 Kbits / s。
发送了1048730字节的ATT有效负载。

计算的数据吞吐量：

传输数据包的时间=数据包大小/原始数据速率= 1 + 4 + 2 + 4 + 158 + 3字节/ 1 Mbps = 172 * 8位/ 1 Mbps = 1376微秒

Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据包的时间+ IFS = 80 + 150 + 1376 + 150微秒= 1756微秒

每个连接间隔的最大数据包数= [连接间隔/ Data_Packet_Time] = [7.5毫秒/ 1756微秒] = [4.27] = 4个包
每个连接间隔传输的总数据= 4 * 155字节= 4 * 155 * 8位= 4960位

数据吞吐量=每个连接间隔/连接间隔传输的总数据= 4960位/ 7.5毫秒= 661.33 Kbits / s

情况4（PHY：2 Mbps，ATT MTU = 247字节，DLE：启用，连接间隔：7.5毫秒）

固件报告的数据吞吐量：

时间：过去了8.45秒。
吞吐量：992.07 Kbits / s。
发送了1048712字节的ATT有效负载。

计算的数据吞吐量：

数据包传输时间=数据包大小/原始数据速率= 2 + 4 + 2 + 4 + 247 + 3字节/ 2 Mbps = 262 * 8位/ 2 Mbps = 1048微秒

Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据包的时间+ IFS = 44 + 150 + 1048 + 150微秒= 1392微秒

每个连接间隔的最大数据包数= [连接间隔/ Data_Packet_Time] = [7.5毫秒/ 1392微秒] = [5.39] = 5个数据包
每个连接间隔传输的总数据= 5 * 244字节= 5 * 244 * 8位= 9760位

数据吞吐量=每个连接间隔/连接间隔传输的总数据= 9760位/ 7.5毫秒= 1301.33 Kbits / s

注意：在后两种情况下，每个连接间隔的数据包数量很小，我们计算和测量的差异将对实际数据吞吐量产生很大影响。例如，如果在情况4中每个连接间隔的数据包数量最终为4，而不是5，则计算出的吞吐量为1,041.1 Kbps，而不是1,301.33 Kbps（这是一个很大的差异，可以在此处解释数量上的差异）。

情况5（PHY：2 Mbps，ATT MTU = 247字节，DLE：启用，连接间隔：50毫秒）

固件报告的数据吞吐量：

时间：6.34秒过去了。
吞吐量：1322.33 Kbits / s。
发送了1048712字节的ATT有效负载。

计算的数据吞吐量：

数据包传输时间=数据包大小/原始数据速率= 2 + 4 + 2 + 4 + 247 + 3字节/ 2 Mbps = 262 * 8位/ 2 Mbps = 1048微秒

Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据包的时间+ IFS = 44 + 150 + 1048 + 150微秒= 1392微秒

每个连接间隔的最大数据包数= [连接间隔/ Data_Packet_Time] = [50毫秒/ 1392微秒] = [35.92] = 35个包

每个连接间隔传输的总数据= 36 * 244字节= 35 * 244 * 8位= 68320位

数据吞吐量=每个连接间隔/连接间隔传输的总数据= 70272位/ 50毫秒= 1366.4 Kbits / s

情况6（PHY：2 Mbps，ATT MTU = 247字节，DLE：启用，连接间隔：400毫秒）

固件报告的数据吞吐量：

时间：过去了6.11秒。
吞吐量：1371.82 Kbits / s。
发送了1048712字节的ATT有效负载。

计算的数据吞吐量：

数据包传输时间=数据包大小/原始数据速率= 2 + 4 + 2 + 4 + 247 + 3字节/ 2 Mbps = 262 * 8位/ 2 Mbps = 1048微秒

Data_Packet_Time =传输空数据包的时间+ IFS +传输实际数据包的时间+ IFS = 44 + 150 + 1048 + 150微秒= 1392微秒

每个连接间隔的最大数据包数= [连接间隔/ Data_Packet_Time] = [400毫秒/ 1392微秒] = [287.36] = 287个数据包

每个连接间隔传输的总数据= 287 * 244字节= 287 * 244 * 8位= 560224位

数据吞吐量=每个连接间隔/连接间隔传输的总数据= 560224位/ 400毫秒= 1400.56 Kbits / s

优化以实现最大数据吞吐量

根据我们经过的因素，在针对高数据吞吐量进行优化时，我们可以注意到以下几点：

• 始终启用DLE。
  显然，如果您使用的是Bluetooth v4.1或更早版本，则此选项无效。但是，通常，请确保启用了DLE，以最大程度地提高数据包对应用程序的数据效率
• 使用LE 2M PHY
  如果您知道两端的设备都支持Bluetooth 5，那么利用LE 2M PHY是最大程度地提高应用程序数据吞吐量的最佳方法之一。使用LE 2M PHY也将有助于降低功耗，因此您可以用一块石头砸死两只鸟！
• 使用没有响应的通知和写入
  利用这些将有助于删除正在传输的任何不必要的数据包（与指示和正常写入相比，接收方需要确认接收到的每个数据包）。
• 选择至少大于247个字节的ATT MTU值，
  这将最大程度减少数据包字节中的任何开销。
• 选择一个连接间隔，该间隔允许每个连接间隔的最大数据包数。
  但是请记住，连接间隔会影响功耗。间隔时间越短，由于无线电开启时间增加，设备将消耗更多的电量。您还想确保不要选择一个过高的间隔，否则会损害用户体验（较高的连接间隔会导致较高的延迟）。确保要考虑的最后一件事是，就所支持的每个连接间隔的最大数据包数而言，系统中设备的任何限制。

总结与结束

我们上面列出的计算值仍然是理论上的值，可能与实际和实际环境中的测量数据吞吐量不符，但它们仍然是一个很好的起点，并且可以很好地说明预期的结果（至少是最大值） 。干扰和传输/接收错误也会影响数据吞吐量（重试，数据丢失和连接事件关闭会导致吞吐量降低）。这可能是由于存在其他使用与蓝牙相同的2.4 GHz频带的设备，设备之间的距离更长，设备之间存在障碍以及更多原因引起的。