En el plano de control del núcleo 5G, la AMF es responsable de funciones clave como la gestión de acceso del UE, la gestión de movilidad y la señalización NAS. Por tanto, la fiabilidad de la arquitectura AMF tiene un impacto directo en la continuidad global del servicio. En una implementación tradicional, una gNB puede quedar asociada estáticamente a una AMF concreta. Este enfoque es relativamente sencillo cuando la red es pequeña, pero sus limitaciones se hacen cada vez más evidentes a medida que aumenta el número de abonados, los patrones de tráfico se vuelven más dinámicos y la implementación basada en la nube se generaliza. Una AMF que atiende un distrito comercial muy concurrido puede mantenerse muy cargada durante las horas punta mientras los recursos vecinos permanecen infrautilizados. Si una única AMF sufre un fallo de software o hardware, los usuarios dentro de su área de servicio pueden verse afectados. Las operaciones rutinarias, como actualizaciones de software y cambios de configuración, también pueden requerir ventanas de mantenimiento cuidadosamente planificadas.

AMF Pool, representado en la arquitectura 3GPP mediante el concepto de AMF Set, resuelve estos problemas con un modelo de implementación compartida de múltiples AMF. Varias AMF forman un único grupo lógico de servicio, mientras que las gNB pueden establecer conectividad N2 con las AMF del pool. Combinada con la estructura jerárquica de identidad GUAMI, la selección ponderada de AMF y la continuidad del contexto del UE, esta arquitectura permite distribuir la carga, resistir fallos, reducir la señalización durante la movilidad y flexibilizar el mantenimiento. La idea de agrupar nodos del plano de control no es exclusiva de 5G. Conceptos similares aparecieron en el SGSN Pool de GPRS y el MME Pool de 4G, todos basados en el mismo principio: sustituir la vinculación rígida a nodos por recursos de red compartidos. En 5G, el pooling de AMF complementa además el despliegue cloud-native y la gestión elástica de recursos.

Por qué es importante el AMF Pooling

Una de las principales razones para desplegar un AMF Pool es corregir el desajuste entre una distribución de abonados cambiante y una capacidad de nodo fija. El tráfico móvil es inherentemente dinámico. Durante el horario laboral, grandes cantidades de abonados pueden concentrarse en zonas comerciales, mientras que por la noche el tráfico se desplaza hacia áreas residenciales. Conciertos, eventos deportivos y desplazamientos vacacionales también pueden generar picos temporales repentinos. Si una zona geográfica depende únicamente de un pequeño número de AMF asignadas de forma estática, algunos nodos pueden saturarse mientras otros permanecen infrautilizados.

Cuando varias AMF operan en el mismo pool, las gNB pueden mantener conectividad con todas las instancias AMF pertinentes y los UE recién llegados pueden distribuirse según los pesos AMF configurados. Por ejemplo, si tres AMF con la misma capacidad de procesamiento prestan servicio en la misma zona, unos pesos equivalentes pueden repartir de forma relativamente uniforme los nuevos registros de UE y los contextos de movilidad, mejorando la utilización global de recursos.

La segunda gran ventaja es la resiliencia. Si una AMF sufre un fallo de software o hardware, las demás AMF del pool siguen disponibles para atender las siguientes solicitudes de acceso y movilidad. Para el plano de control del núcleo 5G, este modelo multinodo evita una dependencia excesiva de una sola AMF y proporciona una base más sólida para el funcionamiento de alta disponibilidad.

El pooling también mejora la flexibilidad operativa. Antes de actualizar software, cambiar la configuración o ampliar una instancia AMF, los operadores pueden reducir o migrar primero la carga activa asociada a ese nodo y permitir que otras AMF del pool asuman el tráfico nuevo o redistribuido. Cuando la AMF deja de transportar usuarios activos, el mantenimiento puede ejecutarse con menor impacto sobre los servicios en producción y con más libertad para elegir la ventana de intervención.

Optimización de movilidad dentro del pool

El valor de un AMF Pool va más allá de la redundancia multinodo. Una ventaja importante es la capacidad de reducir señalización a medida que un UE se desplaza por la red. Un pool puede cubrir múltiples Tracking Areas, mientras que las gNB dentro de ese dominio de servicio mantienen conectividad N2 con las AMF que pertenecen al mismo AMF Set.

