GTP-C Proxy: pools de PGW multivendedor sin reconfigurar SGW ni MME

Acerca de la solución

Stingray GTP-C Proxy permite agrupar PGW de distintos fabricantes en pools comunes, distribuir a los suscriptores según las reglas del operador y gestionar las fallas sin modificar la configuración de SGW y MME: basta con apuntar el APN al proxy en el DNS una sola vez.

La solución es compatible con GTPv1 y GTPv2, facilita la evolución de la red sin reconfigurar SGW y MME y conserva el estado de las conexiones cuando el proxy se reinicia.

Por qué un operador necesita GTP-C Proxy

PGW de distintos fabricantes en una misma red

GTP-C Proxy agrupa los gateways en pools comunes que se gestionan con reglas unificadas. No es necesario modificar la configuración existente de SGW y MME.

Selección de PGW según las reglas del operador

Los suscriptores se dirigen a los gateways adecuados según IMSI, MSISDN, APN, PLMN, tipo de acceso de radio (RAT) y ubicación del suscriptor (ULI), así como sus combinaciones. Los pesos de los pools y los PGW de respaldo permiten ajustar la distribución a los requisitos de la red.

Respuesta ante fallas sin conmutación manual

Si un PGW falla, GTP-C Proxy lo excluye del pool y dirige las nuevas conexiones a PGW operativos con una versión de GTP compatible. El estado de las conexiones se guarda en Redis, incluso cuando se reinicia el propio proxy.

Transiciones entre 2G/3G y LTE

GTP-C Proxy es compatible con GTPv1 y GTPv2 y gestiona el cambio de versión del protocolo cuando el suscriptor pasa de una generación de red a otra.

Cómo funciona Stingray GTP-C Proxy

GTP-C Proxy opera en el plano de control GTP-C entre SGW / SGSN y PGW. Ante el SGW, el proxy se presenta como un PGW, y ante el PGW, como un SGW. El DNS del operador apunta el APN al proxy, que selecciona el PGW de destino según las reglas configuradas y le reenvía la señalización.

El tráfico de usuario GTP-U fluye directamente entre SGW y PGW. GTP-C Proxy no interviene en la ruta de los datos de usuario.

Como resultado, el operador obtiene un nivel adicional de control sobre la selección de PGW y mantiene la arquitectura existente de la red de acceso. La interacción utiliza mensajes GTP estándar.

Solicite una demostración personalizada y una prueba de la solución

Escalabilidad

El rendimiento crece con el número de hilos

¿Cómo escala la infraestructura?

GTP-C Proxy escala en tres niveles: hilos de procesamiento en el servidor, instancias del proxy y almacenamiento de estado. Cada nivel se amplía de forma independiente.

Hilos de procesamiento

La señalización se procesa en varios hilos de trabajo asignados a núcleos del procesador. En un banco de pruebas de nivel industrial, el rendimiento de procesamiento alcanza 348 000 operaciones Modify Bearer por segundo con cuatro núcleos.

Instancias del proxy

Varias instancias de GTP-C Proxy trabajan con un almacenamiento común y reglas de enrutamiento comunes. El estado de las sesiones se almacena de forma centralizada, por lo que la falla de una instancia no provoca la pérdida de conexiones. La conmutación entre instancias se realiza mediante BGP.

Almacenamiento de estado

Un solo servidor Redis soporta alrededor de 105 000 Modify Bearer/s. Para cargas mayores se utiliza un clúster Redis con réplicas y conmutación automática ante la falla del nodo principal.

Reglas sin reinicio

Los pools de PGW, los pesos y las reglas de enrutamiento se guardan en un único documento (archivo YAML o Redis) y se aplican a todas las instancias en caliente, sin reinicio ni pérdida de sesiones.

Tolerancia a fallas

2,03 s como máximo (tiempo máximo de conmutación ante la falla del nodo principal de Redis en una prueba bajo carga)

Reinicio del proxy

El estado se guarda en Redis, por lo que las conexiones se conservan.

Falla o reinicio de un PGW

El PGW con falla se retira del pool y las nuevas conexiones se dirigen a PGW operativos con una versión de GTP compatible. El reinicio de un PGW se detecta mediante mensajes Echo.

Reinicio del SGW

Las sesiones se conservan y se restablecen según el procedimiento de 3GPP TS 23.007 (sección 27).

Sobrecarga

Los suscriptores activos se atienden con prioridad; las nuevas conexiones se rechazan.

Redundancia de instancias

Conmutación entre instancias del proxy mediante BGP.

Funcionalidades de Stingray GTP-C Proxy

Protocolos y enrutamiento

GTPv2 en S5/S8 y GTPv1 en Gn/Gp.
Continuidad de la sesión en las transiciones entre 2G/3G y LTE.
Pools de PGW de distintos fabricantes.
Enrutamiento y redistribución de nuevas conexiones entre PGW, sustitución de parámetros de sesión e informes de ubicación para S5/S8 y Gn/Gp.
Conservación de las conexiones al reiniciarse el SGW según TS 23.007, sección 27.

Confiabilidad, capacidad y gestión

Rendimiento de hasta 348 000 operaciones Modify Bearer por segundo con cuatro hilos.
Control de carga y temporizador watchdog.
Interfaz web, Prometheus y Grafana.
Visualización de sesiones y configuración de pools Gn/Gp en la interfaz web.
Entrega en paquetes RPM para VEOS 8.x y EL8.

Gestión centralizada

Interfaz web

Sesiones, historial del documento de enrutamiento, estado de las instancias y de los PGW, roles de administrador y observador.

Prometheus

Métricas de mensajes, transacciones, fallas, almacenamiento y PGW por versión de GTP.

Grafana

Paneles de monitoreo integrados con autenticación a través de la interfaz web.

Requisitos de implementación

Parámetro	Requisitos
SO	VEOS 8.x o EL8, x86_64; glibc 2.28, systemd 239
Entrega	Paquetes RPM gtpcproxy y gtpcproxy-web. Instalación, actualización y reversión mediante dnf
Virtualización	KVM o VMware. Se recomiendan vCPU dedicadas en proporción 1:1 con los núcleos físicos de un mismo nodo NUMA
Red	Búfer de recepción de señalización de 8 MiB: CAP_NET_ADMIN o net.core.rmem_max de al menos 8 MiB
Redis	Redis debe responder sin pausas de más de 250 ms (por ejemplo, durante la migración en vivo de una VM). Se recomienda migrar la máquina virtual con Redis durante una ventana de mantenimiento
CPU y memoria	Para 348 000 Modify Bearer/s: 19 núcleos dedicados en total, 4 de ellos para el procesamiento de señalización
Contenedor	Podman (rootless)

Solicite una demostración gratuita de GTP-C Proxy

Nos pondremos en contacto con Uds., especifique su tarea, daremos acceso a la documentación y responderemos sus dudas.

Discutiremos su situación actual: volumen de tráfico, equipos disponibles, la funcionalidad que necesita.

Nuestros ingenieros instalan el software seleccionado y lo adaptan a sus tareas específicas. Сontratación – solo después de que la prueba sea exitosa.

Nombre *

Correo electrónico *

Número de teléfono *

Nombre de la Compañía *

Comentarios

Acepto la Disposición de confidencialidad y Acuerdo de licencia de VAS Experts

Soluciones relacionadas

GTP-C Proxy

Acerca de la solución

Por qué un operador necesita GTP-C Proxy

PGW de distintos fabricantes en una misma red

Selección de PGW según las reglas del operador