Un fallo de la red central no siempre se debe a una falta de capacidad de procesamiento. Con mucha frecuencia, el verdadero problema es el estado. Si una función de red falla pero el contexto del usuario sigue existiendo en un lugar fiable, otra función puede continuar el servicio. Si el contexto desaparece junto con el nodo averiado, la recuperación resulta mucho más difícil. Esta es la lógica de una de las ideas de diseño importantes de 5GC: separar los recursos de cómputo de los recursos de almacenamiento.

En una red central móvil, el contexto del usuario puede incluir el estado de registro, información de movilidad, identidades temporales, datos relacionados con la sesión, referencias de ubicación y otros estados del servicio. Estos valores ayudan a la red a saber quién es el UE, dónde está, qué sesión utiliza y cómo debe tratarse la señalización posterior. Cuando dicho contexto queda estrechamente ligado a una única instancia local de función de red, esa instancia deja de ser solo un nodo de procesamiento y se convierte en un punto único de riesgo para la continuidad del servicio.

5GC aborda este riesgo mediante un mayor uso de funciones de red sin estado. La idea no es que una función de red nunca utilice estado durante su operación. El punto clave es que el estado de larga duración o recuperable no debe quedar atrapado en una única instancia local de cómputo. Al permitir que datos no estructurados, como el contexto de UE, se almacenen y recuperen mediante UDSF, 5GC ofrece al AMF y a otras funciones de red un modelo de recuperación más flexible.

Por qué el estado local crea riesgos

El ejemplo del MME de 4G permite entender el problema con facilidad. En una red LTE/EPC, después de que un UE completa el procedimiento de conexión a través de MME1, ese MME crea y almacena localmente el contexto de UE. El contexto puede incluir información de gestión de movilidad y de sesiones, como la ubicación del UE, el GUTI y parámetros relacionados con la IP del UE.

Si MME1 falla de forma inesperada, MME2 puede seguir estando físicamente disponible dentro del grupo de MME. Sin embargo, la disponibilidad de otro MME no implica automáticamente continuidad del servicio. Si el contexto de UE existe únicamente en MME1, MME2 no dispone de información suficiente para seguir atendiendo al UE de forma fluida. Es posible que el usuario tenga que apagar y encender el dispositivo o volver a conectarlo antes de recuperar el servicio. Desde la perspectiva de la experiencia de usuario, este es un modelo de recuperación deficiente.

Una solución tradicional consiste en utilizar un clúster de MME con sincronización activo-en espera. En este diseño, el contexto de UE se sincroniza en tiempo real entre el MME activo y el de reserva. Si falla el MME activo, el nodo de reserva puede asumir el servicio con el contexto sincronizado. Este método puede reducir la interrupción, pero también presenta limitaciones. Puede depender de implementaciones específicas del proveedor, carecer de amplio soporte estándar, aumentar los costes y reducir la portabilidad entre distintos entornos de sistema.

El problema de fondo es que el estado local crea una relación estrecha entre una instancia de servicio y sus datos. Cuando el nodo de cómputo se convierte en el único poseedor práctico del contexto del usuario, la conmutación por error se complica. 5GC avanza hacia un modelo más limpio al colocar el estado recuperable en una función de almacenamiento independiente a la que pueden acceder las funciones de red autorizadas.

Qué cambia UDSF

UDSF significa Función de Almacenamiento de Datos No Estructurados. Permite que cualquier función de red de 5GC almacene y recupere sus datos no estructurados, incluidos datos como el contexto de UE. En este modelo, el AMF u otra NF puede procesar la señalización como función de cómputo, mientras UDSF ofrece un lugar independiente para conservar determinada información de estado.

El concepto es similar al de una estación de trabajo sin disco. Una estación de este tipo dispone de CPU, memoria, interfaz de red y otros componentes de ejecución, pero no guarda sus datos de trabajo en un disco duro local. Arranca y obtiene los datos desde un servidor de red. La estación realiza el cómputo mientras el almacenamiento permanece separado. En 5GC, las funciones de red pueden diseñarse de forma comparable: la NF ejecuta la señalización y la lógica de servicio, mientras los datos de contexto se guardan fuera de la instancia local.

