Android does not use Data Length Extension for L2CAP Coc

[Marco]

Hello,

I'm trying to transfer data to an L2CAP CoC on a nRF52832 from iOS and Android devices.
I've configured the MTU and MPS so that the SDU fits in a single packet with extended Data Length.

On iOS, it's working as expected and I'm getting a good throughput (65 kB/s).

On Android, instead, the L2CAP message is fragmented at the Link Layer and the throughput is low. I can see that the extended Data Length is negotiated correctly to 251 bytes and I've seen the phone sending long packets in ATT during previous tests, so I know it's able to do it. The device is a Pixel 4.

Is there a reason for Android to not use long packets on L2CAP CoC? I can't think of any.

[Sigurd]

Hi,

Have you tested with other Android phones? Do you see the same behavior there?

Could you upload a nRF sniffer log that shows the behavior, one for iOS and one for the Android?

https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE

[Marco]

Hello Sigurd,

I don't currently have another device running Android 10 or higher (needed for L2CAP CoC APIs).

I'm attaching the logs.
Unfortunately, nRF sniffer drops basically all packets on iOS with the optimised parameters (MTU=240). I'm attaching a second iOS log with lower MTU=220 which is logged mostly fine, so you can get a better idea. Android would have the same fragmentation issue on MTU=220.

Pixel 4 - 15ms, MTU=240, PHY=2M.pcapng

iPhone SE 2022 - 15ms, MTU=240.pcapng

iPhone SE 2022 - 15ms, MTU=220.pcapng

[Marco]

Sigurd Any thoughts?

[Sigurd]

Hi,

Yes, seems to be the Pixel phone not supporting sending longer than 27 octets packets:

iPhone in comparison:

[Marco]

Thank you Sigurd, I thought the effective values were on LL_LENGTH_RES, but now I understand each device puts its own in REQ/RES and the effective value is the minimum between the two.

After more testing I discovered that the Android device only switches to a 251 bytes TX size if a big ATT MTU is requested. Weird.