Bluetooth Low Energy - Working with long attributes on a GATT Server - Part 1: ATT_MTU

[bogdanalexandru]

Attributes from a GATT database located on a GATT Server (usually a BLE peripheral device) have a maximum allowed value size of 512 bytes.

While is it recommended to design small attribute value sizes (usually a few bytes), situations arrive where longer attributes are necessary. For example, characteristics whose values contain long strings will certainly need a lot of bytes compared to numbers: Device Name, Manufacturer Name etc.

A problem with such attributes is the limited payload size of BLE packets. For example, for an ATT packet, after stripping down all headers and metadata, we are left with 23 bytes of actual ATT data that an over-the-air packet can contain. If the ATT layer requires sending more than 23 bytes in a certain transaction, the L2CAP layer, which lies immediately under ATT, cuts the data in 23-byte slices and sends multiple packets over the air, because of the radio limitations imposed by the standard.

Because of that, the default size of an ATT packet is 23 (this is abbreviated as ATT_MTU), and all BLE devices must be capable of working with at least this default size. It is possible for some devices to support an ATT_MTU value greater than 23, but in that case two things need to be considered:

1. The ATT_MTU may be increased over 23 only if the peer device also supports greater values. In order to agree on a value for ATT_MTU, the ATT Client (usually the central device) sends an MTU_EXCHANGE_REQUEST packet to the ATT Server, containing the maximum ATT_MTU value that it can work with. The Server then replies with an MTU_EXCHANGE_RESPONSE containing its own maximum ATT_MTU. Once this operation is complete, both devices set their ATT_MTU equal to the minimum of the two exchanged values. For example, a Client may support an ATT_MTU of 40 and wants to know if the Server can increase its ATT_MTU. If the Server is configured to support a value of 30, after it sends the response, both devices will set the ATT_MTU equal to 30. If no MTU exchange is performed, ATT_MTU is assumed to be 23.
2. Even if after MTU exchange the value for ATT_MTU is set to one greater than the default 23, as explained before, the radio packets can still carry a maximum of 23 ATT bytes, so, for example, an ATT packet of size 60 will be split and sent over-the-air into 3 actual packets, containing 23, 23 and 14 ATT bytes respectively. Note that the management of split packets is done entirely at the L2CAP level, so this is transparent for the ATT layer.

               When designing a BLE app, one must keep in mind that a lot of BLE devices do not support the MTU exchange feature (usually due to resource constraints), so it is quite possible it will work with the default value.

       See Bluetooth Core 4.1 specification, vol. 3, section 3.4.2 for more information.

        Continue reading: Part 2