Cuando un UE abre una aplicación de vídeo, el tráfico de usuario real debe viajar desde el gNB hasta el UPF antes de llegar a la red de datos. El plano de control establece la PDU Session, asigna direcciones e instala reglas de reenvío, pero el protocolo que transporta realmente los paquetes IP del usuario a través del plano de usuario de acceso y núcleo 5G es GTP-U. Comprender GTP-U exige algo más que recordar «puerto UDP 2152» y «TEID». En 5G, un único túnel N3 puede transportar varios QoS Flows, mientras que la supervisión de rutas, el tratamiento de túneles desconocidos y la limpieza del plano de usuario después de eventos de movilidad también dependen de mensajes de gestión de GTP-U. Ver la pila de protocolos, los túneles, los TEID, los QFI y los procedimientos de gestión como una única ruta completa del plano de usuario facilita mucho entender cómo llega realmente el tráfico 5G al UPF.

¿Dónde se sitúa GTP-U en la arquitectura 5G?

GTP-U significa GPRS Tunnelling Protocol for the User Plane. En la arquitectura del plano de usuario 5G se utiliza principalmente para encapsular y transportar tráfico de usuario de capas superiores entre nodos del plano de usuario.

Desde la perspectiva del 5G Core, las dos interfaces más habituales que utilizan GTP-U son N3 y N9. N3 conecta el gNB con el UPF y transporta tráfico de usuario entre la red de acceso radio y el 5G Core. N9 se utiliza entre UPF. Dentro de la RAN, Xn-U entre gNB también puede utilizar GTP-U.

Esto es bastante distinto de la arquitectura del plano de control 5G. Funciones de red como AMF y SMF utilizan interfaces basadas en servicios que se apoyan en gran medida en HTTP/2, mientras que la ruta del plano de usuario sigue utilizando GTP-U para transportar el tráfico real del abonado. El paso a una Service-Based Architecture en 5G no significó que el propio plano de usuario pasara a HTTP.

GTP-U funciona sobre UDP y sigue utilizando el puerto UDP 2152. Si se observa la pila de protocolos desde el paquete de aplicación del usuario hacia abajo, la estructura puede entenderse de la siguiente manera.

El tráfico de aplicación primero se convierte en un paquete TCP o UDP y, después, en un paquete IP perteneciente al UE. Cuando entra en el plano de usuario 5G, ese paquete de usuario original se encapsula dentro de GTP-U. A continuación se añaden una cabecera UDP externa, una cabecera IP externa y la trama Ethernet de capas inferiores para transportarlo entre los extremos GTP-U.

Esto significa que una captura de paquetes puede contener dos conjuntos diferentes de direcciones IP. Las direcciones IP internas describen la comunicación entre el UE y el servidor de aplicaciones de la red de datos, mientras que las direcciones IP externas se utilizan entre extremos de túnel GTP-U como el gNB y el UPF. Confundir las cabeceras IP internas y externas es una fuente habitual de errores al diagnosticar tráfico N3.

¿Cuál es la diferencia entre una GTP Path, un túnel y un TEID?

GTP Path, GTP Tunnel, Tunnel Endpoint y TEID son términos estrechamente relacionados, pero describen niveles diferentes del modelo de transporte GTP-U.

Una GTP Path puede entenderse como la ruta de comunicación no orientada a conexión entre dos extremos de túnel GTP. Si un gNB y un UPF pueden intercambiar paquetes GTP-U a través de la red IP, existe una GTP Path entre esos extremos. Varios túneles GTP-U pueden compartir la misma Path.

Un GTP Tunnel representa un túnel lógico de plano de usuario más específico. Un túnel GTP-U se identifica mediante una combinación de TEID, direccionamiento IP e información de transporte UDP, mientras que el propio extremo del túnel se identifica por la dirección IP del nodo y el puerto UDP.

El TEID, o Tunnel Endpoint Identifier, es uno de los campos más importantes de GTP-U. En la cabecera básica GTPv1-U, el TEID tiene una longitud de cuatro bytes. Cuando un paquete GTP-U llega al nodo receptor, este utiliza el TEID junto con su contexto local de túnel para determinar a qué túnel de plano de usuario pertenece el paquete y qué PDU Session o contexto de reenvío debe procesarlo.

Por eso un TEID nunca debe interpretarse de forma aislada. El mismo valor numérico de TEID puede aparecer en contextos de túnel distintos. Si los paquetes pertenecen a extremos GTP diferentes o a direcciones distintas, no forman necesariamente parte del mismo túnel.

Al observar la carga útil también son útiles otros dos términos. Un T-PDU es el dato de usuario original de capa superior, mientras que un G-PDU es el T-PDU después de añadirle la cabecera GTP-U. Por tanto, lo que se transporta por N3 no es únicamente el paquete IP sin procesar del UE, sino un G-PDU encapsulado en GTP-U.

