Si una Registration Request ya ha llegado a un AMF, ¿por qué podría ser necesario cambiar el AMF que atiende al UE mientras el registro sigue en curso? ¿Significa eso que el gNB seleccionó el AMF equivocado? Si el UE no incluye un Requested NSSAI en la Registration Request, ¿en qué momento puede la red determinar qué slice de red necesita realmente? Estas preguntas apuntan a una rama especial del Initial Registration de 5GC: la reasignación de AMF. En conversaciones de ingeniería suele denominarse «reselección de AMF», aunque en el procedimiento de 3GPP es más preciso tratarla como una reasignación del AMF durante el registro.
La diferencia esencial entre una reasignación de AMF y un Initial Registration normal no es un procedimiento de autenticación adicional ni un cambio de AMF motivado por balanceo de carga. El Initial AMF obtiene información más completa sobre la suscripción y los slices, determina que no puede atender el S-NSSAI que finalmente necesita el UE, invoca al NSSF para identificar un ámbito de servicio AMF adecuado y, a continuación, transfiere el procedimiento de registro a un Target AMF.
La forma más útil de entender este flujo de señalización no es memorizar el número de paso en el que cambia el AMF. Conviene seguir tres puntos de decisión sucesivos: qué información tiene el gNB cuando realiza la primera selección de AMF, qué información adicional conoce el Initial AMF durante el registro y qué criterios utiliza finalmente el NSSF para dirigir al UE hacia un nuevo AMF de servicio.
¿Cuándo se activa la reasignación de AMF?
El Initial Registration con reasignación de AMF no es la ruta predeterminada de todos los registros 5GC. Sus condiciones de activación son concretas: Network Slicing está desplegado y el AMF que recibe inicialmente la Registration Request no puede atender el slice de red que el UE termina necesitando.
En un registro normal, el Initial AMF seleccionado por el gNB ya admite el S-NSSAI necesario. Por ello, el tratamiento de identidad, la autenticación, la obtención de datos de suscripción y el Registration Accept pueden permanecer en el mismo AMF durante todo el procedimiento.
La reasignación solo es necesaria cuando la información obtenida posteriormente muestra que el AMF actual no corresponde al slice que el UE tiene autorizado utilizar o que debe utilizar de forma predeterminada. La lógica puede resumirse así:
Registration Request llega al Initial AMF
→ El Initial AMF realiza el procesamiento de registro necesario
→ Se obtiene la información completa de suscripción y slices del UE
→ El Initial AMF determina que no puede atender el S-NSSAI de destino
→ Se invoca al NSSF para determinar el ámbito de servicio adecuado
→ El registro se transfiere al Target AMF
Conviene evitar un malentendido frecuente: que aparezcan dos AMF en la misma traza de registro no significa automáticamente que el AMF original haya fallado ni que se haya producido balanceo de carga dentro de un AMF Pool. En este procedimiento, el desencadenante real es una incompatibilidad entre la capacidad del AMF actual para atender slices y el slice de red que finalmente necesita el UE.
¿Por qué puede el gNB seleccionar inicialmente un AMF no adecuado?
Al analizar por primera vez la reasignación de AMF, es fácil pensar que el gNB se equivocó. Si distintos AMF atienden distintos slices, ¿por qué la RAN no envía al UE directamente al AMF correcto desde el principio?
La razón principal es que el gNB puede no disponer de información suficiente cuando realiza la selección inicial de AMF. Pensemos en un vehículo conectado que se enciende por primera vez con una USIM 5G suscrita a dos slices de red:
Slice eMBB (S-NSSAI1): utilizado para infoentretenimiento en el vehículo y servicios generales de datos;
Slice V2X (S-NSSAI3): utilizado para comunicaciones vehículo-a-todo (V2X) y servicios relacionados con la conducción automatizada.
Supongamos que el Default S-NSSAI del abonado es el slice V2X, pero el UE entra en el 5GS por primera vez, no tiene un 5G-GUTI válido y no incluye un Requested NSSAI en la Registration Request. En ese momento, el gNB no tiene una base directa para saber que el UE debería terminar siendo atendido por el AMF asociado al slice V2X.
En condiciones normales, el gNB puede utilizar información como el GUAMI, el S-NSSAI solicitado por el UE y su configuración local de AMF al seleccionar un AMF. En este escenario, sin embargo, ni el GUAMI ni el Requested NSSAI están disponibles, de modo que el gNB solo puede seleccionar un Initial AMF usando la información disponible y su política local de selección predeterminada.
Si el gNB selecciona inicialmente AMF1, que atiende el slice eMBB, la Registration Request se transporta hasta AMF1 dentro de un NGAP Initial UE Message.
Que este AMF no coincida con el requisito final de slice del UE no implica necesariamente un error de configuración del gNB. Una interpretación más precisa es: cuando se realiza la primera selección de AMF, la RAN todavía no dispone de información suficiente para determinar el AMF específico del slice final del UE.
¿Cómo detecta el Initial AMF la incompatibilidad de slices?
Cuando la Registration Request llega al Initial AMF, este no consulta inmediatamente al NSSF. En ese momento todavía carece de información suficiente del abonado para determinar si es el AMF de servicio final correcto.
El AMF sigue primero la lógica normal de Initial Registration y ejecuta los procedimientos necesarios, entre ellos el tratamiento de identidad del UE, la selección del AUSF, la autenticación 5G-AKA y los procedimientos de seguridad NAS relacionados.
Un resultado clave de esta fase es que el AMF confirma la identidad del UE y obtiene el SUPI. Con el SUPI disponible, el Initial AMF puede localizar el UDM adecuado y recuperar los Access and Mobility Subscription Data del UE.
En esta fase, la red dispone de mucha más información que cuando llegó por primera vez la Registration Request. Los datos de suscripción devueltos por el UDM pueden incluir el Subscribed NSSAI y el Default S-NSSAI del abonado.
Siguiendo con el ejemplo del vehículo conectado, el Initial AMF pertenece al dominio de servicio eMBB, pero los datos de suscripción muestran que el UE está suscrito tanto a eMBB como a V2X, con el Default S-NSSAI apuntando a V2X, es decir, a S-NSSAI3.
El Initial AMF puede ahora llegar a una conclusión que el gNB no podía obtener antes: aunque pudo recibir y comenzar a procesar el Initial Registration, no es el AMF adecuado para prestar servicio continuado al slice V2X predeterminado del UE. Esta determinación se convierte en el punto de activación de la reasignación de AMF.
Etapa del gNB: solo hay información de acceso limitada
→ Etapa del Initial AMF: se confirma la identidad del UE
→ Etapa del UDM: se obtiene la información real del NSSAI suscrito
→ Se determina que el AMF actual es incompatible con el slice de destino
Por tanto, la reasignación de AMF no es un cambio arbitrario de decisión a mitad del registro. Se produce porque la red central puede tomar una decisión más precisa sobre el AMF de servicio una vez que la identidad del abonado y la información de slices están completas.
¿Cómo identifica el NSSF el nuevo AMF de servicio?
Una vez que el Initial AMF determina que no puede atender el slice de destino, no elige simplemente otro AMF por su cuenta. En su lugar, invoca la Network Slice Selection Function, o NSSF.
El Initial AMF utiliza el servicio Nnssf_NSSelection para solicitar Network Slice Selection. Las entradas pueden incluir el S-NSSAI suscrito del UE, información sobre el AMF actual y el TAI actual del UE. El objetivo es determinar qué slices están autorizados en el área de registro actual y qué conjunto de AMF debe prestar servicio.
La Authorized Network Slice Information devuelta por el NSSF puede incluir:
Allowed NSSAI: los slices de red que el UE está autorizado a utilizar en las condiciones actuales;
Configured NSSAI: configuración de slices que puede proporcionarse al UE cuando sea necesario;
Target AMF Set: el conjunto de AMF capaces de atender el slice de red correspondiente;
Rejected NSSAI: slices que no pueden aceptarse bajo el TA actual o las condiciones relacionadas.
Es importante distinguir entre Target AMF Set y Target AMF. La primera responsabilidad del NSSF es determinar qué conjunto de AMF es adecuado, reduciendo el ámbito de candidatos según las condiciones de slice y ubicación, en lugar de devolver directamente la dirección de un AMF concreto.
Después de obtener el Target AMF Set, el Initial AMF puede utilizar la información de instancias NF registrada en el NRF para recuperar direcciones, capacidades, pesos y estado operativo de los AMF del conjunto. A continuación puede determinar qué Target AMF concreto debe asumir el Registration.
La relación puede resumirse así:
UDM: proporciona la información de suscripción a slices del UE
→ Initial AMF: determina que su propia capacidad de servicio no coincide
→ NSSF: determina los slices autorizados y el Target AMF Set
→ NRF: proporciona información sobre instancias AMF disponibles dentro del conjunto
→ Initial AMF: selecciona el Target AMF
El papel del NSSF en este procedimiento no es el balanceo de carga convencional. Su función es asignar un requisito de slice a un ámbito de servicio AMF capaz de admitirlo.
¿Cómo se transfiere la Registration Request al Target AMF?
Una vez determinado el Target AMF, el UE no necesita enviar una Registration Request completamente nueva. La red solo debe transferir el procedimiento de registro que ya está en curso, junto con el contexto necesario, para que el nuevo AMF continúe procesándolo.
Hay dos mecanismos de reenvío disponibles: reenvío indirecto a través del gNB o reenvío directo entre el Initial AMF y el Target AMF.
Reenvío indirecto a través del gNB
Con el reenvío indirecto, el Initial AMF envía al gNB un NGAP Reroute NAS Request. El mensaje transporta información asociada al Initial UE Message original, así como el Target AMF Set ID, e indica a la NG-RAN que redirija el mensaje NAS Registration actual.
El gNB envía entonces un nuevo Initial UE Message al Target AMF que contiene el NAS-PDU de la Registration Request original. La ruta del plano de control puede representarse así:
UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF
El UE no necesita volver a realizar el acceso RRC. La NG-RAN simplemente redirige el mensaje NAS Registration existente al AMF adecuado.
Reenvío directo entre AMF
Con el reenvío directo, el Initial AMF no devuelve el mensaje a través del gNB. En su lugar, transfiere directamente el mensaje N1 y el Registration Context al Target AMF mediante la interfaz basada en servicios de 5GC.
El Initial AMF invoca Namf_Communication_N1MessageNotify y envía al Target AMF la Registration Request completa junto con el Registration Context Container.
La información transferida no se limita a un único mensaje NAS. El Registration Context también puede incluir UE Context, Access Type, información del gNB, User Location, Allowed NSSAI, Configured NSSAI, Rejected NSSAI y otros datos necesarios para continuar procesando el registro.
UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF
Las rutas de señalización son diferentes, pero el objetivo es el mismo: el Target AMF recibe el mensaje NAS y el contexto necesarios para continuar el Registration sin reiniciar todo el procedimiento de Initial Registration.
Tras asumir el proceso, el Target AMF completa el procesamiento restante del registro y devuelve un Registration Accept al UE. La respuesta refleja los resultados de la selección de slice y la reasignación de AMF y puede incluir Allowed NSSAI, Configured NSSAI, Rejected NSSAI y un 5G-GUTI recién asignado.
Desde la perspectiva del UE, el resultado importante es que el registro se completa correctamente y la red proporciona los slices disponibles en el área actual junto con el nuevo contexto de movilidad 5GS. El cambio interno del AMF de servicio es transparente para el UE.
¿Cómo se verifica la reasignación de AMF en una traza de señalización?
Un Initial Registration con reasignación de AMF puede confundirse fácilmente con un enrutamiento de registro anómalo o con una primera selección de AMF fallida. Un método de diagnóstico más eficaz no consiste en comparar números de mensajes uno a uno, sino en seguir dos hilos principales: la determinación del slice y la transferencia de contexto.
Una secuencia de señalización normal debería permitir al ingeniero responder las siguientes preguntas:
¿Por qué la Registration Request llegó primero a este Initial AMF?
→ ¿Dónde obtuvo el Initial AMF el Subscribed / Default NSSAI del UE?
→ ¿Qué hizo que el AMF determinara que no podía seguir atendiendo al UE?
→ ¿Qué Target AMF Set devolvió el NSSF?
→ ¿Qué Target AMF concreto se seleccionó finalmente?
→ ¿Qué ruta se utilizó para transferir el Registration Context?
Si el Initial AMF ya ha obtenido la información de suscripción a slices y ha determinado que no puede atender al UE, pero no aparece después un procedimiento de selección NSSF, la investigación debe centrarse en el descubrimiento del NSSF, la solicitud Nnssf_NSSelection y la configuración de slices correspondiente.
Si el NSSF devuelve un Target AMF Set pero no puede identificarse un Target AMF concreto, las siguientes comprobaciones deben incluir la configuración del AMF Set, los NF Profiles en el NRF, el estado de las instancias AMF y la información de capacidades.
Si aparece un NGAP Reroute NAS Request pero el Target AMF nunca recibe el nuevo Initial UE Message, el foco del diagnóstico debe pasar de la selección de slices al redireccionamiento NAS en el gNB y a la conectividad N2 hacia el Target AMF.
Si se utiliza reenvío directo, la traza debe comprobarse en busca de Namf_Communication_N1MessageNotify y del Registration Context, en lugar de esperar un Reroute NAS Request que no aparecerá en esa ruta.
Visto el procedimiento completo, la reasignación de AMF resuelve un problema específico: la información disponible durante la primera selección de AMF es incompleta, y la red central corrige posteriormente la decisión sobre el AMF de servicio cuando obtiene la identidad completa del abonado y la información de suscripción a slices.
Cuando el UE entra por primera vez en la red, el gNB puede disponer solo de información GUAMI limitada, información de Requested NSSAI o su configuración AMF predeterminada. Después de la autenticación y la recuperación de la suscripción, 5GC puede finalmente determinar qué slices está autorizado a usar el abonado. El NSSF convierte entonces el requisito de slice en un Target AMF Set, mientras que el NRF ayuda a identificar la instancia AMF real que puede continuar el Registration.
Por tanto, la pregunta más útil al analizar este flujo de señalización no es «¿por qué cambió el AMF a mitad del registro?», sino: ¿en qué momento obtuvo finalmente la red información suficiente para determinar qué AMF debía seguir atendiendo al UE?
Preguntas frecuentes
¿La reasignación de AMF es lo mismo que el balanceo de carga en un AMF Pool?
No. El balanceo de carga en un AMF Pool suele centrarse en capacidad, ponderación y distribución de alta disponibilidad entre varias instancias AMF. En este procedimiento, la reasignación se debe a que el Initial AMF no puede atender el slice de red que finalmente necesita el UE. Ambos mecanismos pueden terminar utilizando otro AMF de servicio, pero sus condiciones de activación y la lógica de señalización son fundamentalmente diferentes.
¿Todo despliegue con Network Slicing requiere selección NSSF y reasignación de AMF?
No. Incluso con Network Slicing desplegado, la reasignación de AMF no es necesaria si el AMF seleccionado inicialmente por el gNB ya puede atender el slice que finalmente necesita el UE. La reasignación es una rama condicional del registro, no un paso obligatorio en todas las redes con slicing.
¿Puede el UE detectar directamente que el AMF cambió durante el registro?
Desde la perspectiva del UE, lo principal es si el Registration se completa correctamente y qué valores de Allowed NSSAI, Configured NSSAI, Rejected NSSAI y 5G-GUTI devuelve la red. La reasignación de AMF y la transferencia del Registration Context son procedimientos internos de control de 5GC y resultan en gran medida transparentes para el UE.
¿El reenvío indirecto o el directo es siempre más habitual?
No puede extraerse una conclusión universal solo a partir de la definición del procedimiento. El mecanismo utilizado depende de la arquitectura de despliegue de 5GC, la implementación del proveedor, las capacidades de comunicación basada en servicios entre AMF y la configuración de la RAN y la red central. El diagnóstico real debe seguir la ruta de señalización observada en la red en producción.
