bluetooth-lowenergy - 低功耗蓝牙 4.2 中 PDU 大小说明

Question

在低功耗蓝牙 4.0 和 4.1 中，OTA 数据包的最大 PDU 为 39 个字节(47 个字节，包括前导码、访问地址和 CRC)，在 4.2 版中增加到 257 个字节。
短数据包的原因是 radio 的稳定性，长数据包会加热硅并且要添加额外的电路以保持频率稳定。因此，在 BLE 4.1 中，最长可能的数据包为 376 微秒以避免加热效应。由于数据速率为 1Mhz，376 微秒为 376 位 = 47 字节，因此解释了 PDU 的大小。但是在 4.2 版本中，最长的数据包是 2120 位，所以 2.12ms 和我在蓝牙经典中读取的 3ms 数据包足够长，会导致问题。所以我的问题是:SIG 为何以及如何在 4.2 版本中成功增加 PDU 知道一些半导体公司表示所有版本的硬件都是相同的。是什么导致了这个新的 PDU 长度？

Answer 1

在 4.[01] 中，39 字节是广告数据包达到的最大 LL PDU 大小(2 字节的报头，6 字节的设备地址，31 字节的 AD)。
对于数据包，最大 PDU 大小为 33 字节(2 Header + 4 L2CAP + 23 ATT + 4 MIC)。

注意数据 channel header 计算没有 header 的 PDU 大小，因此这使数据 channel 有效负载大小上升到 31 个字节。这是在 4.2 中放大的数字(如果不支持加密，实际最小值为 27 字节，因为 4 字节 MIC 永远不会出现在数据包中)。

4.2中定义的新数据 channel 有效载荷大小是协议(protocol)可以支持的最大可能值，所以它是一个芯片的值可能支持而不是每个芯片的绝对数据包大小必须支持。

实际数据信道有效载荷大小通过两个相关 radio 之间的 LL_LENGTH_REQ 和 LL_LENGTH_RSP 进行协商。它们可以协商从 27 到 251 字节的任何长度(在有效负载级别)(参见 Core_v4.2 6.B.2.4.2.21)。

在 BLE 规范的第一个版本中，数据包的绝对最大大小为 27 字节(数据有效负载，没有 MIC)。 Spec 使用 5 位字段来表示 LL 数据包大小，该头字节的其他 3 位是 RFU。它最终在 4.2 中扩大到具有完全向后兼容性的 8 位，但在 header 中没有更多的连续位可用。对我来说，这解释了为什么限制大约是 256 个字节(由于不属于字节数的固定 header 大小而给予或接受):它提供了合理的扩展，而无需太多改变协议(protocol)。