Un Bluetooth Beacon estándar solo transmite. Despierta con un temporizador, emite un paquete de advertising y vuelve a dormir. Ese modelo asume que hay una pasarela (gateway) o un smartphone dentro del alcance de radio para escucharlo. Ese supuesto se rompe en cuanto tienes un almacén de 40 000 m², un hospital de varias plantas, un patio de mercancías o un túnel: cualquier sitio donde una sola pasarela no ve cada rincón. La solución barata es un beacon de relé: un nodo que escucha los paquetes de otros beacons y los retransmite, saltando la señal hacia una pasarela realmente alcanzable.
Este artículo trata sobre qué es realmente un beacon de relé, por qué el diseño ingenuo de “cada uno repite todo” explota, y las reglas de ingeniería que mantienen estable una red de relés.
Qué hace realmente un beacon de relé
Un beacon de relé es un dispositivo de doble rol. A diferencia de un transmisor puro, funciona en modo observador (escáner) para recibir paquetes de advertising y luego cambia a modo difusor para enviarlos otra vez. Tres tareas distintas:
1. Escanear los tres canales de advertising (37/38/39) en busca de paquetes de beacons objetivo o relés ascendentes.
2. Decidir si un paquete debe reenviarse (deduplicación, límite de saltos, reglas de intensidad de señal).
3. Reemitir un paquete (normalmente idéntico, a veces enriquecido) por los canales de advertising.
El relé no decodifica la carga de aplicación como una pasarela. Normalmente reenvía la PDU de advertising en crudo — MAC, carga y el RSSI que él midió — sin cambios. Esa es toda la idea: es un extensor tonto y rápido, no un sumidero.
Relé frente a las alternativas
| Rol | ¿Necesita RX? | ¿Necesita TX? | ¿Duerme? | ¿En la ruta? | Consumo típico |
|---|---|---|---|---|---|
| Beacon estándar | No | Sí | Sí (99%+) | No | 5–50 µA medio |
| Beacon de relé | Sí | Sí | Raras veces | Sí | 1–10 mA medio |
| Nodo BLE Mesh | Sí | Sí | No (relé) | Sí | 2–15 mA medio |
| Pasarela | Sí | A veces | No | Final | Red / PoE |
La línea brutal de esa tabla es el consumo. Un beacon solo transmisor pasa ~0,5–2 ms de cada 100 ms de intervalo en la radio y duerme el resto, promediando unos pocos µA. Un relé debe mantener la radio en RX casi continuamente para no perder paquetes, y el RX en un SoC BLE Cortex-M4 consume ~4–6 mA. A 5 mA continuos son 120 mAh al día — una CR2032 (220 mAh) muere en menos de dos días. Los nodos relé reales van a red, PoE, USB o, como mínimo, una pila D / Li-SOCl₂ con objetivo de varios años.
La trampa de la tormenta de difusión
El fallo de relé más común es la inundación. Si cada relé reenvía todo lo que oye, y cada otro relé reenvía eso, la red entra en amplificación exponencial:
- El beacon A envía 1 paquete.
- Los relés B y C lo oyen y cada uno envía 1 → 2 paquetes en el aire.
- B y C oyen las repeticiones del otro, y D/E oyen esas → 4, luego 8, y el canal se satura.
Con N relés reenviando a 10 Hz, la tasa de paquetes en el aire no es 10 Hz, es 10 × N × (N−1) / algo feo. Los canales de advertising son 1 Mbit/s pero un paquete BLE ocupa ~50–350 µs más 150 µs entre tramas; en la práctica un canal aguanta solo unas pocas centenas de paquetes/seg antes de que el colapso por colisiones domine. Una tormenta tumba todo el segmento.
Reglas de control que evitan la tormenta
Todo firmware de relé en producción implementa cuatro mecanismos:
1. Caché de deduplicación. Mantén un búfer circular de pares (MAC TxAdd, SeqNum) vistos recientemente — digamos 64–256 entradas. Si la clave del paquete está en la caché, descártalo. Solo esto detiene el 90% de los bucles.
2. Contador de saltos / TTL. Marca un campo de salto en la carga (o reutiliza un byte sin usar). Increméntalo en cada relé. Descarta si salto ≥ H (normalmente 4–8). Esto acota el diámetro de red y evita bucles infinitos entre A↔B.
3. Hold-off / jitter. Tras decidir reenviar, espera un valor aleatorio de 20–100 ms antes de transmitir. Esto desincroniza los relés para que no disparen todos en la misma ranura, y da tiempo a que la caché de deduplicación se pueble entre vecinos.
4. Compuerta RSSI (relé selectivo). Solo reenvía paquetes cuya RSSI medida esté por debajo de un umbral (p. ej., < −75 dBm). Los paquetes fuertes ya están cerca de una pasarela y no necesitan relé; los débiles sí. Esto recorta repeticiones redundantes en un 50–80%.
Pseudocódigo mínimo de decisión:
on_packet(pkt):
if pkt.hop >= MAX_HOP: drop
if (pkt.mac, pkt.seq) in dedup_cache: drop
dedup_cache.add((pkt.mac, pkt.seq))
if pkt.rssi > RSSI_GATE: drop # ya es suficientemente fuerte
pkt.hop += 1
schedule_tx(pkt, random_delay(20,100))
Latencia y pérdida entre saltos
El relé store-and-forward añade retardo por salto. Con una ventana de hold-off de 100 ms y ~5 ms de proceso, un salto cuesta unos 25–105 ms (media ~60 ms). Tres saltos suman entonces 150–300 ms de latencia a una actualización de posición. Bien para seguimiento de activos, fatal para control en tiempo real.
La pérdida también se acumula. Si un salto simple entrega con probabilidad p, una ruta de N saltos entrega con p^N. Con p = 0,9 (ya optimista en un almacén ruidoso), 4 saltos → 0,66. O despliegas relés de sobra (más densos de lo que cubrir necesita) o aceptas huecos. Por eso en la práctica la profundidad de relé se limita a 3–5 saltos.
Matemática de alcance real
Un relé extiende el alcance linealmente con el número de saltos, pero cada salto está limitado por el más débil de sus dos enlaces. En interior, un salto BLE simple suele ser 15–40 m atravesando paredes; en exterior con línea de vista 80–150 m. Así:
- 1 relé: alcanza ~2× el salto simple ≈ 30–80 m en interior alrededor de una zona muerta
- 3 relés: ~4× el salto simple, pero ojo con latencia y pérdida arriba
- Techo práctico: ~5 saltos antes de que pérdida/latencia lo inutilicen
El alcance también depende de antena, potencia TX y canal. Los relés en cruces de pasillos y escaleras superan a los relés tirados en salas abiertas.
Notas de hardware y firmware
- SoC: Necesitas una pieza de doble rol. nRF52840 / nRF5340 y ESP32 (modo HCI) escanean y difunden. Un nRF52810 solo transmisor no puede relayar.
- Ventana vs intervalo de escaneo: Para captar un beacon que anuncia cada 100 ms, la ventana de escaneo del relé debe sumar en los tres canales al menos el tiempo en aire del beacon. Un escaneo al 100% de duty (ventana = intervalo) no pierde nada pero quema máxima potencia; 30–50% de duty negocia pérdida por batería.
- Rotación de canales: BLE anuncia en ch 37/38/39. El relé debe escanear los tres; saltarse uno pierde un tercio de los paquetes.
- Deriva de reloj: Si los relés usan osciladores RC de bajo consumo, el timing de escaneo deriva y las ventanas se deslizan. TCXO o un reloj de sueño calibrado reduce paquetes perdidos.
Seguridad
Un relé es un límite de confianza. Como reenvía PDU en crudo, un atacante puede:
- Inyectar beacons falsos que se relayan directo a la pasarela (posiciones de activos falsas).
- Replay repetir un paquete capturado para crear una tormenta o movimiento falso.
- Suprimir inundando el canal para que los paquetes reales colisionen.
Mitigaciones: firma o cifra la carga del beacon (y que la pasarela, no el relé, verifique), limita tasa por MAC en el relé, y usa lista blanca de prefijos MAC de beacons de confianza. Los nodos relé deben estar físicamente asegurados y, si es posible, autenticados a la red.
Cuándo NO usar un relé
Si puedes poner una pasarela cada ~30 m, hazlo — las pasarelas son más simples y terminan la cadena. El relé gana solo cuando tirar Ethernet/PoE a cada rincón es imposible (edificios históricos, patios, túneles) y necesitas cobertura, no alta fidelidad. Para RTLS de alta precisión, los relés añaden multipath y ambigüedad; prefiere más pasarelas o AoA.
En resumen
Un Bluetooth Beacon de relé es la forma más barata de empujar la cobertura más allá del horizonte de radio de la pasarela, pero es un problema de potencia y inundación disfrazado de problema de alcance. Haz bien la caché de deduplicación, el límite de saltos, el jitter de hold-off y la compuerta RSSI, limita la profundidad a 3–5 saltos, y alimenta el nodo de red o con una pila grande. Hecho mal, tumba el segmento que debía salvar.
