Questions about s132 scheduler. (Collision avoidance & rescheduling)

RE: Questions about s132 scheduler. (Collision avoidance & rescheduling)

Elias — Mon, 16 Jul 2018 14:24:52 GMT

Test answering. The question was updated.

RE: Questions about s132 scheduler. (Collision avoidance & rescheduling)

Susheel Nuguru — Fri, 13 Jul 2018 07:03:04 GMT

Unfortunately no calback, the softdevice manages the collision and the re-request everything by itself and the application cannot influence this. That is the reason, the application is not notified either.

RE: Questions about s132 scheduler. (Collision avoidance & rescheduling)

Elias — Fri, 13 Jul 2018 06:10:54 GMT

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

RE: Questions about s132 scheduler. (Collision avoidance & rescheduling)

Susheel Nuguru — Fri, 13 Jul 2018 05:46:51 GMT

[quote user=""]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?[/quote]

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.

RE: Questions about s132 scheduler. (Collision avoidance & rescheduling)

Susheel Nuguru — Thu, 12 Jul 2018 18:24:09 GMT

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.

RE: Questions about s132 scheduler. (Collision avoidance & rescheduling)

Elias — Thu, 12 Jul 2018 16:20:23 GMT

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.

RE: Questions about s132 scheduler. (Collision avoidance & rescheduling)

Susheel Nuguru — Thu, 12 Jul 2018 06:27:56 GMT

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.