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

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

Michael — Thu, 24 Nov 2016 09:18:34 GMT

OK, I think I got it. I wrote a simple application that sends constant data continuously based on this project, and I got a data rate of 190kbps with an MTU of 158, but without DLE (27 byte packets). I can share the project if anyone is interested.

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

Ulrich Myhre — Thu, 24 Nov 2016 09:14:47 GMT

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.

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

Michael — Wed, 23 Nov 2016 12:16:52 GMT

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

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

Ulrich Myhre — Wed, 23 Nov 2016 10:15:20 GMT

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

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

Michael — Tue, 22 Nov 2016 08:05:25 GMT

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.

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

Ulrich Myhre — Mon, 21 Nov 2016 09:29:22 GMT

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!