nRF52840, SDK v16.0.0 SD140v7.0.1
Our electrical engineers gave us a hard ATT_MTU limit of 65 bytes, so as to keep the peak current low on the battery for our ultra-low-power IoT device. We can not TX/RX more than 65-byte ATT_MTU per connection interval.
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.
Is there a way to do this? We see https://devzone.nordicsemi.com/f/nordic-q-a/17860/nrf52832-sdk12-1-extended-mtu-with-and-without-dle, in which Ulrich says
"When you increase the ATT MTU size, you increase the maximum logical length of a complete PDU. If the PDU cannot fit in a single on-air packet, it will be fragmented on the link-layer level. This means that the next on-air packet will have a continuation bit set, and no L2CAP or ATT header, basically saying that what follows should be appended directly onto the PDU you are building. Since the first packet contains the length of the complete PDU, the stack knows when the reassembly is complete. Similarly, if a new packet without the continuation bit is received, all the data will be discarded. This can happen in cases where a more important PDU needs to be sent first. However, each on-air packet will have the LL header. This includes preamble, access address, CRC and MIC (if encrypted)."
This seems close? Is there a way to increase the ATT MTU size to stimulate this link-layer fragmentation while guaranteeing that L2CAP frames will be small enough to meet our power concerns? Even if we can, some Central devices we're pairing with have fixed 23-byte ATT MTU values; is there a way to do fragmentation + reassembly below the application layer in these cases?
We also see the LE Data Length Extension in 4.2, but that looks like it's about transmitting longer on-air packets, which runs against our power requirements.
