Um problema comum aparece durante a análise de falhas no plano de usuário do 5G Core: o UE está registrado normalmente, a PDU Session foi estabelecida, o PDR identifica corretamente o tráfego e o FAR encaminha os pacotes pelo caminho esperado, mas os contadores de uso visíveis para a SMF permanecem inalterados. Eventos de tarifação podem não ser acionados, ou o controle de cota pode não responder quando esperado. Em muitos casos, o encaminhamento de pacotes está funcionando corretamente. O que falta é um mecanismo que informe à UPF como medir o uso do plano de usuário e quando reportar o resultado ao plano de controle. Esse mecanismo é a URR (Usage Reporting Rule) na interface N4.

A URR não determina para onde os pacotes devem ser encaminhados e também não impõe diretamente limites de largura de banda. Em vez disso, ela informa à UPF qual tráfego correspondente deve ser medido, como esse uso deve ser medido e em quais condições o resultado da medição deve ser reportado ao plano de controle. Assim, a URR transforma o tráfego do plano de usuário de algo que apenas é encaminhado em algo que também pode ser medido. A UPF realiza a medição de fato, a SMF provisiona as condições de relatório por meio de PFCP e os Usage Reports resultantes formam um ciclo contínuo de feedback entre o plano de usuário e o plano de controle.

Que problema a URR resolve no conjunto de regras da N4?

A forma mais simples de entender a URR é separar sua responsabilidade das responsabilidades de PDR, FAR e QER. Quando a UPF recebe um pacote, o PDR primeiro determina a qual tráfego ele pertence. Depois que o pacote é classificado, o FAR decide como ele deve ser tratado e para onde deve ser encaminhado. O QER aplica o tratamento de QoS necessário. A URR responde a uma pergunta diferente: quanto desse tráfego foi realmente utilizado?

Os principais tipos de regras PFCP podem ser resumidos da seguinte forma:

PDR: Que tráfego é este?
FAR: Como o pacote deve ser tratado e para onde deve ser encaminhado?
QER: Que tratamento de QoS deve ser aplicado a esse tráfego?
URR: Quanto desse tráfego foi utilizado e quando esse uso deve ser reportado?

Uma URR precisa estar associada ao PDR relevante. O motivo é direto: a UPF não consegue medir de forma significativa “quanto um usuário consumiu” sem saber primeiro quais pacotes pertencem àquele UE, serviço ou fluxo de tráfego. Depois que o PDR identifica o tráfego, a URR associada pode medir o uso dos pacotes correspondentes. Se uma PDU Session contiver vários PDRs, URRs diferentes também podem ser usadas para criar relações de medição de uso mais granulares.

Por isso, a primeira pergunta durante a análise de uma URR geralmente não é “A URR foi provisionada?”, mas sim “Qual PDR está correspondendo ao tráfego que está sendo medido e qual URR ID esse PDR referencia?” Se essa associação estiver ausente ou incorreta, as etapas posteriores de medição e relatório não funcionarão como esperado.

Como a URR define o que a UPF mede?

Uma URR é mais do que um simples contador de tráfego. Um dos primeiros elementos definidos em Create URR é o Measurement Method, que informa à UPF que tipo de uso deve ser medido. Dependendo dos requisitos do serviço, a medição pode se basear em volume de tráfego, tempo ou eventos.

Para serviços comuns de dados em pacotes, a medição baseada em volume costuma ser a mais fácil de observar. A UPF pode medir o volume de tráfego de uplink, downlink e total, enquanto os campos relevantes em Volume Measurement indicam quais estatísticas estão incluídas. O volume de tráfego é acumulado em bytes, portanto uma URR pode medir o uso total ou distinguir entre tráfego UL e DL, dependendo da configuração.

Se a capacidade necessária estiver habilitada, a medição também pode incluir a quantidade de pacotes. Por exemplo, o sinalizador MNOP em Measurement Information pode solicitar que a UPF meça o número de pacotes de uplink, downlink e total. Nesse caso, o operador não vê apenas quantos bytes foram transferidos, mas também quantos pacotes foram processados durante o intervalo de medição.

A medição baseada em tempo se concentra na duração do serviço. Dependendo da configuração, pode envolver parâmetros como Time Threshold, Time Quota, Inactivity Detection Time e o mecanismo de medição de tempo aplicável. Já a medição baseada em eventos pode contar eventos específicos de serviço e reportar quando um número definido de eventos tiver ocorrido.

Measurement Method, portanto, responde à pergunta mais fundamental da URR: o que “uso” significa para esta regra? Se isso não for definido primeiro, é fácil confundir Threshold, Quota e Reporting Trigger durante a análise de mensagens PFCP. O método de medição selecionado afeta diretamente o tipo de contador mantido pela UPF, o formato do Usage Report e a forma como a SMF interpreta o resultado.

Reporting Trigger determina quando a UPF deve enviar um relatório

Um método de medição, sozinho, não é suficiente. Se a UPF simplesmente continuar acumulando contadores sem qualquer condição de relatório, a SMF não terá um ponto definido em que deverá receber o resultado. Isso torna os Reporting Triggers outra parte central do mecanismo da URR.

