This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52840 - s140 - MTU and DLE explain

Hi everyone,

I am trying to understand the concepts of ATT MTU and DLE, so let me share my thoughts along with some questions. Maybe this is useful for other community members as well.

ATT MTU defines the length of the Payload in Link Layer. With Bluetooth 4.x the max MTU size could be 27bytes and subtracting L2CAP (4Bytes) and ATT Header (3Bytes) the max ATT payload is just 20Bytes.  With Bluetooth 5.x the max MTU could be 251Bytes and again by subtracting the overhead the useful data payload is 244Bytes.

Also, in order to avoid data fragmentation and send the entire payload in a single packet the ATT Data (ATT MTU) must be <=247Bytes. From SDK you can configure the MTU from the following macro

// <o> NRF_SDH_BLE_GATT_MAX_MTU_SIZE - Static maximum MTU size. 
#ifndef NRF_SDH_BLE_GATT_MAX_MTU_SIZE
#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247
#endif

Moreover, in order to take advantage of MTU size >20Bytes, you need to enable the DLE (Data Length Extension). While the MTU sets the size of the payload in Link Layer the DLE sets the on-air data packet size. You can configure the DLE from the following macro

// <o> NRF_SDH_BLE_GAP_DATA_LENGTH   <27-251> 
// <i> Requested BLE GAP data length to be negotiated.

#ifndef NRF_SDH_BLE_GAP_DATA_LENGTH
#define NRF_SDH_BLE_GAP_DATA_LENGTH 251
#endif

So for example by setting the MTU to 247 means that the Link Layer is capable of holding a payload of 244bytes + 3bytes overhead and setting DLE to 251 means that you can transmit a Payload (L2CAP + ATT Data) up to 251bytes

So, to my understanding, DLE also prevents packet fragmentation. BUT, in case that the DLE is less than the MTU then data fragmentation will occur... For example, if MTU is 250bytes and DLE is 50Bytes and we want to transmit a payload of 200Bytes then:

ATT Data = ATT Header + ATT PAYLOAD = 3 + 200 = 203Bytes

Payload = L2CAP + ATT Data = 4 + 203 = 207Bytes

But the DLE is just 50Bytes, meaning that there is going to be data fragmentation:

1st packet: 50Bytes (7bytes overhead + 47bytes ATT Payload)

2nd packet: 50Bytes (7bytes overhead + 47bytes ATT Payload)

3rd packet: 50Bytes (7bytes overhead + 47bytes ATT Payload)

4th packet: 50Bytes (7bytes overhead + 47bytes ATT Payload)

5th packet: 19Bytes (7bytes overhead + 12bytes ATT Payload)

47+47+47+47+47+12 = 200bytes

The ATT Payload was fragmented into 5 packets and each packet includes a 7Byte overhead.. Also, after each received packet there is a transmission of an empty packet (if there is nothing to respond back) with a duration of 80us and the Bluetooth specification defines that the time delay between consecutive packets Rx/Tx (IFS) is 150us. Taking all this into account, it is obvious that the smaller the DLE the worst the throughput.

The following picture describes the prementioned. The first picture is with DLE enabled while the second one with DLE disabled. It is obvious that when DLE is disabled the throughput is much worse since the fragmentation is at a higher level.

So, could someone from the experts verify what I have said so far and correct any ambiguities? Furthermore, is any point that I am missing and is essential to know for developing?

Thanks in advance

Nick

Parents Reply
  • Hi Keneth,

    I noticed I mistake with my calculations. The ATT payload should be 43bytes..

    1st packet: 50Bytes (7bytes overhead + 43bytes ATT Payload)

    2nd packet: 50Bytes (7bytes overhead + 43bytes ATT Payload)

    3rd packet: 50Bytes (7bytes overhead + 43bytes ATT Payload)

    4th packet: 50Bytes (7bytes overhead + 43bytes ATT Payload)

    5th packet: 35Bytes (7bytes overhead + 28bytes ATT Payload)

    43+43+43+43+43+28 = 200bytes

    Also in here I read that when there is fragmentation the L2CAP overhead do not added to the fragments as shown from the figure below

    With that saying I am not sure If my calculations are correct.. Whould you please refine?

Children
Related