Consideremos una sesión PDU ya establecida que transporta tráfico con normalidad. El UE dispone de una dirección IP, el gNB mantiene los recursos de la sesión PDU y los flujos QoS correspondientes, y el UPF tiene una sesión PFCP activa para el reenvío del plano de usuario. Si el usuario decide finalizar la conexión de datos, una función de políticas exige terminar la sesión o la red determina que ya no debe permanecer activa, el 5GC no se limita a modificar algunos parámetros QoS: debe desmantelar la sesión tanto en el plano de control como en el de usuario.
Esta es la finalidad de la liberación de sesión PDU. El procedimiento define cómo eliminar una sesión PDU establecida: se borra el contexto 5GSM del UE, se liberan los recursos de la RAN, se eliminan la sesión N4 y el estado de reenvío del UPF y, cuando corresponde, se da por terminada la relación de políticas asociada. El objetivo es que AMF, SMF, gNB, UPF y UE alcancen un estado coherente en el que esa sesión PDU ya no exista.
Este procedimiento no equivale al registro (Registration). Un UE puede liberar una sesión PDU y seguir registrado en el 5GS, mientras otras sesiones PDU activas continúan funcionando. Al analizar esta señalización, lo principal es seguir cómo se eliminan los recursos asociados a un ID de sesión PDU concreto en el UE, la RAN, el SMF, el UPF y las capas de control de políticas, en lugar de reiniciar el análisis de trazas desde Registration Request.
Diferencias entre liberación, establecimiento, modificación y cancelación del registro
El establecimiento, la modificación y la liberación de sesiones PDU, así como la cancelación del registro 5GS, pueden aparecer en las mismas trazas, pero responden a objetivos distintos.
| Procedimiento | Objetivo principal | Estado resultante |
|---|---|---|
| Establecimiento de sesión PDU | Crear una nueva sesión de datos y sus recursos del plano de usuario | Se activa una nueva sesión PDU |
| Modificación de sesión PDU | Modificar QoS, políticas o recursos de una sesión existente | La sesión PDU permanece activa |
| Liberación de sesión PDU | Terminar una sesión PDU específica y liberar sus recursos | Esa sesión PDU deja de existir |
| Cancelación del registro 5GS | Terminar la relación de registro entre el UE y el 5GS | El UE abandona el estado de registro 5GS correspondiente |
La liberación y la cancelación del registro se confunden fácilmente. Supongamos que un UE mantiene una sesión PDU para acceder a Internet y otra para una red empresarial privada. Liberar una no elimina automáticamente la otra ni implica necesariamente borrar el contexto de registro del UE almacenado en el AMF.
Tampoco debe confundirse RRC Release con la liberación de una sesión PDU. RRC Release cambia principalmente el estado de la conexión radioeléctrica entre el UE y el gNB, mientras que la sesión PDU puede seguir activa en la red central. En cambio, la liberación de sesión PDU elimina los recursos asociados a un ID de sesión PDUespecífico.
Para revisar cómo se creó originalmente la sesión, consulteProcedimiento de establecimiento de sesiones PDU en la red central 5GC. Si la sesión continúa activa y únicamente cambian sus parámetros QoS o de políticas, consulteProcedimiento de modificación de sesiones PDU en la red central 5GC.
Principales desencadenantes de la liberación de sesiones PDU
La liberación de una sesión PDU puede iniciarse en distintos puntos de la red. Una sesión activa puede terminar por una acción del UE, una decisión de control de políticas, una incoherencia del estado de red o una condición relacionada con los recursos.
Los desencadenantes habituales incluyen:
Iniciada por el UE: el UE envía un PDU Session Release Request cuando ya no necesita la sesión de datos actual;
Iniciada por el PCF: el control de políticas exige terminar la sesión porque la autorización del servicio, las condiciones de uso u otro requisito de política ya no permiten mantenerla activa;
Iniciada por el AMF: el AMF detecta una discrepancia entre los estados de sesión PDU del UE y la red, o el segmento de red (Network Slice) asociado deja de estar disponible;
Iniciada por la RAN: por ejemplo, todos los flujos QoS asociados a una sesión PDU ya se han liberado y la RAN comunica ese estado a la red central;
Iniciada por el SMF: el SMF determina que la sesión debe finalizar según una política local o información recibida de funciones como UDM o CHF.
Como el desencadenante inicial puede proceder de distintas funciones de red, los primeros pasos de señalización no siempre coinciden. El procedimiento acaba convergiendo en el SMF, que mantiene el contexto de control de la sesión PDU y coordina el plano de usuario del UPF, los recursos de acceso de AMF/RAN y la relación de políticas del PCF.
Durante el análisis de trazas de paquetes, identificar qué entidad solicitó primero la liberación suele ser más útil que comenzar directamente por PDU Session Release Command. Un Release Request del UE indica un procedimiento iniciado por el terminal. Una notificación de terminación del PCF señala una liberación determinada por políticas. Una solicitud del AMF para liberar un SM Context corresponde a otra variante iniciada por la red.
Señalización N1, N2 y N4 en una liberación iniciada por el UE
La liberación iniciada por el UE permite observar claramente cómo se eliminan los recursos de sesión en las distintas capas.
Supongamos que el UE utiliza el ID de sesión PDU 5 para acceder a datos. Cuando el dispositivo ya no necesita la sesión, genera un PDU Session Release Request y lo envía dentro de un N1 SM Container. El gNB reenvía el mensaje NAS al AMF mediante UL NAS Transport, y el AMF identifica el SMF responsable de ese ID de sesión PDU.
En la interfaz basada en servicios, el AMF reenvía la solicitud de liberación a través del SM Context existente, por ejemplo mediante Nsmf_PDUSession_UpdateSMContext. No se crea un nuevo SM Context: ya existe, y el AMF informa al SMF de que la sesión activa está entrando en el procedimiento de liberación.
A continuación, el SMF se encarga de limpiar el plano de usuario. Para una sesión N4 existente, envía una PFCP Session Deletion Request al UPF. El UPF elimina el estado del plano de usuario asociado a la sesión PFCP correspondiente y devuelve una PFCP Session Deletion Response.
Esto es fundamentalmente distinto de PFCP Session Modification durante la modificación de una sesión PDU. Una modificación actualiza reglas dentro de una sesión N4 existente; una eliminación suprime el estado de la sesión en el UPF.
Una vez iniciada la limpieza del plano de usuario, el SMF prepara la información para la RAN y el UE:
N2 SM: indica al gNB que libere el recurso correspondiente de la sesión PDU;
N1 SM: transporta el PDU Session Release Command hacia el UE.
El AMF envía PDU Session Resource Release Command al gNB mediante NGAP. El mensaje puede incluir el PDU Session Release Command de NAS para entregarlo al UE. Después de liberar los recursos de acceso asociados a la sesión PDU, el gNB devuelve PDU Session Resource Release Response.
Al recibir Release Command, el UE elimina su contexto local de sesión PDU y envía PDU Session Release Complete como confirmación 5GSM.
Una secuencia típica iniciada por el UE se resume así:
Solicitud de liberación del UE → AMF → SMF → Eliminación de sesión PFCP → Liberación de recursos N2 → Comando de liberación de sesión PDU → Confirmación del UE
Si el UE está inicialmente en CM-IDLE, la red real puede necesitar primero un Service Request para restablecer la conexión de señalización necesaria para continuar la liberación. Por ello, no debe suponerse que las trazas de paquetes comienzan siempre en el mismo estado radioeléctrico.
Liberación iniciada por la red y terminación de políticas del PCF
En una liberación iniciada por la red, el UE no envía primero PDU Session Release Request. El cambio puede comenzar en la capa de control de políticas o en otra función de la red central.
Consideremos un caso iniciado por el PCF. Una sesión PDU transporta tráfico normalmente, pero posteriormente el PCF determina que debe terminarse de acuerdo con la política. El PCF notifica al SMF mediante el mecanismo de notificación establecido para la asociación de políticas existente.
Tras recibir el desencadenante de liberación por políticas, el SMF aún debe desmontar el plano de usuario. Por tanto, PFCP Session Deletion Request y Response pueden aparecer antes de que el SMF envíe por medio del AMF la información N1 y N2 necesaria:
SMF → AMF → gNB / UE
La transferencia AMF N1N2 Message Transfer puede transportar tanto información N2 relativa a la liberación de recursos de sesión PDU como el PDU Session Release Command destinado al UE.
Desde la perspectiva del UE, independientemente de si la liberación inicial la desencadenó el PCF, el SMF u otra función, un procedimiento explícito de liberación NAS incluye el envío de PDU Session Release Commandpor parte de la red, seguido de la respuesta del UE mediante PDU Session Release Complete.
Sin embargo, desde la perspectiva de las trazas de la red central, esos dos mensajes NAS no bastan para identificar el desencadenante original. La evidencia relevante aparece antes de Release Command: una terminación de políticas del PCF, una solicitud del AMF de liberar el SM Context, un evento relacionado con la RAN o una decisión local del SMF.
Esta distinción importa tanto para el análisis técnico como para la resolución de incidencias: PDU Session Release Command indica que la red ordena al UE finalizar la sesión, pero no identifica por sí mismo qué entidad inició originalmente la liberación.
Limpieza de recursos en el UPF, la RAN y el contexto de políticas
No debe considerarse completada la liberación de una sesión PDU simplemente porque el UE ya no pueda enviar datos. Los recursos asociados deben limpiarse en las funciones de red pertinentes según el escenario de liberación.
N4 elimina la sesión del UPF
PFCP Session Deletion es una etapa fundamental de limpieza del plano de usuario. Una vez que el UPF elimina la sesión N4 correspondiente, los PDR, FAR, QER, URR y demás estados de reenvío aplicables dejan de funcionar como parte de la sesión PDU liberada.
Al finalizar el ciclo de vida de la sesión también se liberan los recursos N3 asociados y otros recursos de terminación del plano de usuario que resulten aplicables.
N2 libera los recursos del gNB
El gNB mantiene los recursos de acceso asociados a la sesión PDU y sus flujos QoS. Después de recibir PDU Session Resource Release Command, la RAN elimina los recursos correspondientes e informa del resultado a la red central mediante la respuesta adecuada.
Por tanto, completar correctamente PFCP Session Deletion no demuestra por sí solo que toda la liberación de la sesión PDU haya terminado. Si el UPF ya se ha limpiado pero el gNB conserva el recurso de sesión PDU, la red sigue en un estado incoherente.
El UE elimina su contexto de sesión 5GSM
Tras recibir PDU Session Release Command, el UE borra su contexto local de sesión y confirma la operación con PDU Session Release Complete. Para una sesión PDU de tipo IP, su dirección IP o prefijo asociado también entra en el proceso de liberación.
El SMF notifica al AMF y limpia el estado de políticas
Cuando la sesión alcanza el estado Released, el SMF puede enviar una SM Context Status Notification al AMF para que este sincronice el estado de sesión almacenado.
Si la sesión PDU tiene una SM Policy Association, la relación de políticas del PCF también debe terminarse o eliminarse según la variante aplicable. Si se trata de la última sesión que requiere un DNN, S-NSSAI o estado de suscripción determinado, el SMF puede realizar limpiezas adicionales de suscripción o registro que involucren al UDM o UDR cuando se cumplan las condiciones correspondientes. Estas acciones son condicionales y no aparecen necesariamente en todas las liberaciones.
Por tanto, la limpieza abarca un conjunto de estados asociados al ID de sesión PDU, no solo un túnel:
Contexto UE + Recurso RAN + Contexto SM + Sesión N4 del UPF + Asociación de políticas
Verificación de la finalización de la liberación en las trazas de señalización
Los fallos de liberación de sesión PDU no siempre son evidentes para el usuario. El UE puede haber dejado de transferir datos mientras persisten estados obsoletos en una o varias funciones de la red central. También puede ocurrir que el UE haya eliminado su sesión local y la sesión PFCP del UPF siga activa.
En lugar de memorizar todas las secuencias posibles de mensajes, un método de diagnóstico más eficaz consiste en definir puntos de comprobación alrededor del ID de sesión PDU afectado.
Identificar la sesión que se libera: centrar el análisis en el ID de sesión PDU correcto para no mezclar señalización de otra sesión simultánea en la traza;
Identificar el desencadenante: determinar si el primer evento es un UE Release Request, una notificación de terminación del PCF, una solicitud del AMF u otro evento de red;
Verificar el procesamiento del SMF: confirmar que la solicitud llegó al SMF responsable de la sesión PDU y que este inició la liberación;
Comprobar los recursos N4: confirmar que se completaron PFCP Session Deletion Request y Response y que se eliminaron las reglas de la sesión original del UPF;
Comprobar los recursos N2: verificar que el gNB recibió la señalización de liberación de recursos de sesión PDU y devolvió el resultado correspondiente;
Comprobar el estado N1: en un procedimiento explícito de liberación NAS aplicable, verificar que el UE recibió Release Command y respondió con PDU Session Release Complete;
Verificar el estado final: confirmar que el estado de sesión PDU en el AMF, el contexto del SMF y cualquier asociación del PCF son coherentes con el resultado Released.
Por ejemplo, si el UE ya devolvió PDU Session Release Complete pero la sesión PFCP correspondiente sigue presente en el UPF, la investigación debe centrarse primero en la limpieza de recursos del SMF y N4. Si se eliminó el estado PFCP pero el gNB conserva el recurso de sesión PDU, conviene comprobar después la ruta de liberación N2.
Por el contrario, observar únicamente RRC Release no permite concluir que la sesión PDU terminó si no existe PDU Session Release Request, Release Command o la limpieza correspondiente de recursos de la red central.
Los nombres de mensajes utilizados en distintas capas de las especificaciones también pueden generar confusión. Algunas descripciones emplean «PDU Session Release Ack» para una etapa del flujo, mientras que el mensaje NAS 5GSM real que envía el UE tras aceptar PDU Session Release Command es PDU Session Release Complete. El análisis de trazas de la interfaz radio y de NAS debe seguir el Message Type real.
Por tanto, el criterio de finalización más fiable consiste en preguntar: ¿se eliminaron los estados asociados al ID original de sesión PDU en el UE, la RAN, el SMF y el UPF, en lugar de limitarse a comprobar si apareció un determinado mensaje «final»?
Preguntas frecuentes
¿La liberación de sesión PDU cancela el registro del UE?
No necesariamente. La liberación de sesión PDU solo termina la sesión de datos especificada. El UE puede permanecer registrado en el 5GS y seguir usando otras sesiones PDU activas. La cancelación del registro es el procedimiento que termina la relación de registro del UE con el 5GS.
¿La liberación de sesión PDU libera también la dirección IP del UE?
En una sesión PDU de tipo IP, la dirección IP o el prefijo asociado es uno de los recursos que deben liberarse. Tras completarse el procedimiento, ya no debe utilizarse como dirección válida del plano de usuario de la sesión liberada. La recuperación de direcciones del conjunto disponible y su posterior reasignación dependen de la implementación de la red.
¿PFCP Session Deletion equivale a la liberación de sesión PDU?
No. PFCP Session Deletion es el procedimiento N4 mediante el cual el SMF elimina la sesión del UPF y sus reglas del plano de usuario. Suele ser una parte importante de la liberación de sesión PDU, pero el procedimiento completo también puede involucrar al UE, la RAN, el AMF, el PCF y otros contextos relacionados.
¿Cuál es la principal diferencia entre la liberación y la modificación de sesión PDU?
La modificación mantiene activa la sesión PDU mientras cambia QoS, políticas o recursos relacionados. La liberación termina la sesión especificada y elimina sus recursos asociados. Si el mismo ID de sesión PDU sigue siendo válido y transporta tráfico, normalmente no se trata de una liberación completada.
¿Por qué la red envía PDU Session Release Command después de una solicitud de liberación iniciada por el UE?
UE Release Request expresa la solicitud del UE de terminar la sesión, pero el SMF aún debe coordinar el estado del UPF, la RAN y el UE. Cuando la red procesa la liberación, PDU Session Release Command indica al UE que borre el contexto de sesión 5GSM correspondiente, y el UE responde con PDU Session Release Complete.
