Un UE 5G puede estar funcionando con normalidad, con cobertura radio intacta e incluso con una PDU Session activa, cuando el AMF le envía de repente una Deregistration Request iniciada por la red. El UE no se ha apagado ni ha enviado por su cuenta una Deregistration Request.
No hay ninguna contradicción en este comportamiento. Una relación de registro en el 5GC no tiene que ser terminada necesariamente por el UE. Las acciones de operación y mantenimiento, una indisponibilidad prolongada del UE, el tratamiento interno de estado en el AMF o la retirada de la suscripción 5G del abonado en el UDM pueden hacer que la red finalice un registro existente. Al analizar trazas, las preguntas más importantes no son simplemente si los recursos del UPF acabaron eliminándose, sino quién tomó primero la decisión de desregistro, si el UE todavía puede recibir la notificación, si la red exige un nuevo registro y qué mensajes de señalización pueden legítimamente no aparecer nunca.
¿Quién puede decidir que un UE registrado debe salir del 5GS?
El desregistro iniciado por la red exige primero distinguir entre «iniciar» y «desencadenar». El procedimiento es iniciado y ejecutado finalmente por el AMF, pero la razón que lo provoca no siempre se origina dentro del propio AMF.
Una categoría comienza en el AMF. Un operador puede desregistrar explícitamente a un usuario por mantenimiento, migración de usuarios u otro objetivo de gestión de red, obligando a un UE que se encuentra en RM-REGISTERED a abandonar su registro actual. Otra categoría es el desregistro implícito. Si la red ya no puede confirmar que el UE sea alcanzable y se cumplen las condiciones de temporización correspondientes, el AMF puede empezar a limpiar el contexto sin esperar a que el UE inicie ninguna acción.
Una tercera vía comienza en el UDM. Por ejemplo, si el operador retira la suscripción de servicio 5G del abonado, el UDM detecta que el estado de la suscripción ha cambiado. El UDM no envía señalización NAS directamente al UE. En su lugar, notifica al AMF que presta servicio actualmente a ese UE, y el AMF convierte entonces esa decisión del núcleo en un procedimiento de desregistro iniciado por la red.
Desde la perspectiva de las relaciones entre funciones de red, las fuentes principales pueden resumirse así:
-
inicio explícito por el AMF: acciones de operación y mantenimiento, migración de usuarios u otros fines de gestión de red;
-
desregistro implícito del AMF: se cumplen las condiciones del temporizador de desregistro o de alcanzabilidad y el UE ya no puede considerarse normalmente registrado;
-
desregistro desencadenado por el UDM: por ejemplo, se retira la suscripción del usuario y el UDM indica al AMF que desregistre al UE.
Con independencia de la causa original, el objetivo final es el mismo: el registro 5GS anterior deja de ser válido y el UE pasa de RM-REGISTERED a RM-DEREGISTERED.
¿Por qué el desregistro explícito y el implícito se ven tan diferentes en una traza?
Ambos procedimientos terminan sacando al UE del estado registrado, pero su señalización puede verse muy distinta.
Durante un desregistro explícito, la red normalmente todavía puede comunicarse con el UE. El AMF puede enviar una Deregistration Request NAS para informar al UE de que su registro actual va a terminar. Si el UE sigue siendo alcanzable, puede devolver una Deregistration Accept, tras lo cual la red continúa liberando el contexto restante y la conexión de señalización del lado de acceso.
El desregistro implícito parte de una condición distinta. Normalmente ocurre después de que el UE no haya reaparecido ni respondido durante el tiempo suficiente para que la red deje de poder confirmar su alcanzabilidad. En ese momento, enviar otra Deregistration Request puede no tener sentido porque el UE puede estar ya apagado, fuera de cobertura o desconectado de otro modo.
Como resultado, el desregistro implícito puede aparecer simplemente como una limpieza de contexto del lado de la red sin un intercambio completo Deregistration Request → Deregistration Accept.
De aquí se obtiene una regla útil para analizar trazas: la ausencia de una Deregistration Request de la red al UE no demuestra que no haya ocurrido un desregistro iniciado por la red. En un escenario implícito, la red puede estar limpiando el contexto precisamente porque el UE ya no está disponible para señalización.
¿Cómo transmite el UDM al AMF una decisión de retirada de suscripción?
Un cambio en la habilitación de servicio del abonado es uno de los ejemplos más claros de desregistro iniciado por la red. Supongamos que un UE ya está registrado en una red visitada y ha establecido servicio, pero posteriormente la red de origen retira la suscripción 5G del usuario. El UDM detecta primero ese cambio de suscripción, no el gNB ni el UE.
El UDM puede enviar una Deregistration Notification al AMF de servicio mediante la URI de callback registrada previamente por ese AMF. En un caso típico, la notificación puede indicar un motivo como SUBSCRIPTION_WITHDRAWN e identificar el Access Type correspondiente, por ejemplo 3GPP_ACCESS.
Solo después de recibir esta notificación el AMF entra en el procedimiento de desregistro de red orientado al UE. El AMF puede entonces enviar una Deregistration Request NAS al UE a través del gNB. Además de la identidad del UE y el Access Type, un campo especialmente importante es re-registration required (se requiere un nuevo registro).
Este campo indica si la red espera que el UE ejecute un nuevo Registration después del desregistro. No debe interpretarse como que todo desregistro iniciado por la red obliga siempre a un nuevo registro exitoso. En algunos escenarios, la red puede querer únicamente que el UE abandone el AMF actual o reconstruya su contexto de registro. Si el abonado ha perdido realmente el derecho al servicio 5G, que un Registration posterior tenga éxito es una decisión independiente.
Una vez procesada la notificación del UDM al AMF, el AMF devuelve al UDM el acuse correspondiente. En ese punto, la cadena de control ha pasado de «ha cambiado el estado de la suscripción» a «el AMF de servicio está ejecutando ahora el desregistro».
¿Cómo se limpian los recursos internos después de que la red decide desregistrar al UE?
A partir de este punto, algunos pasos de liberación de recursos se solapan con el desregistro iniciado por el UE. Tiene poco valor repetir de nuevo cada mensaje N4, PCF y UDM. Lo importante es comprender por qué esas acciones de limpieza siguen siendo necesarias en un procedimiento iniciado por la red.
El UE puede tener ya una o más PDU Sessions activas. Cuando el AMF decide terminar el registro, debe indicar a los SMF correspondientes que liberen esas sesiones. El SMF gestiona después los recursos del plano de usuario y las rutas N3 del lado del UPF, y termina las relaciones de SM Policy que ya no disponen de un contexto de servicio válido. Las suscripciones o registros del UDM también pueden eliminarse según el estado de las sesiones restantes.
El propio AMF también puede necesitar liberar relaciones de política de acceso y movilidad, incluida una AM Policy Association y cualquier UE Policy Association aplicable. De lo contrario, la red podría acabar en un estado incoherente en el que el UE ya no esté registrado pero el PCF, SMF o UDM conserven relaciones que sugieren que el servicio activo continúa.
La parte difícil no consiste en «borrar todo lo posible». La red debe comprender el Access Type actual y cualquier estado de servicio que siga siendo válido. Si el UE permanece registrado mediante otro acceso o algún contexto sigue siendo utilizado por otra sesión, sería incorrecto eliminar todo el estado del UE.
Por tanto, tras observar una Deregistration Request iniciada por la red, la resolución de problemas no debe centrarse en si aparece una secuencia idéntica de 14 mensajes. Hay que verificar si las PDU Sessions que debían liberarse se han liberado realmente, si las relaciones de política obsoletas han terminado y si se ha conservado el contexto que todavía debe seguir siendo válido.
¿Cuál es la diferencia entre el desregistro explícito por el AMF y la retirada de suscripción por el UDM?
Las fases posteriores de estos dos procedimientos pueden parecer muy similares porque ambos dependen finalmente del AMF para desregistrar al UE y pueden entrar en la misma lógica de limpieza de PDU Session y políticas. Sin embargo, sus puntos de partida son distintos.
Si un operador elimina explícitamente al UE del AMF, la primera acción importante procede directamente del AMF. No existe una Deregistration Notification previa del UDM. El AMF ya dispone de la razón operativa para el desregistro y puede enviar directamente la Deregistration Request al UE.
Si se ha retirado el servicio 5G del abonado, el punto de partida es el UDM. Antes de que el AMF actúe, normalmente recibe una notificación de desregistro del UDM. En capturas de múltiples funciones de red, esta diferencia es muy útil porque muestra quién decidió primero que debía terminar el registro existente, en lugar de tratar toda la señalización posterior de limpieza como si perteneciera al mismo escenario.
Durante una migración de AMF o una redistribución de usuarios dentro de un pool de AMF, también debe examinarse el requisito de re-registration de la Deregistration Request junto con si el UE entra posteriormente en un nuevo procedimiento Registration. En ese caso, el desregistro puede ser un paso para mover el UE a otro AMF de servicio y no una terminación permanente del servicio 5G del abonado.
La retirada de suscripción es distinta por naturaleza porque refleja un cambio en la habilitación del abonado. Aunque el procedimiento NAS permita al UE intentar de nuevo un Registration, el núcleo seguirá evaluando ese intento frente al estado de suscripción actualizado.
En una traza, empiece por quién envió el primer mensaje
El desregistro iniciado por la red es más fácil de analizar si se divide en cuatro etapas: origen → notificación → limpieza de recursos → respuesta del UE.
-
Primero, identifique el origen. Si el primer mensaje relevante es una Deregistration Notification del UDM al AMF, el procedimiento fue desencadenado por un evento del lado del UDM. Si el AMF envía directamente la Deregistration Request al UE, es más probable que sea un caso de inicio explícito por el AMF. Si no aparece ninguno de los dos pero la red empieza a eliminar contexto del UE, considere el desregistro implícito.
-
Segundo, compruebe la dirección NAS. En un desregistro iniciado por la red, la Deregistration Request fluye AMF → UE. Esta dirección es la opuesta a la del desregistro iniciado por el UE. El nombre del mensaje puede ser idéntico, por lo que la dirección importa.
-
Tercero, compruebe si el UE devuelve Deregistration Accept. Durante un desregistro explícito, si el UE sigue siendo alcanzable, normalmente se ve una respuesta. En el desregistro implícito, el UE puede estar ya inalcanzable, por lo que este paso puede faltar.
-
Cuarto, verifique los recursos internos. Si el UE tenía previamente PDU Sessions, compruebe si se liberaron los recursos correspondientes del SMF y el UPF. Si el procedimiento se originó en el UDM o implicó estado de política, verifique también las relaciones del UDM y PCF.
Una secuencia práctica de análisis es:
-
Identificar qué NF inició o desencadenó el procedimiento;
-
Confirmar la dirección de Deregistration Request y el Access Type;
-
Comprobar si re-registration required coincide con el escenario;
-
Determinar si el UE devuelve Deregistration Accept;
-
Verificar la liberación de las PDU Sessions existentes y de los recursos del plano de usuario;
-
Finalmente, confirmar que el estado de registro del UE ha salido de RM-REGISTERED.
Esto se acerca más a la resolución real de problemas que comparar mecánicamente si falta un mensaje HTTP/2 en un flujo de referencia numerado. El desregistro iniciado por la red puede tener varias causas, por lo que distintos escenarios pueden verse diferentes desde el primer mensaje.
Preguntas frecuentes
¿El desregistro iniciado por la red siempre envía una Deregistration Request al UE?
No. Durante un desregistro explícito, si el UE es alcanzable, el AMF normalmente envía una Deregistration Request. El desregistro implícito suele ocurrir después de que el UE haya permanecido inalcanzable durante un periodo prolongado, por lo que la red puede limpiar directamente el contexto de registro sin que aparezca una Deregistration Request NAS en la traza.
¿Puede el UDM desregistrar directamente al UE?
El UDM es responsable principalmente de los datos del abonado y de suscripción. Eventos como la retirada de suscripción pueden desencadenar el desregistro, pero el AMF de servicio sigue siendo la función de red que ejecuta hacia el UE la Deregistration Request iniciada por la red. El análisis de trazas debe distinguir entre desencadenado por el UDM y iniciado por el AMF en el desregistro.
Si re-registration required está establecido en 1, ¿significa que el UE volverá a registrarse con éxito con certeza?
No. El campo indica que la red exige que el UE vuelva a ejecutar Registration, pero que el nuevo Registration sea aceptado depende de la habilitación del abonado, las restricciones de acceso, la política de red y la razón del desregistro original. Si se ha retirado la suscripción, un nuevo intento de Registration no garantiza que el 5GC acepte al UE.
¿Los pasos de liberación de recursos son completamente distintos a los del desregistro iniciado por el UE?
No. La dirección que desencadena el procedimiento es distinta, pero una vez que la red decide terminar el registro, la limpieza de PDU Sessions existentes, recursos del UPF y relaciones de política puede solaparse considerablemente con el desregistro iniciado por el UE. Las distinciones más útiles son quién inició el procedimiento, la dirección del mensaje NAS, si se espera confirmación del UE y si se requiere un nuevo registro.