GTP-U tampoco se limita al transporte de datos de usuario. Dispone de sus propios mensajes de gestión. Por ello, ver el puerto UDP 2152 en una captura no significa automáticamente que el paquete corresponda a tráfico de una aplicación de usuario. Echo Request, Echo Response, Error Indication, End Marker y otros mensajes GTP-U utilizan el mismo marco de protocolo.

¿Por qué necesita 5G un QFI si ya dispone de TEID?

Si GTP-U se aprende primero desde la perspectiva de 4G, es fácil suponer que identificar el TEID basta para identificar el bearer. En 5G, esa suposición ya no es completa.

La arquitectura QoS de 4G se basa en EPS Bearers. Los distintos bearers tienen sus propios contextos de transporte del plano de usuario y túneles GTP-U, por lo que el túnel y el TEID ayudan de forma natural a diferenciar el tráfico de cada bearer.

5G cambia el modelo QoS a PDU Session más QoS Flow. Una PDU Session puede contener uno o varios QoS Flows, y un DRB también puede transportar uno o varios QoS Flows. Sin embargo, N3 no crea un túnel GTP-U independiente para cada QoS Flow dentro de la misma PDU Session.

En otras palabras, el TEID puede identificar el túnel GTP-U asociado a la PDU Session, pero varios QoS Flows pueden seguir compartiendo ese mismo túnel.

Esto plantea otra pregunta: ¿cómo sabe el nodo receptor a qué QoS Flow pertenece un paquete concreto?

Esta es una de las principales razones del encabezado de extensión PDU Session Container. 5G utiliza este encabezado de extensión GTP-U para transportar información del plano de usuario relacionada con la PDU Session, incluido el QFI, o QoS Flow Identifier.

El QFI es un identificador de 6 bits utilizado para identificar un QoS Flow. Al analizar tráfico 5G N3, TEID y QFI pueden entenderse, por tanto, en dos niveles diferentes:

El TEID identifica el túnel GTP-U o el contexto de la PDU Session, mientras que el QFI identifica el QoS Flow específico transportado dentro de ese túnel.

El PDU Session Container de enlace descendente también puede transportar información como RQI y PPI. RQI se utiliza para señalización relacionada con Reflective QoS, mientras que PPI está asociado a Paging Policy Differentiation y puede permitir un tratamiento de paginación diferente para distintos tipos de tráfico dentro de la misma PDU Session.

El bit E de la cabecera básica GTP-U indica si a continuación existe un Extension Header. Esto significa que no todos los paquetes GTP-U llevan necesariamente los mismos encabezados de extensión. La presencia de un PDU Session Container depende del paquete y de la función que se esté realizando.

¿Qué ocurre realmente con un paquete de usuario N3?

Los conceptos anteriores se entienden mucho mejor cuando se sitúan dentro de un flujo real de paquetes de enlace ascendente.

Supongamos que un UE accede a un servicio de vídeo en línea. El UE genera primero tráfico de aplicación, que se transporta sobre TCP o UDP y después se coloca dentro de un paquete IP normal. En esta cabecera IP interna, la dirección de origen es la dirección IP asignada al UE, mientras que la dirección de destino pertenece al servidor de aplicaciones de internet.

Cuando el paquete llega al gNB, el gNB no reenvía simplemente el paquete IP del UE directamente al UPF. En su lugar, aplica encapsulación GTP-U basándose en el contexto actual del plano de usuario de la PDU Session.

La cabecera GTP-U contiene el TEID correspondiente. Si el paquete necesita identificar un QoS Flow concreto, el PDU Session Container también puede transportar el QFI. A continuación, el gNB añade la cabecera UDP, con puerto de destino 2152, seguida de la cabecera IP externa.

En este punto, las direcciones IP externas ya no describen la comunicación entre el UE e internet. Representan la relación de transporte entre la interfaz N3 del gNB y la interfaz N3 del UPF.

Cuando el paquete llega al UPF, el proceso se invierte. El UPF recibe el paquete a partir de la información de transporte externa, lee el TEID para localizar el contexto correcto del túnel de plano de usuario, procesa el QFI y demás información de extensión cuando sea necesario, elimina la encapsulación GTP-U y reenvía el paquete IP original del UE hacia la red de datos.

Al diagnosticar tráfico N3 con Wireshark u otra herramienta de análisis de paquetes, resulta útil trabajar de fuera hacia dentro. Primero se verifican las direcciones IP externas del gNB y el UPF, después el puerto UDP 2152, seguido del TEID, del PDU Session Container y del QFI cuando estén presentes, y solo entonces se inspeccionan el IP interno, TCP o UDP y el tráfico de capa de aplicación del usuario.

Este método suele ser más eficaz que empezar por el paquete de aplicación, porque muchos fallos de N3 se deben al contexto de túnel, al TEID o a problemas de los extremos, y no a la propia aplicación del usuario.

¿Por qué necesita GTP-U sus propios mensajes de gestión?

