hjs.es ← inicio

SolarLink — Conectividad rural off-grid con LoRa y 5G

Diseño e implementación de un nodo de comunicaciones completamente autónomo — sin red eléctrica, sin línea fija y sin acceso físico frecuente — para llevar conectividad y telemetría a núcleos rurales donde las soluciones tradicionales no llegan. Trabajo de Fin de Grado desarrollado en equipo de tres.

LoRaWAN 5G / 4G failover OpenWRT WireGuard Cloudflare Tunnel MPPT LiFePO₄ PHP · MySQL Upptime

Contexto

En España, en torno al 20% de los municipios carece de cobertura de banda ancha adecuada, y miles de núcleos de menos de 100 habitantes no tienen internet fijo. Desplegar fibra hasta ellos es inviable económicamente, y las soluciones satelitales tienen costes recurrentes altos y latencias que descartan muchos usos.

SolarLink plantea otra vía: un nodo autónomo que se instala en cuestión de horas, sin obra civil, y que ofrece dos cosas a la vez — un punto de acceso a internet para el núcleo y una red de sensores LoRaWAN para telemetría agrícola y ambiental (humedad de suelo, depósitos de agua, meteorología). Mi rol dentro del equipo se centró en la parte de infraestructura: red, seguridad, energía y administración remota del nodo.

Restricciones de diseño

01
Sin red eléctrica El nodo debe generar y gestionar su propia energía: panel solar con controlador MPPT y batería LiFePO₄. Cada vatio consumido por el software es un vatio que hay que justificar.
02
Sin línea fija — solo cobertura móvil intermitente La única salida a internet es la red móvil, con cobertura irregular según la hora y la meteorología. La conectividad no puede depender de un único operador.
03
Sin acceso físico frecuente El punto de instalación puede estar a horas de distancia. Todo — configuración, diagnóstico, actualizaciones, recuperación ante fallos — tiene que poder hacerse en remoto. Si el nodo se cuelga y nadie puede reiniciarlo, el diseño ha fallado.

Problemas por el camino

✗

Problema 1 — La batería no sobrevivía a la noche

Con el Wi-Fi emitiendo 24/7, el consumo nocturno vaciaba la batería en las pruebas de invierno: amanecía con el nodo apagado y, peor aún, con los sensores LoRaWAN sin registrar datos durante horas.

Solución — lógica de supervivencia energética: un script en OpenWRT monitoriza el voltaje de la batería vía cron. Al caer por debajo del umbral, desactiva automáticamente el Wi-Fi (el servicio más caro energéticamente) y prioriza la red de sensores LoRaWAN, que consume una fracción. El nodo "se sacrifica por partes" para mantener vivo lo esencial, y restaura el Wi-Fi cuando el panel vuelve a cargar.
✗

Problema 2 — Un solo operador no era fiable

En el emplazamiento de pruebas, la cobertura del operador principal caía de forma recurrente a ciertas horas. Un nodo de "infraestructura crítica" que pierde conectividad a diario no puede llamarse así.

Solución — enlace dual SIM con failover automático: dos SIM de operadores distintos gestionadas con mwan3 en OpenWRT. El sistema comprueba la salud del enlace activo (ping a destinos externos) y conmuta al secundario en segundos si el primario degrada, volviendo automáticamente cuando se recupera. Cada conmutación queda registrada para analizar patrones de cobertura.
✗

Problema 3 — Administrar un nodo detrás de CGNAT

Las conexiones móviles van detrás de CGNAT: el nodo no tiene IP pública, así que no se puede abrir un puerto y conectarse "hacia dentro". Y exponer el panel de administración a internet, aunque se pudiera, era descartable por seguridad.

Solución — WireGuard con conexión saliente: el nodo levanta un túnel WireGuard saliente hacia un servidor con IP pública. El CGNAT deja de importar (la conexión la inicia el nodo) y toda la administración — SSH, LuCI, dashboard — viaja cifrada por el túnel sin exponer ni un solo puerto a internet. Keepalives configurados para que el túnel sobreviva a los tiempos de NAT del operador.

Arquitectura final

01

Energía — panel solar + MPPT + LiFePO₄

Controlador MPPT para extraer el máximo del panel incluso con nubosidad parcial, y batería LiFePO₄ (más de 3.000 ciclos, química estable). La lógica de supervivencia decide qué servicios viven según el estado de carga.

02

Cerebro — OpenWRT

Router OS open-source con control total: firewall, DHCP, DNS, VLANs, QoS y el bridge entre la red LoRa y la WAN. Acceso root, scripts propios y cron para toda la automatización del nodo.

03

Conectividad — dual SIM 5G/4G con failover

Dos operadores, conmutación automática con mwan3 y registro de cada failover. Redundancia de grado industrial con hardware de coste contenido.

04

Sensores — red LoRaWAN

Gateway LoRa conectado al nodo. Los sensores de campo transmiten a kilómetros de distancia con consumos mínimos — años de batería — y sus datos se almacenan y visualizan en el dashboard.

05

Gestión — WireGuard + dashboard + status público

Túnel WireGuard saliente para la administración del nodo (SSH, LuCI) sin exponer puertos. El dashboard, en cambio, necesita ser accesible públicamente — se expone vía Cloudflare Tunnel, mismo patrón que uso en mi proyecto de acceso a Proxmox: conexión saliente, sin abrir nada en el router. Dashboard propio en PHP/MySQL con roles de usuario para métricas de energía, conectividad y sensores. Upptime como página de estado pública.

Lecciones aprendidas

En sistemas off-grid, la energía es la primera capa de la pila — antes que la red. Un diseño de red perfecto que agota la batería es un diseño fallido.
La redundancia no es paranoia: la SIM secundaria pasó de "por si acaso" a activarse a diario en el emplazamiento real.
CGNAT convierte "abrir un puerto" en un problema de arquitectura. Las conexiones salientes (WireGuard, túneles) son la respuesta estándar, igual que en mi proyecto de homelab.
Diseñar para no ir: cada decisión se evaluó con la pregunta "¿y si esto falla y el nodo está a 3 horas en coche?".

Ver el proyecto

La presentación interactiva del TFG:

Proyecto desarrollado junto a Raúl García y Juanma Ruiz · ASIR 2024–2026.