Infraestructura mesh en entornos hostiles: caso de uso real en operaciones urbanas

Cuando la infraestructura de telecomunicaciones falla — por un evento masivo, una emergencia o simple saturación — las aplicaciones que dependen de ella dejan de funcionar. Un taxi no puede recibir viajes. Una centralita no puede asignar rutas. Un pasajero no puede pagar.

Este artículo documenta el caso de uso real de la red mesh Zénit en entornos hostiles: no como concepto teórico, sino como infraestructura operativa en Madrid.

¿Qué es un “entorno hostil” para las telecomunicaciones?

En el contexto de la movilidad urbana, un entorno hostil es cualquier escenario donde la conectividad tradicional se degrada o desaparece:

• Eventos masivos: Manifestaciones, conciertos, partidos. 50,000 personas en 1 km² saturan las antenas de telefonía.
• Zonas de baja cobertura: Túneles, garajes subterráneos, polígonos industriales alejados.
• Cortes de red: Fallos en estaciones base, cortes de fibra por obras, apagones eléctricos.
• Entornos de desconfianza: Zonas donde el operador de red podría estar comprometido o donde la señal corporativa no es bienvenida.

En todos estos casos, una app de movilidad que depende de AWS y una API REST centralizada deja de funcionar. El conductor no ve viajes. El pasajero no puede pedir un taxi. La centralita pierde visibilidad de la flota.

La solución mesh: cómo Zénit opera cuando todo lo demás falla

La red mesh Zénit está diseñada desde cero para operar en estas condiciones. No es una red de respaldo: es la red primaria para comunicaciones críticas del ecosistema.

Arquitectura de resiliencia

Cada vehículo TripX lleva un nodo Zénit de a bordo. Este nodo tiene cuatro capacidades de comunicación:

1. Radio mesh (LoRa 868MHz): Comunicación básica entre vehículos hasta 5 km. Mensajes de texto cortos, coordenadas GPS, estado del viaje. Sin necesidad de internet.
2. WiFi mesh (5GHz): Comunicación de alta velocidad entre vehículos cercanos (<500m). Transmite datos de viaje, actualizaciones de mapa, pagos.
3. Backhaul celular: Cuando hay cobertura 4G/5G, el nodo la usa como backhaul. Pero no es el camino principal.
4. Almacenamiento local: Cada nodo mantiene una copia local de los datos críticos (conductores activos, tarifas, zonas). Si la red cae, el nodo sigue operando con los datos que tiene.

El protocolo de desconexión

Cuando un nodo Zénit detecta que ha perdido conectividad con el exterior (sin internet, sin backhaul), activa automáticamente el protocolo de desconexión:

Fase 1 (0-5 min): 
  - Notifica a los nodos vecinos por radio mesh
  - Activa almacenamiento local de transacciones
  - Establece cola de mensajes sincrónica entre vehículos

Fase 2 (5-30 min):
  - Los vehículos forman una red mesh ad-hoc
  - La centralita recibe actualizaciones de posición a través de la cadena de nodos
  - Las transacciones se firman localmente y se encolan

Fase 3 (>30 min):
  - La red mesh se autoorganiza con nodos puente hacia zonas con conectividad
  - Los pagos se procesan contra saldo local verificable
  - Al recuperar conectividad, todas las transacciones se sincronizan

Este protocolo se ha probado en entornos reales y garantiza que ningún viaje en curso se pierda por un corte de red.

Caso de uso real: sábado de conciertos en Madrid

El 14 de junio de 2025, tres eventos simultáneos en Madrid (concierto en el Bernabéu, partido en el Metropolitano, macrofestival en el Recinto Ferial de la Casa de Campo) saturaron las redes de telefonía móvil en un radio de 5 km alrededor de cada recinto.

Lo que pasó con la infraestructura tradicional:

• Las apps de VTC dejaron de funcionar durante 45 minutos
• Los conductores perdieron conexión con las centralitas
• Los pasajeros no podían solicitar viajes
• Los pagos con tarjeta en vehículos fallaban por falta de conexión

Lo que pasó con TripX + Zénit:

• Los 12 vehículos TripX activos en la zona formaron una mesh en segundos
• La centralita recibía actualizaciones de posición cada 3 segundos vía mesh
• Los viajes se asignaban y completaban sin conexión a internet
• Los pagos se procesaban contra saldo local y se sincronizaron al recuperar conectividad
• Tasa de finalización de viajes: 100%

Lecciones aprendidas

La mesh no reemplaza, complementa

La red mesh Zénit no está diseñada para reemplazar la infraestructura de telecomunicaciones tradicional. Está diseñada para que el ecosistema siga funcionando cuando esa infraestructura falla. Es un seguro de continuidad operativa, no un sustituto.

El coste de los nodos se amortiza en la primera crisis

Cada nodo Zénit cuesta aproximadamente lo mismo que un mes de conectividad 4G para un vehículo. En la primera interrupción de servicio que evita pérdida de ingresos, el nodo se paga solo.

La clave es la desconexión elegante

El protocolo de desconexión no es un plan de emergencia. Es una característica de diseño. Zénit asume que la conectividad es intermitente y construye todas sus operaciones alrededor de esa premisa. Esto hace que el sistema sea inherentemente más robusto que uno diseñado para conectividad permanente.

Implementación práctica para flotas

Para operadores de flotas interesados en implementar redundancia mesh, los requisitos mínimos son:

1. Nodo Zénit en cada vehículo (LoRa + WiFi mesh + GPS)
2. Software de bordo que gestione el protocolo de desconexión
3. Centralita compatible que acepte actualizaciones asíncronas
4. Formación de conductores en el protocolo de operación offline

No es necesario que toda la flota sea soberana. Un puente entre la mesh Zénit y APIs REST tradicionales permite que flotas mixtas operen con redundancia mesh sin migrar todo el sistema.

La infraestructura que no se ve

La red mesh Zénit es invisible para el usuario. El pasajero no sabe que su viaje se está enrutando a través de una red de malla peer-to-peer. El conductor no ve el protocolo de desconexión activarse. Pero cuando todo lo demás falla, la infraestructura soberana sigue ahí, funcionando, porque fue construida para el mundo real — no para condiciones de laboratorio.

Esa es la diferencia entre una app y un ecosistema.