Durante la resolución de problemas del plano de usuario del 5G Core aparece con frecuencia una situación concreta: el UE está registrado con normalidad, la PDU Session se ha establecido, el PDR identifica correctamente el tráfico y el FAR reenvía los paquetes por la ruta prevista, pero los contadores de uso visibles para el SMF no cambian. Es posible que no se activen eventos de tarificación o que el control de cuota no responda cuando debería. En muchos casos, el reenvío de paquetes funciona correctamente. Lo que falta es un mecanismo que indique al UPF cómo medir el uso del plano de usuario y cuándo comunicar el resultado al plano de control. Ese mecanismo es la URR (Usage Reporting Rule) en la interfaz N4.

URR no decide a dónde deben reenviarse los paquetes y tampoco aplica directamente límites de ancho de banda. En su lugar, indica al UPF qué tráfico coincidente debe medirse, cómo debe medirse ese uso y bajo qué condiciones debe comunicarse el resultado de la medición al plano de control. De este modo, URR convierte el tráfico del plano de usuario, que de otro modo solo se reenviaría, en tráfico que también puede medirse. El UPF realiza la medición efectiva, el SMF aprovisiona las condiciones de informe mediante PFCP y los Usage Reports resultantes forman un bucle de realimentación continuo entre el plano de usuario y el plano de control.

¿Qué problema resuelve URR dentro del marco de reglas N4?

La forma más sencilla de entender URR es separar su responsabilidad de las de PDR, FAR y QER. Cuando el UPF recibe un paquete, el PDR determina primero a qué tráfico pertenece. Una vez clasificado el paquete, el FAR decide cómo debe tratarse y a dónde debe reenviarse. QER aplica el tratamiento QoS necesario. URR responde a una pregunta distinta: ¿cuánto de este tráfico se ha utilizado realmente?

Los principales tipos de reglas PFCP pueden resumirse así:

PDR: ¿Qué tráfico es este?
FAR: ¿Cómo debe tratarse el paquete y a dónde debe enviarse?
QER: ¿Qué tratamiento QoS debe aplicarse a este tráfico?
URR: ¿Cuánto de este tráfico se ha utilizado y cuándo debe informarse de ese uso?

Una URR debe estar asociada al PDR correspondiente. La razón es sencilla: el UPF no puede medir de forma significativa «cuánto ha consumido un usuario» sin saber primero qué paquetes pertenecen a ese UE, servicio o flujo de tráfico. Una vez que el PDR identifica el tráfico, la URR asociada puede medir el uso de los paquetes coincidentes. Si una PDU Session contiene varios PDR, también pueden utilizarse distintas URR para crear relaciones de medición de uso más granulares.

Por este motivo, la primera pregunta al diagnosticar una URR no suele ser «¿Se aprovisionó la URR?», sino «¿Qué PDR está haciendo coincidir el tráfico que se está midiendo y qué URR ID referencia ese PDR?» Si esa asociación falta o es incorrecta, las fases posteriores de medición e informe no podrán funcionar como se espera.

¿Cómo define URR lo que debe medir el UPF?

Una URR es más que un simple contador de tráfico. Uno de los primeros elementos definidos en Create URR es el Measurement Method, que indica al UPF qué tipo de uso debe medir. Según los requisitos del servicio, la medición puede basarse en volumen de tráfico, tiempo o eventos.

En los servicios de datos por paquetes habituales, la medición basada en volumen suele ser la más fácil de observar. El UPF puede medir el volumen de tráfico de enlace ascendente, enlace descendente y total, mientras que los campos correspondientes de Volume Measurement indican qué estadísticas se incluyen. El volumen se acumula en bytes, por lo que una URR puede medir el uso total o diferenciar entre tráfico UL y DL según la configuración.

Si está habilitada la capacidad necesaria, la medición también puede incluir el número de paquetes. Por ejemplo, el indicador MNOP de Measurement Information puede solicitar al UPF que mida el número de paquetes de enlace ascendente, de enlace descendente y total. En ese caso, el operador no solo ve cuántos bytes se transfirieron, sino también cuántos paquetes se procesaron durante el intervalo de medición.

La medición basada en tiempo se centra en la duración del servicio. Según la configuración, puede incluir parámetros como Time Threshold, Time Quota, Inactivity Detection Time y el mecanismo de medición temporal aplicable. La medición basada en eventos, en cambio, puede contar eventos de servicio concretos y generar un informe cuando se alcanza un número definido de eventos.

Por tanto, Measurement Method responde a la pregunta más básica de URR: ¿qué significa «uso» para esta regla? Si esto no se establece primero, es fácil confundir Threshold, Quota y Reporting Trigger al analizar mensajes PFCP. El método de medición seleccionado afecta directamente al tipo de contadores que mantiene el UPF, al formato del Usage Report y a la forma en que el SMF interpreta el resultado.

Reporting Trigger determina cuándo debe enviar un informe el UPF

Un método de medición por sí solo no es suficiente. Si el UPF se limita a seguir acumulando contadores sin ninguna condición de informe, el SMF no tiene un punto definido en el que deba recibir el resultado. Por ello, los Reporting Triggers constituyen otra parte fundamental del mecanismo URR.

