[CC2640] Maximum ATT_MTU size?

Hello Gregor,

All BT4.x core specifications define the maximum characteristic length as 512 bytes.

There are no plans to increase the MTU size at the moment and there would be minimal benefit to do so in BLE. Note that with Data Length Extension using the maximum 251 PDU size, you will still need a minimum of two connection PDUs to transfer the full 512 byte contents of your characteristic.

Best wishes

Hi JXS,

thank You.
Could You please clarify below points:

1) In the latest BLE stack v2.2 You can find the following
// The Exchanging MTU Size is defined as the maximum size of any packet
// transmitted between a client and a server. A higher layer specification// defines the default ATT MTU value. The ATT MTU value should
// be within the range 23 to 517 inclusive.
#define ATT_MTU_SIZE L2CAP_MTU_SIZE //!< Minimum ATT MTU size
#define ATT_MAX_MTU_SIZE 517 //!< Maximum ATT MTU size
--> it says here, that the ATT_MAX_MTU_SIZE is 517, while in the Developers Guide it is mentioned as 251 (MAX_PDU_SIZE - 4)

2) I suppose by "two connection PDUs" You mean 2 packets within one connection interval, correct?
Supporting even larger MTU_SIZE could get rid of the LE Header overhead in fragmentation as far as I understand.
I just want to make sure, my understanding is correct:
With the current BLE stack it would be possible to send a multiple of up to 255 Byte large packets within one connection event (assuming the connection interval is large enough)?

Many thanks and best regards,
Gregor

Hi Gregor,

The ATT_MAX_MTU_SIZE define referenced in #1 is from att.h and describes the ATT protocol. The device setting for MAX_PDU_SIZE Is in ble_user_config.h and specifies the max value of ATT_MTU = MAX_PDU_SIZE - 4 bytes for the L2CAP header.

For #2, yes, you can send multiple Data Channel PDUs in a connection event. The Link Layer will fragment when MAX_PDU_SIZE is 28-251. The amount you can send will depend on the ATT procedure and whether a response is required. You can send multiple Notifications in a single event, for example.

Best wishes

Hi JXS,

thank You very much. If I understand You correctly, then with the current stack implementation I am not allowed to define attributes with sizes above 251 Bytes.

You mentioned link layer for fragmentation. Is it really Link Layer or L2CAP layer responsible for fragmentation?

You also mentioned that Link Layer will fragment when MAX_PDU_SIZE is 28-251

>> If using the "LE Data Packet Length Extension" of v4.2 then my understanding is that You should be able to have packets of max 251 Bytes of length on radio level or is my understanding wrong and it is always 27Bytes on radio level?

In the following image fragmentation seems to happen on the L2CAP layer

While in Section 5.5.2 it says:

The Bluetooth low energy stack supports fragmentation and recombination of L2CAP PDUs at the link layer.

If I understand correctly than fragmentation/recombination can happen on Link Layer, but eventually it is the responsibility of the L2CAP layer to check and make sure PDU sequence/size is correct. Could You please clarify?

Many thanks and best regards,

Gregor

Hi Gregor,

You can support reading & writing GATT Characteristics up to the maximum 512 bytes with the TI BLE-Stack.
To maximize transmission efficiency, both peer devices should:

Define MAX_PDU_SIZE = 251 to match max LL PDU when DLE feature is enabled. This will give you a resulting ATT MTU of 247 bytes. To write 512 bytes you will need to use GATT_WriteLongCharValue since 512 is greater than the ATT_MTU. This will send the data over a minimum of two connection events, each containing up to ATT_MTU-5 bytes. The LL will automatically send each ATT transmission as a longer data PDU, up to 251 bytes if both devices support the data length update procedure up to the max 251 RX & TX bytes. Likewise for Reads, the Read Blob procedure will be used.

Now, it may be more efficient to send the data as 2x writes to two different Characteristics, each up to ATT_MTU - 3 bytes in length. That way you can queue them up and send them on the same CI.

See the BT4.2 core spec, Vol 3, Part F & G for ATT and GATT.

Best wishes