El valor de UDSF no consiste simplemente en actuar como una base de datos. Su valor arquitectónico es que admite el diseño de NF sin estado, la recuperación del AMF y despliegues nativos de la nube más flexibles. Cuando el estado está disponible a través de UDSF, una instancia de AMF puede fallar sin provocar necesariamente la pérdida permanente del contexto de UE. Un AMF recién seleccionado puede recuperar el contexto necesario y continuar el procesamiento cuando se produce la siguiente transacción.

UDSF también encaja en la evolución general hacia redes centrales virtualizadas y nativas de la nube. En un despliegue en la nube, las instancias de funciones de red pueden escalar horizontalmente, reducirse, reiniciarse o desplazarse por la infraestructura. Si cada instancia mantiene una propiedad rígida sobre su estado local, la automatización se vuelve difícil. Separar cómputo y almacenamiento facilita la gestión del escalado y la recuperación.

Cómo se diferencian los tipos de datos

Para comprender correctamente UDSF, es importante distinguir entre datos estructurados y no estructurados. En la terminología de 5GC, los datos estructurados son aquellos cuya estructura está definida por las especificaciones de 3GPP. Los datos de suscripción son un ejemplo típico porque la estructura de sus recursos y su modelo de acceso están claramente descritos.

Los datos no estructurados son aquellos cuya estructura interna no está definida por las especificaciones de 3GPP. El contexto de UE es un ejemplo típico. Resulta esencial para la continuidad del servicio, pero su organización interna exacta no está normalizada del mismo modo que los datos de suscripción. Esto lo hace adecuado para su almacenamiento mediante UDSF.

Esta diferencia afecta al diseño de ingeniería. Los datos estructurados pueden gestionarse mediante servicios de datos normalizados con modelos de recursos definidos. Los datos no estructurados suelen ser generados e interpretados por la función de red responsable de la lógica de servicio. UDSF proporciona a esa función un lugar donde guardar y recuperar los datos sin obligar a convertir todo su formato interno en un árbol de datos estandarizado.

Para planificar el despliegue, los ingenieros no deberían tratar todos los datos de 5GC como una misma categoría. Los datos de suscripción, datos de políticas, estado de sesión, contexto temporal de usuario e información de recuperación pueden tener diferentes frecuencias de acceso, sensibilidad a la latencia, estructura, propiedad y requisitos de recuperación. UDSF se centra principalmente en almacenar el estado no estructurado que las funciones de red necesitan para mantener la resiliencia y la continuidad.

Cómo funciona la recuperación del AMF

Un proceso típico de recuperación de AMF con UDSF sigue una secuencia clara. Primero, un UE 5G se registra a través de AMF1. AMF1 crea el contexto de UE necesario para la gestión de acceso y movilidad. Después, AMF1 almacena el contexto de UE en UDSF. En ese momento, el estado del usuario deja de estar encerrado únicamente en la instancia local de AMF.

Si AMF1 falla, la red de acceso 5G o las funciones pares del plano de control detectan el fallo. El AMF averiado deja de considerarse para la selección. Cuando la red necesita elegir otro AMF del mismo conjunto de AMF, puede seleccionar AMF2. Es aquí donde UDSF modifica el comportamiento de recuperación.

AMF2 no necesita tratar al UE como un dispositivo completamente desconocido. Cuando se produce una transacción con el UE, AMF2 puede recuperar el contexto de UE desde UDSF. La recuperación puede utilizar identificadores como SUPI, 5G-GUTI o AMF UE NGAP ID. Tras obtener el contexto, AMF2 puede procesar el mensaje del UE y actualizar el 5G-GUTI hacia el UE cuando sea necesario.

El resultado práctico es una mejor continuidad del servicio. La red sigue necesitando una detección correcta de fallos, nueva selección de AMF y lógica de recuperación de contexto, pero la base de recuperación es más sólida que en un modelo donde todo el contexto del usuario se almacena únicamente dentro del nodo averiado. Desde el punto de vista del usuario, el resultado ideal es una recuperación que no requiera reiniciar el dispositivo, volver a conectarlo manualmente ni sufrir una interrupción perceptible.

