RE: Maximum NUS packet payload with BLE data length extension.

Hieu — Mon, 10 Jun 2024 07:52:56 GMT

Regarding Massage Integrity Check bits, please refer to Vol 6, Part B, 2.4, Data Channel PDU:

The MIC field shall not be included in an un-encrypted Link Layer connection,
or in an encrypted Link Layer connection with a data channel PDU with a zero
length Payload.
The MIC field shall be included in an encrypted Link Layer connection, with a
data channel PDU with a non-zero length Payload and shall be calculated as
specified in [Vol. 6] Part E, Section 1.

The 4 bytes is only taken in an encrypted link.

RE: Maximum NUS packet payload with BLE data length extension.

kat829 — Fri, 07 Jun 2024 19:41:45 GMT

I see.

The remaining 4 bytes that are not accounted for in the calculation are message integrity check I assume.

- https://devzone.nordicsemi.com/f/nordic-q-a/12211/ble-packet-structure

- https://i0.wp.com/embeddedcentric.com/wp-content/uploads/2019/03/BLE-Packets-Types.png?ssl=1

Thanks!

RE: Maximum NUS packet payload with BLE data length extension.

Hieu — Fri, 07 Jun 2024 18:50:52 GMT

Hi kat829,

You are going into details here, and it is a little difficult to keep things simplified, but I will try.

[quote user=""]- BLE specification limits payload to 251[/quote]

In the context where you want the BLE packet to not get fragmented, yes.

The Bluetooth Spec v4.2 limit a Link Layer packet to just 257 byte of payload.

Subtracting mandatory 2 bytes of Link Layer headers, we are left with maximum 255 bytes for the entire L2CAP packet.

Subtracting 4 bytes of L2CAP headers, we are left with 251 bytes for the L2CAP payload.
However, that is 251 bytes of L2CAP payload per one Link Layer packet, because one L2CAP can be segmented and carried by multiple Link Layer packets.

[quote user=""]

- GPT claims that NUS-handled data are always enclosed in a L2CAP packet, thus adding 4 byte header and reducing effective payload to 247
- NUS operates within GATT, but that is supposed to somehow not eat up any more data of the packet

[/quote]

GATT does eat up more data. The ATT (no typo, GATT is based on ATT) does eat up at least 3 more bytes, leaving you with only 244.

This is true for Write, Notify, Read. Some other ATT operations require more bytes.

At the end of all this, you need to remember that the packet data length is negotiated between the Central and Peripheral devices.
The Central is the one ultimately decide the data length, and it might be lower, making a NUS transmission of 244 bytes still fragmented.
Having said that, in most real cases, the maximum discussed above can be achieved; but please keep this fact in mind.
If keeping the packet not fragmented is an absolute concern, you can adapt the data size dynamically based on the negotiated data length.

For more details, refer to these sections of the Bluetooth Specification:

Link Layer
Vol 6, Part B, 2.1 Packet format for the LE Uncoded PHY
Vol 6, Part B, 2.4.1 Data Physical Channel PDU

L2CAP
Vol 3, Part A, 3.1: Data packet format, Connection-oriented channels in Basic L2CAP mode

ATT
Vol 3, Part F, 3.3: Attribute PDU

Hieu