Combinar un enlace de órbita baja (LEO) con uno geoestacionario (GEO) es hoy la forma más común de construir una red satelital confiable. Aquí explicamos cómo lograr interoperabilidad entre redes satelitales LEO y GEO para que no sean dos conexiones paralelas, sino una sola red.
Por qué LEO y GEO se complementan
- La LEO da baja latencia y mucha velocidad, pero depende de tener mucho cielo libre y su capacidad varía según la saturación de la celda.
- La GEO tiene latencia alta, pero su haz es fijo, funciona con poco cielo despejado y puede contratarse con capacidad comprometida.
- Sus fallas casi nunca coinciden: una obstrucción, una actualización de la constelación o una saturación en LEO no afecta a la GEO, y viceversa.
- Son de operadores distintos, con redes y salidas a Internet distintas: diversidad real.
Paso 1: un router que entienda ambos enlaces
Los dos módems se conectan a un mismo router de borde con dos interfaces WAN (más las de 4G/5G si existen). El router debe medir cada enlace por separado —latencia, pérdida, jitter— y no solo «si hay luz en el puerto».
Paso 2: detección de falla distinta para cada uno
Un umbral de 150 ms marcaría la GEO como caída todo el tiempo. Cada enlace necesita su propio umbral de latencia y su propio número de pruebas fallidas antes de declararlo inútil. Lo ideal es medir hacia un servidor propio (el concentrador), no solo hacia un DNS público.
Paso 3: túneles hacia un concentrador
Ambos enlaces levantan túneles cifrados hacia el mismo concentrador. Así:
- La red privada y la IP pública de tus servicios no cambian.
- La política se aplica igual sin importar el operador.
- El concentrador ve el estado real de cada camino.
Paso 4: bonding en el grupo rápido, GEO aparte
El bonding satelital suma enlaces en un solo túnel y evita cortes, pero funciona bien solo entre enlaces de latencia parecida. Por eso:
- LEO + 4G/5G (o dos LEO) en bonding: el canal principal, rápido y sin cortes.
- GEO como camino independiente: para tráfico masivo y como respaldo si todo el grupo rápido falla.
Meter la GEO en el mismo bonding haría que todo el túnel esperara sus paquetes de 600 ms.
Paso 5: política por tipo de tráfico
| Tráfico | Primero | Si falla |
|---|---|---|
| Voz, videollamada, escritorio remoto | Bonding LEO + celular | GEO con códec ligero |
| Navegación y ERP | Bonding | GEO |
| Respaldos, actualizaciones, video diferido | GEO | Bonding con límite |
| Control y telemetría | Ambos (paquetes duplicados si es crítico) | Banda L |
Paso 6: aceleración para el tramo GEO
Las aplicaciones TCP sufren con 600 ms de latencia. La aceleración (PEP) del módem GEO compensa el efecto, pero dentro de un túnel cifrado el PEP del operador no ve el tráfico: hay que acelerar en el propio router o dejar fuera del túnel el tráfico que no lo necesita.
Paso 7: probar con fallas reales
Desconecta la LEO en horario laboral, tapa la antena GEO, satura un enlace con una descarga, apaga el módem celular. Mide cuánto tarda cada servicio en recuperarse y ajusta. Una red que solo se probó en papel no es interoperable.
Errores frecuentes
- Usar la conmutación por defecto del módem LEO, que solo detecta caída total.
- Dejar que las actualizaciones de Windows saturen la GEO.
- Meter la GEO en el bonding con la LEO.
- No contemplar la lluvia: Ka y Ku se degradan en tormentas fuertes; la banda L es la tercera capa para lo crítico.
- Medir solo contra un DNS público que a veces no responde.
Y el 5G NTN
Cuando los módems celulares puedan usar satélite de forma nativa (5G NTN), el grupo rápido tendrá una capa más. El diseño no cambia: más transportes en la misma red.
