En una red 5G, una vez que el UE ha completado el registro, la red central necesita mantener una referencia general de su ubicación para poder localizarlo cuando lleguen paginación, servicios entrantes o datos de enlace descendente. Sin embargo, un UE no permanece siempre en el mismo lugar. Puede desplazarse de una Tracking Area a otra o incluso salir del área de servicio de su AMF actual. Si el UE tuviera que realizar un nuevo registro después de cada movimiento, la señalización del plano de control sería excesiva. Si nunca actualizara su ubicación, la red podría acabar perdiendo la referencia de dónde encontrarlo. Mobility Registration Update está diseñada para equilibrar la precisión de ubicación con la sobrecarga de señalización.
Una pregunta habitual al estudiar por primera vez la señalización 5GC es: si el UE ya está registrado, ¿por qué necesita enviar otra Registration Request después de desplazarse a una nueva zona? ¿Entrar en otro gNB activa siempre una actualización? ¿Acceder a una nueva Tracking Area significa siempre que debe cambiar el AMF? Todas estas preguntas apuntan al mismo principio: el UE permanece en estado 5GS Registered, pero su ubicación actual puede haber quedado fuera de la Registration Area que la red le asignó anteriormente. Por ello, el 5GC necesita actualizar la ubicación del UE, determinar si el AMF de servicio debe seguir siendo el mismo y asignar la Registration Area aplicable a la siguiente etapa de movilidad. No se trata de otro registro de encendido, ni el UE vuelve a registrarse cada vez que cambia de celda. Es un mecanismo para mantener la continuidad del contexto de movilidad 5GS del UE.
Salir de la Registration Area es el activador clave de la actualización por movilidad
El registro en 5GC no se limita al Initial Registration. El campo 5GS registration type incluido en la Registration Request distingue procedimientos como Initial Registration, Mobility Registration Update, Periodic Registration Update y Emergency Registration. En escenarios de movilidad, una de las confusiones más habituales es la diferencia entre una Tracking Area (TA) y una Registration Area.
Una TA es una de las áreas básicas utilizadas por la red para la gestión de ubicación, mientras que una Registration Area es un conjunto de TA dentro del cual el AMF permite que el UE permanezca registrado. Una Registration Area puede contener una sola TA o varias. Supongamos que un AMF presta servicio a TA1, TA2, TA3 y TA4, pero, según el comportamiento de movilidad, asigna TA1 y TA2 a un UE concreto como su Registration Area actual. Cuando ese UE se desplaza de TA1 a TA2, sigue dentro del área registrada y no necesita realizar una Mobility Registration Update únicamente porque haya cambiado la TA.
La situación cambia cuando el UE continúa hasta TA3 y TA3 no forma parte de la Registration Area almacenada actualmente. El UE detecta que el TAI actual está fuera de su área registrada, envía una nueva NAS Registration Request y establece el 5GS registration type en mobility registration updating. Por tanto, un cambio de celda no activa automáticamente una Mobility Registration Update, e incluso un cambio de TA no siempre la activa. El activador típico es entrar en una TA situada fuera de la Registration Area actual del UE.
Éste es el objetivo del concepto Registration Area. Permite que un UE se desplace dentro de un rango definido sin interactuar con el 5GC cada vez que cruza un límite de TA, ayudando a equilibrar la precisión de ubicación y la carga de señalización del plano de control. La red puede asignar una lista de TA más amplia a un UE con un patrón de movilidad más extenso o reducir la Registration Area cuando se necesita un seguimiento de ubicación más preciso. La propia Registration Area forma, por tanto, parte de la política de gestión de movilidad.
¿Cómo lleva la Registration Request el estado de movilidad existente de nuevo al 5GC?
La diferencia más clara entre Mobility Registration Update e Initial Registration es que el UE no es un abonado completamente desconocido. Ya ha completado el registro 5GS y normalmente conserva información como el 5G-GUTI asignado por la red, su Registration Area y el contexto NAS correspondiente. Por tanto, la nueva Registration Request no se utiliza para establecer la identidad desde cero. En su lugar, indica a la red: «Soy el mismo UE que ya conoces, pero mi ubicación de movilidad ha cambiado».
El UE establece primero el acceso al plano de control a través del nuevo gNB. Después, el gNB transporta la NAS Registration Request al AMF dentro de un NGAP Initial UE Message. Además del NAS-PDU, el Initial UE Message proporciona información de ubicación de acceso, como el NR-CGI y el TAI actuales. En una Mobility Registration Update típica, la Registration Request puede incluir varios elementos de información importantes: el 5GS registration type identifica el procedimiento como mobility registration updating; el 5G-GUTI ayuda a la red a identificar el AMF o GUAMI asociado al registro anterior del UE; Last Visited Registered TAI proporciona una referencia de la ubicación registrada anteriormente; UE Security Capability describe los algoritmos NAS compatibles de cifrado y protección de integridad; PDU Session Status refleja qué sesiones PDU considera el UE que siguen activas; y Requested NSSAI puede proporcionar los segmentos de red solicitados por el UE cuando corresponda.
Durante el análisis de trazas, la primera pregunta no debería ser si más adelante se realiza autenticación. La primera comprobación es si la propia Registration Request identifica claramente el procedimiento como Mobility Registration Update y no como Initial Registration. Si el tipo de registro se interpreta de forma incorrecta, el resto del flujo de señalización puede analizarse fácilmente desde una perspectiva equivocada.
¿Por qué las actualizaciones con el mismo AMF y las actualizaciones entre AMF siguen caminos distintos?
Salir de la Registration Area no significa necesariamente salir del área de servicio del AMF actual. Esta diferencia determina directamente la complejidad del resto del procedimiento de señalización y es una de las primeras ramas que deben identificarse al analizar una Mobility Registration Update.
El Serving AMF permanece igual
Supongamos que un AMF presta servicio tanto a TA1 como a TA2, mientras que la red había asignado previamente sólo TA1 como Registration Area del UE. Cuando el UE se desplaza de TA1 a TA2, TA2 queda fuera de su Registration Area actual, por lo que se requiere una Mobility Registration Update. Sin embargo, TA2 sigue estando dentro del área de servicio del mismo AMF.
En este caso, no existe una migración real de Old AMF a New AMF. El AMF actual ya conserva el contexto de movilidad del UE y sólo necesita procesar la nueva ubicación, actualizar la Registration Area y renovar cualquier información de política o de contexto necesaria. Cambia la Registration Area, pero no cambia el Serving AMF.
Cambia el Serving AMF
El procedimiento se vuelve más complejo cuando el UE pasa de una TA servida por un AMF a otra TA servida por un AMF diferente. Por ejemplo, el UE puede haber completado el registro con AMF1 y recibido un 5G-GUTI asociado a AMF1. Después de desplazarse a través de un nuevo gNB hasta el área de servicio de AMF2, el New AMF necesita saber quién es el UE, qué AMF lo atendía anteriormente y qué contexto puede reutilizarse.
Por ello, una Mobility Registration Update entre AMF es más que una actualización de ubicación. También implica la transferencia del contexto de gestión de movilidad del UE desde el AMF de servicio anterior al nuevo.
¿Cómo encuentra el New AMF al Old AMF y recupera el contexto del UE?
En un escenario de movilidad entre AMF, el primer problema que debe resolver el New AMF después de recibir la Registration Request no es si el abonado puede establecer servicio de datos, sino identificar qué AMF gestionaba anteriormente al UE. El 5G-GUTI desempeña aquí un papel importante. La información relacionada con GUAMI contenida en la identidad temporal ayuda a la red a identificar el AMF que atendía previamente al UE. El New AMF puede entonces determinar el Old AMF y solicitar el UE Context existente mediante el servicio Namf_Communication.
La lógica típica es sencilla: el UE envía una Mobility Registration Update utilizando su 5G-GUTI anterior; el New AMF extrae del 5G-GUTI la identidad relacionada con el AMF; se identifica el Old AMF; el New AMF solicita el UE Context; y el Old AMF devuelve el contexto de movilidad que puede transferirse. Esta información puede ayudar al New AMF a recuperar datos de identidad y movilidad como SUPI, GPSI, PEI y partes del Access and Mobility Context, permitiendo que el nuevo Serving AMF continúe desde un estado existente del UE en lugar de tratar el dispositivo como completamente desconocido.
Obtener el contexto del Old AMF no significa que todos los procedimientos de seguridad posteriores puedan omitirse siempre. Si la información de identidad disponible o el contexto de seguridad son insuficientes, la red puede volver a solicitar el SUCI del UE y realizar verificación de identidad o autenticación 5G-AKA según las condiciones de seguridad actuales. Por ello, el análisis de trazas debe evitar dos suposiciones rígidas: una Mobility Registration Update no siempre requiere una autenticación completa nueva, pero disponer de un Old AMF Context tampoco garantiza que la autenticación nunca vaya a repetirse. La aparición de Identity Request o de un 5G-AKA completo depende del UE Context transferido, del NAS Security Context y de la política de red.
¿Cómo completan UDM, NRF y PCF la toma de control del Serving AMF?
Recuperar el UE Context del Old AMF no significa que la relación de servicio se haya transferido por completo. En el 5GC, la ubicación del usuario y el estado del servicio se distribuyen entre varias funciones de red. En particular, el UDM necesita saber qué AMF es ahora responsable de atender al UE.
El New AMF puede utilizar el NRF para descubrir un UDM que proporcione los servicios necesarios y, a continuación, registrar en el UDM el nuevo 3GPP Access Registration. Este paso es especialmente importante en un escenario entre AMF porque el registro del Serving AMF en el UDM debe pasar del Old AMF al New AMF. El UDM puede entonces activar la Deregistration Notification correspondiente hacia el Old AMF para liberar la relación de servicio anterior.
El New AMF también necesita el Access and Mobility Subscription Data actual, que puede incluir GPSI, Subscribed NSSAI, UE-AMBR, parámetros de registro periódico, restricciones RAT y restricciones de acceso por área. Si la gestión posterior de PDU Session requiere seleccionar un SMF, el AMF también puede recuperar SMF Selection Subscription Data, incluida información de DNN y Default DNN asociada al S-NSSAI correspondiente, y suscribirse a los cambios en esos datos de suscripción. El PCF complementa este proceso proporcionando Access and Mobility Policy. El New AMF puede seleccionar el PCF adecuado y establecer una AM Policy Association para obtener información de política de movilidad, como restricciones de área.
Estos pasos resuelven problemas diferentes. El Old AMF Context indica al New AMF qué estado tenía previamente el UE. UDM Registration indica a la red central qué AMF atiende ahora al UE. Subscription Data indica al New AMF qué puede utilizar el abonado. PCF Policy indica al AMF qué reglas de movilidad y acceso se aplican actualmente. Por este motivo, una Mobility Registration Update no debe reducirse a «el AMF actualiza un TAI». En un escenario entre AMF, también transfiere la responsabilidad de gestión de movilidad de un AMF a otro.
¿Cómo define Registration Accept el siguiente rango de movilidad del UE?
Una vez completados el procesamiento de identidad, contexto, datos de suscripción y política, el AMF necesita aplicar el nuevo estado de registro tanto al gNB como al UE. En un procedimiento típico, el AMF puede utilizar un NGAP Initial Context Setup Request para establecer o actualizar el contexto relacionado con el UE en el gNB mientras entrega al UE el NAS Registration Accept.
La parte más importante de Registration Accept no es simplemente que el registro haya tenido éxito. El mensaje también proporciona parámetros que definen cómo debe operar el UE durante la siguiente etapa de movilidad. Tras un desplazamiento entre AMF puede asignarse un nuevo 5G-GUTI para reflejar el nuevo Serving AMF. Allowed NSSAI identifica los segmentos de red permitidos actualmente para el UE. T3512 define el temporizador asociado a futuras Periodic Registration Update. La TA List, o Registration Area, indica al UE por qué TA puede desplazarse mientras permanece registrado sin activar otra Mobility Registration Update del mismo tipo.
Después de que el gNB complete el procesamiento de contexto correspondiente, devuelve un Initial Context Setup Response y el UE envía Registration Complete. Con ello finaliza la Mobility Registration Update actual. Desde el punto de vista de la transición de estado, el flujo puede resumirse así: el UE sale de su Registration Area existente; la Registration Request lleva al 5GC la identidad de movilidad anterior; la red determina si debe cambiar el Serving AMF; cuando es necesario, se transfiere el UE Context desde el Old AMF; el New AMF completa el registro en UDM y obtiene la información necesaria de suscripción y política; Registration Accept proporciona el nuevo 5G-GUTI y la Registration Area; y, finalmente, el UE devuelve Registration Complete.
La resolución de problemas puede seguir la misma cadena de estados. Si la Registration Request llega al New AMF pero no se puede localizar el Old AMF, las comprobaciones deben centrarse en 5G-GUTI, GUAMI y el direccionamiento del AMF. Si el Old AMF Context se recupera correctamente pero el procedimiento se detiene en la etapa UDM, las siguientes comprobaciones deben cubrir el descubrimiento de UDM, AMF Registration y la recuperación de datos de suscripción. Si el procesamiento interno de la red central finaliza pero Registration Accept no llega al UE, la investigación debe continuar con los resultados de política, las restricciones de área, la señalización NGAP de enlace descendente y el establecimiento del contexto RAN. Por tanto, el objetivo al comprender 5GC Mobility Registration Update no es memorizar decenas de mensajes HTTP/2 y NGAP, sino entender cómo responde la red a tres preguntas después de que un UE registrado se desplace: ¿dónde está ahora el UE, qué AMF debe seguir gestionándolo y qué Registration Area debe aplicarse a su siguiente periodo de movilidad?
Preguntas frecuentes
¿Realiza el UE una Mobility Registration Update cada vez que entra en una nueva Tracking Area?
No necesariamente. La cuestión clave es si la nueva TA sigue formando parte de la Registration Area actual del UE. Si el AMF ya ha asignado TA1 y TA2 como Registration Area del UE, el desplazamiento de TA1 a TA2 normalmente no activará esta actualización únicamente porque haya cambiado la TA. Entrar en una TA situada fuera de la Registration Area es la condición de activación típica.
¿Una Mobility Registration Update siempre cambia el AMF?
No. El UE puede salir de su Registration Area actual mientras que la nueva TA siga perteneciendo al área de servicio del mismo AMF. En ese caso, el Serving AMF permanece sin cambios. La transferencia de contexto de Old AMF a New AMF sólo es necesaria cuando el UE entra en un área que debe ser atendida por otro AMF.
¿Cada Mobility Registration Update repite 5G-AKA?
No debe suponerse una regla fija. Que se repitan los procedimientos de identidad o 5G-AKA depende del UE Context disponible, del NAS Security Context y de la política de red. Si puede seguir utilizándose un contexto válido, es posible que algunos procedimientos de seguridad no tengan que repetirse por completo. Si las condiciones de identidad o seguridad son insuficientes, la red puede volver a ejecutar los pasos de autenticación necesarios.
¿En qué se diferencia una 5GC Mobility Registration Update de una actualización cuando un UE pasa de 4G a 5G?
Ambos escenarios pueden utilizar el tipo de registro Mobility Registration Update, pero el origen del contexto de movilidad es diferente. La movilidad completamente dentro de 5GS suele implicar contexto de movilidad entre un Old AMF y un New AMF. Un escenario de interfuncionamiento en modo inactivo de 4G a 5G puede implicar además al MME, N26 y la traducción entre contexto EPS y 5GS. Al analizar una traza de señalización, el primer paso es determinar si el UE se desplaza dentro del 5GS o entra en el 5GC desde el EPC.
