Una sesión PDU puede llevar cierto tiempo funcionando con normalidad: el UE ya tiene una dirección IP, la ruta del plano de usuario N3 está activa y el tráfico de las aplicaciones circula como se espera. Después cambian las condiciones del servicio. Puede ser necesario reducir la velocidad de datos previamente autorizada, asignar un 5QI distinto a un flujo QoS o limitar la velocidad máxima de la sesión a 10 Mbps.
En esta situación, el 5GC no necesita desmontar y volver a crear toda la sesión PDU. La sesión existente puede seguir activa mientras se actualizan únicamente las reglas QoS, los parámetros de los flujos QoS o las políticas de aplicación del plano de usuario afectadas. Esa es la función de PDU Session Modification.
La diferencia respecto a PDU Session Establishment es clara. El establecimiento crea una sesión que antes no existía; la modificación cambia una sesión que ya está activa. Por tanto, las preguntas principales ya no son cómo se seleccionó el SMF o cómo se creó inicialmente el UPF, sino qué provocó el cambio, cómo obtiene el SMF la nueva política, qué deben actualizar el UE y el gNB y si la nueva política QoS se aplica realmente en el UPF.
Alcance de la modificación de sesión PDU
PDU Session Modification tiene un requisito previo fundamental: la sesión PDU de destino ya debe existir. El UE, el SMF, el PCF y el contexto RAN correspondiente ya están asociados a esa sesión, y el plano de usuario normalmente está operativo.
El objetivo del procedimiento de modificación es cambiar parámetros mientras la sesión permanece activa. QoS es uno de los ejemplos más habituales. Un flujo QoS existente puede necesitar un 5QI, MBR, MFBR u otro parámetro autorizado diferente. Un cambio de política también puede exigir actualizar el control de velocidad que ya aplica el UPF.
Una modificación de QoS no debe entenderse como el simple cambio de un campo NAS. Una sola actualización de QoS puede afectar a tres partes distintas del sistema:
Lado UE: el UE debe recibir la nueva regla QoS o los nuevos parámetros del flujo QoS;
Lado RAN: el gNB puede tener que modificar el recurso de sesión PDU correspondiente o los recursos del flujo QoS;
Lado UPF: si cambia la aplicación en el plano de usuario, las reglas PFCP correspondientes deben actualizarse a través de N4.
Por ello, PDU Session Modification se entiende mejor como una reconfiguración en línea de una sesión activa. La identidad de la sesión no cambia y la modificación se aplica al PDU Session ID existente y a sus flujos QoS asociados.
También hay un límite importante que conviene tener presente. PDU Session Modification puede actualizar un flujo QoS existente y, en escenarios de servicio aplicables, también puede utilizarse para establecer un nuevo flujo QoS dentro de la misma sesión PDU. Por ejemplo, una política impulsada por una aplicación para una llamada VoNR puede requerir un flujo adicional con características QoS específicas. Aquí, sin embargo, el objetivo es modificar los parámetros de un flujo QoS existente, no crear uno nuevo.
Principales desencadenantes de la modificación de sesión
Una diferencia importante respecto a PDU Session Establishment es que el UE no es el único posible desencadenante. Una sesión PDU activa puede reconfigurarse por una solicitud del UE, un cambio de política de red, una actualización de los datos de suscripción o cambios en las condiciones de radio.
Las fuentes de activación más comunes pueden agruparse en cinco categorías:
Iniciada por el UE: el UE envía un PDU Session Modification Request para solicitar un cambio de QoS o de otros parámetros de la sesión;
Iniciada por el PCF: cambia el control de políticas, por ejemplo cuando se alcanza un umbral de consumo y la red reduce la velocidad autorizada, o cuando una política de aplicación requiere otro QoS;
Iniciada por el UDM: cambian los datos de suscripción de gestión de sesión, por ejemplo el nivel del abonado o el perfil QoS contratado;
Iniciada por el SMF: el SMF decide reconfigurar la sesión según la política local, la configuración de red o el estado actual de la sesión;
Desencadenante relacionado con la RAN: el gNB informa de condiciones de radio o de recursos y el SMF determina después que deben modificarse los parámetros de la sesión.
Todos estos desencadenantes terminan convergiendo en el SMF, porque el SMF mantiene el contexto de control de la sesión PDU y convierte un nuevo requisito de servicio o de política en parámetros que pueden aplicar el UE, la RAN y el UPF.
Al diagnosticar PDU Session Modification, el primer paso no debería ser comenzar en PDU Session Modification Command y avanzar desde ahí. Es más útil identificar el primer evento de control que provocó el cambio. Si el primer evento es una UE Modification Request, el procedimiento fue iniciado por el UE. Si el PCF envía una nueva política al SMF mediante una Notification URI, el cambio está impulsado por política. Si primero aparece una actualización de datos de suscripción del UDM, el análisis debe seguir la ruta del cambio de suscripción.
Modificación de sesión PDU iniciada por el UE
Un procedimiento iniciado por el UE se entiende con facilidad como un caso en el que una aplicación necesita un QoS diferente.
Supongamos que el UE tiene actualmente el PDU Session ID 5 y que uno de sus flujos QoS sigue utilizando la configuración original. Una aplicación introduce un nuevo requisito de servicio, por lo que el UE solicita parámetros QoS distintos enviando un PDU Session Modification Request.
El mensaje NAS viaja primero a través del gNB hasta el AMF. A continuación, el AMF actualiza el SM Context existente hacia el SMF. En la interfaz basada en servicios, el AMF utiliza:
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
Esto es distinto de Create SM Context. El SM Context ya existe; la red está actualizando ahora el contexto de una sesión existente.
La solicitud del UE puede contener Requested QoS Rules, Requested QoS Flow Descriptions y Packet Filters relacionados. Tras recibir la solicitud, el SMF debe determinar si la red puede autorizar el cambio solicitado. Si la sesión utiliza control dinámico de políticas, el SMF también envía la solicitud de servicio al PCF para su autorización.
Por ejemplo, si el UE solicita 5QI 8 para un flujo determinado, el SMF puede invocar el servicio PCF SM Policy Control para modificar la Policy Association actual. El PCF evalúa la política del abonado, las reglas del servicio y las condiciones actuales de la red, y devuelve los parámetros QoS realmente autorizados.
Hay una diferencia importante: el QoS solicitado por el UE no tiene por qué ser el QoS que finalmente se aplique. El UE expresa el requisito de servicio, mientras que los parámetros finales están sujetos a la autorización del SMF y el PCF.
Una vez determinados los parámetros autorizados, el SMF genera dos tipos de información:
N1 SM: PDU Session Modification Command que transporta hacia el UE los nuevos parámetros relacionados con QoS;
N2 SM: información para el procedimiento PDU Session Resource Modify, que indica al gNB que modifique los recursos del flujo QoS correspondiente.
El AMF entrega la información N2 al gNB mediante NGAP y reenvía al UE el PDU Session Modification Command contenido en N1.
Después de que el gNB ajuste los recursos correspondientes, devuelve un PDU Session Resource Modify Response. Cuando el UE acepta los nuevos parámetros, envía PDU Session Modification Complete mediante NAS.
Solo después de que el SMF reciba los resultados de ejecución correspondientes puede confirmar que los nuevos parámetros de sesión han pasado de la autorización de política a una aplicación real en el lado de acceso y en el UE.
Modificación de QoS del lado de red iniciada por el PCF
La modificación del lado de red sigue una lógica distinta. El UE no ha solicitado un nuevo QoS; el cambio comienza en la capa de control de políticas.
Consideremos un ejemplo de umbral de consumo. Un usuario ya tiene una sesión PDU activa y está transfiriendo datos de forma continua. El PCF exige que la sesión informe o supervise información de uso. Cuando el consumo acumulado alcanza un umbral configurado, la política puede reducir a 10 Mbps la velocidad máxima de la sesión o del flujo relacionado.
El PCF notifica entonces al SMF mediante la Notification URI registrada al establecerse la SM Policy Association. La notificación contiene la nueva SM Policy Decision, por ejemplo el MBR actualizado y el Policy Control Trigger correspondiente.
Desde la perspectiva del SMF, esto no es la creación de una nueva sesión. Es la modificación de una sesión PDU que sigue siendo válida y está activa.
Si la nueva velocidad debe aplicarse en el UPF, el SMF envía un PFCP Session Modification Request a través de N4. El QER correspondiente puede actualizarse, por ejemplo cambiando el MBR a 10 Mbps. El nuevo límite de velocidad solo entra en vigor en el plano de usuario después de que el UPF acepte la modificación.
No deben confundirse dos usos distintos de la palabra «Modification»:
PDU Session Modification: procedimiento global del 5GS para modificar una sesión PDU activa;
PFCP Session Modification: procedimiento de control específico en N4 que utiliza el SMF para actualizar reglas del plano de usuario en el UPF.
Funcionan en capas distintas. Una PDU Session Modification puede incluir una PFCP Session Modification, pero la presencia de un mensaje de modificación PFCP no significa que haya terminado toda la modificación de la sesión PDU.
Después de que el UPF empiece a aplicar el nuevo QER, el SMF aún puede necesitar actualizar la RAN y el UE. La información N1/N2 se envía a través del AMF, el gNB recibe un PDU Session Resource Modify Request y el UE recibe un PDU Session Modification Command.
Cuando el gNB termina de actualizar los recursos de radio y el UE acepta los nuevos parámetros QoS, ambos devuelven sus resultados de ejecución. El SMF puede entonces informar del resultado satisfactorio al PCF para que el sistema de políticas sepa que la decisión de QoS se ha aplicado realmente y no se ha limitado a almacenarse como una decisión de política.
Modificación coordinada a través de N1, N2 y N4
Una de las partes más confusas de PDU Session Modification es que un mismo cambio de QoS puede generar al mismo tiempo procedimientos de modificación en NAS, NGAP y PFCP.
La lógica resulta más clara cuando se separan las tres rutas.
N1 actualiza los parámetros de sesión del UE
N1 SM transporta información de gestión de sesión entre el UE y el SMF. Después de que la red decida modificar la sesión, el SMF envía un PDU Session Modification Command al UE a través del AMF.
El UE actualiza sus parámetros locales de sesión PDU y confirma la aceptación con PDU Session Modification Complete.
N2 actualiza los recursos RAN
Cuando deben cambiar los recursos de radio asociados a un flujo QoS, el SMF genera la información N2 SM correspondiente y la entrega al gNB a través del AMF. El gNB modifica los recursos del flujo QoS mediante el procedimiento PDU Session Resource Modify y devuelve el resultado, incluidos los QFI modificados correctamente cuando corresponda.
N4 actualiza las reglas de aplicación del UPF
Si el cambio afecta al reenvío del plano de usuario o a la aplicación de QoS, el SMF actualiza las reglas correspondientes del UPF mediante PFCP Session Modification.
Un cambio del límite de velocidad puede requerir actualizar un QER. Otros cambios de política pueden afectar a un PDR, FAR u otra regla del plano de usuario. Las reglas que se modifican dependen del servicio y de la política de control; una PDU Session Modification no implica necesariamente reescribir todas las reglas PFCP.
Por tanto, un cambio completo de QoS puede resumirse así:
Política / solicitud del UE
→ el SMF recalcula los parámetros de sesión
→ N4 actualiza la aplicación en el UPF
→ N2 actualiza los recursos del gNB
→ N1 actualiza los parámetros del UE
→ cada parte confirma el resultado
El orden exacto de los mensajes puede variar según el desencadenante y los parámetros que se estén modificando. Durante el diagnóstico no resulta útil exigir que todos los escenarios contengan una secuencia idéntica de mensajes. Es mejor confirmar que cada punto de ejecución que necesita cambiar recibe y aplica realmente los nuevos parámetros.
Finalización de la modificación y diagnóstico de señalización
Los problemas de PDU Session Modification tienen una característica que los diferencia de los fallos de establecimiento: la sesión PDU puede seguir activa y el usuario puede continuar transfiriendo datos, aunque el QoS resultante no coincida con la política prevista.
Por ejemplo, la política puede exigir reducir la velocidad a 10 Mbps y el PCF puede haber emitido ya la nueva decisión de política, pero una prueba real de rendimiento sigue mostrando una velocidad mucho mayor. Que la sesión PDU siga existiendo no demuestra que la modificación haya tenido éxito. El diagnóstico debe determinar en qué punto dejaron de aplicarse los nuevos parámetros.
Una secuencia práctica de diagnóstico puede utilizar los siguientes puntos de control:
Identificar el desencadenante: determinar si el primer evento fue una UE Modification Request, una PCF Notification, un cambio de datos UDM o un evento del lado SMF/RAN;
Verificar la decisión del SMF: confirmar si el SMF aceptó la solicitud y si el PCF devolvió la decisión de política esperada;
Comprobar la aplicación en N4: si el UPF debe aplicar el nuevo QoS, verificar que PFCP Session Modification se completó correctamente y que los parámetros QER correspondientes cambiaron realmente;
Comprobar la ejecución en N2: verificar que el gNB recibió el PDU Session Resource Modify Request y devolvió los flujos QoS modificados correctamente;
Comprobar la confirmación en N1: verificar que el UE recibió el PDU Session Modification Command y devolvió PDU Session Modification Complete;
Validar el resultado del servicio: confirmar que el tráfico real sigue ahora la velocidad, el QoS o la política de servicio actualizados.
Si el PCF ya ha autorizado 10 Mbps pero el QER del UPF sigue conteniendo el MBR anterior, el análisis debe centrarse en la ruta SMF-N4. Si el UPF ya aplica la nueva velocidad pero el flujo QoS del gNB sigue usando los parámetros antiguos, debe revisarse con más detalle el procedimiento N2 Resource Modify. Si el lado de red ha completado todos los cambios necesarios pero el UE nunca devuelve Modification Complete, debe comprobarse el lado NAS para determinar si se aceptaron las nuevas reglas QoS.
Un nombre de mensaje también puede causar confusión. Algunos diagramas de procedimiento utilizan la expresión «PDU Session Modification Command Ack» para describir el paso de confirmación del UE. Sin embargo, en la señalización NAS 5GSM, el mensaje real enviado por el UE después de aceptar PDU Session Modification Command es PDU Session Modification Complete. Por ello, el análisis de paquetes debe utilizar el NAS Message Type real.
Este método de diagnóstico por capas es mucho más eficaz que reiniciar el análisis desde Registration Request. La sesión PDU ya existe. El problema es que una sesión activa no se ha actualizado de forma coherente con la nueva política. Por tanto, el dominio de fallo debe seguir centrado en el SM Context actual, la política, el flujo QoS y la aplicación en el plano de usuario.
Preguntas frecuentes
¿PDU Session Modification reasigna la dirección IP del UE?
Una modificación normal de QoS actualiza una sesión PDU existente y sus flujos QoS en lugar de reconstruir toda la sesión. Que cambien otros atributos depende del escenario concreto, pero una modificación limitada a parámetros como 5QI o MBR no debe tratarse como otro procedimiento PDU Session Establishment.
¿PDU Session Modification siempre la inicia el UE?
No. El UE puede solicitar una modificación mediante PDU Session Modification Request, pero un cambio de política del PCF, una actualización de datos de suscripción del UDM, una decisión local del SMF o un evento relacionado con la RAN también pueden desencadenar una modificación del lado de red. Normalmente, el SMF coordina las actualizaciones necesarias entre el UE, la RAN y el UPF.
¿Cuál es la diferencia entre PDU Session Modification y PFCP Session Modification?
PDU Session Modification es el procedimiento global del 5GS para modificar una sesión activa y puede implicar al UE, la RAN, el SMF, el PCF y el plano de usuario. PFCP Session Modification se produce específicamente sobre la interfaz N4 entre el SMF y el UPF y cambia reglas concretas del plano de usuario en el UPF. Esta última puede formar parte de la primera, pero no son equivalentes.
Si el QER ya se ha actualizado, ¿por qué siguen necesitando una modificación el gNB y el UE?
El QER controla la aplicación de QoS en el UPF, pero un flujo QoS no se define únicamente en el UPF. El UE puede necesitar una nueva regla QoS o una descripción de flujo, mientras que la RAN puede tener que ajustar los recursos de radio correspondientes. Por ello, algunas modificaciones de QoS requieren que N1, N2 y N4 se mantengan coherentes. Actualizar solo el UPF no significa que haya terminado todo el procedimiento PDU Session Modification.
¿PDU Session Modification puede añadir un nuevo flujo QoS?
Sí. PDU Session Modification puede actualizar los parámetros de un flujo QoS existente y, en escenarios aplicables, también puede utilizarse para establecer un nuevo flujo QoS dentro de la misma sesión PDU. Por ejemplo, un servicio VoNR impulsado por una aplicación puede requerir un flujo QoS adicional con un 5QI específico. Ese escenario tiene un contexto de servicio diferente al de una simple actualización de un flujo existente y conviene analizarlo por separado.
