Durante la resolución de incidencias en campo, uno de los errores más fáciles de cometer es ver un RRC Release y asumir que el desregistro del UE ya ha terminado. La conexión radio puede haber desaparecido y el UE puede haber dejado de enviar datos, pero el contexto de registro en el AMF, la sesión PDU en el SMF, la sesión N4 en el UPF, las asociaciones de políticas en el PCF y las relaciones de registro almacenadas en el UDM no desaparecen todos al mismo tiempo simplemente porque «se perdió la señal». En una traza de señalización, lo importante es la cadena de limpieza entre funciones de red que sigue al Deregistration Request: cómo determina el AMF el alcance del desregistro, cómo ordena el SMF al UPF retirar los recursos de plano de usuario y hasta qué punto deben liberarse las asociaciones del PCF y el UDM.
Desregistro iniciado por el UE es el procedimiento controlado para sacar del 5GS a un UE que ya estaba registrado. Comienza con un NAS Deregistration Request y puede implicar liberar sesiones PDU, eliminar sesiones N4 y túneles de plano de usuario en el UPF, terminar asociaciones de SM Policy y AM Policy, retirar el estado de registro relacionado en el UDM y, por último, liberar la conexión de señalización entre el UE y la red de acceso. El desregistro normal y el apagado pueden parecer similares en la primera parte del procedimiento, pero terminan de forma distinta: uno espera un Deregistration Accept y el otro no permanece conectado solo para recibir la confirmación. Esta diferencia puede pasar desapercibida al analizar trazas.
¿Por qué el desregistro es algo más que marcar el UE como desconectado?
Después de que un UE complete el Initial Registration y establezca una sesión PDU, el 5GC no guarda un único indicador de «conectado». El AMF mantiene el contexto de registro y movilidad, el SMF gestiona el contexto de la sesión PDU, el UPF conserva la sesión N4 junto con recursos de reenvío del plano de usuario como FAR, QER y URR, el UDM almacena las relaciones de registro del AMF y el SMF, y el PCF puede mantener asociaciones de políticas AM, UE o SM.
Si el UE simplemente desaparece de la red, estos recursos no se eliminan automáticamente en el mismo instante. Esto es especialmente importante cuando todavía existen una o varias sesiones PDU. La red necesita saber qué sesiones deben liberarse, qué reglas del plano de usuario deben borrarse y qué suscripciones o asociaciones de políticas ya no tienen motivo para mantenerse.
Por tanto, el desregistro iniciado por el UE realiza una desactivación ordenada del estado de registro y de sus recursos asociados:
El UE indica que debe finalizar el registro 5GS actual
→ El AMF determina el alcance del desregistro
→ Se liberan las sesiones PDU relacionadas
→ El SMF ordena al UPF retirar los recursos del plano de usuario
→ Se eliminan las asociaciones de sesión y de políticas
→ Se elimina el estado de registro
→ Se libera la conexión de señalización del lado de acceso
Por eso el desregistro no debe confundirse con RRC Release ni con una liberación ordinaria de la conexión N2. La liberación de una conexión RAN solo significa que ha terminado la conexión de señalización de acceso actual. El desregistro actúa a un nivel superior y elimina la relación de registro 5GS junto con el estado de sesión y de políticas asociado. Si una traza solo muestra RRC Release, concluir que el UE ya se ha desregistrado puede confundir fácilmente la «liberación de la conexión de acceso» con la «eliminación del registro».
¿Cómo define el Deregistration Request de qué forma y desde qué acceso abandona el UE?
Cuando el UE abandona activamente el 5GS, envía al AMF un NAS Deregistration Request. Para analizar la señalización, lo primero que debe revisarse no es si aparecen después mensajes PFCP, sino el Deregistration type y el Access Type incluidos en la solicitud.
El Deregistration type indica primero a la red si el procedimiento corresponde a un caso de apagado. En términos de ingeniería, el desregistro iniciado por el UE suele aparecer en dos situaciones: desregistro normal, en el que el UE sale de forma ordenada, y apagado, en el que el UE indica que está a punto de apagarse o entrar en una condición equivalente de cierre.
Access Type responde a otra pregunta: qué acceso se está desregistrando realmente. El UE puede desregistrarse solo del acceso 3GPP, solo del acceso no 3GPP o, cuando ambos tipos de acceso de la misma PLMN son atendidos por el mismo AMF, el procedimiento puede abarcar ambos cuando corresponda. Por tanto, «desregistro del UE» no significa siempre que se elimine de una vez todo el estado de acceso asociado a ese UE.
El Deregistration Request también transporta información de identidad del UE. Cuando existe un 5G-GUTI válido, el UE puede utilizarlo para ayudar al AMF a asociar el mensaje NAS con el contexto de UE existente. Si no hay un 5G-GUTI válido, el tratamiento de la identidad depende de la identidad 5GS que tenga disponible el UE. Desde la perspectiva del AMF, asociar correctamente este mensaje NAS al contexto de UE existente es un requisito previo para liberar las sesiones PDU y las asociaciones de políticas correctas.
Con un desregistro normal, el UE envía la solicitud y espera a que la red confirme su finalización. Con el apagado, el objetivo es entregar la indicación «me voy» lo antes posible y continuar después el proceso de apagado, por lo que el tratamiento es distinto. El desregistro normal puede utilizar T3521 para supervisar el periodo durante el que el UE espera Deregistration Accept, mientras que un procedimiento de apagado no espera la confirmación de la red del mismo modo.
¿Por qué el AMF comprueba primero si el UE aún tiene una sesión PDU?
Después de recibir el Deregistration Request, una de las decisiones clave del AMF es determinar si aún existen sesiones PDU establecidas en el acceso objetivo.
Si el UE no tiene ninguna sesión PDU relevante, no existe una sesión de plano de usuario que deba desmontarse individualmente y el procedimiento puede ser mucho más corto. Sin embargo, si una o varias sesiones PDU siguen activas, el AMF no puede limitarse a borrar su propio contexto de registro, porque el SMF y el UPF seguirían considerando que esas sesiones existen.
Para cada sesión PDU que deba liberarse, el AMF puede invocar Nsmf_PDUSession_ReleaseSMContext hacia el SMF correspondiente. Puede entenderse como una instrucción explícita del AMF a la capa de gestión de sesiones: el UE abandona el acceso objetivo y, por tanto, el SM Context relacionado ya no debe mantenerse. Solo después de recibir esta instrucción puede el SMF continuar eliminando la sesión N4, terminando asociaciones de políticas y limpiando el estado de registro pertinente en el UDM.
Esto también muestra la diferencia entre el desregistro y una liberación independiente de sesión PDU. Liberar una sesión PDU no significa que el UE abandone el 5GS; el UE puede seguir en estado 5GS Registered. En cambio, cuando el UE inicia el desregistro, las sesiones PDU asociadas al acceso objetivo normalmente deben limpiarse como parte del procedimiento de desregistro más amplio.
Por tanto, si una traza muestra un Deregistration Request pero después no aparece Nsmf_PDUSession_ReleaseSMContext, no debe tratarse inmediatamente como señalización ausente. Primero hay que confirmar si el UE tenía realmente una sesión PDU establecida sobre el Access Type correspondiente. Si no existía ninguna sesión PDU, la ausencia de un procedimiento de liberación N4 puede ser exactamente lo esperado.
¿Cómo desmontan realmente el SMF y el UPF el plano de usuario?
Una vez que el AMF envía al SMF la solicitud de liberación de la sesión PDU, el SMF asume la responsabilidad de retirar los recursos de plano de usuario asociados. Cuando existe una sesión en el UPF, el SMF la libera a través de la interfaz N4.
En un caso típico, el SMF envía un PFCP Session Deletion Request. El UPF utiliza el F-SEID correspondiente o el contexto de la sesión N4 para eliminar el estado de reenvío del usuario y devuelve un PFCP Session Deletion Response. A continuación se retiran los túneles de plano de usuario, las reglas de reenvío y el contexto relacionado asociados a la sesión PDU. La limpieza no se limita a un único túnel; también elimina el estado de reglas asociado a esa sesión N4, incluidos FAR, QER, URR y otras reglas aplicables.
La relación de control puede resumirse así:
UE → AMF: quiero desregistrarme
→ AMF → SMF: libera el contexto de sesión PDU de este UE
→ SMF → UPF: elimina la sesión N4 y los recursos de plano de usuario
→ UPF → SMF: confirma la eliminación
→ SMF → AMF: liberación del SM Context completada
Si la sesión utiliza PCC dinámico, el SMF también puede tener que terminar la asociación de SM Policy correspondiente, por ejemplo mediante Npcf_SMPolicyControl_Delete. Cuando la sesión liberada es la última sesión PDU gestionada por ese SMF para el DNN y S-NSSAI correspondientes, el SMF también puede cancelar su suscripción a los cambios de Session Management Subscription Data en el UDM y utilizar Nudm_UECM_Deregistration para eliminar del UDM la asociación entre el SMF y el DNN/sesión PDU correspondiente.
Desde la perspectiva de una traza del UPF, el punto en el que el desregistro llega realmente al plano de usuario no es el NAS Deregistration Request, sino la posterior liberación de la sesión N4. Solo cuando se completa este paso se retiran realmente del plano de usuario los recursos de reenvío pertenecientes a la sesión PDU original.
¿Por qué el UDM y el PCF todavía necesitan limpiar contexto adicional?
Una vez completada la liberación de la sesión PDU, el plano de usuario puede haber desaparecido, pero todavía pueden quedar asociaciones de plano de control en el 5GC. Para que el desregistro termine por completo, la red debe determinar qué suscripciones, registros y relaciones de políticas siguen siendo válidos y cuáles deben eliminarse.
En el lado de gestión de sesiones, si el SMF ya no presta servicio a la última sesión PDU del usuario para el DNN y S-NSSAI pertinentes, puede cancelar su suscripción a las actualizaciones de SM Data en el UDM y eliminar el SMF Registration relacionado. Esto evita que el UDM siga enviando actualizaciones de Session Management a un SMF que ya no atiende esa sesión.
En el lado de políticas de acceso y movilidad, si el UE ya no está registrado a través de ningún Access Type relevante y existe una AM Policy Association entre el AMF y el PCF, el AMF debe terminar esa asociación. Si existe una UE Policy Association, también debe liberarse cuando se cumplan las condiciones aplicables. Si el AMF ya no mantiene ningún registro válido para ese UE, la relación de registro del AMF en el UDM también puede tener que eliminarse mediante Nudm_UECM_Deregistration.
Hay aquí un límite importante: no se debe asumir que todo el contexto del PCF y el UDM deba desaparecer simplemente porque se produzca un procedimiento de desregistro. Si el UE continúa registrado mediante otro Access Type, o si el mismo SMF sigue gestionando otras sesiones PDU relevantes de ese UE, algunas asociaciones pueden seguir siendo necesarias.
Por tanto, la limpieza del desregistro no es simplemente una secuencia fija de solicitudes DELETE. Sigue un principio: eliminar únicamente el estado que ha perdido su sentido operativo debido a este desregistro, conservando el contexto que todavía utiliza otro acceso o sesión. Este es uno de los aspectos que más fácilmente se interpretan mal en despliegues con múltiples accesos y múltiples sesiones PDU.
¿Por qué el desregistro normal y el apagado terminan de forma diferente?
El desregistro normal y el apagado pueden provocar ambos la liberación de sesiones PDU y recursos del núcleo durante la primera parte del procedimiento, pero difieren en cómo termina el lado del UE.
En un procedimiento de desregistro normal, después de enviar el Deregistration Request el UE espera la confirmación de la red. Cuando el AMF completa el procesamiento aplicable, devuelve un Deregistration Accept, informando explícitamente al UE de que la red ha aceptado el desregistro. Mecanismos NAS como T3521 pueden supervisar este periodo de espera. Si T3521 expira, el UE sigue la retransmisión o el tratamiento de excepción definidos por el protocolo en lugar de asumir simplemente que el desregistro ha finalizado.
Si el desregistro se aplica al acceso 3GPP y todavía existe una conexión de señalización N2 entre el AMF y el NG-RAN, el AMF puede continuar con N2 UE Context Release para terminar la conexión de señalización correspondiente del lado de acceso.
El apagado es diferente. El UE está a punto de apagarse, por lo que mantenerlo conectado únicamente para esperar un mensaje de confirmación aporta poco valor. Cuando el Deregistration type indica apagado, el AMF no trata el lado del UE igual que en el desregistro normal exigiendo un Deregistration Accept antes de que el UE salga. Una vez que el UE ha hecho un esfuerzo razonable por entregar el Deregistration Request, puede continuar el proceso de apagado.
Esta diferencia es especialmente importante en las trazas de paquetes:
Desregistro normal
Deregistration Request
→ La red núcleo libera los recursos relacionados
→ Deregistration Accept
→ Liberación de señalización / AN
apagado
Deregistration Request
→ La red núcleo libera los recursos relacionados
→ El UE no espera Deregistration Accept antes de completar el apagado
Por tanto, la ausencia de Deregistration Accept en una traza de apagado no significa automáticamente que el procedimiento haya fallado. El primer paso es comprobar si el Deregistration type es desregistro normal o apagado. Si el UE ya se ha apagado, ha perdido el enlace radio o no tuvo tiempo suficiente para recibir una respuesta, la red puede apoyarse posteriormente en mecanismos como Mobile Reachable Timer e Implicit Deregistration para tratar una desaparición anormal del UE.
Preguntas frecuentes
¿Está garantizado que el UE entregue Deregistration Request al AMF cuando se apaga?
No. El procedimiento de apagado está diseñado para que el UE haga su mejor esfuerzo por enviar la solicitud de desregistro antes de apagarse, pero la red puede no recibirla si el UE ya perdió cobertura, falló el enlace radio o desaparece repentinamente la alimentación. Por eso el 5GC sigue necesitando mecanismos del lado de red como Mobile Reachable Timer e Implicit Deregistration para tratar los UE que desaparecen de forma inesperada.
¿El desregistro del UE siempre activa PFCP Session Deletion?
No. Si no existe una sesión PDU establecida en el Access Type objetivo, no hay una sesión N4 de plano de usuario correspondiente que liberar, por lo que pueden faltar los pasos del SMF y UPF asociados a la limpieza de la sesión PDU. PFCP Session Deletion solo es necesario cuando realmente existen una sesión PDU relevante y sus recursos de plano de usuario.
¿El desregistro y la liberación de una sesión PDU son el mismo procedimiento?
No. La liberación de una sesión PDU elimina una sesión de datos específica mientras el UE puede permanecer en estado 5GS Registered. El desregistro elimina la relación de registro del UE con el 5GS. Cuando el UE se desregistra, las sesiones PDU existentes normalmente deben liberarse como recursos asociados, pero ambos procedimientos operan en capas diferentes y tienen finalidades distintas.
¿Por qué puede permanecer parte del contexto del UDM o PCF después del desregistro del UE?
Primero hay que comprobar a qué Access Type se aplica el desregistro y si el UE sigue registrado mediante otro acceso. Si el UE conserva otro acceso válido, otras sesiones PDU o relaciones de políticas que siguen en uso, puede ser necesario conservar parte del contexto. El desregistro no debe interpretarse como una eliminación incondicional de todo el estado del UE en todo el 5GC.
