Un caso común de resolución de problemas del plano de usuario 5G puede resultar confuso al principio: la PDU Session se establece correctamente, el UE recibe una dirección IP, la PDR coincide con el tráfico esperado, la FAR contiene FORW y los paquetes incluso pueden empezar a circular. Aun así, el usuario experimenta buffering de vídeo, velocidades de descarga inesperadamente bajas o tráfico que funciona solo en una dirección.
Cuando ocurre esto, revisar únicamente la PDR y la FAR puede no revelar la causa. El problema puede no estar relacionado con si el tráfico fue identificado o adónde se reenvió el paquete, sino con qué política de QoS aplicó la UPF después de autorizar el reenvío. Dentro del marco de reglas PFCP de la interfaz N4, la QER (QoS Enforcement Rule, regla de aplicación de QoS) es responsable de aplicar estas políticas de QoS en la UPF. Puede controlar si el tráfico puede pasar, limitar las tasas de uplink o downlink, asociar el tráfico con un QoS Flow y aplicar marcas a nivel de transporte. Por ello, PDR, FAR y QER deben analizarse conjuntamente para comprender el comportamiento completo del plano de usuario.
¿Por qué sigue siendo necesaria QER después de que PDR y FAR funcionen correctamente?
La forma más sencilla de entender QER es separar las responsabilidades de las distintas reglas de la UPF.
La PDR responde primero a la pregunta «¿Qué tráfico es este?». Utiliza condiciones como PDI, dirección IP del UE, F-TEID y SDF Filter para detectar y clasificar paquetes. Una vez identificado el tráfico, la FAR responde a la siguiente pregunta: «¿Qué debe ocurrir con este paquete y adónde debe reenviarse?»
Pero permitir que un paquete se reenvíe no significa que pueda hacerlo sin restricciones. Si la red aún necesita controlar la tasa, el gating, la asociación con un QoS Flow o el marcado a nivel de transporte, la UPF debe aplicar la QER asociada.
Por tanto, una secuencia típica de procesamiento puede simplificarse así:
PDR identifica el tráfico → FAR determina la acción de reenvío → QER aplica la política de QoS.
Estas reglas no se sustituyen entre sí; trabajan juntas. Un paquete puede coincidir correctamente con una PDR y estar permitido por la FAR, pero seguir sujeto a límites de velocidad o condiciones de gating definidas por la QER. Sin QER, la UPF puede saber que el paquete debe reenviarse, pero no tendría la misma información de política que describe cómo debe tratarse ese tráfico desde la perspectiva de QoS.
¿Cuándo se instala una QER y por qué puede actualizarse posteriormente?
Una QER suele ser provisionada por la SMF hacia la UPF durante PFCP Session Establishment como parte de las reglas del plano de usuario de una PDU Session. No es una regla de QoS creada de forma independiente por la UPF después de observar el tráfico. El plano de control determina qué comportamiento de QoS debe aplicarse y la UPF ejecuta la regla resultante.
La QER no tiene por qué permanecer sin cambios durante toda la vida de la sesión. Si la política cambia mientras el servicio está activo, la SMF puede actualizar una QER existente mediante PFCP Session Modification. Cambios en la política de suscripción, política de aplicación u otras decisiones del plano de control pueden dar lugar a nuevos límites de tasa, distintos estados de Gate, una asociación de QoS Flow diferente u otros parámetros de QoS.
Por esa razón, la resolución de problemas no debe detenerse en el Create QER inicial. Si un problema de QoS aparece cuando la sesión ya lleva tiempo funcionando, también deben revisarse los Update QER posteriores y compararse con los valores originales.
Desde la perspectiva del plano de control, la política de QoS utilizada por la SMF puede proceder de una configuración local o de información de política asociada con la PCF. Cuando la política llega a la interfaz N4, se representa como reglas PFCP que la UPF puede aplicar. Según el diseño del servicio, la aplicación de QoS puede actuar a nivel de PDU Session, de QoS Flow o sobre tráfico SDF o de aplicación más específico.
¿Cómo puede Gate Status bloquear el tráfico aunque la sesión parezca normal?
Gate Status es uno de los parámetros más directos de una QER porque puede cambiar inmediatamente si el tráfico está autorizado a pasar.
Los estados Gate de uplink y downlink pueden controlarse de forma independiente. Cuando un Gate está OPEN, el tráfico en esa dirección puede continuar. Cuando está CLOSED, el tráfico en esa dirección queda bloqueado por la regla de aplicación de QoS.
Por tanto, una secuencia típica de diagnóstico puede verse así:
La PDU Session se establece correctamente;
El UE ha recibido una dirección IP;
La PDR coincide correctamente;
La FAR contiene FORW;
Pero el tráfico de aplicación sigue sin funcionar.
En este punto deben comprobarse UL Gate y DL Gate en la QER asociada. Como ambas direcciones se controlan por separado, un Gate puede estar OPEN mientras el otro está CLOSED. El síntoma resultante puede parecer un problema unidireccional del plano de usuario: el UE puede recibir tráfico de downlink pero no enviar correctamente tráfico de uplink, o al contrario.
Por eso QER es una regla de aplicación y no simplemente un atributo descriptivo de QoS. Su configuración puede determinar directamente si un tráfico específico puede seguir pasando a través de la UPF.
¿Qué controlan MBR, GBR y Packet Rate?
Gate Status responde a «¿Puede pasar el tráfico?». Los parámetros relacionados con la tasa responden a otra pregunta: «¿Cuánto tráfico puede pasar y a qué velocidad?». QER puede aplicar límites basados tanto en tasa de bits como en tasa de paquetes.
Tasa de bits máxima (MBR)
MBR define la tasa de bits máxima del tráfico coincidente y puede configurarse por separado para uplink y downlink. En un entorno 5GC, el límite aplicable puede corresponder a una restricción a nivel de sesión, a un QoS Flow concreto o a un flujo de tráfico más específico, según el diseño de reglas.
Cuando un usuario puede acceder normalmente al servicio pero el rendimiento se detiene de forma consistente cerca de un techo repetible, el MBR de la QER asociada es uno de los parámetros que conviene comprobar.
MBR se confunde fácilmente con la capacidad de radio. Buenas condiciones radio y suficiente ancho de banda de transporte no garantizan que la aplicación pueda utilizar toda la capacidad física. Si se ha indicado a la UPF que aplique un MBR menor, el rendimiento del plano de usuario seguirá sujeto a ese límite. Por ello, el diagnóstico de bajo rendimiento debe incluir las reglas de QoS de N4 y no centrarse únicamente en el rendimiento radio.
Tasa de bits garantizada (GBR)
GBR describe la tasa de bits garantizada asociada al tráfico que requiere un nivel definido de garantía de recursos. También puede especificarse por separado para uplink y downlink.
GBR puede ser relevante para servicios que requieren un rendimiento más predecible, como determinadas aplicaciones de voz en tiempo real, vídeo u otros servicios sensibles a QoS. No debe interpretarse como un valor aislado; también deben considerarse el QoS Flow correspondiente y la política QoS general.
Conceptualmente, MBR define el límite superior de la tasa permitida, mientras que GBR describe el requisito de tasa garantizada asociado a la política del servicio.
Tasa de paquetes
Algunos tipos de tráfico no pueden describirse adecuadamente solo mediante tasa de bits. QER también puede incluir parámetros Packet Rate que restringen el número de paquetes permitidos dentro de un periodo determinado.
Esto puede ser importante para cargas que generan muchos paquetes pequeños, como transacciones DNS, keepalives de IoT o tráfico similar a señalización. La tasa de bits total puede seguir siendo relativamente baja mientras la tasa de paquetes por segundo se vuelve alta. En estos casos, comprobar solo MBR puede no explicar el comportamiento de QoS observado.
Cuando se alcanza el límite de Packet Rate, el usuario puede experimentar mayor latencia, respuestas más lentas o solicitudes fallidas aunque el consumo general de ancho de banda parezca moderado.
¿Qué hacen QFI, Flow Level Marking y PPI dentro de una QER?
QER es más que un limitador de velocidad. Además de Gate Status, MBR y GBR, puede transportar parámetros relacionados con la identificación del QoS Flow y el tratamiento de paquetes. Juntos, estos parámetros ayudan a determinar cómo se procesa el tráfico a través del plano de usuario.
QoS Flow Identifier (QFI)
QFI identifica un QoS Flow. Una sola PDU Session puede contener varios QoS Flows para que distintos tipos de tráfico reciban tratamientos QoS diferentes.
Desde la perspectiva del plano de usuario, QFI identifica con qué QoS Flow está asociado un paquete. Dentro de la QER, ese identificador puede utilizarse para asociar el comportamiento de QoS correspondiente con el QoS Flow adecuado.
Si el QFI asociado a una regla no coincide con el diseño de servicio previsto, el tráfico puede quedar asociado a un QoS Flow inesperado aunque los parámetros de tasa parezcan correctos. Esto puede provocar un tratamiento de recursos distinto del diseñado para el servicio.
DL Flow Level Marking
QER puede ordenar a la UPF aplicar marcado a nivel de flujo al tráfico de downlink, por ejemplo establecer un valor DSCP para la red de transporte IP.
Este marcado no determina a qué QoS Flow 5G pertenece el paquete. En cambio, afecta a cómo puede identificarse y tratarse una vez que entra en la red de transporte IP.
Si el marcado de transporte es incorrecto, el QoS 5G puede estar bien configurado mientras la red de transporte posterior sigue tratando el paquete con una prioridad no prevista.
Paging Policy Indicator (PPI)
PPI está relacionado con el tratamiento de políticas de paging para el tráfico de downlink. Una QER puede proporcionar información relacionada con paging para escenarios de reenvío aplicables, de modo que distintos tráficos reciban tratamiento diferenciado cuando interviene el paging.
Para un UE que no está actualmente en estado activo de plano de usuario, distintos tipos de tráfico de downlink pueden tener diferentes implicaciones de paging. PPI aporta información que puede utilizarse como parte de ese tratamiento diferenciado.
Averaging Window
La aplicación de la tasa no siempre puede basarse en la observación instantánea de un único paquete. Averaging Window define la ventana temporal sobre la que se evalúa el comportamiento relacionado con la tasa de bits.
Una ventana más corta responde más rápido al tráfico en ráfagas, mientras que una ventana más larga produce una media más suave y puede tolerar de forma diferente las ráfagas cortas. Por eso el análisis de QER no debe centrarse solo en QER ID y MBR. El comportamiento QoS resultante puede depender de varios parámetros que trabajan conjuntamente.
¿Cómo utilizar mensajes PFCP para verificar si QER funciona como se espera?
La forma más útil de analizar QER no es memorizar cada elemento de información, sino relacionar la regla PFCP con el síntoma real del servicio.
Por ejemplo, un Create QER puede contener:
QER ID = 1;
UL Gate = OPEN;
DL Gate = OPEN;
UL MBR = 100000 kbps;
DL MBR = 150000 kbps.
Estos valores son solo un ejemplo, pero demuestran un punto importante: un Gate OPEN no significa que no exista ninguna restricción de QoS. El tráfico puede estar autorizado a pasar y seguir sujeto a la aplicación de MBR.
Una secuencia práctica de diagnóstico puede seguir estos pasos:
Identifique primero la PDR. Determine qué PDR coincide realmente con el tráfico afectado. Si se selecciona una PDR incorrecta, la QER esperada no se aplicará correctamente.
Compruebe el QER ID referenciado por la PDR. No revise todas las QER de la sesión PFCP sin contexto. Primero identifique la QER realmente asociada al tráfico que se analiza.
Revise Create QER y Update QER. Confirme si la regla actualmente efectiva fue modificada por una PFCP Session Modification posterior. Un problema de QoS puede introducirse mediante una actualización posterior y no durante el establecimiento inicial de la sesión.
Compruebe Gate Status. Verifique por separado los estados Gate de uplink y downlink. Un Gate cerrado en una sola dirección puede producir un fallo de servicio unidireccional.
Compruebe MBR, GBR y Packet Rate. Compare los límites configurados con el rendimiento observado o el comportamiento de paquetes, especialmente si el servicio se detiene repetidamente cerca de una tasa fija.
Compruebe QFI y otros parámetros QoS. Verifique que el QoS Flow previsto, el marcado y los ajustes relacionados con paging coincidan con el diseño del servicio.
Compare la regla con el tráfico real del plano de usuario. PFCP muestra lo que se espera que aplique la UPF; las pruebas de rendimiento y las capturas de paquetes muestran lo que realmente ocurrió. La diferencia entre ambas vistas suele ser la pista de diagnóstico más útil.
Este método es más fiable que interpretar un único campo QER de forma aislada. La señalización PFCP indica lo que la UPF debería aplicar, mientras que las pruebas del plano de usuario muestran el resultado realmente observado. Comparar ambas vistas es clave para determinar si QER se comporta como se esperaba.
FAQ
¿Cuál es la principal diferencia entre QER y FAR?
FAR determina principalmente cómo debe tratarse un paquete coincidente y adónde debe reenviarse, incluidas acciones como FORW, DROP o BUFF. QER aplica comportamientos relacionados con QoS, como gating, límites de tasa, asociación con QoS Flow y marcado a nivel de transporte. Ambas suelen actuar después de que la PDR haya identificado el tráfico. Una forma sencilla de entender la relación es: FAR determina adónde y cómo se reenvía el paquete, mientras que QER determina qué tratamiento QoS se aplica a ese tráfico.
¿Por qué el rendimiento del usuario puede seguir siendo bajo cuando Gate Status está OPEN?
OPEN solo significa que el tráfico en esa dirección puede pasar. No elimina otras restricciones QoS. Aún deben comprobarse MBR, GBR, Packet Rate y el QoS Flow asociado. Si MBR está configurado por debajo de la capacidad radio o de transporte disponible, el rendimiento puede seguir limitado aunque ambos Gates estén completamente abiertos.
¿Solo puede crearse una QER durante PFCP Session Establishment?
No. Una QER puede crearse durante PFCP Session Establishment y modificarse posteriormente mediante PFCP Session Modification. Si el comportamiento QoS cambia después de que la sesión lleve tiempo activa, deben revisarse los Update QER posteriores en lugar de analizar solo el Create QER inicial.
¿QFI y QER son lo mismo?
No. QFI es el identificador de un QoS Flow, mientras que QER es una regla de aplicación de QoS ejecutada por la UPF. Una QER puede contener o referenciar información QFI para asociar un tratamiento QoS específico con el QoS Flow correspondiente. QFI identifica qué QoS Flow está implicado; QER define cómo se aplica el control QoS al tráfico.
¿Por qué puede seguir fallando el tráfico cuando la PDR coincide y la FAR permite el reenvío?
Porque el procesamiento del plano de usuario no necesariamente termina en la FAR. Después de permitir el reenvío, la QER asociada todavía puede aplicar Gate Status, MBR, GBR, Packet Rate u otras restricciones QoS. Por ello, el diagnóstico debe tratar PDR, FAR y QER como una cadena continua de procesamiento. Una discrepancia en cualquiera de estas etapas puede afectar al resultado final del servicio.
