Un Bluetooth Beacon aislado no es más que una radio que emite paquetes al aire. El valor real —ubicación, presencia, telemetría— lo crea la capa de gateway y edge que escucha, filtra y reenvía esos paquetes. Este artículo explica cómo arquitectar un pipeline Beacon→gateway, dónde colocar el cómputo y cómo mantener ancho de banda y latencia razonables a escala.

Qué hace realmente el gateway

Un gateway es un escáner BLE con uplink. Por cada paquete publicitario que oye debe:

1. Eliminar duplicados (misma MAC + secuencia puede llegar a 3 gateways solapados).

2. Sellado de tiempo con reloj sincronizado (NTP/PTP) para que la trilateración sea coherente.

3. Normalizar RSSI (cada radio tiene distinta ganancia de front-end).

4. Agregar por tag en una ventana (p.ej. 1 s) en un único registro.

5. Reenviar por el uplink.

Edge vs cloud

Hacer todo en la nube significa enviar cada paquete crudo. Con 500 tags a 1 Hz generas ~500 paquetes/s. Mandar eso entre sitios es desperdicio. El gateway edge debe emitir *un registro agregado por tag por segundo*, cortando el volumen por el número de gateways que oyen cada tag.

Flujo de datos

<strong><a href="https://www.tecksay.com/category/products/bluetooth-beacon/">Beacon</a></strong> ADV ──▶ Gateway (BLE scanner)
├─ dedupe + timestamp
├─ RSSI smoothing (Kalman / moving avg)
└─ aggregate 1 Hz record
│
▼
MQTT broker  (topic: site/floor/tag/uid)
│
▼
Cloud ingestion ──▶ dashboard / alerting

Matemática de filtrado en edge

Clave de dedupe = (mac, seq). Mantén un conjunto deslizante; descarta repeticiones dentro de T_dedup (unos 5 s). Suavizado RSSI por tag:

rssi_smoothed = α·rssi_new + (1-α)·rssi_prev     (α ≈ 0.3)

Esto elimina picos de un solo paquete que fingirían un salto de posición.

Protocolo de uplink

MQTT es el ajuste natural: los gateways publican en tecksay///beacon/, la nube se suscribe una vez. HTTP POST es más fácil de depurar pero necesita conexión keep-alive. CoAP sirve para gateways muy limitados.

Matemática de ancho de banda

500 tags, 1 Hz, cada tag oído por 2.5 radios en promedio, payload 120 B tras agregación:

  • Crudo a la nube: 500 × 120 B × 2.5 = 150 KB/s (duplicado, desperdicio).
  • Agregado en edge: 500 × 120 B = 60 KB/s, una sola copia.

Ese ahorro de 2.5× crece con la densidad de gateways.

Presupuesto de latencia

Evento en tag → gateway lo oye dentro de un intervalo de anuncio (≤1 s) → agregación edge 1 s → salto MQTT ~50 ms → dashboard. Extremo a extremo típicamente 2–3 s, dominado por el intervalo de anuncio, no por la red.

Búfer cuando la nube cae

Los gateways no deben perder datos. Guarda un anillo local (p.ej. última 1 h). Al reconectar, reproduce con retroceso exponencial. Marca los registros reproducidos para que la nube deduplique por (gateway, seq).

Seguridad

  • TLS en el uplink; no envíes RSSI en claro fuera del sitio.
  • Token de auth por gateway (no secreto compartido).
  • Firma cada registro `sig = HMAC(k, payload)` para que un gateway suplantado no inyecte posiciones falsas.
  • Rota las claves de gateway en calendario.

Topología de despliegue

Solapa gateways 20–30% para que cada tag sea oído por ≥2 radios (necesario para trilateración). Más solape = mejor precisión pero más carga de dedupe. El handoff entre gateways es implícito: la nube fusiona los últimos registros de las radios que oyeron el tag.

Checklist

  • [ ] Reloj de gateway sincronizado (NTP, ±50 ms)
  • [ ] Clave de dedupe = mac+seq, T_dedup fijado
  • [ ] RSSI suavizado en edge
  • [ ] Registro agregado 1 Hz, no paquetes crudos
  • [ ] MQTT con jerarquía de tópicos por sitio
  • [ ] Anillo local + reproducción en caída
  • [ ] TLS + registros firmados por gateway
  • [ ] Solape de gateways 20–30%