Questions about s132 scheduler. (Collision avoidance & rescheduling)

[Elias]

I'm developing a peripheral with s132 v5.1.0 that supports multiple concurrent connections. I've looked at section 15 of the SoftDevice Spec and I have a couple of questions.

Section 15 of the SoftDevice Spec says "Activity B will be blocked and its timing-event will be rescheduled for a later time". What will this "later time" be? Simply the next time the timing-event would normally fire? For example, if the timing-event for an advertiser-role with an interval of 1s collides with the peripheral-role timing-event that was already scheduled, will there be just 2s between the advertising packets being sent?

Also, is there a way for the application to be notified of such a collision?

[Susheel Nuguru]

Hi Elias,

Softdevice has a Radio Event Manager (REM) that is a scheduler to manage Radio timeslot. When softdevice mentions scheduler, then it means a scheduler for Radio and not the CPU.

Since there is only one radio, there will be only one event at a time that would get the radio access. In your question, if the device has a connection and also is a advertiser (for example), then the REM (scheduler) makes sure that only one get the radio access based on the priority. Little confusing part is that the flash access uses the same REM scheduler since radio activity affects flash access, so they need to mutually exclusive. The easiest way to fix this problem was to give a radio time slot for flash access. That is while flash access, it is made sure that radio is off.

There could be collisions when both a connection and the advertising role requests REM a timeslot, at this time, the above mentioned priority is taken into affect and the one that wins is given radio access.

 

[Elias]

You didn't answer any of my questions. I understand priority. I'm asking about what happens to the event that doesn't "win" i.e. the one that gets rescheduled.

[Susheel Nuguru]

There is no event that participates in the scheduling, only roles participate and the role that doesn't win the current round participates in the next time slot scheduling.

What exactly do you mean by events here? in terms of softdevice, events are generated after a radio activity, maybe there is a little confusion between us regarding terminology.

[Susheel Nuguru]

Section 15 of the SoftDevice Spec says "Activity B will be blocked and its timing-event will be rescheduled for a later time". What will this "later time" be?

OK, I see your doubt here. When two roles are participating in a scheduling, they normally ask the scheduler for the timeslot. For example if the

scanner with scan window = 10ms , scan interval = 50ms  and

an existing connection with connection interval of 500 ms are participating in the scheduling asking for the time at the exact timeslot (collision), then for example the scheduler gives that time slot to the scanner (connection looses that round with the scheduler).Here due to the specifications, the connection will not participate in the next round of scheduling after the scanner is finished after 10ms. This is because the connection event would not like to start at a delay of 10ms. It would rather miss that slot but request a timeslot after 490 ms which it most likely would get. This is ok as there is supervision timeout and slave latency that alows a device to miss few connection events. When the role looses many time in scheduling and then the supervision timeout of the connection is about to expire, then the scheduler gives highest priority to the role so that it does not disconnect.

In short.

connection and adv roles if loses in the scheduling , they would be participating for the next interval of this respective role.

scanner if it looses in the scheduling, would be participating for the next available timeslot after the lost round.

 

[Elias]

And there is no callback or anything for collisions, correct? I'm not sure how we would use them in my application, but it would be "nice to know".