Aunque GTP-U es un protocolo del plano de usuario, no se limita a mensajes G-PDU de datos de usuario. También define mensajes de gestión de rutas y de túneles que ayudan a mantener operativo el transporte del plano de usuario.

Echo Request y Echo Response comprueban la disponibilidad de la ruta

Un Echo Request se utiliza para comprobar si la GTP Path y el nodo GTP par son alcanzables y están operativos. El par responde con un Echo Response.

Estos mensajes comprueban la relación básica entre dos extremos GTP. Si un gNB no recibe repetidamente Echo Responses de un UPF, el problema puede dejar de estar limitado a un UE o a una PDU Session y puede indicar un fallo de la propia GTP Path o del nodo par.

GTP-U también define el mensaje Supported Extension Headers Notification, que permite a un nodo indicar qué encabezados de extensión GTP admite. Esto cobra relevancia cuando determinadas funciones del plano de usuario 5G dependen de encabezados de extensión como el PDU Session Container.

Error Indication gestiona TEID desconocidos

Si un extremo GTP recibe un G-PDU pero no puede encontrar un EPS Bearer local o un contexto de PDU Session correspondiente al TEID recibido, y el TEID no es cero, puede enviar un Error Indication al par.

Esto informa al nodo emisor de que está enviando datos hacia un túnel de plano de usuario que el lado receptor ya no reconoce.

Si aparecen repetidamente mensajes Error Indication durante el diagnóstico, lo primero es comprobar si ambos extremos mantienen un estado TEID coherente y si una actualización de PDU Session, un procedimiento de movilidad o un cambio de ruta del plano de usuario dejó ambos lados desincronizados.

End Marker ayuda a completar un cambio de ruta del plano de usuario

El End Marker suele estar asociado a la movilidad y a los cambios de ruta del plano de usuario. Indica que ya se ha enviado el último G-PDU por la antigua ruta GTP-U y que el tráfico de usuario posterior no debe continuar por esa ruta anterior.

Por ejemplo, cuando un UE se desplaza de un gNB origen a un gNB destino, la ruta del plano de usuario del núcleo también puede cambiar. El tráfico no debe seguir indefinidamente por la ruta antigua; de lo contrario, las rutas antigua y nueva podrían solaparse y provocar problemas de orden de paquetes o de reenvío.

Por ello, End Marker no es simplemente una notificación de «eliminar túnel». Actúa más bien como un marcador de límite de la antigua ruta del plano de usuario, informando al receptor de que ya se ha entregado el último paquete de esa ruta.

Cuando se observan juntos estos mecanismos, el papel de GTP-U resulta mucho más claro. No es simplemente un protocolo que añade un TEID delante del paquete IP del usuario. Proporciona un marco completo de túneles de plano de usuario que puede identificarse, supervisarse, gestionarse y actualizarse a medida que cambia el estado de la red.

Por tanto, una secuencia práctica de diagnóstico para 5G GTP-U consiste en confirmar primero que los extremos GTP y la Path están operativos, después verificar el TEID y el contexto del Tunnel, inspeccionar el PDU Session Container y el QFI cuando proceda y, finalmente, avanzar hacia el tráfico de usuario original. Si el problema aparece durante movilidad o actualizaciones de ruta, también deben revisarse los mensajes Error Indication y End Marker.

Seguir este orden convierte una captura N3 formada por una gran cantidad de paquetes UDP 2152 en una ruta de reenvío del plano de usuario que puede reconstruirse capa por capa.

Preguntas frecuentes

¿Todos los paquetes del puerto UDP 2152 transportan tráfico de usuario?

No. Los mensajes G-PDU transportan datos del plano de usuario mediante GTP-U y el puerto UDP 2152, pero los mensajes de gestión GTP-U, como Echo Request, Echo Response, Error Indication, End Marker y Supported Extension Headers Notification, también utilizan el mismo marco de protocolo. Debe comprobarse el GTP-U Message Type para determinar qué representa realmente el paquete.

¿Debe un TEID ser globalmente único en toda la red 5G?

No. Un TEID no debe tratarse como un identificador único en toda la red. La identificación de un túnel GTP-U también depende de los extremos del túnel, el direccionamiento IP, la información de transporte y la dirección. Por ello, el diagnóstico debe considerar el contexto completo del túnel en lugar de comparar únicamente valores TEID.

¿Todos los paquetes GTP-U de 5G incluyen un PDU Session Container?

No. El PDU Session Container es un encabezado de extensión GTP-U y su presencia depende del paquete y de la función que se esté realizando. El bit E de la cabecera básica GTP-U indica si siguen otros Extension Headers, por lo que no todos los paquetes N3 tienen la misma estructura de cabecera.

¿Un End Marker significa que se ha liberado toda la PDU Session?

No necesariamente. Un End Marker indica principalmente que el tráfico de una ruta concreta del plano de usuario GTP-U ha llegado a su fin y suele aparecer durante cambios de ruta después de eventos de movilidad. Marca el final del tráfico en esa ruta, no el procedimiento completo de liberación de la PDU Session.