Estos disparadores pueden combinarse según la política de red. PERIO puede utilizarse para informes periódicos. VOLTH indica que debe generarse un informe cuando se alcanza un umbral de volumen. TIMTH se aplica a un umbral de tiempo. START y STOPT pueden activar Usage Reports cuando el UPF detecta el inicio o la finalización del tráfico.

Otro grupo de disparadores está más relacionado con el control de cuotas. VOLQU se asocia a condiciones de cuota de volumen, TIMQU a condiciones de cuota de tiempo y EVEQU a condiciones de cuota de eventos. Quota Holding Time también puede utilizarse cuando se ha concedido una cuota pero el abonado no genera tráfico del plano de usuario durante un periodo definido.

Es especialmente importante distinguir entre Threshold y Quota, ya que cumplen funciones diferentes en PFCP y suelen confundirse durante el análisis de trazas:

Un Threshold se refiere principalmente a cuándo debe comunicarse un resultado de medición, mientras que una Quota se aproxima más a cuántos recursos siguen disponibles para utilizarse. Si una traza PFCP solo muestra que VOLTH o VOLQU está configurado, pero el ingeniero no revisa el parámetro Threshold o Quota correspondiente, es fácil interpretar mal la lógica real del servicio.

Por ejemplo, si VOLTH está configurado pero el Volume Threshold correspondiente no está definido correctamente, el UPF no dispone de un límite de tráfico significativo en el que activar el informe esperado.

¿Cómo envía el UPF los resultados de uso al SMF?

El mecanismo URR forma un bucle de realimentación completo mediante el procedimiento PFCP Session Report. Una vez que se cumple una condición de informe definida por una URR, el UPF no tiene por qué esperar a que el SMF consulte los contadores. Puede enviar una PFCP Session Report Request al SMF.

Cuando Report Type indica que el mensaje contiene un Usage Report, el SMF puede identificar el evento como un informe de uso del usuario. Varios campos son especialmente importantes durante el análisis. URR ID identifica qué regla generó el informe. UR-SEQN identifica la secuencia del Usage Report para esa URR. Usage Report Trigger explica por qué se generó el informe.

Los valores de medición reales aparecen después en los campos que corresponden al Measurement Method. Para la medición basada en volumen, Volume Measurement puede contener valores de uso total, ascendente y descendente. Para la medición basada en tiempo, Duration Measurement adquiere mayor importancia. Campos como Start Time, End Time, Time of First Packet y Time of Last Packet también ayudan a determinar el intervalo exacto de medición cubierto por el informe.

Recibir el Usage Report no pone necesariamente fin al proceso. Según la lógica del servicio, el SMF puede continuar enviando una PFCP Session Modification para actualizar la URR, por ejemplo cambiando el umbral de informe, asignando una nueva cuota o modificando las condiciones del siguiente informe.

El flujo completo de URR puede resumirse así:

El SMF aprovisiona la URR → el UPF mide el tráfico coincidente → se cumple la condición de Reporting Trigger → el UPF envía un Usage Report → el SMF procesa el resultado de uso → la URR se actualiza si es necesario.

Por tanto, informar del uso no consiste simplemente en que el UPF cargue un contador. Es un proceso dinámico en el que el plano de control define la política de medición, el plano de usuario realiza la medición y el resultado se devuelve de forma continua al plano de control. Un problema en cualquier etapa puede producir valores de uso inexactos o informes ausentes.

¿Cómo activa un Volume Threshold un Usage Report real?

La lógica de URR resulta más fácil de entender cuando se aplica a un escenario de tráfico concreto. Supongamos que el SMF crea una URR durante PFCP Session Establishment e indica al UPF que utilice medición basada en volumen para el tráfico que coincide con un PDR específico. VOLTH se habilita como Reporting Trigger.

Si Volume Threshold se configura para TOVOL con un valor de 10240 bytes, la regla no significa que el usuario solo pueda consumir 10240 bytes. Significa que cuando el volumen total medido de enlace ascendente y descendente alcance ese umbral, el UPF debe generar un Usage Report.

A medida que el UE comienza a generar tráfico, el UPF sigue reenviando paquetes normalmente y, al mismo tiempo, acumula los contadores de uso definidos por la URR. Cuando el volumen acumulado alcanza el umbral de informe, el UPF envía una PFCP Session Report Request. El Usage Report identifica VOLTH como motivo del disparo, mientras que Volume Measurement contiene el uso total real y los valores aplicables de enlace ascendente y descendente.

El valor final informado no tiene por qué detenerse exactamente en 10240 bytes. El UPF evalúa el umbral mientras procesa paquetes reales, y un paquete completo puede hacer que el uso acumulado pase directamente de estar por debajo del umbral a superarlo. Por ello, que un Usage Report muestre un valor ligeramente superior al Threshold configurado no supone ninguna contradicción.

Esto conduce a un principio importante al analizar el comportamiento de URR: un Threshold es un límite de informe, no un mecanismo que recorta el valor medido hasta una cifra exacta. Si también se configura una Quota, su agotamiento puede activar comportamientos de control adicionales, pero debe analizarse como una ruta de control separada y no confundirse con un simple informe basado en umbral.

