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]

Hi Hung,

Thanks for the reply. I am part of a technical committee that is looking at using BLE to replace a wired, peer to peer network, so at this point the design is purely conceptual in nature. I am just trying to figure out what is possible or feasible.

It appears that it is not possible to dynamically change how much bandwidth is available to each peripheral connection. So I think we will be stuck with having fixed bandwidth allocations based on the connection event time and connection interval. My understanding is that the application will have little control over the scheduler beyond these parameter values. It's not ideal from a network performance standpoint, but is a limitation if we want to leverage the BLE architecture and protocol.

While bandwidth cannot really be shared between connections, I think it can be shared between the Rx and Tx directions if the max packet size is set properly and data length extension is used. Then if Tx data is minimal, it should allow for additional Tx/Rx packet pairs in the event, and thus allow additional Rx throughput.

[Hung Bui]

Hi John, 

I think what you are looking for is the new "Connection Subrating" feature added in Bluetooth 5.3: https://www.bluetooth.com/blog/new-core-specification-v5-3-feature-enhancements/

However, since it's relatively new it's a feature that we don't support in our latest SDK. 

So for now what you can do is to change the connection interval when you need to have more bandwidth for a connection. The draw back is that it take a few connection event until the new interval is updated. 

From my point of view, BLE in essential not made for high bandwidth complex communication. As the name suggested "Bluetooth Low Energy" focuses on the low energy aspect. The scheduler is designed for simplicity and robustness, not high performance and complexity. 

JDBK said:

While bandwidth cannot really be shared between connections, I think it can be shared between the Rx and Tx directions if the max packet size is set properly and data length extension is used. Then if Tx data is minimal, it should allow for additional Tx/Rx packet pairs in the event, and thus allow additional Rx throughput.

Yes correct. As long as you don't use up the connection event length you can add more pair of TX/RX into the event. So if you limit the TX period you can have longer time for RX. 

[JDBK]

Hope it is okay to revive this thread. I'm doing some more work on the wireless network standard and have some more questions.

Regarding the scheduler, when setting up a new connection, does the scheduler automatically determine the required connection event time based on the max PDU of the Rx and Tx packets, or is it possible to tell the scheduler to reserve a certain minimum connection event time? Just wanting to know if it is possible to set up specific time slots for connection events that allow for multiple transmissions of shorter packets if we wanted to try to mitigate for packet losses in a high BER environment.

Further regarding the scheduler, if we were to set up connection event time slots, say ten 5ms slots in a 50ms base connection interval (ignoring any scanning time for now). And say there were 4 connections using the base 50ms interval and another 10 using an interval of 200ms. If the 10 longer interval connections happened to get scheduled first and took up all 10 slots within one 50ms interval, would the scheduler fail when trying to connect the 4 base interval connections, or would it still schedule them event though it will result in collisions with the other events every 200ms? Is it possible for the application to prioritise the base interval connections by initializing those connections before the longer interval connections? I realize that assumes the application is first aware of all the connections that are to be made.

I have a separate question on retransmissions. If one side of a connection receives a packet that fails verification, will it always have to wait until the next connection event to receive a retransmission, or if there is enough time within the current connection event, is it possible to receive a retransmission in the same connection event?

Finally, regarding the new connection subrating feature, does this only apply to isochronous connections, or can it be used with any standard ATT type connections as well? Do you know if support will be added for this and what the timeline might be if it is?

Thanks.

[Hung Bui]

Hi John, 

JDBK said:

Regarding the scheduler, when setting up a new connection, does the scheduler automatically determine the required connection event time based on the max PDU of the Rx and Tx packets, or is it possible to tell the scheduler to reserve a certain minimum connection event time? Just wanting to know if it is possible to set up specific time slots for connection events that allow for multiple transmissions of shorter packets if we wanted to try to mitigate for packet losses in a high BER environment.

You can set the default event length using (sdc_hci_cmd_vs_event_length_set() ) by default the event length is 7.5ms. There can be several RX, TX packet in a connection event so it can't use the max PDU to decide the event length. 

But there is also event length extension option, so that the softdevice controller can extend an event length (with the limitation of the connection interval and that it doesn't collide with other connection when extending). See here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/doc/scheduling.html#connection-timing-with-connection-event-length-extension

JDBK said:

Further regarding the scheduler, if we were to set up connection event time slots, say ten 5ms slots in a 50ms base connection interval (ignoring any scanning time for now). And say there were 4 connections using the base 50ms interval and another 10 using an interval of 200ms. If the 10 longer interval connections happened to get scheduled first and took up all 10 slots within one 50ms interval, would the scheduler fail when trying to connect the 4 base interval connections, or would it still schedule them event though it will result in collisions with the other events every 200ms? Is it possible for the application to prioritise the base interval connections by initializing those connections before the longer interval connections? I realize that assumes the application is first aware of all the connections that are to be made.

There will be collide and some connection event will need to be skipped. They will by turn being preempted by the other connection event when they overlap. See here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/nrfxlib/softdevice_controller/doc/scheduling.html#connection-timing-as-a-central
There is no prioritization configuration that the application can tell a connection is more important than the other. The scheduler is designed with simplicity and robustness as the most important feature. It doesn't give much for the application to configure (which is a good thing as more complex system tend to bring more trouble than the benefit). 

JDBK said:

I have a separate question on retransmissions. If one side of a connection receives a packet that fails verification, will it always have to wait until the next connection event to receive a retransmission, or if there is enough time within the current connection event, is it possible to receive a retransmission in the same connection event?

Correct, it needs to wait for the next connection event. There is no way the device would know if the peer will continue with the current connection event or not if the current packet is corrupted.

JDBK said:

Finally, regarding the new connection subrating feature, does this only apply to isochronous connections, or can it be used with any standard ATT type connections as well? Do you know if support will be added for this and what the timeline might be if it is?

My understanding is that it's for normal ACL as well. But I don't have the timeline on when it will be implemented. For now you would need to use connection interval update which takes about 6 connection events for the new parameters to take place. 

[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