Change iOS BLE MTU size to 512 (SWIFT)

Question

is there any way to change the MTU value on iOS from the default to an arbitrary value?

Much like in Android it's possible to do requestMTU(512).

Thanks

Melly

No, the mtu can't be changed – Mallory

Here is another question about changing the MTU on iOS: #58526318 it actually received a comment by @Mallory as well ;) – Goatherd

As per my comment on that other question, you can use L2Cap if you need to transfer larger amounts of data – Mallory

@Mallory would this allow me to use BLE notification characteristics and so on? My use case is that i have a BLE peripheral that is sending me larger data than what's allowed by iOS MTU and this data on my Central is truncated at 182 bytes – Melly

L2Cap is a stream based protocol, different to GATT. If you want to stick with GATT then you will need to send your data over multiple updates. – Mallory

Answer 1

No, MTU on iOS is set automatically, maximum value is 185. This is a good answer to your question: https://mcmap.net/q/1259640/-negotiate-ble-mtu-on-ios

Note: you can get MTU value this way (it will be 3 bytes less than the ATT MTU):

connectedPeripheral.maximumWriteValueLength(for: .withoutResponse)

It's important to use parameter .withoutResponse, because .withResponse will always return 512 (when writing with response, iOS automatically chooses the approach: single write if data is shorter than MTU, or queued write if data is larger than MTU).

Apteral

Hi, not certain why, but I was testing under iOS 14 and I did get that MTU was maxed at 182 (185). I updated my phone to iOS 15, magic I am getting 244 off the BLE device we are developing. I know this did not update my chipset, so why iOS 15 is now accepting more on the same hardware. – Elbertina

Just updated 7 Plus to iOS 15.0 (non-beta) - I'm still getting value 182 (peripheral is nRF52840 with NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247). – Apteral

hi, I used this it help find the problem with the connection bluetooth.com/blog/a-new-way-to-debug-iosbluetooth-applications – Elbertina

@PascaleBeaulac Is correct, at some point the modern iPhones dropped the 185 byte limit and support 247 MTU ACTUAL which is 244 usable. – Evident

@Apteral And what happens, if the device does not implement QueuedWrites? I have exactly such a device, where ­– when I send 512 withResponse ­– things silently fail, because the peripheral does not answer to the PREPARE WRITE. Why is iOS assuming that all peripherals can do Queued Writes? According to the spec it's optional. – Talithatalk

@Talithatalk Same happened to me, it was working when sending data shorter than MTU and failing silently when sending data larger than MTU, until I found a way to implement Queued Writes on that Peripheral device. – Apteral

The maximum value is no more 185 but 512 also for .withoutResponse – Coles

Answer 2

this is not an answer but it is interesting non the less. It is a reply from apple engineer on a request I send on the problem.

Hi,

Yes, the issue you are seeing is indeed due to the timing problem/race condition I was suspecting. The reason you are getting DPLE and MTU almost simultanously is, iOS has received the MTU request too early, and as it has not been able to determine if the connection supports EDL, it responds with the minimum.

In iOS 15 this race condition is being handled differently, and the MTU response is held off until the link is ready. Technically the peripheral is not doing something wrong, as the spec allows the MTU request to be sent at any time. Just that on iOS 14, on different devices, this issue may pop-up.

I can’t tell you to not send the MTU request at that time, because spec allows it. And iOS 15 is handling it in a way to bypass these issues.

Delaying the MTU request until PHY update may make the problem less likely, but there is no guarantee that it will not happen ever. The root issue here is that HCI events like PHY Update or EDL change are issued by each controller locally and there is no way to guarantee that just because your peripheral reports EDL that the iPhone controller has also done so. And unfortunately this timing/race issue will be different from controller to controller, therefore from phone to phone.

So I hope it helps. The BLE peripheral we are developing is sending all the commands for the connection negotiation pretty much all at the same time. And this is what was causing us to not be able to get the data length extension.

Elbertina

This was helpful! It appears to me that iPhones on IOS15 take approx .8 seconds after establishing a link to a Nordic peripheral to adjust the PHY and MTU at roughly the same time. I had to add a state to our machine that checks every 200ms or so for the updated MTU. – Evident