Scheduling of Connection Events with multiple peripherals

[JDBK]

We are considering using BLE for a multi node network. I have been looking into how bandwidth would be shared between peripheral connections and the scheduling of the connection events. I have questions about the feasibility of a couple scenarios.

First is if we have a mix of higher and lower bandwidth peripheral devices, could we do something as follows:

Have 4 higher bandwidth devices that use a connection event time of 2.5ms and a connection interval of 12.5ms, and have 4 lower bandwidth devices that use a connection event time of 2.5ms and connection interval of 50ms. Thus in each 12.5ms interval, each higher bandwidth device could transmit, and one lower bandwidth device could transmit. Can the lower bandwidth devices be scheduled so each one's connection event falls in a separate 12.5ms interval?

Second question is about adaptability of connection event scheduling. I understand that a connection event must be terminated before the start of the next scheduled connection event. So the relative position of each connection event puts a hard limit on how many packets and thus how much data each connection can transmit (the connection bandwidth). If some connections are not using their available bandwidth, that bandwidth is effectively lost. So I am wondering if it is possible to change the connection event scheduling and timing on the fly in order to adaptively allocate bandwidth to each peripheral device.

For instance, if 4 peripheral devices are connected, each with an initial connection event time of 5ms and connection interval of 25ms, normally only the last scheduled connection event (device 4) could take advantage of the spare 5ms in the connection interval to send additional packets. But if the central was to know that device 2 had a burst of data it needed to send, is there any way its connection event time could be increased to 10ms without requiring additional overhead, or will the fact that the anchor points for the proceeding connection events will shift mean that the central would need to send a bunch of additional packets to make this change?

[JDBK]

Thank you Hung for your detailed response.

I do want to clarify one item. I understand that there is no priority given to any particular connections by the scheduler, but in my example of the 4 base interval and 10 long interval connections, if the application layer knows all the connections that need to be made, could it establish the 4 base interval connections first, which will fully allocate 4 of the timeslots and thus force the longer interval connections to share the remaining 6 timeslots, rather than having them sharing a timeslot with a base interval connection and cause collisions?

[JDBK]

One additional question. In most cases the peripheral device connections to the central will be static, but there will be a few devices that will have intermittent connections to the central, such as a phone app. These intermittent connections will likely need higher bandwidth when connected, and thus would use the base connection interval to get the most throughput. Say we have 10 timeslots where 9 are used for peripheral connections, and 1 is used for scanning. If the application layer wanted to ensure there was always a timeslot available for an intermittent connection device, could it allocate 2 slots to scanning while the device is not connected, then reduce it to 1 scanning slot when initiating connection to the intermittent device so there is guaranteed to be one fully open slot? Will the scheduler in this case preferentially select the fully open slot over slots that are partially allocated to longer connection interval devices?

Thanks.

[Hung Bui]

Hi John, 

As long as the long interval is the multiple of the base interval, i don't see why it would collide with the 4 base interval connections. If the number of slot you use is under the total time slots and if the long interval are multiple of the base interval, they shouldn't collide. 

Regarding the question of scanning, you can initially have a longer scan window vs the scan interval (high dutycycle) . Then you can reduce the scan window when the application knows that the timeslot is running out. 

But this should be done by the application. The BLE stack wouldn't know about this and the scheduler has no mechanism to automatically adjust the scan window. See the scheduling priorities here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/doc/scheduling.html

[JDBK]

Hi Hung,

I have an idea for how to manage the scheduling of connections for a multiple peripheral connection network as outlined in the attached file. Could you review this and let me know if you see any issues with this process. And can you let me know if you can answer my question at the end about scheduling a connection during a fully allocated base interval?

Thanks!

Scheduler management for multiple connections.pdf

[Hung Bui]

Hi John, 
I would suggestion to perform actual tests to have better understanding of the scheduler. 
As I mentioned it's a very simple scheduling mechanism on the softdevice. It doesn't know where should be the best timeslot to schedule a high bandwidth connection. What it does it to schedule the connection to the nearest available timeslot. 
When it's fully occupied, there will be collision if a new connection to be made and the scheduler priorities the connection that may get disconnection. 

 If the application layer wanted to ensure there was always a timeslot available for an intermittent connection device, could it allocate 2 slots to scanning while the device is not connected, then reduce it to 1 scanning slot when initiating connection to the intermittent device so there is guaranteed to be one fully open slot? 
=> You can reserve 2 timeslot for the scanner but as I mentioned, the scheduler doesn't know where it is better to schedule the new timeslot for the connection, it simply schedule it to the next available timeslot. So there will be a chance that it will schedule the timeslot that my occupy by longer connection interval. 

One tip I can give is that if the bandwidth is the top priority, you should choose 2Mbps PHY, it will double the bandwidth and make it easier for the scheduler. The draw back is shorter range.