Separar el plano de control y el plano de usuario permite distribuir estas funciones en nodos distintos y escalarlas de forma independiente. Pero la separación por sí sola no hace que el servicio sea continuo: solo crea una arquitectura en la que la continuidad puede lograrse.
Para eso, el nodo de transporte de datos debe volverse reemplazable, y su reemplazo debe ser una operación gestionada que no interrumpa las sesiones activas. A este enfoque arquitectónico se lo llama CUPS. Veamos por qué separar los planos no garantiza por sí sola la continuidad de las sesiones, en qué situaciones esa continuidad puede romperse, cómo funciona una transferencia gestionada de sesión y dónde este enfoque tiene sus límites.
De qué se compone la puerta de enlace de servicio
Dentro de la puerta de enlace de servicio hay una división en tres entidades: los datos de estado del abonado, la lógica de procesamiento de tráfico y la interfaz que las conecta.
El plano de control sabe quién es el abonado y a qué tiene derecho. Es una capa donde los cambios ocurren con poca frecuencia, pero son de importancia crítica.
El plano de usuario, en cambio, recibe solo cierta información por sesión, pero sabe qué ocurre con los paquetes. Clasifica el tráfico según el servicio al que pertenece, aplica reglas ya definidas y lleva contadores de consumo por cada servicio. Es una capa de alto rendimiento, optimizada para el throughput y no para almacenar conocimiento.
Entre ambos queda una interfaz estrecha y explícita: el plano de control envía comandos hacia abajo, y el plano de usuario devuelve reportes de estado y consumo.
Precisamente porque la interfaz es estrecha, un nodo del plano de usuario se vuelve reemplazable. No almacena nada permanente, solo lo que puede restablecerse mediante un comando desde arriba. Si ese nodo falla, se quema, se reinicia o se reemplaza por uno nuevo, el plano de control simplemente vuelve a enviar los mismos comandos y todo se restablece.
Figura 1 — Entidades del plano de control y del plano de usuario
Dónde puede romperse la continuidad
Poder cambiar nodos de forma independiente todavía no garantiza que el abonado no note el reemplazo. Un nodo de transporte de datos debe retirarse de servicio no solo ante una falla, sino también de forma planificada: por trabajos de mantenimiento o una actualización.
La diferencia entre estos casos es fundamental. Durante un trabajo técnico, el nodo sigue funcionando, así que hay tiempo para preparar primero un reemplazo y recién después desconectar el origen. Ante una falla no existe ese margen. El nodo deja de responder antes de que la red logre preparar el traspaso de sesiones. Se pierde parte del estado, y ya no es posible descartar por completo una interrupción.
De ahí surge una regla simple pero clave: mientras el nodo siga disponible, hay que trasladar la sesión al nuevo antes de desconectar el antiguo. Justamente sobre esta regla se construye la transferencia gestionada.
Transferencia gestionada: primero conectar, después desconectar
Este principio se conoce en otros ámbitos como «conectar antes de romper» (make before break). El nuevo nodo se prepara primero para atender la sesión, luego se traslada el tráfico hacia él, y solo después se desconecta el nodo antiguo. Aquí se manifiesta el sentido de separar los planos: el plano de control gestiona por completo la transferencia de la sesión, mientras que los nodos del plano de usuario solo ejecutan sus comandos.
El estado del abonado se almacena en el plano de control. Por eso puede recrearlo en otro nodo, transfiriendo el perfil, las reglas y los servicios permitidos. El nuevo nodo no recibe el estado directamente del antiguo: los nodos del plano de usuario no interactúan entre sí.
Es importante notar que la sesión no se «traspasa» de un nodo a otro sin más. Se traslada como una operación secuencial, por pasos, con un punto de no retorno. Mientras la secuencia no se complete, el sistema siempre conserva un nodo listo para atender la sesión. Por eso un reemplazo planificado no debería provocar el corte de la conexión.
Figura 2 — Esquema de la transferencia gestionada de sesión
¿Y qué pasa con la tarificación?
La continuidad de la transferencia de datos por sí sola no implica continuidad en el registro de consumo. El abonado puede no notar el cambio de nodo, pero si luego aparece una discrepancia en la facturación, el problema solo está resuelto a medias. Por eso, durante la transferencia hay que preservar no solo el estado del servicio, sino también la información de consumo.
Aquí se usan los reportes de ambos nodos. El nodo nuevo recibe un umbral: el volumen de tráfico que al abonado aún le queda permitido consumir. Ese umbral corresponde al remanente de la cuota conocida. Antes de desconectarse, el nodo antiguo envía al plano de control un reporte final del volumen realmente consumido. El plano de control suma esos valores y establece en el nodo nuevo un umbral ya absoluto.
Es importante que el volumen no se reconstruya a partir de los umbrales en sí. Se toma de los reportes de consumo real. Esto permite evitar dos problemas:
- la pérdida de parte del volumen consumido;
- el doble conteo del mismo volumen.
De aquí se desprende otra consecuencia: no hace falta cerrar una sesión de tarificación activa solo porque se haya trasladado el nodo. El abonado siguió usando el servicio y el volumen consumido se conoce con exactitud. Por lo tanto, no hay motivo para enviarle a la facturación un mensaje de corte.
Con 20 millones de abonados y cinco nodos de transporte de datos, esto se vuelve especialmente notorio. Si se retirara un nodo cerrando sesiones a la fuerza, hacia la facturación podrían llegar hasta 16 millones de mensajes. Con la transferencia gestionada, esos mensajes no se generan.
Dónde termina la continuidad
Todo mecanismo tiene límites de aplicación. Una arquitectura no solo debe mostrar lo que es capaz de preservar, sino también señalar con honestidad lo que no puede preservarse.
Traducción de direcciones NAT
Cabe notar que el User Plane de PCEF no solo cuenta con la función de DPI, sino que también provee NAT (CG-NAT, NAT64, NAT 1:1).
La traducción de direcciones CG-NAT es un mecanismo en el que el dispositivo del abonado recibe una dirección IP privada dentro de la red del operador, mientras que hacia afuera sale con otra dirección, pública. Esto resuelve el problema de la escasez de direcciones y mejora la seguridad. Pero la correspondencia entre la dirección interna y la externa se almacena en la memoria de un nodo específico. Si la sesión se traslada a otro nodo, la dirección y el puerto públicos de las conexiones ya establecidas cambiarán. Para esas conexiones, eso equivale a un corte.
Por eso, esas conexiones no pueden trasladarse de forma continua. Para ellas se usa la interrupción natural de las sesiones vigentes y el establecimiento de nuevas sesiones de tráfico: un retiro planificado del nodo implica trasladar el tráfico de una dirección privada hacia otro User Plane con un pool distinto de direcciones IP públicas.
Existe también otro enfoque: la sincronización de conexiones entre NAT. En ese caso, se sincroniza la tabla de traducciones NAT entre varios nodos. Pero esto ya es una decisión arquitectónica aparte, que además afecta el plan de direccionamiento. Por eso no puede tratarse simplemente como una configuración que elimina automáticamente la limitación.
Balanceo de tráfico entre varios UP
El tráfico de las sesiones es bidireccional: del abonado al servidor y viceversa. Las direcciones de ida y vuelta se balancean con mecanismos distintos.
El tráfico saliente se balancea mediante un balanceador L3 en función de la IPorigen y el IMSI. El tráfico entrante lo atrae el propio User Plane (DPI+NAT) mediante anuncios BGP.
Falla del nodo
Ante una falla del User Plane no hay transferencia gestionada: el DPI simplemente deja de responder. En ese caso, parte del volumen consumido puede no llegar al reporte final. Pero incluso aquí el tamaño de la pérdida posible puede limitarse de antemano. Está determinado por la suma de los umbrales establecidos en el nodo. El plano de control puede fraccionar las cuotas que otorga, estableciendo umbrales de reporte más pequeños y recopilando él mismo los datos intermedios. Hacia la facturación, sin embargo, se envía el valor original de la cuota, una vez que el volumen acumulado alcanza el valor necesario.
Así surge un presupuesto de riesgo gestionado. El operador define de antemano cuánto volumen resulta aceptable perder si falla un nodo. La frecuencia de los reportes de los nodos la determina ese presupuesto, mientras que la frecuencia del envío de información a la facturación la determina el tamaño de la cuota. El intercambio con la facturación en sí no se vuelve más frecuente por esto.
Cómo verificar la continuidad
La continuidad del servicio no se puede demostrar por el hecho de que el sistema no haya enviado un mensaje de error. Hay que medirla durante una transferencia real.
La prueba debe realizarse únicamente si en el momento de la transferencia hay tráfico real circulando por la sesión activa. Si aparece un corte en el flujo, la continuidad no se logró, sin importar con cuánta precisión el sistema haya registrado el propio cambio. Por eso, la prueba de aceptación debe verificar la transferencia de datos en sí, no la corrección de los mensajes de señalización.
Qué aporta finalmente la separación de planos
El valor de CUPS no se reduce al escalado independiente del control y la transferencia de datos. Lo más importante es que el plano de usuario se vuelve reemplazable. Y cuando un nodo puede reemplazarse, es posible convertir su retiro de un evento de emergencia en una operación gestionada.
Para los trabajos planificados, esto se traduce en una secuencia clara: preparar el nodo nuevo, trasladar las sesiones hacia él, desconectar el antiguo y conciliar los contadores. Para las fallas, queda otro mecanismo: un presupuesto de pérdidas aceptables definido de antemano.
Es justo aquí donde surge la continuidad del servicio. La separación permite gestionar el estado de las sesiones durante los cambios de infraestructura. Entonces, la promesa de «trabajos planificados sin impacto en los abonados» deja de ser una formulación general y se convierte en un procedimiento concreto, con un resultado medible y excepciones claramente definidas.
