En una red 5G Core, un pool de AMF suele asociarse con una mayor disponibilidad y con el reparto de carga, pero no basta con desplegar varias instancias de AMF. Cuando un gNB se conecta a un pool de AMF, necesita saber algo más que qué AMF están en línea. También debe conocer los GUAMI atendidos por cada AMF, los PLMN y segmentos de red compatibles, la capacidad relativa y cómo debe redirigirse el tráfico cuando un AMF se retira del servicio por mantenimiento.
La interfaz N2 proporciona la ruta de plano de control para este intercambio de información. Funciona sobre SCTP y utiliza señalización NGAP para intercambiar capacidades y sincronizar el estado entre el gNB y el AMF. Durante la configuración inicial de la red, primero se establece la asociación SCTP y después se ejecuta el procedimiento NG Setup. Durante la operación, los cambios en la capacidad del AMF, la información GUAMI o los puntos de terminación SCTP deben notificarse al gNB mediante procedimientos de actualización de configuración. Antes de un mantenimiento planificado, el AMF también puede indicar qué GUAMI dejarán de estar disponibles y proporcionar información sobre un AMF de respaldo.
Por tanto, la interfaz N2 dentro de un pool de AMF debe entenderse como una relación de control que se mantiene de forma continua, no como una conexión que se configura una vez y permanece sin cambios. Esta perspectiva permite entender mucho mejor los procedimientos de establecimiento, actualización y reselección como un único proceso de gestión.
Por qué un pool de AMF necesita algo más que una conexión establecida
Desde el punto de vista de la conectividad básica, una vez establecida una asociación SCTP entre un gNB y un AMF, ambos nodos pueden intercambiar mensajes NGAP. Sin embargo, en un pool de AMF la conectividad por sí sola no es suficiente.
Una misma área de servicio puede contener AMF1, AMF2, AMF3 y otras instancias de AMF. El gNB no solo necesita saber si esos AMF son alcanzables, sino también qué GUAMI, PLMN y segmentos de red soportan y qué proporción relativa de carga está en condiciones de asumir cada AMF en ese momento. Sin esta información, todas las asociaciones SCTP podrían estar en estado UP y, aun así, el gNB carecer de los datos necesarios para seleccionar un AMF adecuado para nuevos UE.
La gestión de la interfaz N2 puede dividirse en tres etapas principales:
| Procedimiento | Desencadenante típico | Objetivo principal |
|---|---|---|
| Configuración N2 | Activación inicial del sitio, arranque de la red o primera asociación con un AMF | Establecer la asociación SCTP e intercambiar parámetros del gNB y del AMF mediante NG Setup |
| AMF Configuration Update | Cambios en la capacidad relativa, la información GUAMI o los puntos de terminación SCTP | Mantener el gNB sincronizado con la configuración más reciente del AMF y facilitar la distribución posterior de UE |
| AMF Status Indication | Actualización de software, mantenimiento planificado u otra condición que deje temporalmente no disponible una parte del AMF | Informar al gNB de que determinados GUAMI no están disponibles y facilitar la reselección de AMF cuando sea necesario |
Estos tres procedimientos corresponden a tres etapas distintas del ciclo de vida de la relación con un AMF: descubrimiento inicial, cambios de capacidad o configuración y retirada temporal del servicio. Analizarlos en conjunto ayuda a entender cómo un pool de AMF soporta el reparto de carga y el mantenimiento planificado entre varios nodos de la red troncal.
¿Qué hacen SCTP y NG Setup, respectivamente, durante el establecimiento de N2?
En conversaciones de ingeniería, a toda esta fase se la suele denominar simplemente «configuración N2». Sin embargo, a nivel de protocolo consta de dos pasos consecutivos: primero se establece la asociación SCTP y, a continuación, se ejecuta el procedimiento NGAP NG Setup.
El gNB necesita obtener primero la dirección del punto de terminación SCTP de la interfaz N2 del lado del AMF. La dirección puede configurarse de forma estática u obtenerse mediante un mecanismo de resolución de direcciones adecuado. Después, el gNB establece una asociación SCTP con el AMF.
El establecimiento típico de una asociación SCTP consta de cuatro intercambios: INIT, INIT ACK, COOKIE ECHO y COOKIE ACK. Una vez completados, la capa de transporte está preparada para transportar la señalización NGAP. Sin embargo, el gNB aún no dispone de toda la información de servicio del AMF que necesita, por lo que a continuación se realiza NG Setup.
El gNB envía un NG Setup Request, que puede incluir información como Global gNB ID, Supported TA List, RAN Node Name y Default Paging DRX. En términos prácticos, este mensaje indica al AMF qué nodo RAN está conectándose, qué áreas de seguimiento admite y cuáles son sus parámetros básicos de funcionamiento.
Tras recibir la solicitud, el AMF devuelve un NG Setup Response. La respuesta proporciona información clave del lado del AMF, como AMF Name, Served GUAMI List, información de PLMN compatibles y RelativeAMFCapacity.
RelativeAMFCapacity es especialmente importante en un pool de AMF. No debe interpretarse simplemente como el número máximo de abonados que puede soportar un AMF. En su lugar, proporciona una referencia de capacidad relativa que el gNB puede utilizar para comparar varios AMF y tomar decisiones de selección y reparto de carga para UE posteriores.
Si el pool contiene AMF1, AMF2 y AMF3, el gNB puede establecer asociaciones N2 con los AMF correspondientes mediante el mismo proceso y obtener la información de servicio y capacidad relativa devuelta por cada nodo. Esto permite que varios AMF funcionen como un pool coordinado en lugar de como nodos de plano de control aislados.
Una captura de paquetes también muestra claramente esta secuencia: primero aparece el intercambio de establecimiento SCTP, seguido de los mensajes NG Setup Request y NG Setup Response. Cuando la asociación N2 básica está lista, la señalización de registro y movilidad relacionada con los UE puede utilizar la ruta de plano de control establecida.
¿Por qué debe actualizarse el gNB cuando cambian las capacidades del AMF?
El estado operativo de un pool de AMF no es estático. En un 5G Core basado en la nube, un AMF puede escalarse cuando aumenta la demanda de abonados, y también pueden cambiar su información GUAMI, área de servicio, direcciones de punto de terminación o capacidad de procesamiento.
Si el gNB sigue utilizando los parámetros obtenidos durante el arranque inicial, la lógica de selección de AMF en el lado RAN puede dejar de reflejar las capacidades reales de la red troncal. Aquí es donde cobra importancia el procedimiento AMF Configuration Update.
Este procedimiento no está relacionado con un UE concreto. Permite que el AMF notifique al NG-RAN los cambios de su propia configuración. Por ejemplo, después de escalar un AMF, su capacidad relativa de procesamiento puede aumentar y puede notificarse al gNB un nuevo valor de RelativeAMFCapacity. Los cambios en la información GUAMI también pueden sincronizarse mediante el mismo procedimiento, al igual que la adición o eliminación de direcciones de punto de terminación SCTP.
Supongamos que un sistema de orquestación o gestión detecta un aumento significativo del número de usuarios atendidos por AMF1 y amplía automáticamente sus recursos de procesamiento. Tras la ampliación, AMF1 puede asumir una proporción relativa mayor de la carga del plano de control, por lo que su valor de capacidad se ajusta en consecuencia.
A continuación, AMF1 envía un AMF CONFIGURATION UPDATE al gNB. El mensaje puede contener información GUAMI actualizada, un nuevo valor de RelativeAMFCapacity y cambios de puntos de terminación SCTP. Tras aplicar la actualización, el gNB responde con un AMF CONFIGURATION UPDATE ACKNOWLEDGE.
A partir de ese momento, cuando lleguen nuevos UE o el gNB deba realizar una nueva selección de AMF, podrá utilizar la información actualizada en lugar de los valores aprendidos durante el arranque inicial de la red.
Esto ilustra un principio importante del funcionamiento de un pool de AMF: el reparto de carga no se calcula una sola vez al arrancar la red. Puede ajustarse a medida que cambian los recursos de la red troncal.
Esto es especialmente relevante en un 5G Core nativo de la nube. Los recursos de cómputo pueden escalarse de forma dinámica, pero un aumento de la capacidad de cómputo no modifica automáticamente el comportamiento de selección de AMF en el lado RAN. Los parámetros actualizados del plano de control también deben comunicarse al gNB. AMF Configuration Update proporciona el mecanismo de señalización que vincula los cambios de recursos de la red troncal con los cambios en el comportamiento de selección del lado RAN.
¿Cómo se prepara el gNB para la reselección de AMF antes del mantenimiento?
El escalado añade capacidad. El mantenimiento crea la situación opuesta: un AMF puede necesitar quedar temporalmente no disponible por una actualización de software, un mantenimiento planificado u otra tarea operativa.
Si un AMF simplemente queda fuera de línea sin avisar al NG-RAN, el gNB puede seguir seleccionándolo basándose en la información almacenada previamente hasta que se produzcan fallos. En un pool de AMF, es preferible indicar al gNB con antelación que determinadas identidades de AMF dejarán de estar disponibles.
El procedimiento AMF Status Indication de NGAP se utiliza para este tipo de escenario de gestión de AMF.
Supongamos que AMF1 necesita una actualización de software. Antes de iniciar el mantenimiento, AMF1 puede enviar un AMF STATUS INDICATION al gNB e identificar los GUAMI que dejarán de estar disponibles. Si el mensaje también incluye un Backup AMF Name, por ejemplo AMF2, el gNB puede tenerlo en cuenta durante reselecciones posteriores, siempre que se admita la capacidad correspondiente.
Cuando el gNB recibe la indicación de estado, trata los GUAMI indicados como no disponibles y ajusta en consecuencia la selección y reselección posteriores de AMF.
Esto no significa que todos los contextos UE existentes se trasladen mecánicamente de AMF1 a AMF2 exactamente en el mismo instante. El objetivo es evitar que el NG-RAN siga seleccionando un AMF que está siendo retirado del servicio cuando más adelante sea necesaria una selección o reselección de AMF.
Por ejemplo, cuando un UE inicia posteriormente una actualización de registro de movilidad, el gNB puede enrutar la señalización correspondiente hacia otro AMF. El nuevo AMF puede seguir prestando funciones de gestión de movilidad y, cuando el procedimiento lo requiera, asignar un nuevo 5G-GUTI al UE.
Desde el punto de vista operativo, AMF Status Indication es esencialmente un mecanismo de retirada planificada del servicio. Traduce un evento operativo como «AMF1 entra en mantenimiento» en información de estado a nivel de protocolo que el NG-RAN puede comprender y utilizar antes de que el AMF quede realmente no disponible.
¿Qué gestiona realmente el pool de AMF mediante estos tres procedimientos?
Cuando NG Setup, AMF Configuration Update y AMF Status Indication se estudian por separado, pueden parecer tres procedimientos NGAP sin relación. Si se observan a lo largo del ciclo de vida de un pool de AMF, su relación resulta mucho más clara.
NG Setup establece la relación inicial. Cuando el gNB se conecta por primera vez a un AMF, necesita saber con qué AMF está comunicándose, qué servicios proporciona y cuál es su capacidad relativa de procesamiento dentro del pool.
AMF Configuration Update gestiona los cambios de capacidad y configuración. El AMF sigue disponible, pero han cambiado su información GUAMI, su capacidad relativa o sus puntos de terminación de transporte, por lo que el NG-RAN debe actualizar la información almacenada.
AMF Status Indication gestiona los cambios de disponibilidad. Cuando un AMF se prepara para mantenimiento o una retirada temporal, el gNB debe tratar los GUAMI correspondientes como no disponibles y prepararse para una reselección posterior de AMF.
En conjunto, estos procedimientos mantienen para el gNB una visión operativa esencial: qué AMF están disponibles, qué servicios ofrecen, qué proporción relativa de carga son adecuados para asumir y qué AMF están en proceso de salir del servicio.
Por tanto, un pool de AMF no alcanza alta disponibilidad simplemente por desplegar varias instancias de AMF. El gNB debe mantener continuamente una visión actualizada de las capacidades y el estado de los AMF y utilizarla al tomar decisiones de selección. Solo así un despliegue con varios AMF puede soportar eficazmente reparto de carga, escalado elástico y mantenimiento planificado.
La misma lógica resulta útil para el diagnóstico de fallos. Empiece confirmando que la asociación SCTP está sana y, después, verifique que NG Setup se ha completado correctamente. Si la conexión sigue activa pero la distribución de carga es anómala, revise la señalización AMF Configuration Update y RelativeAMFCapacity. Si el tráfico sigue dirigiéndose a un AMF que está saliendo de servicio, revise AMF Status Indication, la información de disponibilidad GUAMI y el comportamiento de reselección de AMF.
Preguntas frecuentes
¿Cómo se pueden distinguir rápidamente los fallos SCTP de los fallos NGAP en una captura de paquetes?
Empiece comprobando si la asociación SCTP se estableció correctamente. Si no se completa el intercambio INIT, INIT ACK, COOKIE ECHO y COOKIE ACK, el problema sigue estando en la capa de transporte. Si SCTP está establecido pero no se recibe NG Setup Response, o se devuelve un error de nivel NGAP, el diagnóstico debe continuar con los parámetros NGAP, la configuración TA, la información PLMN y los ajustes del lado AMF.
¿RelativeAMFCapacity representa el número máximo de UE que puede soportar un AMF?
No. RelativeAMFCapacity se entiende mejor como un indicador de capacidad relativa utilizado dentro de un pool de AMF. Ayuda al NG-RAN a comparar la capacidad relativa de procesamiento de distintos AMF con fines de selección. No debe interpretarse directamente como un límite absoluto de abonados.
¿Por qué no basta con cambiar la configuración local del AMF cuando cambia la información GUAMI?
El gNB ya ha almacenado información de servicio del AMF obtenida a través de la interfaz N2. Si el AMF cambia su configuración GUAMI sin avisar al NG-RAN, ambos lados pueden mantener visiones incoherentes de la identidad del AMF y de la disponibilidad del servicio. Por ello, la información actualizada debe sincronizarse mediante el procedimiento de gestión NGAP correspondiente.
¿AMF Status Indication siempre debe incluir un Backup AMF Name?
No. Backup AMF Name es opcional. Aunque no se incluya, el NG-RAN debe procesar los GUAMI identificados como no disponibles y realizar el comportamiento adecuado de gestión y reselección de AMF. Si se incluye Backup AMF Name y el NG-RAN admite el procedimiento correspondiente, el AMF de respaldo especificado puede tenerse en cuenta durante la reselección.
