在低功耗蓝牙 4.0 和 4.1 中，OTA 数据包的最大 PDU 为 39 个字节（47 个字节，包括前导码、访问地址和 CRC），并在 4.2 版中增加到 257 个字节。 短数据包的原因是无线电的稳定性，长数据包会加热硅并且要添加额外的电路以保持频率稳定。因此，在 BLE 4.1 中，最长可能的数据包为 376 微秒以避免加热效应。由于数据速率为 1Mhz，376 微秒为 376 位 = 47 字节，因此解释了 PDU 的大小。但是在 4.2 版本中，最长的数据包是 2120 位，所以 2.12ms 和我在蓝牙经典中读取的 3ms 数据包足够长，会导致问题。所以我的问题是：SIG 为何以及如何在 4.2 版本中成功增加 PDU 知道一些半导体公司表示所有版本的硬件都是相同的。是什么导致了这个新的 PDU 长度？
【问题讨论】：
在 4.[01] 中，39 字节是广告数据包达到的最大 LL PDU 大小（2 字节报头，6 字节设备地址，31 字节 AD）。 对于数据包，最大 PDU 大小为 33 字节（2 Header + 4 L2CAP + 23 ATT + 4 MIC）。
注意数据通道标头计算没有标头的 PDU 大小，因此这使数据通道有效负载大小上升到 31 个字节。这是 4.2 中放大的数字（如果不支持加密，实际最小值为 27 字节，因为 4 字节的 MIC 永远不会出现在数据包中）。
4.2 中定义的新数据通道有效负载大小是协议可以支持的最大可能值，因此它是一个芯片可能支持的值，而不是每个芯片必须支持的绝对数据包大小强>支持。
实际数据通道有效载荷大小是通过两个相关无线电之间的 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 位，但标头中不再有可用的连续位。对我来说，这解释了为什么限制大约是 256 个字节（由于不属于字节数的固定标头大小而给予或接受）：它提供了合理的扩展而无需过多更改协议。
【讨论】：