Quando um UE abre um aplicativo de vídeo, o tráfego real do usuário precisa sair do gNB, passar pelo UPF e só então chegar à rede de dados. O plano de controle estabelece a PDU Session, atribui endereços e instala regras de encaminhamento, mas o protocolo que realmente transporta os pacotes IP do usuário pelo plano de usuário de acesso e núcleo 5G é o GTP-U. Entender GTP-U exige mais do que memorizar “porta UDP 2152” e “TEID”. No 5G, um único túnel N3 pode transportar vários QoS Flows, enquanto a supervisão do caminho, o tratamento de túneis desconhecidos e a limpeza do plano de usuário após eventos de mobilidade também dependem de mensagens de gerenciamento do GTP-U. Enxergar a pilha de protocolos, os túneis, os TEIDs, os QFIs e os procedimentos de gerenciamento como um único caminho completo do plano de usuário facilita muito compreender como o tráfego 5G realmente chega ao UPF.

Onde o GTP-U se encaixa na arquitetura 5G?

GTP-U significa GPRS Tunnelling Protocol for the User Plane. Na arquitetura do plano de usuário 5G, ele é usado principalmente para encapsular e transportar tráfego de usuário das camadas superiores entre nós do plano de usuário.

Do ponto de vista do 5G Core, as duas interfaces mais comuns que usam GTP-U são N3 e N9. A N3 conecta o gNB ao UPF e transporta tráfego de usuário entre a rede de acesso por rádio e o 5G Core. A N9 é usada entre UPFs. Dentro da RAN, a Xn-U entre gNBs também pode usar GTP-U.

Isso é bem diferente da arquitetura do plano de controle 5G. Funções de rede como AMF e SMF usam interfaces baseadas em serviços que dependem em grande parte de HTTP/2, enquanto o caminho do plano de usuário continua usando GTP-U para transportar o tráfego real do assinante. A adoção de uma Service-Based Architecture no 5G não significa que o próprio plano de usuário tenha migrado para HTTP.

O GTP-U opera sobre UDP e continua usando a porta UDP 2152. Se a pilha de protocolos for observada do pacote da aplicação do usuário em direção às camadas inferiores, a estrutura pode ser entendida da seguinte forma.

O tráfego da aplicação primeiro se torna um pacote TCP ou UDP e, em seguida, um pacote IP pertencente ao UE. Ao entrar no plano de usuário 5G, esse pacote de usuário original é encapsulado dentro do GTP-U. Depois são adicionados um cabeçalho UDP externo, um cabeçalho IP externo e o enquadramento Ethernet das camadas inferiores para o transporte entre os pontos finais GTP-U.

Isso significa que uma captura de pacotes pode conter dois conjuntos diferentes de endereços IP. Os endereços IP internos descrevem a comunicação entre o UE e o servidor de aplicação na rede de dados, enquanto os endereços IP externos são usados entre pontos finais de túneis GTP-U, como o gNB e o UPF. Confundir os cabeçalhos IP internos e externos é uma fonte comum de erro ao solucionar problemas de tráfego N3.

Qual é a diferença entre GTP Path, túnel e TEID?

GTP Path, GTP Tunnel, Tunnel Endpoint e TEID são termos estreitamente relacionados, mas descrevem camadas diferentes do modelo de transporte GTP-U.

Um GTP Path pode ser entendido como o caminho de comunicação sem conexão entre dois pontos finais de túneis GTP. Se um gNB e um UPF conseguem trocar pacotes GTP-U pela rede IP, existe um GTP Path entre esses pontos finais. Vários túneis GTP-U podem compartilhar o mesmo Path.

Um GTP Tunnel representa um túnel lógico de plano de usuário mais específico. Um túnel GTP-U é identificado por uma combinação de TEID, endereçamento IP e informações de transporte UDP, enquanto o próprio ponto final do túnel é identificado pelo endereço IP do nó e pela porta UDP.

O TEID, ou Tunnel Endpoint Identifier, é um dos campos mais importantes do GTP-U. No cabeçalho básico do GTPv1-U, o TEID tem quatro bytes. Quando um pacote GTP-U chega ao nó receptor, o receptor usa o TEID em conjunto com seu contexto local de túnel para determinar a qual túnel do plano de usuário o pacote pertence e qual PDU Session ou contexto de encaminhamento deve processá-lo.

Por isso, um TEID nunca deve ser interpretado isoladamente. O mesmo valor numérico de TEID pode aparecer em contextos de túnel diferentes. Se os pacotes pertencerem a pontos finais GTP distintos ou a direções diferentes, eles não fazem necessariamente parte do mesmo túnel.

Dois outros termos são úteis ao observar a própria carga útil. Um T-PDU é o dado de usuário original de camada superior, enquanto um G-PDU é o T-PDU após a adição do cabeçalho GTP-U. Portanto, o que é transportado pela N3 não é apenas o pacote IP bruto do UE, mas um G-PDU encapsulado em GTP-U.

