[nRF52832 SDK12.1] Extended MTU with and without DLE

[Michael]

Hi,

I'm developing an application based on the nRF52832 and I need a large throughput of over 100kbps, preferably over 200kbps. I have managed to reach around 128kbps using an interval of 7.5ms and the 6 slots of the standard spec. However, I would like to extend the throughput further.

As per this question, it seems that it should be possible to extend the MTU in the GATT server up to 158 bytes, without using DLE (per BLE 4.2 spec).

As I understand it, this method still uses the regular (unextended) 27 byte packet but sends the 7 byte header once for the entire extended MTU instead of sending it for each and every packet. Am I correct?

After going over the documentation in the infocenter as well as the examples in SDK v12.1, I can't seem to find a clear explanation how to accomplish this.

Could you direct me to such information and/or example?

In addition, there doesn't seem to be an example on how to use DLE. In this case too, there isn't enough clear information on how to use it. Do you plan on adding an official example on this subject? that would be extremely helpful.

Thanks, Michael.

[Ulrich Myhre]

I can try to summarize a bit what extended ATT MTU and DLE actually do.

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).

When you increase the DLE size, you increase the maximum length of an on-air packet. It will not have any direct effect on throughput with the default ATT MTU, but will reduce the fragmentation and LL header overhead significantly when used in tandem with extended ATT MTU.

The Nordic Softdevices with DLE support also comes with the option to enable connection event extensions, which can further improve the throughput. Enabling this allows the SoftDevice to continue sending packets until the next connection event is scheduled, or the peer device runs out of receive buffers. With multiple active links, this will have little to no effect, but it gives huge gains on single links - especially if the connection interval is as long as possible. This might feel counter-intuitive to what has been previously learned, where you want the interval to be as short as possible, but there is quite a lot of overhead in opening and closing a connection event too.

To summarize quickly: Increasing ATT MTU gives longer logical PDUs, which are fragmented without L2CAP/ATT overhead. Enabling DLE gives longer on-air packets when needed. Connection events can be extended for further throughput, by increasing the number of packets sent per connection interval.

Hope this clears things up a bit!

[Michael]

Thank you Ulrich for this explanation. It does indeed clarify things. However, it would be helpful to look at example code to really understand the implementation of either solution. Specifically, it's not clear to me how the GATT server can initiate an MTU exchange.

[Ulrich Myhre]

GATT Server side and GATT Client side. The MSCs are very useful in describing various situations that can occur.

[Michael]

Thanks again Ulrich. I still don't see how the server can initiate the exchange MTU request.

[Ulrich Myhre]

The client initiates the MTU request, and the server responds. The relevant API calls, events and configurations needed in sd_ble_enable should all be in the MSCs I linked to.