BLE: L2CAP Fragmentation and reassembly

RE: BLE: L2CAP Fragmentation and reassembly

ovrebekk — Fri, 28 Aug 2020 09:39:37 GMT

Happy to help Charles. The best of luck with your project 🙂

RE: BLE: L2CAP Fragmentation and reassembly

charles — Thu, 27 Aug 2020 16:05:37 GMT

Thanks to both of you for the detailed and thoughtful responses. This is extremely helpful and we sincerely appreciate it.

RE: BLE: L2CAP Fragmentation and reassembly

Dmitry — Wed, 26 Aug 2020 14:57:19 GMT

Hi Charles,

Let me share my thoughts concerning your case. If 65-byte limitation is quite hard, I'm afraid you should take it into account at application level. As Torbjørn pointed out, miminum event length is 2.5 ms that is quite long, and you have no control over a number of packets sent during a single event, other than restrain SoftDevice's tx queue no more than 65 bytes long. Using large MTU with short data length, you'll probably see two or more fragments sent one-by-one every connection event.

RE: BLE: L2CAP Fragmentation and reassembly

ovrebekk — Wed, 26 Aug 2020 09:29:56 GMT

Hi Charles

The maximum ATT_MTU you can use is normally 512 bytes, while the maximum data length is 251 (leaving 244 bytes for data once you subtract the 3 byte ATT header and the 4 byte L2CAP header).

If your data fits logically in ~160 bytes then I would scale the MTU after this, plus 3 bytes for the ATT header. Using a larger ATT_MTU might provide slightly more efficient communication, depending on how the link layer can split the attribute into multiple 65 byte on air packets, but I don't think the difference would be very significant.

The NRF_SDH_BLE_GAP_EVENT_LENGTH can be quite useful, yes, but I don't think it is directly related to any parameters in the Bluetooth specification. The transmit window is related to the first packet in a BLE connection, and is not relevant for subsequent packets in a connection.

The number of packets you can send in one connection event is not defined by the Bluetooth specification, other than that it needs to be at least one (obviously), and that you can extend it for as long as both the master and the slave allow by setting the 'more data' bit in the packet header.

The NRF_SDH_BLE_GAP_EVENT_LENGTH uses a unit of 1.25ms, and the minimum value is 2, meaning the minimum time you can set is 2.5ms.

[quote user="nicholsonc"]I wonder if I misspoke and instead of seeing 23-byte ATT_MTU we're actually seeing 23-byte data length? I'll investigate more; if was a report from a partner of ours.[/quote]

Typically the minimum data length should be 27 bytes, because this includes the 4 byte L2CAP header on top of the 23 byte minimum attribute MTU.

Did they mention which phone(s) they were talking about?

[quote user="nicholsonc"]Do you know of any resources that catalogue the capabilities of modern Android + iOS handsets? We're using a third-party testing company for handset compatibility and they're doing a great job, but we've also wished for a database somewhere that describes BLE version, max ATT_MTU / Data Length / Connection Interval ranges / Slave Latency / .....[/quote]

I don't know of any such tool unfortunately.

At various times we have thought of doing something like that ourselves, create an app that people can run on their own handsets that would report the capabilities back to the cloud. Then it wouldn't be necessary for any one company or group to acquire every single phone, but it could be a collaborative project between users of the app (assuming they have a Nordic DK available to act as the peripheral device).
We might do something like this in the future, but for the time being we don't have any concrete plans for it unfortunately.

Best regards
Torbjørn

RE: BLE: L2CAP Fragmentation and reassembly

charles — Mon, 24 Aug 2020 14:38:31 GMT

Thanks for the thorough and fast response, Torbjørn!

So it sounds like a good strategy is to go for as large of an ATT_MTU as we can get (250?), and then as long as the Data Length is <= 65 we'll get the fragmentation + reassembly for free and keep our EEs happy. They were very excited to learn about the NRF_SDH_BLE_GAP_EVENT_LENGTH field as well, presumably that controls the "transmit window" value?

I wonder if I misspoke and instead of seeing 23-byte ATT_MTU we're actually seeing 23-byte data length? I'll investigate more; if was a report from a partner of ours.

Do you know of any resources that catalogue the capabilities of modern Android + iOS handsets? We're using a third-party testing company for handset compatibility and they're doing a great job, but we've also wished for a database somewhere that describes BLE version, max ATT_MTU / Data Length / Connection Interval ranges / Slave Latency / .....

Charles

RE: BLE: L2CAP Fragmentation and reassembly

ovrebekk — Mon, 24 Aug 2020 14:10:02 GMT

Hi Charles

In this case it sounds like your best bet is to use LE Data Length Extension, but ensure that you don't set the data length larger than 65.

Then you can safely set the ATT_MTU to 160 bytes or more, and the link layer will have to fragment a single 160 byte update into multiple on-air packets according to the data length.

You might want to set the NRF_SDH_BLE_GAP_EVENT_LENGTH to a low number also, otherwise the SoftDevice will be able to send multiple packets back to back in a single connection event, which could break your peak current constraints set by the electrical engineers.

If you have central devices that don't support more than 23-byte ATT MTU I must assume these are quite old devices, as longer ATT MTU has been a feature in the specification for a long time?
In this case you don't really have any choice other than to split the packet into multiple fragments manually, and send 20 bytes at a time.

Best regards
Torbjørn

RE: BLE: L2CAP Fragmentation and reassembly

charles — Sun, 23 Aug 2020 18:27:08 GMT

Sorry, to be clear, by

[quote userid="25714" url="~/f/nordic-q-a/65105/ble-l2cap-fragmentation-and-reassembly"]We have a scenario where the most optimal solution would be to have the BLE LL / L2CAP fragment and reassemble data for us, so that we can write ~160 bytes over N connection intervals, but not require application-level awareness of this fragmentation and reassembly. Ideally this ~160 byte payload would appear all at once to the GATT Client running on the Central device.[/quote]

I mean, "so that we can write ~160 bytes over N connection intervals with the ATT_MTU <= 65 bytes". If the Central only supports a 23-byte ATT_MTU, then this would take 160 / 20 = 8 connection intervals.