La mayoria de los modulos Bluetooth en produccion hoy no sirven a un unico peer — gestionan 3, 5 o incluso 20 conexiones concurrentes a sensores, smartphones, gateways y actuadores. La gestion multi-conexion es donde los ingenieros BLE junior descubren que el intervalo de conexion, la latencia esclava, el tamaño MTU, la velocidad PHY y la extension de longitud de datos no son perillas independientes sino un problema de planificacion estrechamente acoplado. Equivocate en una y obtendras desconexiones intermitentes, picos de latencia de 400 ms o un throughput que nunca supera 30 kbps a pesar de un PHY de 2 Mbps. Este articulo descompone el modelo del planificador, deriva los presupuestos de throughput y latencia desde primeros principios y compara silicio real.
1. Modelo de Evento de Conexion BLE
Una conexion BLE no es un enlace continuo — es una cita periodica. El maestro (central) y el esclavo (periferico) acuerdan un intervalo de conexion (T_interval), y dentro de cada intervalo hay un evento de conexion donde ambas radios estan activas. El maestro transmite primero, el esclavo responde, y pueden intercambiar multiples PDUs en ping-pong dentro de ese evento. Cuando no hay mas datos o el evento se extiende, las radios duermen hasta el siguiente intervalo.
Parametros clave en LL_CONNECTION_PARAM_REQ:
- Intervalo de conexion (connInterval): 7.5 ms a 4.0 s, en pasos de 1.25 ms.
- Latencia esclava (connLatency): 0 a 499. El periferico puede saltar este numero de eventos consecutivos sin desconectarse.
- Timeout de supervision (supervisionTimeout): 100 ms a 32 s. Debe cumplir: supervisionTimeout > (1 + connLatency) × connInterval × 2.
2. Planificacion Multi-Conexion: Division de Tiempo
Cuando un modulo actua como central con N perifericos, el planificador debe colocar N eventos dentro de cada intervalo. La restriccion fundamental es que solo una transaccion de radio ocurre en cada instante. Con 4 conexiones a 30 ms y eventos de 5 ms, el tiempo activo total es 20 ms / 30 ms = 67% de duty cycle. Con 8 conexiones, 40 ms de eventos desbordarian el intervalo de 30 ms, empujando algunos eventos al siguiente intervalo y duplicando su latencia.
2.1 Conexiones Concurrentes Maximas por Chip
| Chip | Central Max | Periferico Max | Total Max | Factor Limitante |
|---|---|---|---|---|
| nRF52840 | 20 | 20 | 20 | RAM (8 KB/conn) |
| nRF52832 | 7 | 7 | 7 | RAM (64 KB total) |
| CC2640R2F | 8 | 3 | 8 | TI-RTOS scheduler |
| BGM220SC | 8 | 4 | 8 | Gecko stack |
| ESP32-C3 | 9 | 3 | 9 | Bluedroid/NimBLE |
| ESP32 (dual) | 15 | 4 | 15 | Bluedroid |
Cada conexion consume ~8 KB de RAM para contexto de link layer, buffers TX/RX y estado L2CAP. A 20 conexiones son 160 KB de 256 KB de RAM. ESP32-C3 con NimBLE logra 9 conexiones en 60 KB de heap — significativamente mas eficiente en memoria.
3. Calculo de Presupuesto de Throughput
Cada PDU de datos lleva 10 bytes de overhead (preamble 1 + access addr 2 + header 2 + length 2 + CRC 3). A 2 Mbps, 10 bytes = 40 us. Para payload de 251 bytes (DLE max): tiempo PDU = (10+251)×8/2,000,000 = 1.044 ms. Overhead = 3.8%. Pero para 20 bytes (default), overhead = 33%.
IFS (inter-frame space) = 150 us de tiempo muerto entre PDU maestro y esclavo. Ciclo para 251 bytes a 2M: 1.044+0.150+1.044+0.150 = 2.388 ms. Throughput = 251×8/2.388ms = 840 kbps — 42% del raw 2 Mbps. Con 4 conexiones a 30 ms / 5 ms eventos: throughput por conexion = 244×8×3/30ms ≈ 195 kbps. Agregado = 780 kbps.
4. Analisis de Latencia
Mejor caso: datos listos justo antes del evento. Latencia ≈ 1-3 ms. Peor caso: datos listos justo despues. Latencia ≈ connInterval. Promedio = connInterval / 2. Con connLatency > 0, intervalo efectivo = connInterval × (1 + connLatency). Bajo contencion multi-conexion, el peor caso puede alcanzar 2× connInterval. Con 4 conexiones a 30 ms: peor caso 62 ms. A 7.5 ms: 15 ms, pero duty cycle 4× mayor.
5. Negociacion de Parametros
El central establece parametros iniciales, pero cualquier lado puede solicitar cambio via LL_CONNECTION_PARAM_REQ. iOS es restrictivo: 15-30 ms de intervalo, latencia ≤ 29, timeout 2-6 s. Android es mas flexible pero algunos OEMs rechazan intervalos menores a 10 ms. El procedimiento: iniciador envia parametros + instant → respondedor acepta o contrapropone → efectivo en 6 eventos.
6. PHY Update y Data Length Extension
LL_PHY_REQ permite cambio de PHY. Coded PHY (125/500 kbps) intercambia throughput por rango. 2M PHY duplica la tasa bruta. DLE aumenta payload maximo de 27 a 251 bytes. Critico: MTU y DLE son negociaciones independientes — ambos deben aumentarse. MTU solo → 9 fragmentos, 90 bytes desperdiciados. DLE solo → L2CAP fragmenta a 23 bytes. Ambos → 244 bytes en un PDU, overhead minimo.
7. Channel Map y AFH
BLE usa 37 canales de datos, saltando por evento. El central proporciona el channel map via LL_CHANNEL_MAP_REQ. En coexistencia Wi-Fi, marcar canales que solapan con Wi-Fi 1 (BLE 0-10), 6 (11-20), 11 (21-30) como no usados. Con 37 canales: ~2% packet loss. Con 7: ~8%, pero sin interferencia Wi-Fi.
8. Resolucion de Conflictos del Scheduler
| Estrategia | Descripcion | Pros | Contras |
|---|---|---|---|
| Prioridad Estricta | Conexion de mayor prioridad siempre gana | Predictible para links criticos | Starvation de baja prioridad |
| Round-Robin Justo | Rotar slots | Sin starvation | Latencia impredecible |
| Earliest Deadline First | Servir conexion mas cercana a timeout | Minimiza desconexiones | Complejo |
nRF52 usa round-robin justo modificado. ESP32 Bluedroid usa prioridad estricta — la 9na conexion tiene 2× latencia que la 1ra. NimBLE implementa EDF con 15-20% mejor distribucion de latencia bajo carga.
9. Consumo en Multi-Conexion
nRF52840 0 dBm 1M: RX 5.4 mA, TX 4.6 mA. Evento 3 ms ≈ 15 uC. 4 conexiones a 30 ms: corriente media ≈ 2.0 mA. CR2032: 4.6 dias. Con latency=3, 100 ms: 0.15 mA, 61 dias. Pero latencia peor caso = 400 ms. Optimo para redes de sensores donde 400 ms es aceptable.
10. Benchmark Real: Hub de 4 Conexiones
| Metrica | 1 Conn | 2 Conn | 4 Conn |
|---|---|---|---|
| Throughput/conn | 712 kbps | 681 kbps | 523 kbps |
| Agregado | 712 kbps | 1,362 kbps | 2,092 kbps |
| Latencia media | 16 ms | 19 ms | 28 ms |
| P99 latencia | 31 ms | 45 ms | 72 ms |
| Desconexiones/hr | 0 | 0 | 0.3 |
11. Errores Comunes de Diseno
- 2M PHY con MTU 23 → overhead 33%, ganancia solo ~15%
- Slave latency sin verificar supervision timeout → desconexiones frecuentes
- Asumir connInterval = latencia → peor caso es 2× con offsets
- Negociar parametros durante transferencia → 2× latencia por 6 eventos
- Olvidar restricciones iOS → 15-30 ms obligatorio
- Todas las conexiones en offset 0 → contention concentrada
12. Checklist de Diseno
- [ ] Intervalo 15-100 ms segun balance latencia/potencia
- [ ] Latency 0 real-time, 3-9 low-power
- [ ] Supervision timeout ≥ (1+latency)×interval×3
- [ ] MTU 247 al establecer conexion
- [ ] DLE 251 al establecer conexion
- [ ] 2M PHY si BLE 5.0+
- [ ] Offsets distribuidos en el intervalo
- [ ] Channel map sin canales Wi-Fi
- [ ] Compatibilidad iOS (15-30 ms)
- [ ] Presupuesto de latencia = 2×interval×(1+latency)
- [ ] Throughput por conexion, no solo agregado
- [ ] Timeout mayor para >4 conexiones
- [ ] Corriente medida a carga completa
13. Conclusion
El diseno multi-conexion BLE es fundamentalmente un problema de planificacion. La tasa PHY bruta es el numero menos interesante — el throughput real lo determinan overhead de PDU, IFS, packing de eventos y numero de conexiones. La latencia no es connInterval sino hasta 2× bajo contencion. La potencia escala linealmente con conexiones activas e inversamente con el intervalo. El trabajo del ingeniero es elegir connInterval, connLatency, MTU, DLE y PHY como sistema acoplado. Un hub de 4 conexiones (30 ms / MTU 247 / DLE 251 / 2M PHY) logra 523 kbps por conexion con 28 ms de latencia media. Para tu proximo despliegue BLE multi-conexion, empieza con la formula de throughput, no con el titular del datasheet.
