ATT MTU for multi link and event length setting

[eric ding]

Hi Team,

S132 V5.0 for nRF52832 can support up to 20 links.

If the connected links have different ATT MTU setting, what is the behavior of the device/softdevice regarding effective MTU setting?

Will it needs to negotiate MTU again with all previous established link peers, and use the smallest requested MTU value?

Another question is about the NRF_SDH_BLE_GAP_EVENT_LENGTH setting as you can see in below picture.

This value is highly related to the ATT MTU size and also the connection interval.

Improper setting will result in sd_ble_gap_data_length_update() return error value " NRF_ERROR_RESOURCES "

What may be the correct method to set this value? 

I heard there may be a calculator or something ?

Thanks

B.R

Eric

[MartinBL]

Hi,

I'm not sure if I understand your questions.

Will it needs to negotiate MTU again
As of S132 v4.0.x the MTU length can be individually configured per link. I don't see why the Softdevice would have to renegotiate anything.

What may be the correct method to set this value? 
How this should be done is described in the S132 Migration Guide. If you get the NRF_ERROR_RESOURCES error you should inspect the p_dl_limitation parameters to find the limits, as is stated in the sd_ble_gap_data_length_update() documentation.

I'm not aware of any calculators, but there is quite a lot of information about how to optimize connection parameters here: S132 Scheduling.

 

[eric ding]

Hi MartinBL,

As of S132 v4.0.x the MTU length can be individually configured per link.

So in a scenario one central needs to connect to two peripherals which have different MTU size, then what your are saying is that the central will keep two different effective MTU for each of the peripheral/link? 

I thought there is only one effective MTU for the central.

How about S132 v3 which unfortunately the customer is using? how will it handle this kind of scenario?

thanks.

B.R

Eric

[MartinBL]

Hi,

I talked to the Softdevice team and they say that our centrals have always had support for different effective MTUs per link. Although on S132 v3 all links shared the same MAX_MTU size and the softdevice allocated memory thereafter. This means that even though this configured all links to support 512 bytes, it didn't mean that all links had to use 512 bytes long MTUs. So for example, if you first connected device #1 and used 512 bytes MTU, and then connected device #2 and used 128 bytes MTUs, then the central would not re-negotiate anything with device #1, but indeed use 512 bytes long MTUs on link #1 and 128 on link #2.

Best regards

Martin

[eric ding]

Hi Martin,

S132 v3 seems fine to me now, all links share the same MAX_MTU and different links can have different effective MTUs.

I investigate further on the latest S132 v5.x, it still confuses me on the MTU setting per link.

I looked at the source code and found there are two related MTU settings in the SDK v14.x, one is during BLE stack configuration, the other is in Gatt module.

• BLE stack configuration -- sd_ble_cfg_set()

In function nrf_sdh_ble_default_cfg_set(), sd_ble_cfg_set() is called to set the MTU. This is connection specific setting using connection config tag.

Does it mean for different link MTU setting, different connection config tag is needed?

 

• Gatt module

During Gatt init, MTU is also set for peripheral, central and every links.

I don’t know why there are MTU settings for peripheral and central considering there is already setting for each link?

• MTU exchange

The actual parameters used for MTU exchange are the peripheral or central MTU settings.

So I don’t understand the purpose of MTU setting on the BLE stack init and link init?

And I’m confused on how to set different desired MTU for different links?

Could you help to shed some lights on this and give your comments?

Thanks.

B.R

Eric

  

[MartinBL]

I found this quite confusing myself, but I contacted the creator of the GATT Library who gave me an explanation. 

When you configure MTU sizes in ble_stack_init(), you are informing the Softdevice what the maximum MTU sizes will be. The softdevice will then allocate resources like RAM accordingly (this is why you might need to change your RAM settings after making changes to your BW configuration). You can use tags to make the Softdevice allocate resources for several different configurations. So once again, these configurations are preparing the Softdevice for "worst case" scenarios, and doesn't necessarily mean that these exact configurations will be used in the links. 

That is where the GATT Library comes in to play. When a new link is established it is up to the GATT library to negotiate what MTU lengths will actually be used in each particular link. And during the negotiations it will use the configuration you did in ble_stack_init() as boundaries. 

PS: Next week it is Easter holiday in Norway and response time might be slow. 

BR, 
Martin

[eric ding]

HI Martin,

That explains it.

Thanks