Most Bluetooth modules in production today are not serving a single peer — they are managing 3, 5, or even 20 concurrent connections to sensors, smartphones, gateways, and actuators. Multi-connection management is where junior BLE engineers discover that connection interval, slave latency, MTU size, PHY rate, and data length extension are not independent knobs but a tightly coupled scheduling problem. Get one wrong and you get intermittent disconnects, 400 ms latency spikes, or throughput that never exceeds 30 kbps despite a 2 Mbps PHY. This article breaks down the scheduler model, derives throughput and latency budgets from first principles, and benchmarks real silicon.
1. The BLE Connection Event Model
A BLE connection is not a continuous link — it is a periodic appointment. The master (central) and slave (peripheral) agree on a connection interval (T_interval), and within each interval there is one connection event where both radios are active. The master transmits first, the slave responds, and they may exchange multiple PDUs in a ping-pong within that event. When there is no more data, or when the connection event is extended beyond its allotted time, the radios sleep until the next interval.
Key parameters defined in LL_CONNECTION_PARAM_REQ:
- Connection Interval (connInterval): 7.5 ms to 4.0 s, in 1.25 ms steps. This is the period between connection events.
- Slave Latency (connLatency): 0 to 499. The peripheral may skip this many consecutive events without being disconnected. Each skipped event saves ~1 ms of radio-on time.
- Supervision Timeout (supervisionTimeout): 100 ms to 32 s. If no packet is received within this window, the link is terminated. Must satisfy: supervisionTimeout > (1 + connLatency) × connInterval × 2.
The connection event duration is not fixed — it is bounded by the lesser of (a) the data available to send, (b) the connection event length negotiated in LL_CONNECTION_PARAM_REQ, and (c) the radio’s maximum event time. For nRF52840, the default max event length is 40 ms but can be configured up to 4000 ms via sd_ble_gap_conn_evt_lengths_set(). For CC2640R2F, the max event length is controlled by the GAPBondMgr parameter set.
2. Multi-Connection Scheduling: Time Division
When a module acts as central with N peripherals, the scheduler must place N connection events within each interval. The fundamental constraint is that only one radio transaction occurs at any given instant — BLE is half-duplex on a single channel. The scheduler assigns each connection a time slot within the interval:
| Connection | Interval | Event Offset | Event Duration | Notes |
|---|---|---|---|---|
| Conn A | 30 ms | 0 ms | 3 ms | Sensor, low data |
| Conn B | 30 ms | 5 ms | 8 ms | Audio stream |
| Conn C | 60 ms | 15 ms | 3 ms | Every other interval |
| Conn D | 100 ms | 20 ms | 2 ms | Slave latency = 4 |
The scheduler must ensure no two events overlap. With 4 connections at 30 ms interval, if each event is 5 ms, total active time is 20 ms out of 30 ms — a 67% duty cycle. At 8 connections, 40 ms of events would overflow the 30 ms interval, causing the scheduler to push some events to the next interval, effectively doubling their latency.
2.1 Maximum Concurrent Connections by Chip
| Chip | Max Central | Max Peripheral | Max Total | Limiting Factor |
|---|---|---|---|---|
| nRF52840 | 20 | 20 | 20 | RAM (8 KB per conn) |
| nRF52832 | 7 | 7 | 7 | RAM (64 KB total) |
| CC2640R2F | 8 | 3 | 8 | TI-RTOS scheduler |
| BGM220SC | 8 | 4 | 8 | Gecko stack limit |
| ESP32-C3 | 9 | 3 | 9 | Bluedroid/NimBLE |
| ESP32 (dual-core) | 15 | 4 | 15 | Bluedroid |
The nRF52840’s 20-connection limit is not a silicon ceiling — it is the SoftDevice’s compiled maximum. Each connection consumes approximately 8 KB of RAM for the link layer context, TX/RX buffers, and L2CAP state. At 20 connections, that is 160 KB of the 256 KB RAM, leaving 96 KB for application code. The ESP32-C3 with NimBLE achieves 9 connections in 60 KB of heap — significantly more memory-efficient.
3. Throughput Budget Calculation
BLE throughput is often quoted as “2 Mbps PHY = 2 Mbps throughput.” This is wrong by a factor of 3-5×. The actual throughput depends on a chain of overheads:
3.1 PDU Overhead Chain
Each data PDU carries: 1 byte preamble + 2 byte access address + 2 byte header + 2 byte length + payload + 3 byte CRC = 10 bytes overhead per PDU. At 2 Mbps PHY, 10 bytes takes 40 μs. For a 251-byte payload (DLE max), total PDU time = (10 + 251) × 8 / 2,000,000 = 1.044 ms. The 10-byte overhead is 3.8% — acceptable. But for a 20-byte payload (default), overhead is 33%.
3.2 Inter-Frame Space (IFS)
Between master PDU and slave PDU, the BLE spec mandates a 150 μs inter-frame space (T_IFS). This is dead time — the radio is on but not transmitting. In a single PDU exchange (master sends, slave responds), IFS consumes 300 μs out of the cycle. For 251-byte payloads at 2 Mbps: cycle = 1.044 ms + 0.150 ms + 1.044 ms + 0.150 ms = 2.388 ms. Throughput = 251 × 8 / 2.388 ms = 840 kbps. That is 42% of the raw 2 Mbps.
3.3 Connection Event Packing
Within a connection event, multiple PDU exchanges can occur. The number of exchanges per event depends on the event length and packet size:
| Config | PHY | MTU | DLE | Payload/PDU | Exchanges/Event | Throughput |
|---|---|---|---|---|---|---|
| Default | 1M | 23 | 20 | 20 B | 4 | ~53 kbps |
| MTU 247 | 1M | 247 | 20 | 20 B | 4 | ~53 kbps |
| MTU 247 + DLE | 1M | 247 | 251 | 244 B | 4 | ~650 kbps |
| MTU 247 + DLE | 2M | 247 | 251 | 244 B | 8 | ~1,300 kbps |
| MTU 247 + DLE | 2M | 247 | 251 | 244 B | 16* | ~1,600 kbps |
*16 exchanges per event requires a 38 ms event length with 2M PHY. At 30 ms connection interval, this would consume the entire interval for a single connection — feasible only if there is one active connection.
3.4 Throughput Formula
The practical single-connection throughput formula:
Throughput = (payload_per_PDU × 8) / (T_PDU_master + T_IFS + T_PDU_slave + T_IFS) × min(exchanges_per_event, floor(event_length / cycle_time))
Where:
- T_PDU = (10 + payload_bytes) × 8 / PHY_rate
- T_IFS = 150 μs
- cycle_time = T_PDU_master + T_IFS + T_PDU_slave + T_IFS
- exchanges_per_event = floor(event_length / cycle_time)
- event_length = min(negotiated_event_length, connInterval × 0.9)
For multi-connection scenarios, divide by the number of active connections sharing the interval. With 4 connections at 30 ms interval and 5 ms events each: each connection gets 5 ms per 30 ms = 16.7% of airtime. At 2M PHY with 244-byte payloads, 5 ms allows ~3 exchanges: throughput per connection = 244 × 8 × 3 / 30 ms = 195 kbps. Total aggregate = 780 kbps — still well below the 2 Mbps raw rate.
4. Latency Analysis
4.1 Best-Case and Worst-Case Latency
For a peripheral sending a notification to a central, the latency depends on when the data is ready relative to the next connection event:
- Best case: Data is ready just before the connection event. Latency = event processing time ≈ 1-3 ms.
- Worst case: Data is ready just after the connection event. Latency = connInterval + event time ≈ connInterval.
- Average case: Latency ≈ connInterval / 2.
With slave latency > 0, the peripheral may skip events. If connLatency = 3 and connInterval = 30 ms, the effective interval is 120 ms. Worst-case latency jumps to 120 ms. Slave latency saves power but increases latency proportionally — there is no free lunch.
4.2 Latency Under Multi-Connection Contention
When N connections share an interval, the scheduler staggers events. If connection B’s event is scheduled at offset 15 ms within a 30 ms interval, and data arrives at the peripheral just after B’s event ends, the worst-case latency becomes connInterval + scheduling_offset = 30 + 15 = 45 ms, not 30 ms. With 4 connections at 30 ms interval, worst-case latency can reach 2 × connInterval = 60 ms if the scheduler pushes the event to the next interval due to contention.
| Connections | Interval | Best Latency | Avg Latency | Worst Latency |
|---|---|---|---|---|
| 1 | 30 ms | 2 ms | 17 ms | 32 ms |
| 2 | 30 ms | 2 ms | 17 ms | 47 ms |
| 4 | 30 ms | 3 ms | 25 ms | 62 ms |
| 8 | 30 ms | 5 ms | 45 ms | 120 ms |
| 4 | 7.5 ms | 2 ms | 6 ms | 15 ms |
Reducing connInterval from 30 ms to 7.5 ms cuts worst-case latency from 62 ms to 15 ms but increases radio duty cycle by 4×, reducing battery life proportionally. The 7.5 ms minimum interval is rarely used in battery-powered designs because the radio-on overhead (preamble, access address, CRC, IFS) becomes a larger fraction of the useful data time.
5. Connection Parameter Negotiation
The central sets the initial connection parameters, but either side can request a change via LL_CONNECTION_PARAM_REQ (BLE 4.1+). The procedure is:
- Initiator sends LL_CONNECTION_PARAM_REQ with preferred parameters and an instant (offset).
- Responder accepts or sends LL_CONNECTION_PARAM_RSP with counter-proposal.
- Parameters take effect at the negotiated instant (6 connection events later minimum).
Common negotiation failure: the peripheral requests connInterval = 10 ms but the central’s scheduler cannot fit it alongside existing connections. The central rejects or counter-proposes 30 ms. iOS is particularly restrictive — Apple’s Accessory Design Guidelines mandate connInterval between 15 ms and 30 ms, slave latency ≤ 29, and supervision timeout between 2 s and 6 s. Android is more flexible but some OEM stacks reject intervals below 10 ms.
6. PHY Update and Data Length Extension
6.1 PHY Update Procedure (BLE 5.0+)
The LL_PHY_REQ procedure allows either side to request a PHY change. Coded PHY (125 kbps or 500 kbps) trades throughput for range — useful for asset tracking where range matters more than data rate. 2M PHY doubles raw data rate, halving PDU airtime and IFS proportionally.
Critical timing: the PHY update takes effect at a specific connection event (instant). During the transition, both sides must be on the new PHY simultaneously. If either side misses the instant (due to packet loss), the connection survives but the PHY remains unchanged — retry is needed. In practice, PHY update success rate is >99% at close range but drops to 85-90% at the edge of range where packet loss is high.
6.2 Data Length Extension (DLE)
DLE (BLE 4.2+) increases the maximum PDU payload from 27 bytes to 251 bytes. The LL_LENGTH_REQ procedure negotiates the supported max RX/TX lengths and times. Key insight: DLE negotiation is independent of MTU negotiation. MTU is an L2CAP-layer parameter; DLE is a link-layer parameter. Both must be increased to realize the throughput benefit:
- MTU only (no DLE): L2CAP fragments 244-byte SDU into 9 × 27-byte PDUs. 9 PDUs × 10-byte overhead = 90 bytes wasted.
- DLE only (no MTU increase): Single PDU carries 251 bytes but L2CAP still fragments at 23-byte MTU. Application sees 20-byte payloads.
- Both: Single PDU carries 244-byte payload, single L2CAP fragment, minimal overhead.
7. Channel Map and Adaptive Frequency Hopping
BLE uses 37 data channels (0-36) in the 2.4 GHz band, hopping per connection event. The central provides a channel map via LL_CHANNEL_MAP_REQ, marking channels as “used” or “unused.” Unused channels are remapped to used channels via a pseudo-random hop algorithm.
In multi-connection deployments, each connection has its own hop increment (5-16) and channel map. With 4 connections, there will inevitably be moments when two connections land on the same channel in the same interval — the scheduler resolves this by time-division, not channel-division. The channel map update takes effect 6 connection events after the LL_CHANNEL_MAP_REQ instant, similar to PHY update.
Practical tip: in Wi-Fi coexistence scenarios, mark channels that overlap with Wi-Fi channel 1 (BLE channels 0-10), 6 (channels 11-20), or 11 (channels 21-30) as unused. This reduces the channel map to 7 usable channels, increasing collision probability but eliminating Wi-Fi interference. The trade-off is measurable: with 37 channels, packet loss is ~2% in a clean environment; with 7 channels, it rises to ~8% under the same conditions.
8. Scheduler Conflict Resolution
When two connections’ events are scheduled to overlap, the scheduler must decide which to prioritize. The three common strategies:
| Strategy | Description | Pros | Cons |
|---|---|---|---|
| Strict Priority | Higher-priority connection always wins | Predictable for critical links | Starvation of low-priority connections |
| Fair Round-Robin | Rotate which connection gets the slot | No starvation | Unpredictable latency for all |
| Earliest Deadline First | Serve the connection closest to supervision timeout | Minimizes disconnects | Complex, requires deadline tracking |
nRF52 SoftDevice uses a modified fair round-robin with a soft priority system: connections with shorter intervals get more scheduling slots. The ESP32 Bluedroid stack uses strict priority with the first connection getting highest priority — a known issue that causes the 9th connection to experience 2× latency compared to the 1st. NimBLE on ESP32-C3 implements EDF and shows 15-20% better latency distribution under load.
9. Power Consumption Under Multi-Connection
Each active connection event consumes radio current. For nRF52840 at 0 dBm, 1M PHY:
- RX current: 5.4 mA
- TX current: 4.6 mA
- Average per connection event (3 ms, 2 exchanges): ~5 mA × 3 ms = 15 μC
- Base current (sleep, RTC, RAM retention): 1.5 μA
With 4 connections at 30 ms interval (3 ms events each), per-interval charge = 4 × 15 μC = 60 μC. Average current = 60 μC / 30 ms = 2.0 mA + 1.5 μA base ≈ 2.0 mA. On a CR2032 (220 mAh), lifetime = 220 / 2.0 = 110 hours = 4.6 days. This is why multi-connection central devices typically use Li-ion or USB power, not coin cells.
| Connections | Interval | Event Length | Avg Current | CR2032 Life |
|---|---|---|---|---|
| 1 | 30 ms | 3 ms | 0.5 mA | 18 days |
| 2 | 30 ms | 3 ms | 1.0 mA | 9 days |
| 4 | 30 ms | 3 ms | 2.0 mA | 4.6 days |
| 8 | 30 ms | 3 ms | 4.0 mA | 2.3 days |
| 4 | 100 ms | 3 ms | 0.6 mA | 15 days |
| 4 (latency=3) | 100 ms | 3 ms | 0.15 mA | 61 days |
The last row shows the power of slave latency: 4 connections at 100 ms with latency 3 means each peripheral only wakes every 400 ms. Average current drops to 0.15 mA — a 13× improvement. But worst-case latency increases to 400 ms. For sensor networks where 400 ms latency is acceptable (e.g., temperature monitoring), this is the optimal configuration.
10. Real-World Benchmark: 4-Connection Hub
Test setup: nRF52840 DK as central, 4 × nRF52832 peripherals. All at 1M PHY, MTU 247, DLE 251. Connection interval 30 ms. Each peripheral sends 244-byte notifications at maximum rate.
| Metric | 1 Conn | 2 Conn | 4 Conn |
|---|---|---|---|
| Throughput/conn | 712 kbps | 681 kbps | 523 kbps |
| Aggregate | 712 kbps | 1,362 kbps | 2,092 kbps |
| Avg latency | 16 ms | 19 ms | 28 ms |
| P99 latency | 31 ms | 45 ms | 72 ms |
| Disconnects/hr | 0 | 0 | 0.3 |
Per-connection throughput drops by 27% from 1 to 4 connections, but aggregate throughput nearly triples. The P99 latency at 4 connections is 72 ms — 2.4× the average. The occasional disconnects at 4 connections are caused by supervision timeout edge cases where two connections’ events collide and neither can be serviced in time. Increasing supervision timeout from 2 s to 4 s eliminates these disconnects at the cost of slower failure detection.
11. Common Design Pitfalls
- Enabling 2M PHY but keeping MTU at 23: The 2M PHY halves PDU airtime, but with 20-byte payloads, overhead is 33% and the throughput gain is only ~15%. Always pair 2M PHY with MTU 247 + DLE 251.
- Using slave latency without checking supervision timeout: If connInterval = 100 ms, connLatency = 9, supervisionTimeout must be > 2000 ms. A 1000 ms timeout will cause frequent disconnects.
- Assuming connInterval is the latency: With scheduling offsets, worst-case latency can be 2× connInterval. Always budget for 2× in real-time designs.
- Negotiating parameters during data transfer: The LL_CONNECTION_PARAM_REQ instant is 6 events away. During those 6 events, the link may experience 2× latency as the scheduler adjusts. Negotiate parameters during idle periods.
- Forgetting iOS restrictions: Apple enforces 15-30 ms interval. A peripheral requesting 7.5 ms will be rejected. Design for 15 ms minimum when iOS compatibility is required.
- Stacking connections at the same offset: If all connections use offset 0, the scheduler must serialize them within the first few ms of each interval. Spread offsets across the interval to reduce contention.
12. Design Checklist
- [ ] Connection interval chosen to balance latency vs. power (typical: 15-100 ms)
- [ ] Slave latency set to 0 for real-time, 3-9 for low-power sensors
- [ ] Supervision timeout ≥ (1 + connLatency) × connInterval × 3 (safety margin)
- [ ] MTU negotiated to 247 at connection establishment
- [ ] DLE negotiated to 251 at connection establishment
- [ ] 2M PHY requested if both sides support BLE 5.0+
- [ ] Connection event offsets distributed across interval
- [ ] Channel map updated to exclude Wi-Fi-overlapping channels
- [ ] iOS compatibility verified if applicable (15-30 ms interval)
- [ ] Worst-case latency budgeted at 2× connInterval × (1 + connLatency)
- [ ] Throughput budget calculated per connection, not just aggregate
- [ ] Supervision timeout increased for multi-connection (>4) to handle scheduler contention
- [ ] Current consumption measured under full load, not single-connection
13. Conclusion
Multi-connection BLE module design is a scheduling problem at its core. The raw PHY rate (1M or 2M) is the least interesting number — the real throughput is determined by PDU overhead, IFS, event packing, and the number of connections sharing the interval. Latency is not connInterval but can be up to 2× connInterval under contention. Power scales linearly with active connections and inversely with interval. The engineer’s job is to choose connInterval, connLatency, MTU, DLE, and PHY as a coupled system, not as independent checkboxes. A 4-connection hub at 30 ms / MTU 247 / DLE 251 / 2M PHY achieves 523 kbps per connection with 28 ms average latency — practical, useful, and a far cry from the “2 Mbps” on the datasheet. For your next multi-connection BLE deployment, start with the throughput formula, not the spec sheet headline.