El diagnóstico de URR debe seguir cuatro capas: asociación, medición, disparo e informe

Los problemas de URR pueden ser difíciles de detectar porque el servicio del plano de usuario puede parecer totalmente normal. El UE puede acceder a la red, el PDR identifica correctamente el tráfico y el FAR continúa reenviando paquetes, mientras los contadores de uso visibles en los sistemas internos siguen siendo incorrectos, no se genera ningún Usage Report o nunca aparece el evento esperado en el plano de control tras alcanzar un umbral.

Por ello, la resolución de problemas de URR no debe comenzar con la pregunta «¿Puede el usuario acceder a la red?». Debe seguir toda la cadena de medición de uso.

Primero confirme la asociación entre PDR y URR

Comience identificando el PDR que realmente coincide con el tráfico y confirme después el URR ID asociado. Una PFCP Session puede contener varios PDR y varias URR. Analizar la URR equivocada no explicará los resultados actuales de uso, aunque todos los parámetros de esa URR parezcan correctos.

Un problema habitual es que la condición de coincidencia del PDR haya cambiado mientras la URR sigue asociada a un PDR ID anterior. En ese caso, el propio objetivo de medición se ha desplazado fuera del tráfico real.

Después verifique el Measurement Method y la dirección

Compruebe si la URR está configurada para medición de Volume, Duration o Event. Si se utiliza medición basada en volumen, verifique también si la regla mide Total, UL, DL o el número de paquetes.

Este paso es especialmente importante cuando las estadísticas de enlace ascendente y descendente no coinciden con lo esperado. Algunos fallos aparentes se deben simplemente a que la URR mide solo una dirección mientras el tráfico de prueba circula en la dirección opuesta, por lo que el contador esperado no cambia.

Compruebe el Reporting Trigger y su Threshold correspondiente

Si el UPF no genera un informe, confirme qué disparador solicitó realmente el plano de control. Configurar VOLTH sin un Volume Threshold adecuado, o esperar informes periódicos cuando PERIO no está habilitado, puede producir resultados diferentes del comportamiento de servicio previsto.

Del mismo modo, los informes basados en tiempo deben interpretarse junto con los parámetros de medición temporal y las condiciones de monitorización relacionadas, en lugar de examinar un único indicador de disparo de forma aislada.

Por último, siga el PFCP Session Report

Cuando se cumpla la condición de disparo, compruebe si el UPF envía el Usage Report esperado. Verifique Report Type, URR ID, UR-SEQN y Usage Report Trigger frente a la PFCP Session actual.

Si el UPF ya ha generado el informe pero no aparece una nueva cuota, umbral o acción de control posterior, la investigación debe desplazarse hacia el SMF y la lógica posterior del plano de control, en lugar de seguir centrada en el contador del UPF.

Si el problema implica la medición antes o después de aplicar QoS, también deben revisarse los indicadores pertinentes de Measurement Information y Usage Information. URR no representa un único número aislado. La ventana temporal de medición, el tráfico que se está midiendo y la etapa de procesamiento en la que se realiza la medición influyen en la forma en que debe interpretarse el valor final de uso.

Muchos casos en los que «el uso no coincide» no se deben a un contador incorrecto del UPF, sino a una diferencia entre el alcance real de la medición y el alcance de contabilización esperado.

URR convierte el tráfico del plano de usuario en información medible para el plano de control

PDR, FAR y QER describen principalmente cómo se identifican y reenvían los paquetes y cómo se les aplica el tratamiento QoS dentro del UPF. URR añade otra capacidad esencial: permite al plano de control saber cuánto tráfico del plano de usuario se ha consumido realmente.

URR utiliza Measurement Method para definir el alcance de medición, Reporting Trigger para determinar cuándo se requiere un informe y parámetros como Threshold, Quota y Monitoring Time para controlar distintas etapas de la medición de uso. Una vez cumplida la condición necesaria, el UPF devuelve el resultado al SMF mediante un PFCP Usage Report; después, el plano de control puede actualizar la URR o ejecutar otra acción de política si es necesario.

Por tanto, la forma más práctica de entender URR no es memorizar decenas de Information Elements, sino seguir una cadena completa:

El PDR selecciona el tráfico que se medirá → la URR define el método de medición → el UPF mide continuamente el uso → Reporting Trigger determina cuándo informar → Usage Report devuelve el resultado al SMF → el SMF actualiza la política de control según sea necesario.

Cuando esta cadena queda clara, parámetros como Volume Threshold, Volume Quota, Measurement Period, Monitoring Time y los distintos Reporting Triggers dejan de parecer campos PFCP aislados. Se convierten en diferentes puntos de control dentro del mismo mecanismo de medición e informe del uso 5G.

Para servicios que requieren tarificación basada en uso, gestión de cuotas en tiempo real o ajustes de política según el consumo, este mecanismo aporta la base que permite que el plano de usuario 5G no solo reenvíe tráfico, sino que también sea medible y controlable.

Preguntas frecuentes