最大化蓝牙吞吐量系列2: 使用更大的ATT MTU

- 日理万妓 2022-09-08 13:51 22阅读 0赞

大家普遍认为随着BLE设备吞吐量的增加，其功耗也会增加。但是，通过智能地选择MTU大小，您实际上可以增加吞吐量，同时降低功耗.

> NOTE: This is Part 2 in Punch Through’s Maximizing BLE Throughput blog series. Here are links to our other posts in this series:
> 
> Part 1: [Maximizing BLE Throughput on iOS and Android][]  
> Part 3: [Maximizing BLE Throughput: Data Length Extension (DLE)][Maximizing BLE Throughput_ Data Length Extension _DLE]

## 数据通过BLE的过程 ##

让我们讨论一下应用程序数据通过蓝牙层的传输路径，并讨论可以优化和利用哪些层来提升吞吐量。  
![data path][]

通用属性概述(GATT) 是开发人员经常使用最多和习惯的层。 GATT 定义了在两个蓝牙低功耗设备之间传输数据的协议。 应用程序数据通过称为**属性**的小实体 (small entity) 进行唯一标识。 **属性组**形成特征，它为一个独特的数据组添加了额外的属性，例如权限和交互规则。 一组特征组合成**服务**实体，它为给定的特性或功能添加了更大的蓝图。 例如，电池服务包括电池电量特性，其中包括给定设备的电池电量。

属性协议（ATT）定义了传输属性数据的协议。 这包括 GATT 相关功能，例如写请求、写响应、通知、读响应。 简而言之，GATT 为给定的应用程序定义并创建适当的属性，而 ATT 创建输出并解析输入数据包, 这些操作在GATT 层中定义。

逻辑链路控制和适配协议 (L2CAP) 负责服务质量 (QoS)、路由、更高层的协议 (例如ATT) 的数据包的分段和组装、安全管理协议 (SMP) 等。

链路层(LL)处理L2CAP数据包的传输，同时确保数据的可靠传输和完整性。

## 蓝牙数据包 ##

一个包含应用程序并通过空中传输的BLE包具有如下结构:  
![ble packet struct][]

**注意** :数据字段依赖于蓝牙规范。在蓝牙v4.0和4.1中，Data字段的最大大小是27个字节。蓝牙v4.2，添加了一个新功能来交换数据字段长度。

## 更近一步观察数据区域 ##

BLE 数据包的数据字段将填充 L2CAP 消息，如下所示：  
![在这里插入图片描述][2c692dee45704a5aa69ecb3215b2194a.png]  
L2CAP 标头的大小是固定的（4 个字节），并且存放数据以满足其要求。长度超过允许的数据字段减去 L2CAP 标头大小的 4 个字节的数据包的进行重组和分段。

当数据字段的最大大小为 27 字节时，每个 BLE 数据包允许最大传输 23 字节的 ATT 数据。

重点就是：

*  理想情况下，我们努力为每个链路层数据包或（链路层数据字段长度 – 4 个八位字节）传输 23 个应用程序数据。
 *  较大的应用数据包23(链路层数据字段长度4字节)或更多可以从ATT->GATT->应用。

## ATT MTU ##

ATT 最大传输单元 (MTU) 是 ATT 数据包的最大长度。 ATT MTU 由 L2CAP 定义，可以是 23 到无穷大之间的任何值。 蓝牙堆栈的实现是确定客户端和外设上 ATT MTU 的关键因素。

通用 ATT 数据包具有以下结构：

![ATT Packet][]  
其中 OP-Code 表示 ATT 操作，例如写命令、通知、读响应等。 ATT 数据（Data）字段包含应用程序数据。

**当发送写入、读取和通知或指示数据包时，还需要包括相关的属性句柄（2 个字节）以识别数据。**

![ATT WRITE Packet][]  
对于 ATT MTU 为 23 字节的默认情况，开销字节导致 13% 的开销数据。

如果您还记得之前的[吞吐量优化博客文章][Maximizing BLE Throughput on iOS and Android] ，我们为每个 BLE 数据包选择了 20 字节的应用程序数据，以匹配蓝牙 v4.0 和 4.1 中允许的默认值。

