Um caso comum de diagnóstico do plano de usuário 5G pode parecer confuso no início: a PDU Session é estabelecida com sucesso, o UE recebe um endereço IP, a PDR corresponde ao tráfego esperado, a FAR contém FORW e os pacotes podem até começar a fluir. Mesmo assim, o usuário ainda enfrenta buffering de vídeo, taxas de download inesperadamente baixas ou tráfego que funciona em apenas uma direção.
Quando isso acontece, verificar somente a PDR e a FAR pode não revelar a causa. O problema pode não estar relacionado a se o tráfego foi identificado ou para onde o pacote foi encaminhado, mas sim a qual política de QoS a UPF aplicou depois que o encaminhamento foi permitido. Dentro da estrutura de regras PFCP na interface N4, a QER (QoS Enforcement Rule, regra de aplicação de QoS) é responsável por aplicar essas políticas de QoS na UPF. Ela pode controlar se o tráfego é permitido, limitar taxas de uplink ou downlink, associar o tráfego a um QoS Flow e aplicar marcações no nível de transporte. Por isso, PDR, FAR e QER precisam ser analisadas em conjunto para compreender todo o comportamento do plano de usuário.
Por que a QER ainda é necessária depois que PDR e FAR já estão funcionando?
A maneira mais simples de entender QER é separar as responsabilidades das diferentes regras da UPF.
A PDR responde primeiro à pergunta “Que tráfego é este?”. Ela usa condições como PDI, endereço IP do UE, F-TEID e SDF Filter para detectar e classificar pacotes. Depois que o tráfego é identificado, a FAR responde à próxima pergunta: “O que deve acontecer com este pacote e para onde ele deve ser encaminhado?”
Mas permitir o encaminhamento de um pacote não significa que ele possa ser encaminhado sem restrições. Se a rede ainda precisa controlar taxa, gating, associação a QoS Flow ou marcação no nível de transporte, a UPF deve aplicar a QER associada.
Assim, uma sequência típica de processamento pode ser simplificada como:
PDR identifica o tráfego → FAR determina a ação de encaminhamento → QER aplica a política de QoS.
Essas regras não substituem umas às outras; elas trabalham juntas. Um pacote pode corresponder corretamente a uma PDR e ser permitido pela FAR, mas ainda estar sujeito a limites de taxa ou condições de gating definidas pela QER. Sem QER, a UPF pode saber que o pacote deve ser encaminhado, mas não teria as mesmas informações de política que descrevem como esse tráfego deve ser tratado do ponto de vista de QoS.
Quando uma QER é instalada e por que ela pode ser atualizada depois?
Uma QER normalmente é provisionada pela SMF na UPF durante PFCP Session Establishment como parte das regras do plano de usuário de uma PDU Session. Ela não é uma regra de QoS criada de forma independente pela UPF depois de observar o tráfego. O plano de controle determina qual comportamento de QoS deve ser aplicado, enquanto a UPF executa a regra resultante.
A QER não precisa permanecer inalterada durante toda a vida útil da sessão. Se a política mudar enquanto o serviço está ativo, a SMF pode atualizar uma QER existente por meio de PFCP Session Modification. Mudanças na política de assinatura, na política da aplicação ou em outras decisões do plano de controle podem resultar em novos limites de taxa, estados de Gate diferentes, alteração da associação com QoS Flow ou outros parâmetros QoS.
Por esse motivo, o diagnóstico não deve parar no Create QER inicial. Se um problema de QoS surgir depois que a sessão já estiver funcionando há algum tempo, as informações posteriores de Update QER também devem ser examinadas e comparadas aos valores originais.
Do ponto de vista do plano de controle, a política QoS utilizada pela SMF pode vir de configuração local ou de informações de política associadas à PCF. Quando a política chega à interface N4, ela é representada como regras PFCP que a UPF consegue aplicar. Dependendo do desenho do serviço, a aplicação de QoS pode ocorrer no nível da PDU Session, do QoS Flow ou em tráfego SDF ou de aplicação mais específico.
Como Gate Status pode bloquear o tráfego mesmo quando a sessão parece normal?
Gate Status é um dos parâmetros mais diretos da QER porque pode mudar imediatamente se o tráfego está autorizado a passar.
Os estados de Gate de uplink e downlink podem ser controlados de forma independente. Quando um Gate está OPEN, o tráfego naquela direção pode continuar. Quando está CLOSED, o tráfego naquela direção é bloqueado pela regra de aplicação de QoS.
Assim, uma sequência típica de diagnóstico pode ser:
A PDU Session foi estabelecida com sucesso;
O UE recebeu um endereço IP;
A PDR corresponde corretamente;
A FAR contém FORW;
Mas o tráfego da aplicação ainda não funciona.
Nesse ponto, devem ser verificados UL Gate e DL Gate na QER associada. Como as duas direções são controladas separadamente, um Gate pode estar OPEN enquanto o outro está CLOSED. O sintoma pode parecer um problema unidirecional do plano de usuário: o UE recebe tráfego de downlink, mas não consegue enviar corretamente tráfego de uplink, ou vice-versa.
É por isso que QER é uma regra de aplicação, e não apenas um atributo descritivo de QoS. Suas configurações podem determinar diretamente se um tráfego específico pode continuar atravessando a UPF.
O que MBR, GBR e Packet Rate controlam?
Gate Status responde à pergunta “O tráfego pode passar?”. Os parâmetros relacionados à taxa respondem a outra pergunta: “Quanto tráfego pode passar e a que velocidade?”. QER pode aplicar limites com base tanto em taxa de bits quanto em taxa de pacotes.
Taxa de bits máxima (MBR)
MBR define a taxa de bits máxima para o tráfego correspondente e pode ser configurado separadamente para uplink e downlink. Em um ambiente 5GC, o limite aplicável pode corresponder a uma restrição no nível da sessão, a um QoS Flow específico ou a um fluxo de tráfego mais específico, dependendo do desenho das regras.
Quando um usuário consegue acessar normalmente o serviço, mas a taxa de transferência para consistentemente perto de um teto repetível, o MBR da QER associada é um dos parâmetros que vale a pena verificar.
MBR é facilmente confundido com capacidade do lado rádio. Boas condições de rádio e largura de banda de transporte suficiente não garantem que a aplicação possa utilizar toda a capacidade física. Se a UPF recebeu instrução para aplicar um MBR mais baixo, a taxa de transferência do plano de usuário continuará sujeita a esse limite. Portanto, o diagnóstico de baixa taxa de transferência deve incluir as regras QoS da N4, e não se concentrar apenas no desempenho rádio.
Taxa de bits garantida (GBR)
GBR descreve a taxa de bits garantida associada ao tráfego que exige um nível definido de garantia de recursos. Ela também pode ser especificada separadamente para uplink e downlink.
GBR pode ser relevante para serviços que precisam de desempenho mais previsível, como determinadas aplicações de voz em tempo real, vídeo ou outros serviços sensíveis a QoS. Ele não deve ser interpretado como um número isolado; o QoS Flow correspondente e a política QoS mais ampla também precisam ser considerados.
Conceitualmente, MBR define o limite superior da taxa permitida, enquanto GBR descreve o requisito de taxa garantida associado à política do serviço.
Taxa de pacotes
Alguns tipos de tráfego não podem ser descritos adequadamente apenas por taxa de bits. QER também pode incluir parâmetros Packet Rate que limitam o número de pacotes permitidos em um período definido.
Isso pode ser importante para cargas que geram muitos pacotes pequenos, como transações DNS, keepalives de IoT ou tráfego semelhante a sinalização. A taxa de bits total pode continuar relativamente baixa enquanto a taxa de pacotes por segundo se torna alta. Nesses casos, verificar apenas MBR pode não explicar o comportamento QoS observado.
Se o limite de Packet Rate for atingido, o usuário pode perceber aumento de latência, respostas mais lentas ou solicitações que falham, mesmo que o consumo total de largura de banda pareça moderado.
O que QFI, Flow Level Marking e PPI fazem em uma QER?
QER é mais do que um limitador de velocidade. Além de Gate Status, MBR e GBR, ela pode carregar parâmetros relacionados à identificação do QoS Flow e ao tratamento de pacotes. Juntos, esses parâmetros ajudam a definir como o tráfego é tratado no plano de usuário.
QoS Flow Identifier (QFI)
QFI identifica um QoS Flow. Uma única PDU Session pode conter vários QoS Flows para que diferentes tipos de tráfego recebam tratamentos QoS diferentes.
Do ponto de vista do plano de usuário, QFI identifica a qual QoS Flow um pacote está associado. Dentro da QER, esse identificador pode ser utilizado para associar o comportamento de aplicação de QoS correspondente ao QoS Flow correto.
Se o QFI associado a uma regra não corresponder ao desenho de serviço pretendido, o tráfego pode ser associado a um QoS Flow inesperado mesmo que os parâmetros de taxa pareçam corretos. Isso pode causar um tratamento de recursos diferente daquele previsto para o serviço.
DL Flow Level Marking
QER pode instruir a UPF a aplicar marcação em nível de fluxo ao tráfego de downlink, por exemplo definindo um valor DSCP para a rede de transporte IP.
Essa marcação não determina a qual QoS Flow 5G o pacote pertence. Em vez disso, afeta como o pacote pode ser identificado e tratado depois que entra na rede de transporte IP.
Se a marcação no nível de transporte estiver incorreta, o QoS 5G pode estar configurado corretamente enquanto a rede de transporte a jusante ainda trata o pacote com uma prioridade não pretendida.
Paging Policy Indicator (PPI)
PPI está relacionado ao tratamento da política de paging para tráfego de downlink. Uma QER pode fornecer informações relacionadas à política de paging nos cenários de encaminhamento aplicáveis, permitindo tratamento diferenciado quando o paging está envolvido.
Para um UE que não está atualmente em estado ativo de plano de usuário, diferentes tipos de tráfego de downlink podem ter implicações de paging diferentes. PPI fornece informações que podem ser utilizadas como parte desse tratamento diferenciado.
Averaging Window
A aplicação de taxa nem sempre pode se basear na observação instantânea de um único pacote. Averaging Window define a janela de tempo sobre a qual o comportamento relacionado à taxa de bits é avaliado.
Uma janela mais curta reage mais rapidamente ao tráfego em rajadas, enquanto uma janela mais longa produz uma média mais suave e pode tolerar rajadas curtas de forma diferente. Esse é um dos motivos pelos quais a análise de QER não deve se concentrar apenas em QER ID e MBR. O comportamento QoS resultante pode depender de vários parâmetros atuando em conjunto.
Como usar mensagens PFCP para verificar se QER está funcionando como esperado?
A forma mais útil de analisar QER não é memorizar cada elemento de informação, mas relacionar a regra PFCP ao sintoma real do serviço.
Por exemplo, um Create QER pode conter:
QER ID = 1;
UL Gate = OPEN;
DL Gate = OPEN;
UL MBR = 100000 kbps;
DL MBR = 150000 kbps.
Esses valores são apenas um exemplo, mas demonstram um ponto importante: um Gate OPEN não significa que não exista nenhuma restrição de QoS. O tráfego pode ser autorizado a passar e ainda continuar sujeito à aplicação de MBR.
Uma sequência prática de diagnóstico pode seguir estes passos:
Identifique primeiro a PDR. Determine qual PDR realmente corresponde ao tráfego afetado. Se a PDR errada for selecionada, a QER esperada não será aplicada corretamente.
Verifique o QER ID referenciado pela PDR. Não inspecione todas as QERs da sessão PFCP sem contexto. Primeiro identifique a QER que está realmente associada ao tráfego analisado.
Revise Create QER e Update QER. Confirme se a regra atualmente efetiva foi alterada por uma PFCP Session Modification posterior. Um problema de QoS pode ser introduzido por uma atualização posterior, e não pela configuração inicial da sessão.
Verifique Gate Status. Verifique separadamente os estados de Gate de uplink e downlink. Um Gate fechado em apenas uma direção pode produzir uma falha de serviço unidirecional.
Verifique MBR, GBR e Packet Rate. Compare os limites configurados com a taxa de transferência observada ou o comportamento dos pacotes, principalmente se o serviço para repetidamente perto de uma taxa fixa.
Verifique QFI e outros parâmetros QoS. Confirme se o QoS Flow pretendido, a marcação e os ajustes relacionados ao paging correspondem ao desenho do serviço.
Compare a regra com o tráfego real do plano de usuário. PFCP mostra o que se espera que a UPF aplique; testes de taxa de transferência e capturas de pacotes mostram o que realmente aconteceu. A diferença entre as duas visões costuma ser a pista mais útil para o diagnóstico.
Esse método é mais confiável do que interpretar um único campo QER isoladamente. A sinalização PFCP mostra o que a UPF deveria aplicar, enquanto os testes do plano de usuário mostram o resultado realmente observado. Comparar essas duas visões é fundamental para determinar se QER está se comportando como esperado.
FAQ
Qual é a principal diferença entre QER e FAR?
FAR determina principalmente como um pacote correspondente deve ser tratado e para onde deve ser encaminhado, incluindo ações como FORW, DROP ou BUFF. QER aplica comportamentos relacionados a QoS, como gating, limites de taxa, associação a QoS Flow e marcação no nível de transporte. Ambas normalmente atuam depois que a PDR identifica o tráfego. Uma forma simples de entender a relação é: FAR determina para onde e como o pacote é encaminhado, enquanto QER determina qual tratamento QoS é aplicado a esse tráfego.
Por que o taxa de transferência do usuário ainda pode ser baixo quando Gate Status está OPEN?
OPEN significa apenas que o tráfego naquela direção pode passar. Isso não remove outras restrições QoS. MBR, GBR, Packet Rate e o QoS Flow associado ainda precisam ser verificados. Se MBR estiver configurado abaixo da capacidade disponível de rádio ou transporte, a taxa de transferência pode continuar limitada mesmo com os dois Gates totalmente abertos.
Uma QER só pode ser criada durante PFCP Session Establishment?
Não. Uma QER pode ser criada durante PFCP Session Establishment e depois modificada por PFCP Session Modification. Se o comportamento QoS mudar depois que a sessão já estiver em funcionamento, os Update QER posteriores devem ser revisados em vez de analisar apenas o Create QER inicial.
QFI e QER são a mesma coisa?
Não. QFI é o identificador de um QoS Flow, enquanto QER é uma regra de aplicação de QoS executada pela UPF. Uma QER pode conter ou referenciar informações QFI para associar um tratamento QoS específico ao QoS Flow correspondente. QFI identifica qual QoS Flow está envolvido; QER define como o controle QoS é aplicado ao tráfego.
Por que o tráfego ainda pode falhar quando a PDR corresponde e a FAR permite encaminhamento?
Porque o processamento do plano de usuário não termina necessariamente na FAR. Depois que o encaminhamento é permitido, a QER associada ainda pode aplicar Gate Status, MBR, GBR, Packet Rate ou outras restrições QoS. Portanto, o diagnóstico deve tratar PDR, FAR e QER como uma cadeia contínua de processamento. Uma incompatibilidade em qualquer etapa pode afetar o resultado final do serviço.