Supongamos que un UE se registra inicialmente en TA1 y AMF1 crea su contexto. Si después el UE se desplaza a TA2 dentro del mismo pool, la nueva gNB puede seguir seleccionando AMF1 para gestionar la señalización NAS de ese UE. Mientras el UE permanezca dentro del área de servicio del mismo AMF Pool, la red puede intentar conservar la asociación AMF original.

Este diseño reduce la señalización de movilidad innecesaria. Sin pooling, el movimiento entre áreas de servicio podría exigir un cambio de AMF servidora, generando procedimientos adicionales de transferencia de contexto y registro. El pooling desacopla los cambios de ubicación del lado radio de los cambios obligatorios de nodo en el plano de control, permitiendo que un UE se mueva entre gNB y Tracking Areas sin cambiar automáticamente su AMF servidora.

Desde una perspectiva de ingeniería, el pool amplía de hecho el área geográfica en la que un contexto AMF puede mantenerse estable. Un UE puede desplazarse por múltiples gNB y TA conservando el mismo anclaje AMF, siempre que permanezca dentro del área de servicio del AMF Set correspondiente. Esto reduce las interacciones del plano de control y mejora la continuidad de la gestión de movilidad.

En la arquitectura 3GPP, esta lógica se representa mediante una estructura jerárquica. Un AMF Set contiene varias AMF que sirven una zona definida y soportan el mismo Network Slice o los mismos slices. Dentro de una única AMF Region pueden existir varios AMF Sets, lo que permite a redes de mayor tamaño dividir el plano de control en dominios de servicio manejables.

Cómo identifica GUAMI una AMF

Cuando el plano de control pasa de un nodo único a una arquitectura agrupada, la red necesita una forma estructurada de identificar regiones, sets e instancias AMF individuales. GUAMI, Globally Unique AMF Identifier, proporciona esa jerarquía.

Un GUAMI está compuesto por MCC, MNC, AMF Region ID, AMF Set ID y AMF Pointer. En conjunto, estos campos forman un modelo de direccionamiento jerárquico que abarca PLMN, AMF Region, AMF Set y la instancia AMF individual. El AMF Region ID identifica la región AMF más amplia, el AMF Set ID identifica un AMF Set concreto dentro de esa región y el AMF Pointer distingue una AMF individual dentro del set.

La misma jerarquía aparece también en las identidades temporales del UE. Un 5G-GUTI está formado por GUAMI y 5G-TMSI. Por ello, la información asociada a la identidad temporal del UE puede indicar qué AMF atendió previamente al UE. El 5G-S-TMSI contiene AMF Set ID, AMF Pointer y 5G-TMSI, aportando información utilizada en procedimientos como paging.

Por eso GUAMI influye directamente en la selección de AMF. Si un UE proporciona durante el establecimiento RRC información que identifica la AMF servidora previa, la gNB no necesita necesariamente realizar una selección completamente nueva basada en carga. Puede intentar seleccionar la AMF original y conservar la relación de servicio existente.

Además de los identificadores binarios, el descubrimiento de AMF también puede utilizar mecanismos FQDN y DNS. Una gNB puede construir un AMF Set-FQDN y consultar DNS para obtener información sobre las AMF que pertenecen a un set determinado, aportando datos para el posterior establecimiento de la asociación N2. Un AMF Instance-FQDN identifica una instancia AMF individual y puede ayudar a localizar una AMF servidora previa en escenarios de movilidad o interfuncionamiento aplicables.

Cómo selecciona la gNB una AMF

Una vez que un AMF Pool está operativo, la gNB debe gestionar dos situaciones de UE fundamentalmente diferentes. Una es la de un UE nuevo sin información utilizable sobre una AMF servidora previa. La otra es la de un UE que transporta información que identifica su AMF anterior. Estos casos requieren prioridades de selección distintas.

Si el UE no proporciona GUAMI ni otra información capaz de identificar su AMF previa durante el establecimiento RRC, la gNB selecciona una AMF del AMF Set utilizando los valores de peso configurados. A cada AMF se le puede asignar un peso en el rango de 0 a 255, normalmente según su capacidad de procesamiento. Una AMF de mayor capacidad puede recibir un peso más alto y aceptar más usuarios nuevos, mientras que una instancia de menor capacidad puede recibir un peso inferior.

Por ejemplo, si tres AMF están configuradas con pesos de 100, 50 y 50, la primera AMF puede recibir aproximadamente la mitad de los usuarios recién asignados cuando las demás condiciones son comparables. Estos pesos no tienen que permanecer estáticos. Si una AMF se amplía, se reduce o cambia de capacidad por otro motivo, la información de peso actualizada puede enviarse a las gNB conectadas mediante un procedimiento de actualización de configuración N2, permitiendo que las posteriores asignaciones de UE reflejen la nueva distribución de capacidad.