## ATT MTU 检测 ##

当进入连接时，客户端和外围设备应通过 `Exchange MTU Request/Response`(交换 MTU 请求/响应)的 ATT 层命令交换 MTU。 每一方都不能传输比另一方指定的 `ATT_MTU` 更大的 `ATT` 数据包。

### 示例 ###

iPhone 6 和 6S `ATT_MTU` 为 185。这造成了相对于 182 字节的有效负载占比3/185 或 1.6% 的报头开销。 L2CAP 将传输 185/23 或 9 个链路层数据包。

当 ATT\_MTU 为 23 时，185 字节的有效载荷将被分片为 185/20 或 10 个 ATT 数据包，从而产生 8 个链路层数据包。

## 吞吐量的比较 ##

我们的计算基于一个连接事件中的 4 个 BLE 数据包和 30 毫秒的连接间隔。 这些设置与 iOS 设备类似。

当给定的连接使用更大的 ATT\_MTU 大小来发送数据流时，其吞吐量差异如图：  
![throughput graph][]

## 结论 ##

当使用更大的 `ATT_MTU` 时，吞吐量增加了大约 `0-15%`，因为我们消除了传输 ATT 层开销字节并将其替换为数据。 使用 ATT\_MTU 大小是 23 字节的倍数或（链路层数据字段 – `L2CAP` 标头大小（4 字节））是理想的。

通过使用更大的 ATT 数据包增加吞吐量，并且会创建更少的 BLE 数据包，这可以降低功耗。

## 翻译文章 ##

1.  [Maximizing BLE Throughput Part 2: Use Larger ATT MTU][Maximizing BLE Throughput Part 2_ Use Larger ATT MTU];

## 扩展阅读 ##

1.  [一分钟读懂低功耗蓝牙(BLE)MTU交换数据包][BLE_MTU] 包含蓝牙数据包的抓包示例；
2.  [BLE一次能传多少数据][BLE] 包含更详细的蓝牙协议帧解析；

以下是GAPP Client 进行特征值写请求的完整抓包，AttValue表示写入的值，该值的最大长度到底是多少呢，本文将详细研究并且验证。  
![GAPP client write request packet][]  
本文的正确打开姿势，我们希望你已经仔细阅读并理解协议栈的L2CAP，和BLE4.2/5.0全新支持的 LE 数据扩展功能：

*  [Logical Link Control and Adaptation Layer Protocol (L2CAP)][Logical Link Control and Adaptation Layer Protocol _L2CAP]
 *  [LE Data Length Extension][Logical Link Control and Adaptation Layer Protocol _L2CAP]

### 术语 ###

<table> 
 <thead> 
  <tr> 
   <th>术语</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>PDU</td> 
   <td>Potocal Data Unit 协议数据单元，对于协议栈数据单元我们应该理解为蓝牙协议分层的消息实体的完整封装，例如LL PDU表示我们 逻辑链路层的协议消息的完整封装</td> 
  </tr> 
  <tr> 
   <td>MTU</td> 
   <td>Maximum Transmission Unit 最大传输单元，和本文研究的BLE数据包的最大长度意思接近</td> 
  </tr> 
  <tr> 
   <td>LL</td> 
   <td>Logic Link 逻辑链路层</td> 
  </tr> 
  <tr> 
   <td>PHY</td> 
   <td>physical layer 物理层 蓝牙协议的最底层</td> 
  </tr> 
 </tbody> 
</table>

### 分析 ###

在 BLE PHY 包格式由以下组成,排除 前导码、访问地址、CRC地址 对于BLE4.0/BLE4.1 上层协议（LL）最大可以包含39字节长度的PDU（协议数据单元）。  
![BLE PHY PACKET 4.1 before][]

但是更新后的BLE4.2/BLE5.0 直接升级硬件，将这一长度扩展到257。但是默认了兼容BLE4.0/4.1还是采用了上面的39设计。

![BLE phy 4.2 or 5.0][]

