Quando uma UPF recebe um pacote do plano de usuário, ela não decide imediatamente para onde esse pacote deve ser encaminhado. Primeiro, precisa determinar a qual sessão PFCP o pacote pertence e qual regra de processamento deve ser aplicada. Dentro da estrutura de regras PFCP da interface N4, a PDR (Packet Detection Rule, Regra de Detecção de Pacotes) cuida dessa primeira etapa do processamento. Uma PDR informa à UPF quais pacotes pertencem a uma determinada categoria de tráfego. Depois que um pacote corresponde à regra, a UPF pode aplicar FAR, QER, URR e outras regras associadas para encaminhamento, aplicação de QoS e relatório de uso.
A forma mais simples de entender uma PDR é separar três responsabilidades diferentes: a PDR identifica o tráfego, a PDI define as condições de correspondência e FAR/QER/URR determinam o que acontece após uma correspondência. Manter essas funções separadas torna o processamento de pacotes PFCP muito mais fácil de acompanhar do que tentar memorizar cada IE individualmente.
Que problema uma PDR resolve na interface N4?
N4 é a interface de controle entre a SMF e a UPF no núcleo 5G. A SMF usa sessões PFCP para instalar regras de processamento do plano de usuário na UPF, e a PDR é o tipo de regra responsável por detectar e classificar pacotes. Uma PDR normalmente é criada durante o estabelecimento de uma sessão PFCP e depois pode ser adicionada, removida ou atualizada por meio de uma modificação de sessão PFCP. Em outras palavras, a classificação dos pacotes é controlada por regras provisionadas pela SMF de acordo com a sessão PDU, o fluxo de tráfego e os requisitos de encaminhamento atuais.
Uma única sessão PFCP pode conter várias PDRs. A mesma sessão PDU, por exemplo, normalmente precisa de regras separadas para tráfego de uplink e downlink. PDRs adicionais podem ser necessárias quando a sessão contém vários fluxos de dados de serviço, diferentes fluxos de QoS ou classificações de tráfego mais granulares. Assim, uma PDR pode ser vista como a regra de seleção de tráfego da UPF: ela determina que tipo de pacote chegou antes que outras regras decidam como esse pacote será processado.
Como a UPF encontra a PDR correspondente?
O processamento de pacotes na UPF segue uma sequência definida. Depois que um pacote entra na UPF, a função identifica primeiro a sessão PFCP correspondente e, em seguida, avalia as PDRs associadas a essa sessão. Se mais de uma PDR puder corresponder, a UPF usa o valor de Precedence para determinar a prioridade relativa. Um valor menor de Precedence representa uma prioridade maior; portanto, regras de maior prioridade são avaliadas antes das regras de menor prioridade durante a busca por uma correspondência.
Depois que uma PDR corresponde, a própria PDR não executa todas as operações posteriores de processamento do pacote. Em vez disso, ela pode referenciar outras regras PFCP:
FAR (Forwarding Action Rule, Regra de Ação de Encaminhamento): determina como o pacote deve ser tratado e encaminhado, incluindo se deve ser encaminhado, descartado, armazenado em buffer ou enviado para uma interface de destino específica.
QER (QoS Enforcement Rule, Regra de Aplicação de QoS): aplica controles relacionados à QoS, como gating, limitação de taxa e outros tratamentos de tráfego.
URR (Usage Reporting Rule, Regra de Relatório de Uso): mede o uso do tráfego e fornece informações de relatório que podem ser usadas para tarifação, monitoramento ou finalidades relacionadas a políticas.
O caminho geral de processamento da UPF pode, portanto, ser simplificado como:
Identificar a sessão PFCP → avaliar as PDRs por Precedence → classificar o pacote → aplicar FAR/QER/URR. A ordem é importante. A FAR responde como um pacote deve ser tratado, mas a UPF primeiro precisa de uma PDR para estabelecer a qual pacote ou fluxo de tráfego a ação se aplica.
Quais são os principais parâmetros de uma PDR?
Um Create PDR contém vários Information Elements, mas apenas um conjunto menor precisa ser compreendido inicialmente ao estudar o comportamento de detecção de pacotes. Esses parâmetros definem como a regra é identificada, como os pacotes são comparados e quais regras de processamento subsequentes são associadas ao resultado.
| Parâmetro | Função principal |
|---|---|
| ID da PDR | Identifica de forma única a PDR dentro da sessão PFCP e a diferencia de outras regras de detecção de pacotes |
| Precedence | Define a prioridade relativa da PDR quando várias regras são avaliadas; valores menores indicam maior precedência |
| PDI | Contém os critérios de detecção de pacotes usados pela UPF para determinar se o tráfego de entrada corresponde à PDR |
| Remoção do cabeçalho externo | Indica se a UPF deve remover um cabeçalho de protocolo externo, como um cabeçalho GTP-U/UDP/IP no tráfego de uplink |
| ID da FAR | Referencia a FAR que define a ação de encaminhamento para os pacotes correspondentes |
| ID da URR | Referencia uma URR usada para medição de tráfego e relatório de uso |
| ID da QER | Referencia uma QER que aplica tratamento relacionado à QoS ao tráfego correspondente |
| Ativar regras predefinidas | Ativa uma ou mais regras predefinidas já disponíveis na UPF |
| Hora de ativação / Hora de desativação | Define quando a PDR se torna ativa e quando deixa de estar ativa |
Entre esses parâmetros, o elemento que realmente define quais pacotes podem corresponder à PDR é a PDI (Packet Detection Information). Os IDs de FAR e QER referenciam ações que ocorrem depois que o tráfego foi classificado; a PDI contém as informações usadas para realizar a própria classificação.
Como a PDI define as condições de correspondência de pacotes?
A PDI pode ser entendida como o conjunto de condições de detecção de pacotes dentro de uma PDR. Ela não é um único campo. Em vez disso, contém vários parâmetros que podem ser combinados para identificar o tráfego de acordo com o ponto de entrada do pacote na UPF, as informações do túnel, o endereço da UE, as características do fluxo de serviço e as informações de QoS. Entre os parâmetros PDI comuns estão:
Interface de origem: identifica o lado lógico de onde o pacote chega, como Access para tráfego do lado de acesso ou Core para tráfego vindo do núcleo ou do lado da rede de dados.
F-TEID local: pode ser usado para corresponder ao TEID e às informações de endereçamento relacionadas a um túnel GTP-U, sendo especialmente importante na detecção de tráfego de túnel de uplink.
Instância de rede: identifica uma rede lógica configurada na UPF, como uma instância de rede relacionada à Internet ou ao IMS.
Endereço IP da UE: corresponde o tráfego de acordo com o endereço IP de origem ou de destino da UE, dependendo da direção do pacote.
ID do endpoint de tráfego: identifica um endpoint de tráfego que pode ser usado em cenários compatíveis de otimização de PDI.
Filtro SDF: fornece filtragem mais granular com base em parâmetros como endereços de origem e destino, protocolo, portas e direção do tráfego.
ID da aplicação: pode ser usado para identificação de tráfego no nível da aplicação quando a UPF dispõe da capacidade necessária de detecção de aplicações.
QFI (QoS Flow Identifier): identifica o fluxo de QoS associado ao pacote.
Tipo de interface de origem: fornece informações adicionais sobre a interface 3GPP associada à origem, como N3, N6 ou N9.
Quando vários parâmetros de correspondência estão presentes na PDI, eles definem coletivamente a condição de detecção do pacote. O pacote de entrada deve atender aos critérios aplicáveis antes que a PDR seja considerada correspondente. Isso permite que a SMF crie regras que vão de uma classificação ampla no nível da sessão até uma detecção muito mais específica de fluxos de serviço.
Quão granular pode ser a detecção de tráfego com um filtro SDF?
A interface de origem, o F-TEID e o endereço IP da UE podem ser suficientes para identificar uma sessão ou uma categoria ampla de tráfego, mas nem sempre distinguem fluxos de dados de serviço individuais. Um filtro SDF oferece uma classificação mais granular. Sua Descrição de fluxo pode incluir endereço IP de origem, endereço IP de destino, número do protocolo, porta de origem, porta de destino e direção do tráfego. Esses campos permitem que a UPF diferencie fluxos IP específicos em vez de tratar todos os pacotes associados a uma UE da mesma maneira.
Um filtro SDF também pode transportar informações adicionais de correspondência:
TOS / Classe de tráfego: corresponde ao campo Type of Service do IPv4 ou Traffic Class do IPv6.
Security Parameter Index (SPI): pode ser usado ao corresponder tráfego associado a uma Security Association IPsec.
Flow Label: corresponde ao Flow Label contido em um cabeçalho IPv6.
ID do filtro SDF: identifica o filtro SDF associado para fins de gerenciamento e referência.
Isso cria um modelo de classificação em camadas. Parâmetros PDI como interface, túnel e endereço da UE podem primeiro restringir o tráfego a um contexto específico, enquanto o filtro SDF identifica fluxos IP individuais dentro desse contexto. Quando a identificação de aplicações também é suportada, a UPF pode aplicar um mecanismo adicional de classificação no nível da aplicação, em vez de depender apenas de endereços e portas.
Qual é a diferença entre PDRs de uplink e downlink?
Comparar o tráfego de uplink e downlink é uma das formas mais claras de entender como as PDRs funcionam. As duas direções usam a mesma estrutura geral de regras, mas os pacotes entram na UPF por interfaces diferentes e, portanto, exigem critérios de detecção diferentes.
No tráfego típico de uplink, os pacotes chegam à UPF pelo lado de acesso de rádio. A PDI pode, portanto, usar Interface de origem = Access. A regra também pode usar um F-TEID local para identificar o túnel GTP-U e um Endereço IP da UE para identificar o tráfego da UE. Uma PDR de uplink típica pode, portanto, exigir:
A interface de origem é Access;
o pacote GTP-U de entrada corresponde ao F-TEID especificado, incluindo o TEID e as informações de endereço relevantes;
o endereço IP da UE corresponde ao endereço associado à sessão.
Quando as condições são atendidas, a PDR corresponde. Como o tráfego recebido pela N3 normalmente é encapsulado em GTP-U, Remoção do cabeçalho externo pode instruir a UPF a remover os cabeçalhos externos GTP-U/UDP/IP antes que o pacote seja processado de acordo com a FAR associada.
A detecção de downlink começa na direção oposta. Os pacotes normalmente chegam de uma rede de dados em direção à UPF, portanto a PDI pode usar Interface de origem = Core. Nesse caso, parâmetros como a Instância de rede e o Endereço IP da UE podem ser usados para determinar a qual sessão PDU o pacote pertence. Uma PDR de downlink típica pode, portanto, exigir:
A interface de origem é Core;
a instância de rede corresponde à rede lógica necessária, como “internet” ou “ims”;
o destino do pacote corresponde ao endereço IP da UE associado à sessão.
Depois que a PDR de downlink corresponde, a FAR associada determina como o pacote deve ser encaminhado para o lado de acesso, incluindo o comportamento necessário de encaminhamento por túnel. A diferença entre PDRs de uplink e downlink reflete, portanto, a direção pela qual os pacotes entram na UPF e as informações disponíveis para identificá-los.
Como PDR, FAR, QER e URR trabalham juntas?
Uma PDR resolve o problema de identificação do pacote, mas não representa toda a política de processamento do plano de usuário. O PFCP separa detecção de pacotes, encaminhamento, aplicação de QoS e medição de uso em diferentes tipos de regras. Essa separação permite que cada regra execute uma função específica, mantendo a operação dentro da mesma sessão PFCP.
PDR: Que tráfego é este? (Detecção e classificação)
FAR: O que deve acontecer com ele e para onde deve ir? (Ação de encaminhamento)
QER: Que tratamento de QoS deve ser aplicado? (Aplicação de QoS)
URR: Como seu uso deve ser medido e reportado? (Relatório de uso)
Considere um pacote de uplink que corresponde a uma PDR. Depois que a UPF determina a qual UE e fluxo de serviço o pacote pertence, ela pode remover o cabeçalho externo GTP-U necessário, aplicar o comportamento de encaminhamento referenciado pela FAR, impor a QER aplicável e contabilizar o tráfego de acordo com a URR associada. O resultado da detecção do pacote fornece, portanto, o contexto necessário para todas as operações subsequentes.
Do ponto de vista de engenharia, a PDR não deve ser vista como uma política de encaminhamento isolada. Ela é o ponto de entrada para o conjunto de regras do plano de usuário PFCP. Quando fica clara a relação entre PDR para classificação, PDI para critérios de correspondência e FAR/QER/URR para o processamento subsequente , parâmetros como Interface de origem, F-TEID, endereço IP da UE e filtro SDF tornam-se muito mais fáceis de entender na análise real de sinalização N4 e de pacotes.
FAQ
A Precedence é usada quando a UPF avalia PDRs dentro de uma sessão PFCP. Entretanto, se as condições PDI de duas regras forem totalmente mutuamente exclusivas, as duas PDRs não podem corresponder ao mesmo pacote e sua precedência relativa não altera o resultado final. A Precedence se torna especialmente importante quando as condições das regras se sobrepõem e mais de uma PDR poderia corresponder ao mesmo tráfego.
Se o endereço da UE usado como condição de correspondência PDI mudar, a regra associada a esse endereço também deve refletir as informações atualizadas da sessão. A SMF pode atualizar as informações PDR relevantes por meio de uma modificação de sessão PFCP para que a UPF continue classificando corretamente o tráfego da UE.
Sim. A filtragem SDF não exige que todos os campos possíveis restrinjam o tráfego a uma porta específica. Dependendo da definição da regra, faixas de portas ou condições de correspondência menos restritivas podem ser usadas para cobrir um conjunto maior de tráfego. Máscaras de endereço também podem ser usadas quando a definição de filtro aplicável exigir a correspondência de uma faixa de endereços.
Se um pacote de entrada não puder ser associado a uma PDR aplicável, a UPF não terá uma regra de processamento de pacotes correspondente para esse tráfego dentro do contexto relevante. O tratamento resultante depende das regras PFCP aplicáveis, da implementação da UPF e da configuração da sessão. Na solução de problemas, uma incompatibilidade inesperada de PDR é, portanto, um ponto importante a investigar quando o tráfego chega à UPF, mas não é encaminhado como esperado.
O PFCP oferece suporte a regras predefinidas que já estão provisionadas na função UP e podem ser ativadas quando necessário. Em vez de provisionar repetidamente todos os parâmetros de regra para os cenários aplicáveis, o plano de controle pode ativar a regra predefinida correspondente. Isso pode reduzir a quantidade de sinalização necessária quando os mesmos conjuntos de regras são reutilizados em sessões adequadas.