Esses gatilhos podem ser combinados conforme a política da rede. PERIO pode ser usado para relatórios periódicos. VOLTH indica que um relatório deve ser gerado quando um limite de volume for atingido. TIMTH se aplica a um limite de tempo. START e STOPT podem acionar Usage Reports quando a UPF detecta o início ou a parada do tráfego.

Outro grupo de gatilhos está mais relacionado ao controle de cotas. VOLQU está associado a condições de cota de volume, TIMQU a condições de cota de tempo e EVEQU a condições de cota de eventos. Quota Holding Time também pode ser utilizado quando uma cota foi concedida, mas o assinante não gera tráfego do plano de usuário durante um período definido.

É especialmente importante distinguir entre Threshold e Quota, pois eles têm finalidades diferentes no PFCP e são frequentemente confundidos durante a análise de traces:

Um Threshold trata principalmente de quando um resultado de medição deve ser reportado, enquanto uma Quota está mais próxima de quanto recurso ainda permanece disponível para uso. Se um trace PFCP mostrar apenas que VOLTH ou VOLQU está configurado, mas o engenheiro não verificar o parâmetro Threshold ou Quota correspondente, será fácil interpretar incorretamente a lógica real do serviço.

Por exemplo, se VOLTH estiver configurado, mas o Volume Threshold correspondente não estiver corretamente definido, a UPF não terá um limite de tráfego significativo no qual possa acionar o relatório esperado.

Como a UPF envia os resultados de uso para a SMF?

O mecanismo da URR forma um ciclo completo de feedback por meio do procedimento PFCP Session Report. Quando uma condição de relatório definida por uma URR é satisfeita, a UPF não precisa necessariamente esperar que a SMF consulte os contadores. Ela pode enviar uma PFCP Session Report Request à SMF.

Quando Report Type indica que a mensagem contém um Usage Report, a SMF pode identificar o evento como um relatório de uso do usuário. Vários campos são particularmente importantes durante a análise. URR ID identifica qual regra gerou o relatório. UR-SEQN identifica a sequência do Usage Report para aquela URR. Usage Report Trigger explica por que o relatório foi gerado.

Os valores reais de medição aparecem então nos campos correspondentes ao Measurement Method. Para medição baseada em volume, Volume Measurement pode conter valores de uso total, de uplink e de downlink. Para medição baseada em tempo, Duration Measurement passa a ser mais importante. Campos como Start Time, End Time, Time of First Packet e Time of Last Packet também podem ajudar a determinar o intervalo exato de medição coberto pelo relatório.

Receber o Usage Report não necessariamente encerra o processo. Dependendo da lógica do serviço, a SMF pode continuar enviando uma PFCP Session Modification para atualizar a URR, por exemplo, alterando o limite de relatório, atribuindo uma nova cota ou modificando as condições do próximo relatório.

O fluxo completo da URR pode ser resumido assim:

A SMF provisiona a URR → a UPF mede o tráfego correspondente → a condição de Reporting Trigger é atendida → a UPF envia um Usage Report → a SMF processa o resultado de uso → a URR é atualizada, se necessário.

Portanto, o relatório de uso não é simplesmente uma questão de a UPF enviar um contador. Trata-se de um processo dinâmico no qual o plano de controle define a política de medição, o plano de usuário executa a medição e o resultado é continuamente retornado ao plano de controle. Um problema em qualquer etapa pode resultar em valores de uso incorretos ou relatórios ausentes.

Como um Volume Threshold aciona um Usage Report real?

A lógica da URR fica mais fácil de entender quando colocada em um cenário concreto de tráfego. Suponha que a SMF crie uma URR durante PFCP Session Establishment e instrua a UPF a usar medição baseada em volume para o tráfego correspondente a um PDR específico. VOLTH é habilitado como Reporting Trigger.

Se o Volume Threshold for configurado para TOVOL com valor de 10240 bytes, a regra não significa que o usuário pode consumir no máximo 10240 bytes. Em vez disso, significa: quando o volume total medido de uplink e downlink atingir esse limite, a UPF deverá gerar um Usage Report.

À medida que o UE começa a gerar tráfego, a UPF continua encaminhando os pacotes normalmente enquanto também acumula os contadores de uso definidos pela URR. Quando o volume acumulado atinge o limite de relatório, a UPF envia uma PFCP Session Report Request. O Usage Report identifica VOLTH como motivo do gatilho, enquanto Volume Measurement contém o uso total real e os valores aplicáveis de uplink e downlink.

O valor final reportado não precisa parar exatamente em 10240 bytes. A UPF avalia o limite enquanto processa pacotes reais, e um pacote completo pode levar o uso acumulado diretamente de um valor abaixo do limite para outro acima dele. Portanto, ver um valor de Usage Report ligeiramente maior que o Threshold configurado não representa uma contradição.

Isso leva a um princípio importante ao analisar o comportamento da URR: um Threshold é um limite para geração de relatório, não um mecanismo que corta o valor medido em um número exato. Se uma Quota também estiver configurada, o esgotamento da cota poderá acionar comportamentos de controle adicionais, mas isso deve ser analisado como um caminho de controle separado, e não confundido com um simples relatório baseado em limite.