Valor de ingeniería y limitaciones

El principal valor de ingeniería de separar cómputo y almacenamiento es la resiliencia. Si falla una instancia de AMF, el estado del servicio puede seguir estando disponible mediante UDSF. Esto reduce la dependencia del estado local del nodo y ayuda a la red a recuperarse con menor impacto. También admite escalado elástico, ya que pueden incorporarse nuevas instancias de función de red sin tener que sincronizar previamente y de forma local todo el estado histórico.

El segundo valor es la portabilidad arquitectónica. En comparación con la sincronización activo-en espera específica de un proveedor, UDSF forma parte de la arquitectura 5GC y se ajusta mejor al diseño estandarizado de redes centrales nativas de la nube. Permite abordar el almacenamiento y la recuperación del estado de una forma más abierta, en lugar de encerrar la alta disponibilidad en un mecanismo de clúster privado.

Sin embargo, UDSF no elimina toda la complejidad. Se convierte en un componente crítico de la cadena de recuperación. Si UDSF es lenta, no está disponible, presenta incoherencias o está mal protegida, puede transformarse en un nuevo cuello de botella. Por ello, UDSF debe diseñarse con alta disponibilidad, lectura y escritura rápidas, replicación fiable, control de acceso seguro y capacidad de recuperación ante desastres.

La selección de la base de datos también es importante. Tanto las bases de datos relacionales como las no relacionales pueden aparecer en diseños relacionados con UDSF, según la implementación del proveedor y los requisitos del sistema. La cuestión clave no es solo qué tipo de base de datos se utiliza, sino si toda la capa de almacenamiento puede cumplir los requisitos de latencia, fiabilidad, coherencia y recuperación propios de las telecomunicaciones.

Para los ingenieros, las comprobaciones más importantes incluyen si el contexto de UE se escribe en UDSF en el momento correcto, si el AMF recién seleccionado puede recuperarlo adecuadamente, si la selección del conjunto de AMF funciona como se espera, si los identificadores se gestionan de forma coherente y si la conmutación por error resulta realmente invisible o casi invisible para el usuario. La separación solo aporta valor cuando se prueba de extremo a extremo toda la ruta de recuperación.

Preguntas frecuentes

¿UDSF se utiliza únicamente por el AMF?

No. UDSF está diseñada para cualquier función de red que necesite almacenar y recuperar datos no estructurados. La recuperación del AMF mediante el contexto de UE es simplemente uno de los ejemplos más claros.

¿Por qué el contexto de UE se considera dato no estructurado?

El contexto de UE es importante, pero su estructura interna no está completamente definida como una estructura de datos normalizada por 3GPP. Esto lo hace adecuado para almacenarse como dato no estructurado.

¿UDSF sustituye todo el estado local dentro de las funciones de red?

No por completo. Las funciones de red pueden seguir utilizando estado local temporal durante el procesamiento. UDSF se emplea principalmente para conservar datos no estructurados recuperables que no deberían perderse junto con una sola instancia de cómputo.

¿Puede UDSF garantizar una interrupción de servicio igual a cero?

No por sí sola. Mejora la base de recuperación, pero la continuidad real también depende de la detección de fallos, la nueva selección de AMF, la actualidad de los datos, el comportamiento de señalización y la disponibilidad de UDSF.

¿Qué debe probarse antes de desplegar UDSF en producción?

Las pruebas deben cubrir el momento de escritura del contexto, su recuperación, la detección de fallos del AMF, la nueva selección del conjunto de AMF, la conmutación por error de la base de datos, la latencia de lectura y escritura, la seguridad de acceso y la experiencia real del UE durante la recuperación.

La separación de cómputo y almacenamiento en 5GC es más que un ajuste de base de datos. Cambia la forma en que la red central entiende el estado, los fallos y la recuperación. Al utilizar UDSF para guardar datos no estructurados, como el contexto de UE, las funciones de red pueden depender menos del almacenamiento local y adaptarse mejor a despliegues nativos de la nube resilientes. La idea esencial es sencilla: las instancias de cómputo pueden fallar o cambiar, pero el estado del usuario debe seguir siendo recuperable.