O GTP-U também não se limita ao transporte de dados de usuário. Ele possui suas próprias mensagens de gerenciamento. Por isso, ver a porta UDP 2152 em uma captura não significa automaticamente que o pacote pertença ao tráfego de uma aplicação de usuário. Echo Request, Echo Response, Error Indication, End Marker e outras mensagens GTP-U usam a mesma estrutura de protocolo.

Por que o 5G precisa de QFI se já possui TEID?

Se o GTP-U for aprendido primeiro sob a perspectiva do 4G, é fácil supor que identificar o TEID seja suficiente para identificar o bearer. No 5G, essa suposição já não é completa.

A arquitetura de QoS do 4G é baseada em EPS Bearers. Bearers diferentes possuem seus próprios contextos de transporte do plano de usuário e túneis GTP-U, de modo que o túnel e o TEID ajudam naturalmente a distinguir o tráfego de diferentes bearers.

O 5G altera o modelo de QoS para PDU Session mais QoS Flow. Uma PDU Session pode conter um ou mais QoS Flows, e um DRB também pode transportar um ou mais QoS Flows. No entanto, a N3 não cria um túnel GTP-U separado para cada QoS Flow dentro da mesma PDU Session.

Em outras palavras, o TEID pode identificar o túnel GTP-U associado à PDU Session, mas vários QoS Flows ainda podem compartilhar esse mesmo túnel.

Isso levanta outra questão: como o nó receptor sabe a qual QoS Flow pertence um determinado pacote?

Essa é uma das principais razões para o cabeçalho de extensão PDU Session Container. O 5G usa esse cabeçalho de extensão GTP-U para transportar informações do plano de usuário relacionadas à PDU Session, incluindo o QFI, ou QoS Flow Identifier.

O QFI é um identificador de 6 bits usado para identificar um QoS Flow. Ao analisar tráfego 5G N3, TEID e QFI podem, portanto, ser compreendidos em dois níveis diferentes:

O TEID identifica o túnel GTP-U ou o contexto da PDU Session, enquanto o QFI identifica o QoS Flow específico transportado dentro desse túnel.

O PDU Session Container de downlink também pode transportar informações como RQI e PPI. O RQI é usado em sinalização relacionada a Reflective QoS, enquanto o PPI está associado a Paging Policy Differentiation e pode permitir tratamento de paging diferente para diversos tipos de tráfego dentro da mesma PDU Session.

O bit E no cabeçalho básico GTP-U indica se há um Extension Header em seguida. Isso significa que nem todo pacote GTP-U carrega necessariamente os mesmos cabeçalhos de extensão. A presença de um PDU Session Container depende do pacote e da função executada.

O que realmente acontece com um pacote de usuário N3?

Os conceitos anteriores ficam muito mais fáceis de entender quando são colocados em um fluxo real de pacotes de uplink.

Suponha que um UE esteja acessando um serviço de vídeo on-line. Primeiro, o UE gera tráfego de aplicação, que é transportado sobre TCP ou UDP e depois colocado dentro de um pacote IP normal. Nesse cabeçalho IP interno, o endereço de origem é o endereço IP atribuído ao UE, enquanto o endereço de destino pertence ao servidor da aplicação na internet.

Quando o pacote chega ao gNB, o gNB não encaminha simplesmente o pacote IP do UE diretamente para o UPF. Em vez disso, aplica encapsulamento GTP-U com base no contexto atual do plano de usuário da PDU Session.

O cabeçalho GTP-U contém o TEID correspondente. Se o pacote precisar identificar um QoS Flow específico, o PDU Session Container também pode transportar o QFI. Em seguida, o gNB adiciona o cabeçalho UDP, com porta de destino 2152, seguido pelo cabeçalho IP externo.

Nesse ponto, os endereços IP externos já não descrevem a comunicação entre o UE e a internet. Eles representam a relação de transporte entre a interface N3 do gNB e a interface N3 do UPF.

Quando o pacote chega ao UPF, o processo é invertido. O UPF recebe o pacote com base nas informações de transporte externas, lê o TEID para localizar o contexto correto do túnel do plano de usuário, processa o QFI e outras informações de extensão quando necessário, remove o encapsulamento GTP-U e então encaminha o pacote IP original do UE para a rede de dados.

Ao solucionar problemas de tráfego N3 com Wireshark ou outra ferramenta de análise de pacotes, uma abordagem útil é trabalhar de fora para dentro. Primeiro verifique os endereços IP externos do gNB e do UPF, depois a porta UDP 2152, em seguida o TEID, o PDU Session Container e o QFI quando presentes, e só então examine o IP interno do usuário, TCP ou UDP e o tráfego da camada de aplicação.

Esse método costuma ser mais eficaz do que começar pelo pacote da aplicação, porque muitas falhas de N3 são causadas por contexto de túnel, TEID ou problemas nos pontos finais, e não pela própria aplicação do usuário.

Por que o GTP-U precisa de suas próprias mensagens de gerenciamento?