A análise de falhas de URR deve seguir quatro camadas: associação, medição, gatilho e relatório

Problemas de URR podem ser difíceis de perceber porque o próprio serviço do plano de usuário pode parecer completamente normal. O UE consegue acessar a rede, o PDR identifica corretamente o tráfego e o FAR continua encaminhando pacotes, enquanto os contadores de uso vistos nos sistemas de retaguarda permanecem incorretos, nenhum Usage Report é gerado ou o evento esperado no plano de controle nunca ocorre depois que um limite é atingido.

Por esse motivo, a análise de falhas de URR não deve começar com a pergunta “O usuário consegue acessar a rede?”. Ela deve seguir toda a cadeia de medição de uso.

Primeiro, confirme a associação entre PDR e URR

Comece identificando o PDR que realmente corresponde ao tráfego e, em seguida, confirme o URR ID associado a ele. Uma PFCP Session pode conter vários PDRs e várias URRs. Analisar a URR errada não explicará os resultados atuais de uso, mesmo que todos os parâmetros dessa URR pareçam corretos.

Um problema típico é a condição de correspondência do PDR ter mudado enquanto a URR continua associada a um PDR ID anterior. Nesse caso, o próprio alvo da medição se afastou do tráfego real.

Depois, verifique o Measurement Method e a direção

Verifique se a URR está configurada para medição de Volume, Duration ou Event. Se for usada medição baseada em volume, confirme também se a regra mede Total, UL, DL ou a quantidade de pacotes.

Essa etapa é especialmente importante quando as estatísticas de uplink e downlink não correspondem ao esperado. Algumas falhas aparentes ocorrem simplesmente porque a URR mede apenas uma direção enquanto o tráfego de teste flui na direção oposta, deixando o contador esperado inalterado.

Verifique o Reporting Trigger e o Threshold correspondente

Se a UPF não gerar um relatório, confirme qual gatilho o plano de controle realmente solicitou. Configurar VOLTH sem um Volume Threshold adequado, ou esperar relatórios periódicos quando PERIO não está habilitado, pode produzir resultados diferentes do comportamento de serviço pretendido.

Da mesma forma, o relatório baseado em tempo deve ser interpretado em conjunto com os parâmetros de medição temporal e as condições de monitoramento relacionados, em vez de analisar isoladamente um único sinalizador de gatilho.

Por fim, acompanhe o PFCP Session Report

Quando a condição de gatilho for atendida, verifique se a UPF envia o Usage Report esperado. Confira Report Type, URR ID, UR-SEQN e Usage Report Trigger em relação à PFCP Session atual.

Se a UPF já tiver gerado o relatório, mas não surgir nova cota, limite ou ação de controle subsequente, a análise deve se deslocar para a SMF e para a lógica posterior do plano de controle, em vez de permanecer focada no contador da UPF.

Se o problema envolver medição antes ou depois da aplicação de QoS, os sinalizadores relevantes em Measurement Information e Usage Information também devem ser examinados. A URR não representa apenas um número isolado. A janela de tempo da medição, o tráfego que está sendo medido e a etapa de processamento em que a medição ocorre afetam a forma como o valor final de uso deve ser interpretado.

Muitos casos em que “o uso não confere” não são causados por um contador incorreto da UPF, mas por uma diferença entre o escopo real da medição e o escopo de contabilização esperado.

A URR transforma o tráfego do plano de usuário em informação mensurável para o plano de controle

PDR, FAR e QER descrevem principalmente como os pacotes são identificados, encaminhados e submetidos ao tratamento de QoS dentro da UPF. A URR acrescenta outra capacidade essencial: permite que o plano de controle saiba quanto tráfego do plano de usuário foi realmente consumido.

A URR usa Measurement Method para definir o escopo da medição, Reporting Trigger para determinar quando um relatório é necessário e parâmetros como Threshold, Quota e Monitoring Time para controlar diferentes etapas da medição de uso. Quando a condição exigida é atendida, a UPF envia o resultado de volta à SMF em um PFCP Usage Report; depois disso, o plano de controle pode atualizar a URR ou executar outra ação de política, se necessário.

Portanto, a forma mais prática de entender uma URR não é memorizar dezenas de Information Elements, mas acompanhar uma cadeia completa:

O PDR seleciona o tráfego a ser medido → a URR define o método de medição → a UPF mede continuamente o uso → Reporting Trigger determina quando reportar → Usage Report retorna o resultado à SMF → a SMF atualiza a política de controle conforme necessário.

Quando essa cadeia fica clara, parâmetros como Volume Threshold, Volume Quota, Measurement Period, Monitoring Time e os diversos Reporting Triggers deixam de parecer campos PFCP isolados. Eles passam a ser diferentes pontos de controle dentro do mesmo mecanismo de medição e relatório de uso 5G.

Para serviços que exigem tarifação baseada em uso, gerenciamento de cotas em tempo real ou ajuste de políticas de acordo com o consumo, esse mecanismo fornece a base que torna o plano de usuário 5G não apenas capaz de encaminhar tráfego, mas também mensurável e controlável.

Perguntas frequentes