在蓝牙低功耗 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 知道一些半导体公司表示所有版本的硬件都是相同的。
问问题
6651 次
1 回答
3
In 4.[01], 39 bytes is the maximum LL PDU size reached for advertisement packets (2 bytes of header, 6 bytes of device address, 31 bytes of AD). For data packets, max PDU size is 33 bytes (2 Header + 4 L2CAP + 23 ATT + 4 MIC).
Note Data channel header counts the PDU size without the header, so this makes the data channel payload size go up to 31 bytes. This is the number that got enlarged in 4.2 (the actual minimal value is 27 bytes if crypto is not supported, because 4-byte MIC will never appear in the packet).
The new data channel payload size defined in 4.2 is the maximum possible value protocol can support, so it's a value a chip may support rather than an absolute packet size every chip must support.
Actual data channel payload size is negotiated with LL_LENGTH_REQ and LL_LENGTH_RSP between the two involved radios. They may negotiate any length from 27 up to 251 bytes (at the payload level) (See Core_v4.2 6.B.2.4.2.21).
In first release of the BLE spec, packet absolute max size was 27 bytes (data payload, without MIC). Spec used a 5-bit field for LL packet size, 3 other bits of this header byte were RFU. It eventually got enlarged to 8-bit with full backward compatibility in 4.2, but there are no more contiguous bit available in the header. To me, this explains why limit is around 256 bytes (give or take because of fixed header sizes that are not part of the byte count): it gives a reasonable extension without changing the protocol much.
于 2016-09-13T08:39:19.717 回答