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?

[Hung Bui]

Hi John, 
Could you let me know which SDK /Bluetooth stack you are using ? 

I assume you have looked at the scheduling documentation for the Softdevice controller ? It mentions about the Best Fit algorithm: 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/softdevice_controller/doc/scheduling.html#initiator-timing
Where the connection event be scheduled depends on which timeslot is free at the time the connection is established. 

Regarding your question, 

Can the lower bandwidth devices be scheduled so each one's connection event falls in a separate 12.5ms interval?

It can be scheduled right after the high bandwidth events. However, there is also a chance that the two low bandwidth event is scheduled right next to each other, just because it's when the scheduler find the free slot there. Something like this: 

Where the red ones are low bandwidth and blue ones are high bandwidth. It's largely depend on when the advertising packet is received and where the nearest free slot is. 

Regarding your 2nd question, you can take a look here: https://github.com/nrfconnect/sdk-nrfxlib/blob/main/softdevice_controller/include/sdc_hci_vs.h#L923

As you can find the connection event can only be extended if it doesn't conflict with other connection event.  So if they are allocated back to back it's not possible to extend over the connection event. 

My suggestion is to use a power profiler to visualize the scheduling on the central device (by looking at the power consumption you would know if the radio is active or not, and if it's in RX or TX mode). With the power profile you can find how the scheduler put each connection event in respective to each other. From that you may find the optimized configuration for your application. 

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