This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Is MTU of all BLE devices limitted to 23 bytes when using ATT protocol?

Is MTU of all BLE devices limitted to 23 bytes when using ATT protocol?

I don't know explicitly.

Some say it is possible to use MTU longer than 23 bytes.

Others say it is possible to use MTU longer than 23 bytes in softdevice(except to s132)

Is it impossible to use MTU longer than 23 bytes at Only softdevice?

does other vender implement MTU longer than 23 bytes for ATT protocol?

Parents
  • Hi JoonDong,

    Trying to answer the questions one by one:

    • "Is MTU of all BLE devices limited to 23 bytes when using ATT protocol?" - NO, 23 bytes is just default ATT_MTU size, can be negotiated higher.
    • "Is it impossible to use MTU longer than 23 bytes at Only softdevice?" - Soft Device S130 (for nRF51) and S132 (for nRF52832) support extended ATT_MTU since v2.x, S140 and others as well.
    • "does other vender implement MTU longer than 23 bytes for ATT protocol?" - Yes. Also note that you don't need to use Nordic BLE stack (Soft Device) on nRF5x, there are alternatives in open source projects such as Zephyr or Mynewt.

    Cheers Jan

Reply
  • Hi JoonDong,

    Trying to answer the questions one by one:

    • "Is MTU of all BLE devices limited to 23 bytes when using ATT protocol?" - NO, 23 bytes is just default ATT_MTU size, can be negotiated higher.
    • "Is it impossible to use MTU longer than 23 bytes at Only softdevice?" - Soft Device S130 (for nRF51) and S132 (for nRF52832) support extended ATT_MTU since v2.x, S140 and others as well.
    • "does other vender implement MTU longer than 23 bytes for ATT protocol?" - Yes. Also note that you don't need to use Nordic BLE stack (Soft Device) on nRF5x, there are alternatives in open source projects such as Zephyr or Mynewt.

    Cheers Jan

Children
  • Isn't it meaningful to set to MTU longer than 23 byte if peer support just 23 bytes?

  • Sure, it's meaningless to support larger MTU only on one side of the link. However majority of mobile phones and also other devices already support it. Note that "support for larger ATT_MTU" is compile time option but if it is used or not depends on Master (ATT Client) during every connection, otherwise it stays on default value (23). Also it is used only to minimum from two "max" values shared by both peers so it can easily happen that even your device support large MTU size of >200 bytes the other side supports only 50/100/150 and so lower value will be used.

  • So is it possible to fail communication if MTU is different from the value I expected? I tested with ble_uart example.

    When I set the MTU to 23, the server can send a packet with a GATT MTU longer than 20 using the double sending method.

    But when I modified MTU=16, pca10028 could not receive and recognize the packet with that server(iPhone) sent GATT_MTU longer than 13bytes. And I used nRF Toolbox app.

    Is this problem of server(iPhone) because iPhone expect 23 byte MTU but MTU was configured 16?

  • And does developer have to code these things one by one on both side?

  • First of all you cannot use ATT_MTU size lower than 23 bytes, that violates BT SIG Core specification and I believe Nordic stack doesn't allow it anyway. Note that this is just theoretical maximum, BLE uses smart PDU implicit sizing so the MTU/PDU you observe on radio depends on higher application data and if these are shorter then maximum there is no padding.

    When it comes to ATT_MTU negotiation then yes, you need to do some explicit step from higher level to be able to use it. However it looks differently on each platform. E.g. with Nordic's BLE stack it takes care about procedure itself (you can get event call back if you want to know that it happened), you just need to say during SD initialization what ATT stack size (including MTU) you want to use. On Android if you are a master (GAP Central + GATT Client) you need to call API to extend ATT_MTU. On iOS all is done automatically.

Related