19

I was wondering what was the maximum packet length in Bluetooth Low Energy. The 20 bytes limit if often said, for example here

"BLE allow you transfer maximum is 20 bytes."

"You are correct that the BLE specification doesn't allow write operations to exceed 20 bytes."

However, reading the Bluetooth Core Specification, we can see that the ATT_MTU value is written with 2 bytes, meaning that it can go up to 65 535 bytes.

What's the truth behind all this ?

Community
  • 1
  • 1
jdoe
  • 323
  • 1
  • 2
  • 7

1 Answers1

44

Specification is always right !

In Bluetooth 4.0, BLE was introduced with a maximum payload of 33 bytes (not including Access Address and CRC fields). Each layer in the protocol stack takes its cut:

  • 2 bytes for packet header (type and length),
  • 4 bytes for MIC (when encryption is enabled),
  • 4 bytes for L2CAP header (channel ID and packet length),
  • ATT protocol is left with 23 bytes, which is the default and minimal MTU for ATT protocol.

With an ATT write request (or notification), 3 bytes are used by command type and attribute ID, 20 bytes are left for the attribute data.

At the ATT level, this limit may be enlarged in two ways:

  • Using fragmentation at the L2CAP level:

    L2CAP will split ATT PDUs in 27 bytes fragments (23 for the first one).

    Drawbacks:

    • It needs memory on both sides,
    • It is less reliable as packets may get lost by some implementation (even if spec do not speak about packet loss at the L2CAP level, it happens)
  • Using packet length extension introduced in Bluetooth 4.2:

    Up to 251 bytes at the radio level (255 with MIC), so 242 bytes available for attribute data.

    Drawbacks:

    • Still new, needs hardware support, so not implemented everywhere (even if announcing BLE 4.2 support),

    • Packet with longer airtime will have more chances of getting jammed, so longer packets implies more retransmissions.

If both methods are used, L2CAP may use bigger fragments.

Whatever low-level splitting of ATT PDU, Attribute value length is limited to 512 by 3.F 3.2.9.

Nipo
  • 2,617
  • 13
  • 20
  • 1
    Thank you. So, although the ATT_MUT parameter is coded on 2 bytes, it can't go up to 65535 ? And characteristics longer than 238 bytes are fragmented ? – jdoe Aug 12 '16 at 09:59
  • 2
    About Attribute value length, 3.F 3.2.9 specifies: `The maximum length of an attribute value shall be 512 octets.` – Nipo Aug 12 '16 at 10:47
  • 3
    ATT_MTU can be negotiated between devices to achieve higher throughput, although, of course, it won't affect MTU at L2CAP level (where MTU is controlled by LE packet extension). This was confusing for me as a BLE newcomer because it was not clear which MTU is the subject of various articles and how it's possible to modify it even without BLE 4.2. – JustAMartin Mar 02 '17 at 07:53
  • 2
    Perhaps I am wrong but max of 238 doesn't sound right (w/ packet length extension). The spec states that the payload field shall be less than or equal to 251 octets in length (v4.2 [Vol 6, Part B], 2.4 Data Channel PDU), where payload refers to a section of the Data Channel PDU. If the payload is composed of an opcode (1 byte), attribute handle (2 bytes) and channel / length (4 bytes), that leaves 244 bytes for actual data. I was able to confirm that by sending some actual data. – mateusz Dec 22 '17 at 13:55
  • @mateusz: It seems you're right. 251 bytes is without MIC (255 with), so we get to 242 bytes for ATT data. Edited my answer. – Nipo Nov 08 '18 at 16:03