BLE Dual-Role is it possible to switch roles?

[csulz]

Hello, I have a question that I can not answer myself searching the available documentation. 

The application that we are developing is intended to be one set of firmware that is installed on multiple devices. I have already made it possible for a device to both advertise and scan, and any device can become a BLE Central or Peripheral based on which device connects to which. Additionally devices can connect to multiple other devices, and this creates a network of devices. Each device on the network is basically randomly connected as central to some devices and peripheral to other devices.

We are now moving to a development phase where we are trying to optimize for throughput. I have read through pretty much all the available documentation on how to achieve maximum throughput and the difficulties related to scheduling multiple concurrent central connections. My concern now is mainly to deal with how the peripheral role is managed, and comes down to this tidbit in this document:

infocenter.nordicsemi.com/.../ble_data_throughput.html

Throughput may be reduced if a peripheral link is running because peripheral links are not synchronized with central links. If a peripheral link is running, throughput may decrease to half for up to two central links and the peripheral link

I understand that the schedule of a peripheral link is managed by the central on the other end, and we can deal with that and have plans to mitigate peripheral-central collisions in the overall network. 

Now to my actual question: once a BLE connection is established between a central and a peripheral, is it at all possible for the peripheral to become the central? This will allow the former-peripheral to take control of the connection event scheduling. Our idea was for the devices on the network to be able to reconfigure once the BLE connections are made, but I don't know if this is actually possible without having the devices disconnect and reconnect in the opposing roles. 

[tesc]

Hi,

The main consideration, and reason behind (a worst-case of) half throughput for "up to two central links and the peripheral link", is clock drift. Connection events in BLE are initiated by the central, as the central sends the first packet of the connection event. Packets are then sent back-and-forth, until any side decides there is no reason to continue sending packets. (The other side then gets no response, and therefore considers the event to be over.)

The peripheral wakes up a short time before the event, to guarantee that it is listening in case the central clock is slightly faster than the peripheral clock, subject to the accuracy of the clocks for both central and peripheral. Similarly, the peripheral listens past the start time of the event, in case the central clock is slightly slower than the peripheral clock. The peripheral then calculates when the next event will start, based on when the current event actually started. This is the mechanism for ensuring the connection is kept running, even in the face of drifting clocks. The central clock is the reference clock for the connection. At the start of every connection event, the peripheral synchronizes the timing for that particular connection with the central, based on the exact reception timing of the first packet of the connection event.

What this all means in practice, is that there is no synchronization mechanism which allows for two devices to synchronize their respective clocks used for their various connections. Connections as peripheral will therefore drift into collisions, even if you theoretically time them perfectly.

With two links as central (they will be scheduled back-to-back locally and never overlap with each-other) and one as peripheral, the latter will at some point drift to cover partly both of the two former. The scheduling will typically then, alternate between running the central events and running the peripheral event, since in case of conflict it typically provides priority in a round-robin fashion. This is when you will experience half throughput. For more information about the scheduling, see SoftDevice timing-activities and priorities.

Now to your actual question: BLE roles are fixed for the duration of the connection. The only solution for a role switch would be, as you suggest, to disconnect then reconnect with opposite roles. (I.e. the former central start advertising; the former peripheral start scanning and initiating connection.)

Please take into consideration the drifting mentioned above, and the fact all connections are tied to the clock of the central, for building your network of devices. In practice a star network of a central connecting to multiple peripheral (and peripherals only connecting to the one and only central) on the one hand guarantees throughput, but on the other hand introduces the single central as a bottleneck. Any configuration where a node act in both central and peripheral role is guaranteed to have intermittent overlaps.

To some extent, having different connection intervals for the various connections may in some cases have better effect than trying to time everything perfectly. It would result in more frequent collisions, but if intervals are chosen carefully would also guarantee collisions are not happening several times in a row. The total number of collisions would be roughly the same, but they would be evenly spread out instead of appearing in bursts.

Regards,
Terje

[csulz]

Now to your actual question: BLE roles are fixed for the duration of the connection. The only solution for a role switch would be, as you suggest, to disconnect then reconnect with opposite roles. (I.e. the former central start advertising; the former peripheral start scanning and initiating connection.)

This is what I thought. We were considering the case where a new node on the fringe of the network could only connect to another node that had all it's peripheral 'slots' used up with active connections, it would not be able to join the network as a central and would instead have to advertise and become a peripheral instead. 

Thank you for the additional information, it clears some things up even though it's not all new information. 

To some extent, having different connection intervals for the various connections may in some cases have better effect than trying to time everything perfectly. It would result in more frequent collisions, but if intervals are chosen carefully would also guarantee collisions are not happening several times in a row.

It is encouraging to see you recommend this as I had a similar idea. My idea was that if each node when acting as a central had a different connection interval then at the very least peripheral events (from other centrals) would not exactly overlap the central event schedule. The chance of collision remains the same, but with the peripheral events happening at different times but at least the collisions wouldn't appear in bursts as you say. Do you see any issues with this?

Since I have you here, would you be willing to answer some related questions. 

1. There is the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL, assuming these two values are not the same, how does the SoftDevice choose the actual Connection Interval? Also assume the peripheral has the same values configured for it's preferred parameters. 
2. In addition there is NRF_SDH_BLE_GAP_EVENT_LENGTH, does this define the Connection Event length? 

Thank you.

[tesc]

Hi,

csulz said:

The chance of collision remains the same, but with the peripheral events happening at different times but at least the collisions wouldn't appear in bursts as you say.

Exactly. The trade-off is in when the collisions happen.

csulz said:

Do you see any issues with this?

Try to select intervals that are not multiples of each other or otherwise share common factors. That is, ideally choose intervals that are relatively prime, or intervals that are very close (but just far enough apart that two consecutive events will not collide.) That way, you will not end in a situation where every Nth event, for a small value of N, collides, until the clocks drifts out of that "perfect hit" timing.

One potential issue is that for the central role, connections of equal interval are scheduled back-on-back, so a connection as peripheral with slightly different interval would collide with a different connection as central each time. From what I understand, the scheduling should still prioritize every other event for the connection as peripheral.

I would expect the best performance when all connections as central use the same interval, since then at least those connections will never overlap. (Provided the intervals and event lengths result in less than 100 % duty cycle.)

csulz said:

There is the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL, assuming these two values are not the same, how does the SoftDevice choose the actual Connection Interval?

I have not found an answer to this question, but the recommendation if you need exact control of the connection interval is to set both of those to the same value, on the central. The central device is the one deciding the interval. For peripheral you can set a wide range, to ensure the peripheral will accept to stay in connections regardless of what interval it is given from the central.

csulz said:

In addition there is NRF_SDH_BLE_GAP_EVENT_LENGTH, does this define the Connection Event length? 

This defines the (maximum) length of the connection event, yes. The event will last shorter if one of the devices stops sending packets. Typically "I have nothing more to send" is indicated by an empty PDU, which the SoftDevice will do if it has nothing to send for that connection event.

Regards,
Terje

[csulz]

Thank you for all of the information, it's all very useful.