Bluetooth: Delay advertising events instead of dropping them on collision

[wdhpawa]

Is your enhancement proposal related to a problem? Please describe.
Currently, an advertising event is dropped when it collides in time with a higher priority event, unless a sufficient number of consecutive advertising events have already been dropped, in which case the advertising event wins, and the higher priority event is dropped. Such collisions can be quite frequent when advertising is running in parallel with multiple connections, especially when some of those connections are carrying audio in large packets. When many advertising events are dropped, it may impair the ability of other devices to detect and connect to the advertiser, and the user may experience this as undesirable latencies and sluggishness.

Describe the solution you'd like
Instead of dropping the advertising event when there's a collision, the event should be rescheduled to the first free time slot in the future. To keep things simple, a time slot should only be considered free if it is large enough to hold the advertising event without overlapping any other events, i.e. priorities/aging should not be considered even if this would allow the advertising event to win over another event in an earlier time slot.

The total time between advertising events should probably be restricted to T_advEvent = advInterval + advDelay as specified in the Core spec v5.1 vol 6 part B section 4.4.2.2.1, where advDelay is a random value in the range 0 - 10 ms. So, if the first free slot corresponds to an advDelay larger than 10 ms, the event should probably be dropped. In order to stay within this limit when rescheduling (which may happen multiple times for the same event), the scheduler would need to store the actual time limit for the given event, until the event is either successfully executed or dropped.

This solution should significantly reduce the number of dropped advertising events as well as the number of other events dropped due to the aging of advertising events, thus increasing the responsiveness of the overall system. The randomization of advDelay would no longer have a flat distribution - large values would have a slightly higher probability than small values - but this is probably a small price to pay.

Describe alternatives you've considered
As mentioned, the spec sets an upper limit of 10 ms on advDelay, so the proposal is to drop the event rather than exceed this limit. However, dropping the event is also in a way equivalent to exceeding the limit (by a much larger amount), so would it actually be better to just ignore the limit? A downside of doing so, is that there would be no theoretical upper bound on how far into the future to search for a free time slot.

Instead of always delaying the advertising event to avoid a collision, one could consider allowing it to be advanced in time as well. This would reduce the risk of dropping events that are already close to the advDelay limit. However, I'm told that collision detection currently happens quite late, so it is not possible to advance the time. Also, if advancing were to occur frequently, it might cause a noticeable increase in average power, which would violate the spec.

Additional context
None.

[mtpr-ot]

I am looking into a ticker update design which would implement this.
The design proposal is as follows:

• Update ticker_start interface, or add new ticker_start_ext function, with a new parameter: ticks_slot_window
• The ticks_slot_window defines the window in which a ticker is allowed to re-locate an event. A ticks_slot_window value of '0' yields existing functionality.
• Setting ticks_slot_window to a non-zero value informs the ticker to attempt to re-schedule the event in case of collision. The event should be re-scheduled to the latest possible time within the window, where there's a free slot. This should be done in the bottom-half (ticker job).
• It should be discussed whether to re-schedule colliding events, even if they win the collision challenge.
• If there's no free slots within the ticks_slot_window, the event will be "lost" and the "lazy" count increased.
• For events which use edrift updates, e.g. ADV, it is important to take the randomized delay into considerations, to keep the event within the window. For ADV, the ticks_slot_window should be set to the equivalent of 10 ms (advDelay), and only reschedule within window minus advDelay.

This design enables "intelligent" scheduling with only a small processing overhead, and with a simple interface change.

[wdhpawa]

@mtpr-ot, why reschedule to the latest possible time? Shouldn't it be the earliest possible time? I don't think we want most rescheduled advs to end up at precisely the max possible time - that would completely eliminate their randomization.

[mtpr-ot]

@mtpr-ot, why reschedule to the latest possible time? Shouldn't it be the earliest possible time? I don't think we want most rescheduled advs to end up at precisely the max possible time - that would completely eliminate their randomization.

Yes, you're right that we have to be careful not to lose the randomization. However, we want to prevent aborting slave intra-event packets by scheduling early. Some compromise is needed I guess.