Cancelled Timeslots in MPSL since upgrade to nRF Connect SDK v2.4.2

[B3rni]

Hello,

previously I was using the nRF Connect SDK v2.3.0. I have an application that is using the MPSL library where I am requesting a new earliest timeslot (with a duration of 3 ms) about every 250 ms. As the used BLE connection interval is 20 ms I typically never had any issues getting and executing the timeslot. Inside the timeslot I am using the radio, but it is still not critical when exactly the timeslot is executed. For this reason I was using the priority MPSL_TIMESLOT_PRIORITY_NORMAL. So, I typically got the timeslot every time, just sometimes scheduled a little bit later after a finished BLE interval. The main reason for the used priority is that I want to still ensure that the normal BLE traffic via the SoftDevice is prioritized over my timeslot. However, since the upgrade to nRF Connect SDK v2.4.2 I am constantly getting most of my requested timeslots cancelled. They seems that they always get scheduled but then cancelled due to a BLE event from the SoftDevice. In the old SDK version I always got the timeslot, just probably a little bit later after a BLE event.

In general it seems that changing the priority of my timeslot to MPSL_TIMESLOT_PRIORITY_HIGH solves the problem by still not  interfering with the SoftDevice. I also did some tests with lowering down the connection interval and also requesting timeslots more often (even several times inside a BLE connection interval) which seemed to be working without leaving out BLE transmissions (at least as long as I did not make the timeslot duration longer than the BLE connection interval).

Even though using the high priority timeslot seems to fix my problem, I still want to ask whether there has been an (intentional) change to the functionality of the MPSL that causes the described behavior? (I at least did not find something in the release notes.)

And whether it is correct as derived from my experiments that the SoftDevice still has a higher priority over my high priority timeslot?

[Hieu]

Hello B3rni,

And whether it is correct as derived from my experiments that the SoftDevice still has a higher priority over my high priority timeslot?

BLE activities scheduled by the SoftDevice Controller generally always have higher priority than timeslot requested by the application. You can see the priority documented here: Scheduling — nrfxlib 2.4.2 documentation (nordicsemi.com).

Even though using the high priority timeslot seems to fix my problem, I still want to ask whether there has been an (intentional) change to the functionality of the MPSL that causes the described behavior? (I at least did not find something in the release notes.)

From the Release Notes, between 2.3.0 and 2.4.2, I can see a few changes in 2.4.0 regarding BLE. Is your system just running BLE and your timeslot activities? Let me check internally to see if the changes in 2.4.0 is the reason for your observation.

Hieu

[Hieu]

Hello B3rni, 

Could you please also let me know:

• Are you using any BLE features besides the connection?
• What timeout did you use with your MPSL Timeslot request?

Hieu

[B3rni]

Hello Hieu,

thanks for your reply and your link, this is good to know how the scheduling priorities are. As indicated in the table the high priority timeslot has the same priority as normal BLE activity. So, if possible I would prefer using the normal priority timeslot. Or does the order of the list elements also indicate some kind of sub priority within one priority group?

I am just using one BLE connection, no other features. The timeout of the timeslot is set to 1 second, so I guess this value also should be high enough.

Best Regards,

Bernhard

[Hieu]

Hello Bernhard,

B3rni said:

Or does the order of the list elements also indicate some kind of sub priority within one priority group?

No there is no sub priority within each group. However, you can see that BLE events critical for maintaining a BLE connections are all already put in higher priority than that.

I will check with our SoftDevice Controller team and let me know if they can think of any cause for your issue.

Best regards,

Hieu

[Hieu]

Hello Bernhard,

A SoftDevice Controller engineer confirm that there was a change in the way connections are scheduled in order to make them more cooperative with other roles. This resulted in the change in timeslot request behavior you observed.

The BLE packets critical to maintaining the BLE link should still have a higher priority, so the reliability of the connection shouldn't be a concern.
However, during large data transfer scenario, non-critical packets will have to share the time slots with the ones the application requested, and you might see a lower throughput.

That should be the only impact towards BLE when you request timeslot with high priority. I hope that isn't a concern for you.

Best regards,

Hieu

[B3rni]

Hello Hieu,

thanks for your further investigation.

The behavior is for my application not 100% as intended. My plan was to stick to the low priority and probably just switch to the higher priority when I detect several cancelled or blocked timeslots in the application (in case of such a high throughput scenario). But in general it is fine for me. At least I now know which behavior to expect.

It is just a pity that (at least from my opinion) the low priority timeslots are not that useful anymore when most of them are likely to being cancelled even when just one BLE connection is used where there would be enough room for the timeslots and the timeout also being set high enough too reach such a spot in between BLE events.

Best Regards,

Bernhard