Un escenario habitual de resolución de problemas en redes 5G parece sencillo al principio: el UE se registra correctamente, se establece la PDU Session y se asigna una dirección IP correcta, pero no hay acceso web y ni siquiera funciona el tráfico Ping básico. Las capturas pueden mostrar tráfico llegando a la UPF por N3, pero ningún paquete correspondiente sale por la ruta esperada. Si el análisis se concentra únicamente en la señalización AMF y en el resultado del establecimiento de la PDU Session, puede resultar difícil aislar la causa real.
Que una PDU Session se haya establecido correctamente no significa automáticamente que la ruta de reenvío del plano de usuario esté operativa. Tras recibir un paquete, la UPF utiliza primero una PDR para identificar el tráfico y luego aplica la FAR (Forwarding Action Rule, regla de acción de reenvío) asociada para determinar qué ocurre después: reenviar, descartar, almacenar en búfer o duplicar el paquete. La FAR también puede definir la interfaz de destino y si es necesario crear una cabecera externa de túnel GTP-U.
Desde el punto de vista de la resolución de problemas, la diferencia es útil: una PDR responde «¿A qué sesión y flujo de tráfico pertenece este paquete?», mientras que una FAR responde «Ahora que el paquete ha sido identificado, ¿qué debe hacer la UPF con él?» Cuando los procedimientos del plano de control parecen normales pero el tráfico de usuario sigue fallando, la FAR de la interfaz N4 se convierte en un punto importante de investigación.
¿Por qué una PDU Session establecida correctamente no garantiza conectividad del plano de usuario?
Completar el procedimiento de establecimiento de la PDU Session solo confirma que se han inicializado los recursos de sesión necesarios del plano de control. El tráfico real de aplicaciones sigue dependiendo de la ruta completa del plano de usuario formada por el gNB, N3, la UPF y N6.
En una PDU Session de Internet típica, el tráfico ascendente viaja del UE al gNB, se encapsula en un túnel GTP-U y llega a la UPF por N3. La UPF debe eliminar la cabecera externa de túnel correspondiente, identificar el tráfico y reenviar el paquete original hacia la red de datos. En sentido descendente ocurre lo contrario: el tráfico entra en la UPF desde N6, la UPF identifica la PDU Session correspondiente, obtiene la información del túnel del plano de usuario del gNB, añade la cabecera externa GTP-U necesaria y envía el paquete al gNB por N3.
Este comportamiento de reenvío no queda disponible simplemente porque se haya creado la PDU Session. La SMF debe aprovisionar en la UPF las reglas PFCP adecuadas a través de N4. La PDR identifica el tráfico coincidente, mientras que la FAR define la acción de reenvío que se aplicará después de clasificarlo. Ambos tipos de reglas son necesarios para un procesamiento correcto del plano de usuario.
Cuando toda la señalización del plano de control parece normal pero el servicio sigue sin estar disponible, el problema puede reducirse a dos preguntas principales:
¿La PDR identifica correctamente el tráfico actual?
Después de identificar el paquete, ¿la FAR asociada contiene los parámetros correctos de procesamiento y reenvío?
Centrarse en la relación entre PDR y FAR suele ser más eficiente que revisar repetidamente desde el principio todo el procedimiento de establecimiento de la PDU Session.
¿Qué le indica realmente una FAR a la UPF que haga?
Una FAR es una regla de reenvío dentro del marco PFCP. La SMF la aprovisiona en la UPF a través de N4 y queda asociada al tráfico mediante el FAR ID referenciado por una PDR. Cuando un paquete coincide con esa PDR, la UPF ejecuta el comportamiento de procesamiento definido por la FAR referenciada.
Una FAR puede contener varios Information Elements. Para la resolución de problemas del plano de usuario, los siguientes campos son especialmente importantes:
| Parámetro FAR | Función principal |
|---|---|
| FAR ID | Identifica de forma única la instancia FAR para que una PDR pueda referenciar la regla de reenvío correcta |
| Apply Action | Define la acción básica sobre el paquete, incluido reenvío, descarte, almacenamiento en búfer o duplicación |
| Forwarding Parameters | Define el destino, Network Instance, encapsulación de túnel y otros parámetros utilizados cuando se requiere reenvío |
| Duplicating Parameters | Define cómo debe reenviarse una copia duplicada del paquete cuando está habilitada la duplicación de tráfico |
| BAR ID | Referencia una Buffering Action Rule utilizada para controlar el comportamiento de almacenamiento en búfer de paquetes |
En la práctica, Apply Action y Forwarding Parameters son los dos elementos que más fácilmente se confunden. Apply Action responde «¿Qué acción debe realizarse?», mientras que Forwarding Parameters responde «Si el paquete se reenvía, ¿cómo y adónde debe enviarse?»
Ver la marca FORW en Apply Action no demuestra por sí solo que la ruta descendente esté completa. La Destination Interface, Network Instance, la información de Outer Header Creation y los demás parámetros de reenvío relacionados también deben ser correctos.
¿Cómo determina Apply Action el primer paso de procesamiento del paquete?
Apply Action se representa mediante un conjunto de indicadores de bits que indican a la UPF qué operaciones básicas deben aplicarse a los paquetes coincidentes. Estos indicadores no son simplemente opciones mutuamente excluyentes; su significado debe interpretarse en el contexto de la sesión PFCP y del escenario de servicio.
DROP: Descarta el paquete coincidente.
FORW: Reenvía el paquete según los Forwarding Parameters aplicables.
BUFF: Almacena el paquete en búfer en lugar de reenviarlo inmediatamente.
NOCP: Se utiliza en escenarios de almacenamiento en búfer para notificar al plano de control cuando llega tráfico descendente que debe almacenarse.
DUPL: Crea una copia duplicada del paquete y procesa esa copia según los Duplicating Parameters.
¿Por qué son necesarios BUFF y NOCP?
Un caso típico se produce cuando el UE está inactivo y no hay disponible de inmediato una ruta descendente del plano de usuario. El tráfico descendente puede haber llegado ya a la UPF, pero todavía no puede entregarse al UE. La UPF puede almacenar el paquete en búfer y, cuando sea necesario, utilizar el comportamiento de notificación al plano de control asociado para iniciar procedimientos posteriores como paging o recuperación de la ruta del plano de usuario.
BUFF solo indica que es necesario almacenar en búfer. Los detalles de cómo se gestiona ese almacenamiento están asociados con la BAR, por lo que la resolución de problemas no debe basarse únicamente en la marca BUFF.
¿Por qué DUPL es algo más que simplemente «reenviar otra vez el paquete»?
DUPL crea una copia independiente del paquete. El paquete original continúa por su ruta normal de procesamiento, mientras que la copia duplicada se controla de forma independiente mediante los Duplicating Parameters. La copia puede utilizar una Destination Interface diferente, otra configuración de cabecera externa, Transport Level Marking o Forwarding Policy.
Por este motivo, no debe asumirse automáticamente que el tráfico reflejado o duplicado sigue la misma ruta que el tráfico de servicio original. Los parámetros de duplicación deben revisarse por separado.
¿Cómo determinan los Forwarding Parameters adónde va realmente un paquete?
Cuando Apply Action incluye FORW, los Forwarding Parameters determinan la ruta real de reenvío. Varios campos son especialmente importantes al diagnosticar fallos del plano de usuario.
Destination Interface
Destination Interface define la interfaz lógica hacia la que la UPF debe enviar el paquete después del procesamiento. En un escenario descendente típico se configura como Access, lo que significa que el paquete debe reenviarse hacia el gNB. El tráfico ascendente normalmente se reenvía hacia el lado Core.
Una Destination Interface incorrecta puede provocar un fallo difícil de detectar: la PDR coincide correctamente, pero el paquete se envía hacia la interfaz lógica equivocada mientras el plano de control puede no mostrar ningún error evidente.
Network Instance
Network Instance identifica el contexto de red lógica utilizado para el reenvío. Es especialmente importante en despliegues con varios DNN, slices o redes de datos en los que el tráfico debe permanecer separado.
Al diagnosticar conectividad N6 o servicios de red privada, comprobar la conectividad física no es suficiente. La Network Instance de la FAR también debe coincidir con la configuración correspondiente de la UPF. Una discrepancia puede impedir que el tráfico se enrute al contexto de red esperado.
Outer Header Creation
Outer Header Creation es uno de los parámetros clave para el reenvío descendente por N3. Un paquete que entra en la UPF desde N6 contiene la carga útil original del UE. Antes de poder enviarlo al gNB por N3, la UPF necesita añadir la encapsulación externa GTP-U/UDP/IP requerida.
Outer Header Creation proporciona la información necesaria para esta operación, incluida la dirección del plano de usuario del gNB, el TEID del túnel N3 y el tipo de cabecera externa.
Muchos casos en los que el tráfico descendente llega a la UPF pero no aparece ningún paquete correspondiente en N3 pueden atribuirse a información ausente o incorrecta en esta parte de la FAR, como un TEID incorrecto o una dirección de gNB equivocada.
Otros Forwarding Parameters
Forwarding Parameters también puede incluir Redirect Information, Transport Level Marking, Forwarding Policy, Header Enrichment, Linked Traffic Endpoint ID, Proxying, Destination Interface Type y otra información opcional.
Transport Level Marking puede utilizarse para aplicar la marca DSCP necesaria a los paquetes reenviados. Forwarding Policy puede referenciar una política de reenvío configurada localmente en la UPF. Header Enrichment admite procesamiento adicional de cabeceras en servicios aplicables. No todas las FAR contienen todos estos Information Elements; el contenido real depende de la señalización PFCP y de los requisitos del servicio.
¿Por qué puede actualizarse una FAR descendente después de establecer la sesión?
Durante el procedimiento inicial de establecimiento de la PDU Session, la SMF puede crear las primeras PDR y FAR en la UPF. Sin embargo, en ese momento el gNB puede no haber terminado de asignar los recursos del plano de usuario descendente de N3. Por tanto, el TEID final del túnel y la dirección del plano de usuario del gNB pueden no estar todavía disponibles para la SMF.
Una vez que el gNB ha asignado esos recursos y la información correspondiente del plano de usuario N3 está disponible para la SMF, esta puede enviar una PFCP Session Modification para actualizar la FAR existente en la UPF con los parámetros necesarios del túnel descendente.
La FAR descendente actualizada puede incluir entonces la información clave de reenvío:
Destination Interface = Access, indicando reenvío hacia el lado de acceso;
la Network Instanceaplicable;
Outer Header Creation = GTP-U/UDP/IPv4 u otro tipo de cabecera externa aplicable;
la dirección IP del plano de usuario N3 del gNB y el TEID de túnel asignado.
Por eso la resolución de problemas no debe detenerse después de revisar únicamente el PFCP Session Establishment Request. La FAR inicial puede contener solo la acción básica de reenvío, mientras que la información necesaria para construir el túnel descendente N3 real puede añadirse después mediante PFCP Session Modification.
Si se ignora esa actualización posterior durante el análisis, un proceso normal de aprovisionamiento escalonado de reglas puede confundirse fácilmente con una configuración FAR ausente o incompleta.
¿Cómo devuelve una FAR el tráfico descendente al túnel N3?
Seguir la ruta completa del paquete descendente facilita comprender la función de la FAR.
Un paquete procedente de un servidor externo llega a la UPF por N6. La UPF utiliza una PDR para identificar el tráfico y asociarlo con la PDU Session correcta. Después lee la FAR referenciada por esa PDR.
Si Apply Action incluye FORW, la UPF evalúa los Forwarding Parameters. Una Destination Interface configurada como Access indica que el paquete debe enviarse hacia el lado de acceso radio. Outer Header Creation contiene la dirección del túnel del gNB y el TEID necesarios para construir la cabecera externa GTP-U. A continuación, la UPF encapsula el paquete original y lo envía al gNB por N3.
La ruta completa puede resumirse así:
Paquete descendente llega por N6 → PDR identifica el tráfico del UE → FAR aplica FORW → UPF obtiene los parámetros del túnel N3 del gNB → UPF crea la cabecera externa GTP-U → el paquete se transmite al gNB por N3.
Esto también aclara la diferencia entre FAR y GTP-U. GTP-U es el protocolo de túnel que transporta los datos de usuario, mientras que FAR es la regla de decisión de la UPF que controla si debe crearse una cabecera externa de túnel, qué información del túnel debe utilizarse y qué interfaz lógica debe recibir el paquete.
Por tanto, un TEID incorrecto observado en una captura N3 es solo el síntoma visible. La investigación debe continuar hacia el plano de control: ¿el gNB asignó la información correcta del plano de usuario? ¿La SMF la recibió correctamente? ¿Se escribió después en la FAR adecuada mediante la actualización N4?
¿Cómo puede utilizarse FAR para diagnosticar una PDU Session activa pero sin conectividad de datos?
Si el registro del UE es normal y la PDU Session se ha establecido, pero el servicio sigue sin funcionar, el análisis puede seguir la secuencia real de procesamiento de paquetes de la UPF en lugar de repetir desde el principio todo el procedimiento de registro.
Una secuencia práctica de diagnóstico de FAR es:
Confirme que el paquete llega a la UPF. Si no llega ningún paquete por N3 o N6, el problema está antes de la FAR y debe investigarse primero en el UE, el gNB o la ruta de transporte.
Confirme que la PDR coincide con el paquete. Una FAR no tiene tráfico sobre el que actuar si el paquete no es identificado primero por la PDR asociada.
Verifique el FAR ID referenciado por la PDR. Asegúrese de que un paquete correctamente identificado no esté asociado con la regla de reenvío equivocada.
Revise Apply Action. Determine si el comportamiento configurado es FORW, DROP, BUFF o una combinación de indicadores aplicables.
Compruebe Destination Interface y Network Instance. Confirme que el paquete se envía hacia la dirección lógica y el contexto de red correctos.
Compruebe Outer Header Creation. Para tráfico N3 descendente, verifique la dirección del gNB, el TEID y el tipo de cabecera externa.
Revise los mensajes PFCP Session Modification. No examine únicamente el Create FAR inicial. Confirme que la información del túnel del gNB se haya actualizado posteriormente en la UPF.
Compare las capturas de N3 y N6. Compare el comportamiento esperado según las reglas PFCP con los paquetes que realmente transmite la UPF.
La principal ventaja de este enfoque es que las reglas del plano de control y las capturas del plano de usuario pueden validarse mutuamente. La señalización PFCP muestra cómo la UPF debería reenviar el paquete, mientras que las capturas N3 y N6 muestran lo que la UPF realmente hizo.
Cuando ambas vistas no coinciden, el dominio del fallo normalmente puede reducirse a una de tres áreas: aprovisionamiento incorrecto de reglas N4, ejecución incorrecta de reglas por parte de la UPF o un problema en la ruta de transporte del plano de usuario. Esto es mucho más eficiente que buscar sin dirección clara en todo el 5G Core.
FAQ
¿Cuál es la principal diferencia entre una FAR y una PDR?
Una PDR realiza la detección y clasificación de paquetes y responde a preguntas como a qué sesión y flujo de tráfico pertenece un paquete. Una FAR define qué ocurre después de la coincidencia, incluida la forma en que debe tratarse el paquete y adónde debe reenviarse. La PDR referencia la FAR correspondiente mediante el FAR ID.
¿Por qué puede seguir fallando el reenvío cuando Apply Action incluye FORW?
FORW solo indica que debe realizarse el reenvío. El éxito también depende de los Forwarding Parameters asociados. Si la Destination Interface, Network Instance o la información de Outer Header Creation son incorrectas, el paquete puede no llegar al destino esperado. Un TEID N3 incorrecto o una dirección del plano de usuario del gNB equivocada son ejemplos típicos.
¿Por qué la FAR del primer PFCP Session Establishment a veces no contiene toda la información del túnel N3?
El establecimiento de la PDU Session es un procedimiento de varios pasos. Cuando se crea la sesión PFCP inicial, el gNB puede no haber asignado todavía los recursos finales del plano de usuario descendente N3. Cuando la dirección del túnel del gNB y el TEID están disponibles, la SMF puede actualizar la FAR mediante PFCP Session Modification. Por tanto, la resolución de problemas debe seguir también los intercambios N4 posteriores, además del mensaje inicial de establecimiento.
¿Qué relación existe entre Outer Header Creation y PDR Outer Header Removal?
Se aplican a direcciones opuestas del procesamiento de túnel. Para el tráfico ascendente que llega desde N3, Outer Header Removal elimina la cabecera externa GTP-U correspondiente. Para el tráfico descendente que sale de la UPF hacia N3, Outer Header Creation de la FAR proporciona la información necesaria para construir una nueva cabecera externa GTP-U. Juntas permiten encapsular y desencapsular el túnel del plano de usuario en ambos sentidos.
Si el TEID de N3 es incorrecto, ¿debe centrarse la resolución de problemas solo en GTP-U?
No. Una captura N3 solo muestra que el TEID utilizado es incorrecto. La información del túnel se origina en el gNB, es procesada por la SMF y después se aprovisiona en la FAR a través de N4. Por tanto, el análisis debe seguir la asignación del gNB, la información recibida por la SMF y la actualización de la FAR en el procedimiento PFCP Session Modification para localizar la causa real.
