Multiple Connection BLE throughput optimization

[MarioG]

Hi,

we have a issue to find the right configuration to get the maximum throughput in a multiple connection scenario. 

In our setup, we are using one central and three peripherals. The PHY mode is 1M, the connection interval is 7.5ms, the MTU size is 247, DLE is enabled.

All peripheral devices sending big amounts of data to the central. The theoretical throughput should be ~60 kByte/s. But each device only reach 10 kByte/s - even if the other are only connected an not sending data. If all devices sending data, each device is limited to ~10kBate/s.

On the other hand: If we only connect one device to the central node, the maximum throughput of ~60 kByte/s is achieved. So, it seems to be someting about the multiple connection configuration optimization.

What could be the reason for this behavior?

[PjGlasso]

Hi there,

SO I have worked with this on another forum and interested in it.

Have you done any of these to test where it's bogging down?

Optimization Strategies

• Increase the Connection Interval (Experimentally): Try increasing the connection interval to a slightly higher value (e.g., 10ms, 15ms, or 20ms) and see if the aggregate throughput of all devices improves. A longer interval might allow for a longer, more efficient "burst" of data transfer for each device during its time slot, reducing switching overheads.
• Ensure "Write Without Response" or Notifications are Used: The operation type significantly impacts throughput. Using "write with response" or "indications" requires acknowledgment packets, adding overhead and latency. Using "write without response" (for central to peripheral) or "notifications" (for peripheral to central, which is your case) for bulk data transfer minimizes this overhead.
• Verify MTU and DLE Implementation: Your current settings (MTU 247, DLE enabled) are good for single-connection throughput. Ensure the central device is actually using the maximum packet length (251 bytes payload) and the full MTU for all three connections simultaneously and that no software limits are imposed.
• Adjust Connection Event Length Parameter (if available in the API): Some advanced BLE stacks allow you to configure the connection event length (e.g., NRF_SDH_BLE_GAP_EVENT_LENGTH in Nordic's stack) to allow more time for data exchange within a single event.
• Use LE 2M PHY (if supported): If both central and peripheral devices support Bluetooth 5 and the 2M PHY mode, switching to it will double the raw data rate, immediately improving potential throughput (though this is a hardware upgrade and not a configuration fix for existing hardware). 

The likely reason for the significant drop in throughput when connecting multiple peripheral devices is the scheduling limitation and bandwidth management of the central device. The central device has to service each connection sequentially within a given time frame, and the current configuration may not be optimized for sharing the available bandwidth efficiently among all connections. 

• Connection Interval Limitation: While a 7.5ms connection interval seems low, it might be too low when managing multiple connections. In some cases, a slightly longer connection interval can allow more packets to be exchanged within a single, longer connection event, which reduces the overhead associated with starting new events and potentially increases overall efficiency. 

HTH

GL :-) PJ 

[MarioG]

Hi, 

thx for the answer. Is there a wiki or webinar which show the basics about BLE? Especially influence Connnection Interval and Connection Event Length in a multi device scenario would be interesting.

We will check and test your suggestions.

Especially Connection Length parameter seems to be promising. How many packets can I send in one connection interval, assuming a higher interval like 40ms? Is the stack allowing to send multiple packets in one interval?

[Einar Thorsrud]

Hik

Bluetooth LE in the NCS is covered in Bluetooth Low Energy Fundamentals, which I advice you go through. It covers the basics, though it does not focus specifically on throughput and multiple connections.

You may also be interested in experimenting with the throughput sample. This again is not multi connection, but it lets you play with the effect of other important parameters like connection interval, packet length and event length.

With multi connection things are a bit different. If I understand you correctly, y ou will have one central connected to multiple peripherals. This means that the central has to schedule the connections. This is described in the SoftDevice Controller docuemtnation under Connection timing as a Central. A key point here is event length, and if all connections are the same, you must be able to fit all connections with their maximum event length within the connection interval (assuming the same event length and connnection interval for all connections). With this, you can get a fairly good utilization.

Note that generally, you will have less overhead with lnoger connection intefvals and event lengths. However, retransmissions always happen on the next connection event, so the approach depends on the use case.