In Bluetooth Low Energy 4.0 and 4.1, the max PDU of an OTA packet is 39 bytes (47 bytes with preamble, access address and CRC) and was increased to 257 bytes in version 4.2. The reason of short packet is stability of the radio, long packets heat up the silicon and extra circuitry to be added to keep the frequency stable.So, in BLE 4.1, the longest possible packet is 376 microseconds to avoid heating effect. As the data rate is 1Mhz, 376 microseconds is 376 bits = 47 bytes so the size of PDU is explained. But in the version 4.2, the longest packet is 2120 bits, so 2.12ms and I read 3ms packets in bluetooth classic are long enough to cause problems. So my question is: Why and how did SIG succeed to increase the PDU in version 4.2 know some semiconductor companies state the hardware is the same for all the versions. What did lead to this new PDU length?
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.