> 注意:PHY 的数据包最大长度直接由硬件决定，也是限制我们BLE 数据包大小的根本原因。换句话说，PHY的硬件寄存器/存储器/FIFO 等直接决定了我们蓝牙数据包最大长度。

对于蓝牙协议分层设计来看，逻辑链路层是最底层，已经正常连接的两个设备之间通信PDU主要由LL Data PDU组成。这里的LL Playload作为我们上层协议的负载。  
![LL Data PDU][]

逻辑链路层再往上就是L2CAP——逻辑逻辑链路控制适配协议,如下的Basic L2CAP Header+Information Payload组成我们这里的基本帧(B-frame)。

![L2CAP packet][]

L2CAP协议再上就是我们操作特征值的ATT层，这一层数据长度被 最大传输单元 ATT\_MTU限制，ATT\_Payload由Attribute OPCode+Attribute Parames+Authentication Signature（可选）组成。排除12字节可选的认证签名，和一个字节属性操作码。

![ATT\_Payload][ATT_Payload]

对于我们这里的写属性值，其Attribute Parameters=其Attribute Handle(2) + Attribute Value,Attribute Value就是我们操作属性的值，其最大长度=ATT\_MTU-Attribute OPCode(1)-Attribute Handle(2)=ATT\_MTU-3。

![Write Attribute][]

同样地，对于读操作属性，主要包含在ReadResponse 操作码。最大长度=ATT\_MTU-Attribute OPCode(1)=ATT\_MTU-1。

![ReadResponse Attribute][]

再总结下，读写属性值最大有效数据长度直接由ATT\_MTU决定,但是根本收LL PDU 大小限制

[Maximizing BLE Throughput on iOS and Android]: https://punchthrough.com/maximizing-ble-throughput-on-ios-and-android/
[Maximizing BLE Throughput_ Data Length Extension _DLE]: https://punchthrough.com/maximizing-ble-throughput-part-3-data-length-extension-dle-2/
[data path]: /images/20220829/9301bf1d06a844b68ca907d41a37b1db.png
[ble packet struct]: /images/20220829/c2dc15335aaa41e390f7317dbbb2bef2.png
[2c692dee45704a5aa69ecb3215b2194a.png]: /images/20220829/1b79f68750824746a93f6325da92d6e8.png
[ATT Packet]: /images/20220829/68ce6b0d2abb43c3ac11b166eb404987.png
[ATT WRITE Packet]: /images/20220829/d11ec97508f04e68808c8fcf0d07bd07.png
[throughput graph]: /images/20220829/8b7e0828f88d41d0a3592c6c8ee56743.png
[Maximizing BLE Throughput Part 2_ Use Larger ATT MTU]: https://punchthrough.com/maximizing-ble-throughput-part-2-use-larger-att-mtu-2/
[BLE_MTU]: https://zhuanlan.zhihu.com/p/28141658
[BLE]: https://leconiot.com/download/cc2640r2f/ble_stack_app/app_examples/exchange_mtu/exchange_mtu.html
[GAPP client write request packet]: /images/20220829/44fd3fc9c872417d923f0c9d12e01455.png
[Logical Link Control and Adaptation Layer Protocol _L2CAP]: https://leconiot.com/download/cc2640r2f/ble_stack_app/stack/l2cap/l2cap.html
[BLE PHY PACKET 4.1 before]: /images/20220829/5009b08192c64524b85114977dabc076.png
[BLE phy 4.2 or 5.0]: /images/20220829/8bbe8303129f4ecc84af5ede9d5f89d8.png
[LL Data PDU]: /images/20220829/c6596722f9af4dc7974a7463e5c26986.png
[L2CAP packet]: /images/20220829/ad74d851ab6b41a59f8c63136b56efb6.png
[ATT_Payload]: /images/20220829/5060f4d0f64d4821a746f747000b16c9.png
[Write Attribute]: /images/20220829/b438eb7d20cb4f598b946ba93b7b607c.png
[ReadResponse Attribute]: /images/20220829/1ace824de13044ef9ef494c718e82593.png