Embora o GTP-U seja um protocolo do plano de usuário, ele não se limita a mensagens G-PDU de dados de usuário. Ele também define mensagens de gerenciamento de caminho e de túnel que ajudam a manter o transporte do plano de usuário operacional.

Echo Request e Echo Response verificam a disponibilidade do caminho

Um Echo Request é usado para verificar se o GTP Path e o nó GTP par estão acessíveis e operacionais. O par responde com um Echo Response.

Essas mensagens testam a relação básica entre dois pontos finais GTP. Se um gNB falhar repetidamente ao receber Echo Responses de um UPF, o problema pode deixar de estar restrito a um UE ou a uma PDU Session e pode indicar uma falha no próprio GTP Path ou no nó par.

O GTP-U também define a mensagem Supported Extension Headers Notification, que permite a um nó indicar quais cabeçalhos de extensão GTP ele suporta. Isso se torna relevante quando recursos do plano de usuário 5G dependem de cabeçalhos de extensão como o PDU Session Container.

Error Indication trata TEIDs desconhecidos

Se um ponto final GTP receber um G-PDU, mas não conseguir encontrar um EPS Bearer local ou um contexto de PDU Session correspondente ao TEID recebido, e o TEID não for zero, ele poderá enviar uma Error Indication ao par.

Isso informa ao nó transmissor que ele está encaminhando dados para um túnel do plano de usuário que o lado receptor já não reconhece.

Se mensagens Error Indication aparecerem repetidamente durante a análise, as primeiras verificações devem confirmar se os dois pontos finais mantêm estado de TEID consistente e se uma atualização de PDU Session, um procedimento de mobilidade ou uma alteração no caminho do plano de usuário deixou os dois lados fora de sincronia.

End Marker ajuda a concluir uma troca de caminho do plano de usuário

O End Marker costuma estar associado à mobilidade e à troca de caminhos do plano de usuário. Ele indica que o último G-PDU no caminho GTP-U antigo foi enviado e que o tráfego de usuário subsequente não deve continuar por esse caminho anterior.

Por exemplo, quando um UE se move de um gNB de origem para um gNB de destino, o caminho do plano de usuário do núcleo também pode mudar. O tráfego não deve continuar indefinidamente pelo caminho antigo; caso contrário, os caminhos antigo e novo podem se sobrepor e criar problemas de ordenação ou encaminhamento de pacotes.

Portanto, o End Marker não é simplesmente uma notificação de “excluir túnel”. Ele funciona mais como um marcador de limite do caminho antigo do plano de usuário, informando ao lado receptor que o último pacote desse caminho já foi entregue.

Quando esses mecanismos são analisados em conjunto, o papel do GTP-U fica muito mais claro. Ele não é apenas um protocolo que adiciona um TEID à frente do pacote IP do usuário. Ele fornece uma estrutura completa de tunelamento do plano de usuário que pode ser identificada, monitorada, gerenciada e atualizada à medida que o estado da rede muda.

Uma sequência prática de solução de problemas de GTP-U no 5G é, portanto, primeiro confirmar que os pontos finais GTP e o Path estão íntegros, depois verificar o TEID e o contexto do Tunnel, inspecionar o PDU Session Container e o QFI quando aplicável e, por fim, avançar para o tráfego original do usuário. Se o problema ocorrer durante mobilidade ou atualizações de caminho, as mensagens Error Indication e End Marker também devem ser analisadas.

Seguir essa ordem transforma uma captura N3 com uma grande coleção de pacotes UDP 2152 em um caminho de encaminhamento do plano de usuário que pode ser reconstruído camada por camada.

Perguntas frequentes

Todo pacote na porta UDP 2152 transporta tráfego de usuário?

Não. Mensagens G-PDU transportam dados do plano de usuário por GTP-U e pela porta UDP 2152, mas mensagens de gerenciamento GTP-U como Echo Request, Echo Response, Error Indication, End Marker e Supported Extension Headers Notification também usam a mesma estrutura de protocolo. O GTP-U Message Type deve ser verificado para determinar o que o pacote realmente representa.

Um TEID precisa ser globalmente único em toda a rede 5G?

Não. Um TEID não deve ser tratado como um identificador globalmente único em toda a rede. A identificação de um túnel GTP-U também depende dos pontos finais do túnel, do endereçamento IP, das informações de transporte e da direção. Por isso, a análise deve considerar o contexto completo do túnel, e não apenas comparar valores de TEID.

Todo pacote GTP-U 5G inclui um PDU Session Container?

Não. O PDU Session Container é um cabeçalho de extensão GTP-U, e sua presença depende do pacote e da função executada. O bit E no cabeçalho básico GTP-U indica se outros Extension Headers vêm em seguida, portanto nem todo pacote N3 possui a mesma estrutura de cabeçalho.

Um End Marker significa que toda a PDU Session foi liberada?

Não necessariamente. Um End Marker indica principalmente que o tráfego em um determinado caminho do plano de usuário GTP-U chegou ao fim e é comum durante trocas de caminho após eventos de mobilidade. Ele marca o fim do tráfego naquele caminho, e não o procedimento completo de liberação da PDU Session.