Um cenário comum de solução de problemas em redes 5G parece simples à primeira vista: o UE se registra com sucesso, a PDU Session é estabelecida e um endereço IP é atribuído corretamente, mas o acesso à web falha e até o tráfego Ping básico não funciona. Capturas de pacotes podem mostrar tráfego chegando à UPF pela N3, porém nenhum pacote correspondente sai pelo caminho esperado. Se a análise permanecer concentrada apenas na sinalização AMF e no resultado do estabelecimento da PDU Session, a causa real pode ser difícil de isolar.
Uma PDU Session estabelecida com sucesso não significa automaticamente que o caminho de encaminhamento do plano de usuário esteja operacional. Depois de receber um pacote, a UPF primeiro usa uma PDR para identificar o tráfego e então aplica a FAR (Forwarding Action Rule, regra de ação de encaminhamento) associada para determinar o que acontece em seguida: encaminhar, descartar, armazenar em buffer ou duplicar o pacote. A FAR também pode definir a interface de destino e se um cabeçalho externo de túnel GTP-U precisa ser criado.
Do ponto de vista da solução de problemas, essa distinção é útil: uma PDR responde “A qual sessão e fluxo de tráfego este pacote pertence?”, enquanto uma FAR responde “Agora que o pacote foi identificado, o que a UPF deve fazer com ele?” Quando os procedimentos do plano de controle parecem normais, mas o tráfego de usuário continua falhando, a FAR na interface N4 se torna um ponto importante de investigação.
Por que uma PDU Session bem-sucedida não garante conectividade do plano de usuário?
A conclusão do procedimento PDU Session Establishment confirma apenas que os recursos necessários da sessão no plano de controle foram inicializados. O tráfego real das aplicações ainda depende do caminho completo do plano de usuário envolvendo gNB, N3, UPF e N6.
Em uma PDU Session de Internet típica, o tráfego de uplink vai do UE ao gNB, é encapsulado em um túnel GTP-U e chega à UPF pela N3. A UPF precisa remover o cabeçalho externo de túnel aplicável, identificar o tráfego e encaminhar o pacote original para a rede de dados. No sentido de downlink ocorre o inverso: o tráfego entra na UPF pela N6, a UPF identifica a PDU Session correspondente, obtém as informações do túnel do plano de usuário do gNB, adiciona o cabeçalho externo GTP-U necessário e envia o pacote ao gNB pela N3.
Esse comportamento de encaminhamento não fica disponível apenas porque a PDU Session foi criada. A SMF precisa provisionar as regras PFCP adequadas na UPF pela N4. A PDR identifica o tráfego correspondente, enquanto a FAR define a ação de encaminhamento a ser aplicada após a classificação. Os dois tipos de regra são necessários para o processamento correto do plano de usuário.
Quando toda a sinalização do plano de controle parece normal, mas o serviço continua indisponível, o problema pode ser dividido em duas perguntas principais:
A PDR identifica corretamente o tráfego atual?
Depois que o pacote é identificado, a FAR associada contém os parâmetros corretos de processamento e encaminhamento?
Concentrar-se na relação entre PDR e FAR geralmente é mais eficiente do que revisar repetidamente todo o procedimento de estabelecimento da PDU Session desde o início.
O que uma FAR realmente instrui a UPF a fazer?
Uma FAR é uma regra de encaminhamento dentro da estrutura PFCP. Ela é provisionada pela SMF na UPF pela N4 e associada ao tráfego por meio do FAR ID referenciado por uma PDR. Quando um pacote corresponde a essa PDR, a UPF executa o comportamento de processamento definido pela FAR referenciada.
Uma FAR pode conter vários Information Elements. Para a solução de problemas do plano de usuário, os campos a seguir são especialmente importantes:
| Parâmetro FAR | Função principal |
|---|---|
| FAR ID | Identifica de forma exclusiva a instância FAR para que uma PDR possa referenciar a regra de encaminhamento correta |
| Apply Action | Define a ação básica do pacote, incluindo encaminhamento, descarte, armazenamento em buffer ou duplicação |
| Forwarding Parameters | Define o destino, a Network Instance, a encapsulação de túnel e outros parâmetros usados quando o encaminhamento é necessário |
| Duplicating Parameters | Define como uma cópia duplicada do pacote deve ser encaminhada quando a duplicação de tráfego está ativada |
| BAR ID | Referencia uma Buffering Action Rule usada para controlar o comportamento de armazenamento de pacotes em buffer |
Na prática, Apply Action e Forwarding Parameters são os dois elementos mais fáceis de confundir. Apply Action responde “Que ação deve ser executada?”, enquanto Forwarding Parameters responde “Se o pacote for encaminhado, como e para onde ele deve ser enviado?”
Ver a flag FORW em Apply Action, por si só, não comprova que o caminho de downlink esteja completo. Destination Interface, Network Instance, as informações de Outer Header Creation e os demais parâmetros de encaminhamento relacionados também precisam estar corretos.
Como Apply Action determina a primeira etapa do processamento do pacote?
Apply Action é representado por um conjunto de flags de bits que instruem a UPF sobre quais operações básicas devem ser aplicadas aos pacotes correspondentes. Essas flags não são simplesmente opções mutuamente exclusivas; seu significado precisa ser interpretado no contexto da sessão PFCP e do cenário de serviço.
DROP: Descartar o pacote correspondente.
FORW: Encaminhar o pacote de acordo com os Forwarding Parameters aplicáveis.
BUFF: Armazenar o pacote em buffer em vez de encaminhá-lo imediatamente.
NOCP: Usado em cenários de buffering para notificar o plano de controle quando chegam dados de downlink que precisam ser armazenados.
DUPL: Criar uma cópia duplicada do pacote e processá-la de acordo com os Duplicating Parameters.
Por que BUFF e NOCP são necessários?
Um caso típico ocorre quando o UE está ocioso e não há um caminho imediato de downlink do plano de usuário disponível. O tráfego de downlink pode já ter chegado à UPF, mas ainda não pode ser entregue ao UE. A UPF pode armazenar o pacote em buffer e, quando necessário, usar o comportamento associado de notificação ao plano de controle para iniciar procedimentos posteriores, como paging ou recuperação do caminho do plano de usuário.
BUFF apenas indica que o armazenamento em buffer é necessário. Os detalhes de como esse buffering é tratado estão associados à BAR, portanto a análise não deve se basear apenas na flag BUFF.
Por que DUPL é mais do que simplesmente “encaminhar o pacote novamente”?
DUPL cria uma cópia separada do pacote. O pacote original continua seguindo seu caminho normal de processamento, enquanto a cópia duplicada é controlada de forma independente pelos Duplicating Parameters. A cópia pode usar uma Destination Interface diferente, outra configuração de cabeçalho externo, Transport Level Marking ou Forwarding Policy.
Por esse motivo, não se deve presumir automaticamente que o tráfego espelhado ou duplicado segue o mesmo caminho do tráfego original de serviço. Os parâmetros de duplicação precisam ser verificados separadamente.
Como os Forwarding Parameters determinam para onde um pacote realmente vai?
Quando Apply Action inclui FORW, os Forwarding Parameters determinam o caminho real de encaminhamento. Vários campos são especialmente importantes na investigação de falhas do plano de usuário.
Destination Interface
Destination Interface define a interface lógica para a qual a UPF deve enviar o pacote após o processamento. Em um cenário típico de downlink, ela é definida como Access, indicando que o pacote deve ser encaminhado ao gNB. O tráfego de uplink normalmente é encaminhado para o lado Core.
Uma Destination Interface incorreta pode causar uma falha difícil de detectar: a PDR corresponde corretamente, mas o pacote é enviado para a interface lógica errada, enquanto o plano de controle pode não apresentar nenhum erro evidente.
Network Instance
Network Instance identifica o contexto lógico de rede usado no encaminhamento. Ela é especialmente importante em implantações com vários DNNs, slices ou redes de dados nas quais o tráfego precisa permanecer separado.
Na solução de problemas de conectividade N6 ou serviços de rede privada, verificar apenas a alcançabilidade física não é suficiente. A Network Instance na FAR também deve corresponder à configuração associada da UPF. Uma incompatibilidade pode impedir que o tráfego seja roteado para o contexto de rede esperado.
Outer Header Creation
Outer Header Creation é um dos parâmetros principais para o encaminhamento de downlink pela N3. Um pacote que entra na UPF pela N6 contém a carga útil original do UE. Antes de enviar esse pacote ao gNB pela N3, a UPF precisa adicionar a encapsulação externa GTP-U/UDP/IP necessária.
Outer Header Creation fornece as informações necessárias para essa operação, incluindo o endereço do plano de usuário do gNB, o TEID do túnel N3 e o tipo de cabeçalho externo.
Muitos casos em que o tráfego de downlink chega à UPF, mas nenhum pacote correspondente aparece na N3, podem ser atribuídos a informações ausentes ou incorretas nessa parte da FAR, como um TEID ou endereço de gNB incorreto.
Outros Forwarding Parameters
Forwarding Parameters também pode incluir Redirect Information, Transport Level Marking, Forwarding Policy, Header Enrichment, Linked Traffic Endpoint ID, Proxying, Destination Interface Type e outras informações opcionais.
Transport Level Marking pode ser usado para aplicar a marcação DSCP necessária aos pacotes encaminhados. Forwarding Policy pode referenciar uma política de encaminhamento configurada localmente na UPF. Header Enrichment permite processamento adicional de cabeçalhos em serviços aplicáveis. Nem toda FAR carrega todos esses Information Elements; o conteúdo real depende da sinalização PFCP e dos requisitos do serviço.
Por que uma FAR de downlink pode ser atualizada depois que a sessão é estabelecida?
Durante o procedimento inicial de PDU Session Establishment, a SMF pode criar as primeiras PDRs e FARs na UPF. Nesse momento, porém, o gNB pode ainda não ter concluído a alocação dos recursos do plano de usuário de downlink N3. Assim, o TEID final do túnel e o endereço do plano de usuário do gNB podem ainda não estar disponíveis para a SMF.
Depois que o gNB aloca esses recursos e as informações correspondentes do plano de usuário N3 ficam disponíveis para a SMF, ela pode enviar uma PFCP Session Modification para atualizar a FAR existente na UPF com os parâmetros necessários do túnel de downlink.
A FAR de downlink atualizada pode então incluir as principais informações de encaminhamento:
Destination Interface = Access, indicando encaminhamento para o lado de acesso;
a Network Instanceaplicável;
Outer Header Creation = GTP-U/UDP/IPv4 ou outro tipo de cabeçalho externo aplicável;
o endereço IP do plano de usuário N3 do gNB e o TEID de túnel alocado.
Por isso, a investigação não deve terminar após examinar apenas o PFCP Session Establishment Request. A FAR inicial pode conter apenas a ação básica de encaminhamento, enquanto as informações necessárias para construir o túnel N3 de downlink real podem ser adicionadas posteriormente por meio de PFCP Session Modification.
Se essa atualização posterior for ignorada durante a análise, um processo normal de provisionamento gradual de regras pode ser facilmente confundido com uma configuração FAR ausente ou incompleta.
Como uma FAR envia o tráfego de downlink de volta para o túnel N3?
Acompanhar o caminho completo do pacote de downlink facilita a compreensão do papel da FAR.
Um pacote de um servidor externo chega à UPF pela N6. A UPF usa uma PDR para identificar o tráfego e associá-lo à PDU Session correta. Em seguida, lê a FAR referenciada por essa PDR.
Se Apply Action inclui FORW, a UPF avalia os Forwarding Parameters. Destination Interface definida como Access significa que o pacote deve ser enviado para o lado de acesso rádio. Outer Header Creation contém o endereço de túnel do gNB e o TEID necessários para construir o cabeçalho externo GTP-U. A UPF então encapsula o pacote original e o envia ao gNB pela N3.
O caminho completo pode ser resumido como:
Pacote de downlink chega pela N6 → PDR identifica o tráfego do UE → FAR aplica FORW → UPF obtém os parâmetros do túnel N3 do gNB → UPF cria o cabeçalho externo GTP-U → pacote é transmitido ao gNB pela N3.
Isso também esclarece a diferença entre FAR e GTP-U. GTP-U é o protocolo de túnel que transporta os dados de usuário, enquanto a FAR é a regra de decisão da UPF que controla se um cabeçalho externo de túnel deve ser criado, quais informações de túnel devem ser usadas e qual interface lógica deve receber o pacote.
Portanto, um TEID incorreto observado em uma captura N3 é apenas o sintoma visível. A investigação deve continuar em direção ao plano de controle: o gNB alocou as informações corretas do plano de usuário? A SMF as recebeu corretamente? Elas foram depois gravadas na FAR apropriada por meio da atualização N4?
Como usar FAR para diagnosticar uma PDU Session estabelecida, mas sem conectividade de dados?
Se o registro do UE está normal e a PDU Session foi estabelecida, mas o serviço continua sem funcionar, a solução de problemas pode seguir a sequência real de processamento de pacotes da UPF em vez de repetir desde o início todo o procedimento de registro.
Uma sequência prática de diagnóstico de FAR é:
Confirmar que o pacote chega à UPF. Se nenhum pacote chega pela N3 ou N6, o problema está antes da FAR e deve ser investigado primeiro no UE, gNB ou caminho de transporte.
Confirmar que a PDR corresponde ao pacote. Uma FAR não tem tráfego sobre o qual atuar se o pacote não for primeiro identificado pela PDR associada.
Verificar o FAR ID referenciado pela PDR. Certificar-se de que um pacote corretamente identificado não esteja associado à regra de encaminhamento errada.
Inspecionar Apply Action. Determinar se o comportamento configurado é FORW, DROP, BUFF ou uma combinação das flags aplicáveis.
Verificar Destination Interface e Network Instance. Confirmar que o pacote está sendo enviado na direção lógica e no contexto de rede corretos.
Verificar Outer Header Creation. Para tráfego N3 de downlink, verificar o endereço do gNB, o TEID e o tipo de cabeçalho externo.
Revisar as mensagens PFCP Session Modification. Não examinar apenas o Create FAR inicial. Confirmar que as informações do túnel do gNB foram posteriormente atualizadas na UPF.
Comparar as capturas de pacotes N3 e N6. Comparar o comportamento esperado pelas regras PFCP com os pacotes realmente transmitidos pela UPF.
A principal vantagem dessa abordagem é que as regras do plano de controle e as capturas do plano de usuário podem validar umas às outras. A sinalização PFCP mostra como a UPF deveria encaminhar o pacote, enquanto as capturas N3 e N6 mostram o que a UPF realmente fez.
Quando essas duas visões não coincidem, o domínio da falha normalmente pode ser reduzido a uma de três áreas: provisionamento incorreto de regras N4, execução incorreta das regras pela UPF ou problema no caminho de transporte do plano de usuário. Isso é muito mais eficiente do que procurar sem direção clara por todo o 5G Core.
FAQ
Qual é a principal diferença entre FAR e PDR?
Uma PDR realiza detecção e classificação de pacotes, respondendo a perguntas como a qual sessão e fluxo de tráfego um pacote pertence. Uma FAR define o que acontece após a correspondência, incluindo como o pacote deve ser tratado e para onde deve ser encaminhado. A PDR referencia a FAR correspondente por meio do FAR ID.
Por que o encaminhamento ainda pode falhar quando Apply Action inclui FORW?
FORW apenas indica que o encaminhamento deve ser realizado. O sucesso ainda depende dos Forwarding Parameters associados. Se Destination Interface, Network Instance ou as informações de Outer Header Creation estiverem incorretas, o pacote pode não chegar ao destino esperado. Um TEID N3 incorreto ou endereço do plano de usuário do gNB errado são exemplos típicos.
Por que a primeira FAR do PFCP Session Establishment às vezes não contém todas as informações do túnel N3?
O estabelecimento da PDU Session é um procedimento de várias etapas. Quando a sessão PFCP inicial é criada, o gNB pode ainda não ter alocado os recursos finais do plano de usuário de downlink N3. Assim que o endereço do túnel do gNB e o TEID ficam disponíveis, a SMF pode atualizar a FAR por meio de PFCP Session Modification. A solução de problemas, portanto, precisa acompanhar também as trocas N4 posteriores, além da mensagem inicial de estabelecimento.
Como Outer Header Creation e PDR Outer Header Removal se relacionam?
Eles se aplicam a direções opostas do processamento do túnel. Para o tráfego de uplink que chega pela N3, Outer Header Removal é usado para remover o cabeçalho externo GTP-U aplicável. Para o tráfego de downlink que sai da UPF em direção à N3, Outer Header Creation da FAR fornece as informações necessárias para construir o novo cabeçalho externo GTP-U. Juntos, eles suportam as duas direções de encapsulamento e desencapsulamento do túnel do plano de usuário.
Se o TEID na N3 estiver errado, a investigação deve se concentrar apenas no GTP-U?
Não. Uma captura N3 mostra apenas que o TEID utilizado está incorreto. As informações do túnel se originam no gNB, são processadas pela SMF e depois provisionadas na FAR pela N4. Portanto, a investigação deve acompanhar a alocação do gNB, as informações recebidas pela SMF e a atualização da FAR no procedimento PFCP Session Modification para localizar a causa real.
