Cuando una UPF recibe un paquete del plano de usuario, no decide de inmediato adónde debe reenviarlo. Primero debe determinar a qué sesión PFCP pertenece el paquete y qué regla de procesamiento debe aplicarse. Dentro del marco de reglas PFCP de la interfaz N4, la PDR (regla de detección de paquetes) se encarga de esta primera etapa del procesamiento. Una PDR indica a la UPF qué paquetes pertenecen a una categoría de tráfico concreta. Una vez que un paquete coincide, la UPF puede aplicar las FAR, QER, URR y otras reglas asociadas para el reenvío, la aplicación de QoS y los informes de uso.
La forma más sencilla de entender una PDR es separar tres responsabilidades diferentes: la PDR identifica el tráfico, la PDI define las condiciones de coincidencia y FAR/QER/URR determinan qué sucede después de una coincidencia. Mantener estas funciones separadas facilita mucho el seguimiento del procesamiento de paquetes PFCP que intentar memorizar cada IE por separado.
¿Qué problema resuelve una PDR en la interfaz N4?
N4 es la interfaz de control entre la SMF y la UPF en el núcleo 5G. La SMF utiliza sesiones PFCP para instalar reglas de procesamiento del plano de usuario en la UPF, y la PDR es el tipo de regla responsable de detectar y clasificar paquetes. Normalmente se crea una PDR durante el establecimiento de una sesión PFCP y después puede añadirse, eliminarse o actualizarse mediante la modificación de sesión PFCP. En otras palabras, la clasificación de paquetes se controla mediante reglas aprovisionadas por la SMF según la sesión PDU, el flujo de tráfico y los requisitos de reenvío actuales.
Una sola sesión PFCP puede contener varias PDR. Por ejemplo, una misma sesión PDU normalmente necesita reglas independientes para el tráfico ascendente y descendente. También pueden requerirse PDR adicionales cuando la sesión contiene varios flujos de datos de servicio, distintos flujos QoS o clasificaciones de tráfico más detalladas. Por tanto, una PDR puede verse como la regla de selección de tráfico de la UPF: determina qué tipo de paquete ha llegado antes de que otras reglas decidan cómo procesarlo.
¿Cómo encuentra la UPF la PDR coincidente?
El procesamiento de paquetes en la UPF sigue una secuencia definida. Después de que un paquete entra en la UPF, la función identifica primero la sesión PFCP correspondiente y luego evalúa las PDR asociadas a esa sesión. Si más de una PDR puede coincidir, la UPF utiliza el valor de Precedencia para determinar su prioridad relativa. Un valor de Precedencia más bajo representa una prioridad mayor, por lo que las reglas de mayor prioridad se evalúan antes que las de menor prioridad al buscar una coincidencia.
Una vez que una PDR coincide, la propia PDR no realiza todas las operaciones posteriores de procesamiento del paquete. En su lugar, puede hacer referencia a otras reglas PFCP:
FAR (regla de acción de reenvío): determina cómo debe tratarse y reenviarse el paquete, incluido si debe reenviarse, descartarse, almacenarse temporalmente o enviarse hacia una interfaz de destino concreta.
QER (regla de aplicación de QoS): aplica controles relacionados con QoS, como habilitación/bloqueo, limitación de velocidad y otros tratamientos del tráfico.
URR (regla de informe de uso): mide el uso del tráfico y proporciona información para tarificación, supervisión u otros fines relacionados con políticas.
Por tanto, la ruta general de procesamiento de la UPF puede simplificarse así:
Identificar la sesión PFCP → evaluar las PDR por Precedencia → clasificar el paquete → aplicar FAR/QER/URR. El orden es importante. La FAR responde a cómo debe tratarse un paquete, pero primero la UPF necesita una PDR para establecer a qué paquete o flujo de tráfico se aplica la acción.
¿Cuáles son los principales parámetros de una PDR?
Un Create PDR contiene varios elementos de información, pero al estudiar el comportamiento de detección de paquetes basta con comprender primero un conjunto más reducido. Estos parámetros definen cómo se identifica la regla, cómo se comparan los paquetes y qué reglas de procesamiento posteriores se asocian al resultado.
| Parámetro | Función principal |
|---|---|
| ID de PDR | Identifica de forma única la PDR dentro de la sesión PFCP y la distingue de otras reglas de detección de paquetes |
| Precedencia | Define la prioridad relativa de la PDR cuando se evalúan varias reglas; los valores más bajos indican mayor precedencia |
| PDI | Contiene los criterios de detección de paquetes que utiliza la UPF para determinar si el tráfico entrante coincide con la PDR |
| Eliminación de cabecera externa | Indica si la UPF debe eliminar una cabecera de protocolo externa, por ejemplo una cabecera GTP-U/UDP/IP en tráfico ascendente |
| ID de FAR | Hace referencia a la FAR que define la acción de reenvío para los paquetes coincidentes |
| ID de URR | Hace referencia a una URR utilizada para medir el tráfico y generar informes de uso |
| ID de QER | Hace referencia a una QER que aplica el tratamiento relacionado con QoS al tráfico coincidente |
| Activar reglas predefinidas | Activa una o varias reglas predefinidas ya disponibles en la UPF |
| Hora de activación / Hora de desactivación | Define cuándo se activa la PDR y cuándo deja de estar activa |
Entre estos parámetros, el elemento que realmente define qué paquetes pueden coincidir con la PDR es la PDI (Información de detección de paquetes). Los ID de FAR y QER hacen referencia a acciones que se ejecutan después de clasificar el tráfico; la PDI contiene la información utilizada para realizar la propia clasificación.
¿Cómo define la PDI las condiciones de coincidencia de paquetes?
La PDI puede entenderse como el conjunto de condiciones de detección de paquetes dentro de una PDR. No es un único campo. Contiene varios parámetros que pueden combinarse para identificar el tráfico según por dónde entró el paquete en la UPF, su información de túnel, la dirección de la UE, las características del flujo de servicio y la información de QoS. Entre los parámetros PDI habituales se incluyen:
Interfaz de origen: identifica el lado lógico desde el que llega el paquete, por ejemplo Access para tráfico del lado de acceso o Core para tráfico que llega desde el núcleo o desde el lado de la red de datos.
F-TEID local: puede utilizarse para hacer coincidir el TEID y la información de direccionamiento relacionada con un túnel GTP-U, por lo que resulta especialmente importante al detectar tráfico de túnel ascendente.
Instancia de red: identifica una red lógica configurada en la UPF, por ejemplo una instancia de red relacionada con Internet o IMS.
Dirección IP de la UE: hace coincidir el tráfico según la dirección IP de origen o destino de la UE, dependiendo de la dirección del paquete.
ID de punto extremo de tráfico: identifica un punto extremo de tráfico que puede utilizarse en escenarios compatibles de optimización de PDI.
Filtro SDF: proporciona un filtrado más granular basado en parámetros como direcciones de origen y destino, protocolo, puertos y dirección del tráfico.
ID de aplicación: puede utilizarse para identificar tráfico a nivel de aplicación cuando la UPF dispone de la capacidad de detección de aplicaciones necesaria.
QFI (identificador de flujo QoS): identifica el flujo QoS asociado al paquete.
Tipo de interfaz de origen: proporciona información adicional sobre la interfaz 3GPP asociada al origen, como N3, N6 o N9.
Cuando hay varios parámetros de coincidencia en la PDI, estos definen conjuntamente la condición de detección de paquetes. El paquete entrante debe cumplir los criterios aplicables antes de que se considere que la PDR coincide. Esto permite a la SMF crear reglas que van desde una clasificación amplia a nivel de sesión hasta una detección mucho más específica de flujos de servicio.
¿Qué nivel de detalle puede alcanzar la detección de tráfico con un filtro SDF?
La interfaz de origen, el F-TEID y la dirección IP de la UE pueden ser suficientes para identificar una sesión o una categoría amplia de tráfico, pero no siempre distinguen flujos de datos de servicio individuales. Un filtro SDF proporciona una clasificación más granular. Su Descripción de flujo puede incluir dirección IP de origen, dirección IP de destino, número de protocolo, puerto de origen, puerto de destino y dirección del tráfico. Estos campos permiten a la UPF distinguir flujos IP concretos en lugar de tratar del mismo modo todos los paquetes asociados a una UE.
Un filtro SDF también puede incluir información adicional de coincidencia:
TOS / Clase de tráfico: coincide con el campo Tipo de servicio de IPv4 o Clase de tráfico de IPv6.
Índice de parámetros de seguridad (SPI): puede utilizarse al comparar tráfico asociado a una asociación de seguridad IPsec.
Etiqueta de flujo: coincide con la etiqueta de flujo incluida en una cabecera IPv6.
ID de filtro SDF: identifica el filtro SDF asociado para fines de gestión y referencia.
Esto crea un modelo de clasificación por capas. Los parámetros PDI, como interfaz, túnel y dirección de la UE, pueden primero acotar el tráfico a un contexto concreto, mientras que el filtro SDF puede identificar flujos IP individuales dentro de ese contexto. Cuando también se admite la identificación de aplicaciones, la UPF puede aplicar un mecanismo adicional de clasificación a nivel de aplicación en lugar de depender solo de direcciones y puertos.
¿Cuál es la diferencia entre las PDR de enlace ascendente y descendente?
Comparar el tráfico ascendente y descendente es una de las formas más claras de entender cómo funcionan las PDR. Ambas direcciones utilizan la misma estructura general de reglas, pero los paquetes entran en la UPF desde interfaces diferentes y, por tanto, requieren criterios de detección distintos.
En el tráfico ascendente típico, los paquetes llegan a la UPF desde el lado de acceso radio. Por ello, la PDI puede usar Interfaz de origen = Access. Además, la regla puede utilizar un F-TEID local para identificar el túnel GTP-U y una dirección IP de la UE para identificar el tráfico de la UE. Una PDR ascendente típica puede requerir:
La interfaz de origen es Access;
el paquete GTP-U entrante coincide con el F-TEID especificado, incluidos el TEID y la información de dirección pertinentes;
la dirección IP de la UE coincide con la dirección asociada a la sesión.
Cuando se cumplen las condiciones, la PDR coincide. Como el tráfico recibido por N3 normalmente está encapsulado en GTP-U, Eliminación de cabecera externa puede indicar a la UPF que elimine las cabeceras externas GTP-U/UDP/IP antes de que el paquete se procese según la FAR asociada.
La detección descendente comienza en la dirección opuesta. Los paquetes suelen llegar desde una red de datos hacia la UPF, por lo que la PDI puede usar Interfaz de origen = Core. En este caso, parámetros como la Instancia de red y la Dirección IP de la UE pueden utilizarse para determinar a qué sesión PDU pertenece el paquete. Una PDR descendente típica puede requerir:
La interfaz de origen es Core;
la instancia de red coincide con la red lógica requerida, como «internet» o «ims»;
el destino del paquete coincide con la dirección IP de la UE asociada a la sesión.
Después de que la PDR descendente coincida, la FAR asociada determina cómo debe reenviarse el paquete hacia el lado de acceso, incluido el comportamiento de reenvío por túnel necesario. La diferencia entre las PDR ascendentes y descendentes refleja, por tanto, la dirección desde la que los paquetes entran en la UPF y la información disponible para identificarlos.
¿Cómo trabajan juntas PDR, FAR, QER y URR?
Una PDR resuelve el problema de identificación del paquete, pero no representa toda la política de procesamiento del plano de usuario. PFCP separa la detección de paquetes, el reenvío, la aplicación de QoS y la medición de uso en diferentes tipos de reglas. Esta separación permite que cada regla realice una función específica y siga operando dentro de la misma sesión PFCP.
PDR: ¿Qué tráfico es este? (Detección y clasificación)
FAR: ¿Qué debe hacerse con él y adónde debe ir? (Acción de reenvío)
QER: ¿Qué tratamiento QoS debe aplicarse? (Aplicación de QoS)
URR: ¿Cómo debe medirse e informarse su uso? (Informe de uso)
Considere un paquete ascendente que coincide con una PDR. Una vez que la UPF determina a qué UE y flujo de servicio pertenece el paquete, puede eliminar la cabecera externa GTP-U requerida, aplicar el comportamiento de reenvío referenciado por la FAR, hacer cumplir la QER aplicable y contabilizar el tráfico según la URR asociada. El resultado de la detección del paquete proporciona así el contexto necesario para todas las operaciones posteriores.
Desde una perspectiva de ingeniería, la PDR no debe verse como una política de reenvío aislada. Es el punto de entrada al conjunto de reglas del plano de usuario PFCP. Una vez que queda clara la relación entre PDR para clasificación, PDI para criterios de coincidencia y FAR/QER/URR para el procesamiento posterior , parámetros como Interfaz de origen, F-TEID, Dirección IP de la UE y Filtro SDF resultan mucho más fáciles de entender en el análisis real de señalización N4 y paquetes.
Preguntas frecuentes
La Precedencia se utiliza cuando la UPF evalúa PDR dentro de una sesión PFCP. Sin embargo, si las condiciones PDI de dos reglas son completamente excluyentes entre sí, ambas PDR no pueden coincidir con el mismo paquete y su precedencia relativa no cambia el resultado final. La Precedencia cobra especial importancia cuando las condiciones de las reglas se solapan y más de una PDR podría coincidir con el mismo tráfico.
Si cambia la dirección de la UE utilizada como condición de coincidencia PDI, la regla asociada a esa dirección también debe reflejar la información actualizada de la sesión. La SMF puede actualizar la información PDR pertinente mediante la modificación de sesión PFCP para que la UPF siga clasificando correctamente el tráfico de la UE.
Sí. El filtrado SDF no exige que todos los campos posibles restrinjan el tráfico a un puerto específico. Según la definición de la regla, pueden utilizarse rangos de puertos o condiciones de coincidencia menos restrictivas para cubrir un conjunto más amplio de tráfico. También pueden emplearse máscaras de dirección cuando la definición del filtro aplicable requiera hacer coincidir un rango de direcciones.
Si un paquete entrante no puede asociarse con una PDR aplicable, la UPF no dispone de una regla de procesamiento de paquetes coincidente para ese tráfico dentro del contexto correspondiente. El tratamiento resultante depende de las reglas PFCP aplicables, de la implementación de la UPF y de la configuración de la sesión. En la resolución de problemas, una falta de coincidencia PDR inesperada es un punto importante que investigar cuando el tráfico llega a la UPF pero no se reenvía como se esperaba.
PFCP admite reglas predefinidas que ya están aprovisionadas en la función UP y pueden activarse cuando sea necesario. En lugar de aprovisionar repetidamente todos los parámetros de una regla para los escenarios aplicables, el plano de control puede activar la regla predefinida correspondiente. Esto puede reducir la señalización necesaria cuando los mismos conjuntos de reglas se reutilizan en sesiones adecuadas.