Si el UE proporciona un GUAMI válido, sin embargo, el objetivo de selección cambia. En lugar de reequilibrar inmediatamente el UE hacia otra AMF, la gNB intenta identificar y seleccionar la AMF servidora anterior. Mantener la AMF original ayuda a conservar la continuidad del contexto y evita cambios innecesarios en el plano de control.

Por tanto, la selección de AMF dentro de un pool puede resumirse en dos principios: cuando no existe una asociación histórica con una AMF, se prioriza la distribución de carga; cuando se conoce una asociación AMF previa, se prioriza la continuidad del servicio. El primer principio mejora el uso de recursos y el segundo reduce la señalización de movilidad. Un AMF Pool eficiente no está diseñado para mover cada UE a la AMF que tenga la menor carga en ese momento, sino para equilibrar la distribución de recursos con la estabilidad del contexto.

Del despliegue inicial al escalado elástico

Poner en servicio un AMF Set implica varias etapas. Primero se crean múltiples instancias AMF mediante un sistema de orquestación MANO o una plataforma de gestión de red, y se configuran las direcciones de asociación SCTP necesarias para la conectividad N2.

Después, la gNB establece asociaciones SCTP con las AMF del pool y ejecuta el procedimiento N2 Setup con cada AMF pertinente. N2 Setup hace más que establecer conectividad. También permite a la gNB obtener parámetros relacionados con el funcionamiento y la selección de AMF, incluidos datos como capacidad relativa o peso, slices soportados e información del área de servicio. Una vez establecidas estas relaciones, el AMF Set está preparado para prestar servicio a los UE.

Cuando llega un nuevo UE, la gNB determina si debe conservar una asociación AMF previa o seleccionar una AMF conforme a la información disponible del pool y los pesos configurados. Si todas las AMF tienen capacidades de procesamiento similares y pesos idénticos, con el tiempo sus cargas de abonados deberían tender hacia una distribución relativamente equilibrada.

Desde el punto de vista arquitectónico, un AMF Pool no debe considerarse una solución active-standby convencional. En un diseño active-standby, un nodo de respaldo puede permanecer casi inactivo hasta que se produzca un fallo. En un AMF Pool, varias AMF pueden prestar servicio activamente a usuarios al mismo tiempo. La resiliencia es uno de los resultados del pooling, pero el objetivo más amplio es hacer que varias instancias AMF funcionen como un único grupo lógico de servicio.

Esta característica convierte además al AMF Pooling en una base importante para despliegues 5GC basados en la nube. En un entorno cloud-native, las instancias AMF pueden escalarse mediante orquestación. El número de instancias, la capacidad de procesamiento y los pesos de selección pueden cambiar con el tiempo, mientras que el AMF Set lógico presentado a gNB y UE permanece estable. El pooling proporciona así un límite de servicio consistente sobre recursos de núcleo que cambian dinámicamente y soporta el comportamiento elástico esperado de un núcleo 5G orientado a la nube.

Preguntas frecuentes

¿Puede una AMF Region contener más de un AMF Set?

Sí. Una única AMF Region puede contener varios AMF Sets. Los diferentes sets pueden prestar servicio a zonas distintas, mientras que las AMF dentro de un mismo set soportan el mismo Network Slice o los slices requeridos por ese set.

¿Un Tracking Area corresponde únicamente a una gNB?

No. No existe una relación uno a uno entre Tracking Area y gNB. Un TA puede contener múltiples celdas y una gNB puede contener varias celdas que pertenezcan a uno o más Tracking Areas.

¿Cuál es la diferencia entre AMF Pointer y AMF Set ID?

AMF Set ID identifica un AMF Set, mientras que AMF Pointer distingue una instancia AMF concreta dentro de ese set. Junto con AMF Region ID, ambos forman partes importantes de la información de direccionamiento jerárquico contenida en GUAMI.

¿Cambiar el peso de una AMF requiere restablecer todas las conexiones N2?

No. Cuando cambia la capacidad de una AMF, la información actualizada de peso o capacidad relativa puede comunicarse a las gNB ya conectadas mediante el procedimiento correspondiente de actualización de configuración N2. El nuevo valor puede influir después en la asignación de nuevos UE sin necesidad de reconstruir la conectividad N2 existente.