Understanding Maximum BT GATT notification size

RE: Understanding Maximum BT GATT notification size

timl2415 — Wed, 22 May 2024 17:56:38 GMT

Thank you for confirming.

The documentation for the callback states that callback gets an updated TX ATT MTU and RX ATT MTU.

- Being unfamiliar with BLE, i assumed this meant that there were two individual MTU's, one in each direction. Every example using this callback prints these as tx:%d and rx:%d updated MTU, when in reality only the min of the two is used by both devices in the connection.

- The "tx" and "rx" MTUs are actually "server" and "client" MTUs. On a server device its locally supported MTU is reported as the "rx" MTU and the client device MTU is the "tx". From the server perspective it doesn't make a ton of sense to me why my MTU is the "rx" MTU when its just the MTU i can support for both incoming and outgoing messages.

It would be nice if there was some example that uses the negotiated MTU values in the callback to determine some notification size.

RE: Understanding Maximum BT GATT notification size

Einar Thorsrud — Wed, 22 May 2024 12:54:38 GMT

Hi,

You are right that the minimum will be used (as it must be supported by both peers). This is generally how most parameters are handled in Bluetooth. I did not get how the API documentation for the GATT callback is misleading, though?

PS: In most cases an ATT MTU of 247 is use also for high throughput, as that is the largest that can fit in a BLE packet with data length extension (a longer ATT MTU will cause fragmentation on the physical layer so the throughput will not increase).

RE: Understanding Maximum BT GATT notification size

timl2415 — Tue, 21 May 2024 19:29:37 GMT

It seems I may have misunderstood the params of the att callback, in att.c, att_mtu_req takes the requested MTU from the client and the local MTU from the configured L2CAP buffer sizes and sets the MTU for the channel to the minimum of the two. So the maximum notification size should be the min of the client-requested and server-local MTU. From the BLE Core Spec 5.1:

When using an L2CAP channel with a fixed CID, the client and server may optionally exchange the maximum size of a packet that can be received using the ATT_EXCHANGE_MTU_REQ and ATT_EXCHANGE_MTU_RSP PDUs. Both devices then use the minimum of these exchanged values for all further communication

If that is the case then the documentation on the att_mtu_updated callback certainly seems misleading:

/** @brief The maximum ATT MTU on a connection has changed.

* This callback notifies the application that the maximum TX or RX

* ATT MTU has increased.

* @param conn Connection object.

* @param tx Updated TX ATT MTU.

* @param rx Updated RX ATT MTU.

void (*att_mtu_updated)(struct bt_conn *conn, uint16_t tx, uint16_t rx);

It should be that tx is the MTU the client tx'd to the server and rx is the MTU the client rx'd from the server. Please correct me if I'm wrong.