Ya contamos qué puede hacer GTPCProxy y cómo está construido por dentro. Ahora pasemos a la práctica y analicemos cuatro escenarios en los que GTPCProxy de VAS Experts simplifica estos cambios y ayuda a reducir los riesgos para los suscriptores.
1. Retiro del GGSN sin reemplazar el SGSN
Muchos operadores conocen bien este panorama. LTE lleva tiempo atendido por gateways PGW modernos, mientras que la red 2G/3G sigue funcionando a través de un GGSN antiguo, el gateway que cumplía la función del PGW en las redes de generaciones anteriores. Los SGSN que atienden a los suscriptores 2G/3G solo pueden trabajar con la versión anterior del protocolo, y los PGW modernos no pueden funcionar como GGSN. Por eso, sin el GGSN no hay con qué atender a los suscriptores 2G/3G, y el operador no tiene previsto reemplazar los SGSN. Cuanto más tiempo opera el GGSN antiguo, más difícil es mantenerlo funcionando, conseguir repuestos y conservar la compatibilidad con el sistema de tarificación vigente.
GTPCProxy mantiene la interoperabilidad entre el GGSN antiguo y los nuevos nodos de la red mediante la conversión de mensajes entre versiones del protocolo. El SGSN sigue trabajando con la versión anterior (GTPv1), mientras que la conexión la atiende un PGW moderno que solo entiende la nueva (GTPv2). El proxy convierte no solo los mensajes, sino todo su contenido: direcciones e identificadores de túnel (TEID), parámetros de calidad de servicio, ubicación del suscriptor, identificador de tarificación y causas de rechazo. Los suscriptores en roaming se atienden de la misma forma.
Figura 1: Compatibilidad entre los nodos antiguos y nuevos de la red
Mientras el GGSN siga en operación, el proxy puede dirigirle parte de las conexiones. Cuando se apague el GGSN, todos los suscriptores 2G/3G serán atendidos por el PGW moderno.
La conversión se activa en la configuración del pool y funciona en uno de dos modos.
- Modo de respaldo. La conexión va al PGW moderno solo si los gateways con función de GGSN no están disponibles.
- Modo principal. Las reglas de enrutamiento dirigen directamente a los suscriptores seleccionados al PGW moderno.
El modo principal permite retirar el GGSN por etapas. Primero se migra una parte de los suscriptores al nuevo gateway, luego todo el punto de acceso (APN) y, solo después, se retira el GGSN. Durante el proceso, el suscriptor que pasa entre 2G/3G y LTE conserva su conexión.
| Detalles técnicos | Descripción |
| Interfaces | Gn/Gp (2G/3G, GTPv1) y S5/S8 (LTE, GTPv2) |
| Qué se convierte | Direcciones y TEID, parámetros de QoS (TS 23.401, anexo E), ubicación, Charging ID, causas de rechazo |
| Roaming | Suscriptores conectados a través de Gp |
2. Reemplazo del PGW sin un cambio de una sola noche
Por lo general, la migración a un PGW de otro fabricante se hace de una sola vez. El cambio se programa para la noche y un plan de reversión preparado con anticipación permite restaurar la configuración anterior si surgen problemas durante la migración. Con GTPCProxy, el nuevo gateway se puede incorporar de forma gradual.
Las reglas de enrutamiento y los pesos del pool envían al nuevo PGW la proporción deseada de nuevas conexiones. Los suscriptores se pueden seleccionar por rango de IMSI, punto de acceso (APN) o tipo de red radio. Las sesiones ya establecidas permanecen en el PGW anterior hasta que terminan por sí solas.
Las reglas y los pools se guardan en el documento de enrutamiento, que es la configuración del proxy. Se puede modificar sin reiniciar el proxy. Antes de aplicarla, el proxy valida la nueva versión, y es posible volver a la anterior con una sola acción en la interfaz web.
Si el nuevo PGW empieza a rechazar conexiones o se sobrecarga, el proxy lo detecta al verificar el estado del pool y envía las conexiones a otro gateway del pool. Si el PGW falla por completo, sus suscriptores se vuelven a conectar a los gateways que funcionan y obtienen nuevas direcciones IP. El PGW recuperado vuelve a operar de forma gradual.
3. Gateways de socios, operadores virtuales y M2M
Muchos operadores tienen operadores móviles virtuales (MVNO), puntos de acceso corporativos o un gran cliente M2M con su propio PGW. Estos suscriptores deben distribuirse con precisión a sus gateways. Las reglas de GTPCProxy eligen el pool según los prefijos y rangos de IMSI, el punto de acceso, la red a través de la cual se conecta el suscriptor y el tipo de red radio.
El proxy también puede modificar los parámetros de la sesión, por ejemplo, el punto de acceso, las condiciones de tarificación o el tipo de conexión. Los parámetros modificados se tienen en cuenta al elegir el PGW y se transmiten al gateway seleccionado. Así, el PGW del socio recibe los parámetros en la forma que espera, y no hace falta reconfigurar el SGW ni el MME.
Otro criterio es la ubicación del suscriptor. En las reglas se pueden definir hasta 64 áreas. Así se construyen pools regionales de PGW y pools separados para una zona de eventos masivos o para dispositivos M2M en un territorio determinado.
| Qué tiene en cuenta la regla | Parámetro técnico |
| Número de la tarjeta SIM (prefijo o rango) | IMSI |
| Número telefónico (prefijo) | MSISDN |
| Punto de acceso | APN |
| Red a través de la cual se conecta el suscriptor | PLMN |
| Tipo de red radio | RAT Type |
| Ubicación (hasta 64 áreas) | TAC, ECI, eNB, LAC, CGI, SAI, RAI |
Los parámetros que el proxy puede sustituir son APN, Selection Mode, Charging Characteristics, PDN Type, entre otros.
4. Reconexión al gateway de la nueva región
Un PGW regional es práctico hasta que el suscriptor se traslada a otra región con una conexión abierta. En ese caso, sigue funcionando a través del gateway de la región anterior. El proxy se entera del cambio de ubicación por los reportes de los nodos de control de la red (MME y S4-SGSN).
GTPCProxy puede finalizar esa conexión según los procedimientos del estándar 3GPP (TS 23.401). Primero cierra la conexión hacia el SGW y el MME, luego hacia el PGW, y pide al dispositivo que vuelva a conectarse. El dispositivo se conecta entonces al pool de la nueva región y obtiene una nueva dirección IP.
Es mejor activar esta función por etapas.
- Primero se activa el modo de observación. El proxy no finaliza nada; solo cuenta las conexiones que finalizaría y las muestra en las métricas.
- Después se activa la finalización de conexiones propiamente dicha. Para ello se definen un límite de ritmo, una atenuación y una protección contra la finalización masiva cuando la ubicación cambia al mismo tiempo para un gran número de suscriptores.
Algunas conexiones el proxy no las toca. Si el suscriptor está en una llamada de voz, la finalización se pospone hasta que termine la conversación. Las conexiones de emergencia e IMS, las conexiones con dirección estática y las conexiones a puntos de acceso de la lista de exclusiones nunca se finalizan.
Adicional: las conexiones IMS se mantienen al reiniciar el SGW
Las llamadas por LTE (VoLTE) funcionan a través de conexiones IMS. Normalmente, cuando un SGW se reinicia, el PGW se entera por el cambio en el contador de reinicios (Recovery) y elimina todas las conexiones de ese SGW, incluidas las conexiones IMS.
Con la configuración correspondiente, GTPCProxy conserva las conexiones del SGW o SGSN reiniciado para que puedan restaurarse según el estándar 3GPP. De forma predeterminada, las conexiones se guardan durante 3660 segundos, es decir, alrededor de una hora. Como resultado, el reinicio de un SGW no corta las conexiones IMS en las que funciona VoLTE.
Conclusión
Ninguno de los cuatro escenarios requiere cambiar el MME, el SGW, el SGSN ni el PGW. Basta con agregar registros en el DNS para los puntos de acceso correspondientes. El proxy trabaja con todos los nodos según los estándares 3GPP, y todas las reglas se guardan en un único documento de enrutamiento.
VAS Experts propone probar la conversión de protocolo y la finalización de conexiones por cambio de región en el laboratorio del operador, en sus propios nodos. El paquete de validación en laboratorio incluye configuraciones, escenarios, el procedimiento de reversión y el formato de informe. Escríbanos y seleccionaremos los escenarios adecuados para su red.
