Increasing MTU ATT to 1020 bytes generates a CMake error

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

ovrebekk — Fri, 25 Mar 2022 07:05:01 GMT

Hi Armand

L2CAP packets are only limited by the 16-bit length field, which means they can be up to 65536 bytes long pr spec.

Attributes are limited to 512 bytes pr spec, so when running normal communication through ATT there is little need for an MTU larger than 515 bytes (512 bytes for data and 3 bytes for the attribute header).

If you bypass ATT and open an L2CAP Connected Oriented Channel you are not limited to 512 bytes, but the practical implication on data throughput will not be very large since the link layer still needs to fragment the packets into 251 byte payloads over the air.

Best regards
Torbjørn

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

Ignacio — Thu, 24 Mar 2022 15:40:30 GMT

Nordic devices on each side. I think I will manually split the messages for now. I just wanted to understand why CONFIG_BT_L2CAP_TX_MTU can be set up to 2000 on the zephyr specs. Any hint?

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

ovrebekk — Thu, 24 Mar 2022 14:59:27 GMT

Hi Armand

[quote user="Armand La Flent"]One final query. Is it possible to set to CONFIG_BT_L2CAP_TX_MTU=1020 and get the ble stack to split the messages? If yes, how?[/quote]

This should be possible, yes, but using L2CAP connection oriented channels is not a very common way of sending data over BLE. Then you bypass the entire ATT and GATT layer, which means you can't use normal BLE services.

Are you sure this is what you want to do?

Could you give me some information about the application you are working on, and what kind of devices you want to connect?

Do you have Nordic devices on both sides of the link, or do you want to connect to other devices like phones or PC's?

Best regards
Torbjørn

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

ovrebekk — Thu, 24 Mar 2022 14:53:23 GMT

Hi Jörg

This is both a Bluetooth specification limitation and a hardware limitation (the hardware being designed with the Bluetooth specification in mind).

For details please refer to Vol 6, part B, chapter 2.4 of the Bluetooth 5.2 specification, in particular this section regarding Data Physical Channel PDU packets (normal packet format in a connection):
The Length field of the Header indicates the length of the Payload and MIC if
included. The length field has the range 0 to 255 octets. The Payload shall be
less than or equal to 251 octets in length. The MIC is 4 octets in length.

In other words the payload is limited to 251 bytes, and when sending data through ATT you lose 4 bytes for the link layer header and 3 bytes for the ATT header, leaving you with 244 bytes maximum for attribute data.

The radio hardware allows up to 255 bytes total (not including preamble, header, address or CRC) in order to handle a 251 byte BLuetooth payload plus the 4 byte MIC.

Higher level protocols such as ATT or L2CAP allow you to send longer packets, but they will be fragmented by the link layer to fit in 251 bytes or less.

Best regards
Torbjørn

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

Ignacio — Thu, 24 Mar 2022 08:28:08 GMT

Thanks, Turbo and Torbjørn,

One final query. Is it possible to set to CONFIG_BT_L2CAP_TX_MTU=1020 and get the ble stack to split the messages? If yes, how?

Zephyr specified that CONFIG_BT_L2CAP_TX_MTU can be configured up to 2000.

docs.zephyrproject.org/.../CONFIG_BT_L2CAP_TX_MTU.html

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

Turbo J — Wed, 23 Mar 2022 10:48:12 GMT

It is a hardware specific limitation - at least that is what I read from the RADIO peripherial specification. A TX packet can only be up to 255 bytes in length - that register has only 8 bits.

I'm pretty sure you could configure the zephyr BT stack for supporting a RADIO with a larger possible TX packet size, but I don't see this possible with currently available NordiSemi chips that I'm aware of.

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

Ignacio — Wed, 23 Mar 2022 10:24:11 GMT

Thanks Torbjørn,

Just for me to fully understand and close the case. The article on the link below states the following:

www.novelbits.io/.../

There is no limit per the spec on how high the MTU value can be, but the specific stack in use may have its own limitations

Could you confirm that the 244 bytes payload per packet is a specific stack limitation?

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

ovrebekk — Mon, 21 Mar 2022 14:14:44 GMT

Hi Armand

The most efficient way to send a large payload over BLE is to split it manually into 244 byte blocks, since this is the maximum amount of user data you can have in one BLE packet.

1020 bytes would have to be split into 5 packets in order to fit in 244 bytes or less (244 x 4 + 44).

Depending on your configuration you should be able to send 5 packets or more in a single connection event, unless the connection interval is very small.

If you look at the Bluetooth configuration in the throughput sample you can see how to configure the stack for optimal throughput:
https://github.com/nrfconnect/sdk-nrf/blob/main/samples/bluetooth/throughput/prj.conf#L31-L42

Best regards
Torbjørn

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

Ignacio — Sun, 20 Mar 2022 20:41:26 GMT

Thanks.

Is it possible to send 1020 bytes payload data in a single connection interval? If yes, how?

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

ovrebekk — Mon, 14 Mar 2022 12:13:14 GMT

Hi Armand.

If you scroll up in the build log you should see a text like this:

warning: user value 1024 on the int symbol BT_BUF_ACL_TX_SIZE (defined at C:\ncs\v1.8.0\zephyr\subsys\bluetooth\common\Kconfig:7, c:\ncs\v1.8.0\_cust\285777_peripheral_hr\build\subsys\bluetooth\common\Kconfig:7) ignored due to being outside the active range ([27, 251]) -- falling back on defaults

error: Aborting due to Kconfig warnings

Essentially you have exceeded the maximum value for this configuration parameter, and you need to adjust it accordingly.

If you adjust CONFIG_BT_BUF_ACL_TX_SIZE parameter to 251 it should build.

Best regards
Torbjørn

RE: Increasing MTU ATT to 1020 bytes generates a CMake error

Turbo J — Sun, 13 Mar 2022 08:28:25 GMT

There is probably a message further up that notes the actual limit around 250 bytes. Pretty sure that is either a hardware or BT LE spec limit.