Neste artigo, vamos analisar cada um deles, mostrar como estimar e limitar as perdas e quais métricas acompanhar para identificar um problema a tempo.
Como funciona a contabilização em um gateway de serviços
Um gateway de serviços é formado por nós de processamento e nós de controle. Vários componentes participam da contabilização de tráfego:
- Nó de processamento (DPI): componente do gateway de serviços no plano de usuário (user plane) pelo qual passa fisicamente o tráfego dos assinantes.
- Nó de controle (PCEF): componente do gateway de serviços no plano de controle (control plane) que envia aos nós de processamento os limiares de cada grupo de contabilização e recebe os relatórios de consumo.
- Billing (OCS): sistema de tarifação externo. Concede cotas de tráfego e recebe os relatórios de consumo.
- PCRF: sistema externo de gerenciamento de políticas. Define a política de serviço do assinante e o conjunto de grupos que o assinante pode usar. Às vezes, o PCRF também desempenha o papel de OCS.
Figura 1. Arquitetura do gateway de serviços
A unidade básica de contabilização é o grupo de contabilização. Ele reúne o tráfego de vários serviços tarifados da mesma forma, e o DPI informa o volume total desses serviços. Por exemplo, um grupo “streaming de vídeo” com os identificadores RG 10 e SI 0 (Rating Group e Service Identifier) pode reunir o tráfego do YouTube e de outros serviços de vídeo.
O DPI classifica os pacotes, atribui-os aos grupos de contabilização e mantém um contador de volume para cada grupo. O PCEF obtém os dados de volume a partir dos relatórios do DPI. Além disso, o PCEF armazena o estado das sessões: créditos concedidos, volume consumido e prazos de validade das cotas.
O PCRF também define os limites de velocidade de cada grupo de contabilização. O OCS concede volumes para cada grupo permitido e recebe os relatórios de consumo.
O ciclo de contabilização começa no PCRF. Ele informa ao PCEF quais grupos de contabilização estão disponíveis para o assinante. O PCEF solicita ao OCS volumes para cada grupo permitido e repassa ao DPI o conjunto de grupos com seus limites e limiares.
Figura 2. O ciclo de contabilização
Quando o consumo de um grupo atinge o limiar, o DPI envia um relatório ao PCEF. O relatório também pode ser enviado antes, se o PCEF solicitar. O PCEF repassa os dados ao OCS ou ao PCRF e recebe em resposta uma nova cota ou um novo conjunto de regras, que então envia ao DPI. Toda a comunicação entre o DPI e o OCS passa pelo PCEF.
O ponto fraco desse ciclo é o intervalo entre relatórios. Até que um relatório chegue, nem o PCEF nem o OCS têm dados sobre o consumo acumulado. Esse consumo existe apenas nos contadores do DPI. Se um nó falhar ou uma sessão for transferida durante um rebalanceamento, o volume não informado se perde. Essa é a causa raiz das perdas de contabilização.
Ponto um: falha do nó de processamento
Quando um nó falha, alguma perda é inevitável, já que o nó não tem tempo de enviar os dados acumulados. Mas o tamanho da perda pode ser calculado antecipadamente:
A fórmula fornece uma estimativa para um nó com carga total. No intervalo entre dois relatórios, esse nó escoa um volume igual à sua capacidade multiplicada pela duração do intervalo. Em média, a falha ocorre no meio desse intervalo, portanto perde-se cerca de metade desse volume.
Veja como fica para um nó com capacidade de 200 Gbps.
| Intervalo médio entre relatórios | Perda na falha do nó |
| 5 minutos | cerca de 3,75 TB |
| 1 minuto | cerca de 750 GB |
| 30 segundos | cerca de 375 GB |
Os números parecem grandes, mas, na escala de um nó, isso não é muito. O prejuízo financeiro final depende da frequência com que os nós falham e de como o tráfego perdido é tarifado.
De acordo com a fórmula, a perda é proporcional ao intervalo entre relatórios. O DPI envia um relatório quando uma sessão consome um volume igual ao limiar. Quanto menor o limiar, mais rápido ele é atingido, mais frequentes são os relatórios e mais curto é o intervalo, o que significa uma perda menor.
O volume não informado de cada sessão nunca ultrapassa o seu limiar. Isso significa que a perda na falha de um nó de processamento nunca ultrapassa a soma dos limiares de todas as sessões desse nó. Assim, as perdas podem ser controladas por meio dos limiares, que por sua vez são definidos pelo nó de controle PCEF.
Por padrão, o PCEF define o limiar igual à cota do OCS. Nesse caso, a soma dos limiares em um nó é igual à cota multiplicada pelo número de sessões. É isso que será perdido no pior cenário se o nó falhar. Para reduzir esse risco, a operadora pode limitar antecipadamente as perdas possíveis.
Orçamento de risco
Para isso, o PCEF da VAS Experts oferece um orçamento de risco: o volume máximo que é aceitável perder em caso de falha de um nó. A operadora pode configurá-lo para o nó como um todo e, separadamente, para cada grupo de serviços. Quando há um orçamento configurado, o PCEF verifica se a cota concedida ao assinante, multiplicada pelo número de sessões que usam esse serviço, não o ultrapassa.
Se o orçamento for ultrapassado, a cota é fracionada: o nó de processamento recebe um limiar de relatório menor. O PCEF soma ele mesmo os relatórios intermediários e envia um relatório ao OCS somente quando toda a cota tiver sido consumida.
Figura 2. Fracionamento da cota para respeitar um orçamento de perda definido
Exemplo de cálculo
O sistema de tarifação concedeu uma cota de 100 MB. Há dois cenários possíveis:
- A cota, considerando o número de sessões, cabe no orçamento de risco. O nó de controle define um limiar de 100 MB. Ao atingir o limiar, o PCEF envia um relatório ao sistema de tarifação e solicita uma nova cota.
- A cota ultrapassa o orçamento de risco. O nó de controle define um limiar de 10 MB, e o nó de processamento envia um relatório intermediário a cada 10 MB. Assim que a soma dos relatórios intermediários chega a 100 MB, o nó de controle envia um relatório ao sistema de tarifação e solicita uma nova cota.
Em vez do orçamento de risco, é possível usar uma opção simplificada. A cota é dividida por um coeficiente fixo ou limitada a um valor constante. A configuração vale para todos os serviços de uma vez ou para cada um separadamente. A opção simplificada não considera o número de sessões. Ela limita a perda por sessão, e não a do nó de processamento como um todo. Sua vantagem é dispensar cálculos, o que a torna um ponto de partida prático para a implantação.
Duas frequências de relatório em vez de uma
Em nossa solução, o fracionamento da cota é feito pelo PCEF. O PCEF envia a configuração aos nós DPI via PFCP. Esse protocolo permite definir para um nó DPI um limiar de relatório menor que a cota. O PCEF determina o tamanho do limiar e o ajusta ao orçamento de risco configurado. Por exemplo, suponha que a operadora definiu que no máximo 100 GB de tráfego não informado do grupo “streaming de vídeo” podem se acumular em um nó. Se apenas um assinante usar o serviço, o PCEF definirá para ele um limiar de 50 GB. Se houver um milhão de assinantes, o DPI enviará relatório de cada sessão aproximadamente a cada 100 KB.
Sem fracionamento, o limiar é igual à cota, então o DPI envia relatórios ao PCEF com a mesma frequência com que o PCEF envia relatórios ao OCS. Com o fracionamento, essas duas frequências são desacopladas e definidas de forma independente.
| Relatórios | O que define a frequência | Resultado |
| Do nó de controle para o sistema de tarifação (do PCEF para o OCS) | A cota concedida pelo sistema de tarifação | A carga sobre o sistema de tarifação não muda |
| Do nó de processamento para o nó de controle (do DPI para o PCEF) | O orçamento de risco | A perda na falha de um nó de processamento não ultrapassa o orçamento de risco |
Sem fracionamento, a operadora precisa escolher. Relatórios frequentes reduzem as perdas em caso de falha, mas sobrecarregam o OCS. Relatórios esparsos aliviam o OCS, mas aumentam as perdas. Com o fracionamento, apenas os relatórios do nó de processamento para o nó de controle ficam mais frequentes. Essa troca acontece dentro do gateway de serviços e custa menos do que a comunicação com o sistema de tarifação.
Três condições para o mecanismo funcionar corretamente
Os relatórios intermediários não são enviados ao sistema de tarifação
Os relatórios intermediários não são repassados ao OCS. O OCS recebe um relatório quando toda a cota é consumida, e também quando a cota expira ou a sessão termina. Os relatórios intermediários multiplicariam a carga sobre o OCS pelo número de partes em que a cota foi dividida, que é justamente o que o fracionamento busca evitar.
A ação por esgotamento da cota é executada somente após o consumo de toda a cota
O sistema de tarifação pode definir uma ação para quando a cota se esgota: bloqueio ou redirecionamento. Um limiar intermediário apenas dispara o envio de um relatório, enquanto a ação é executada quando toda a cota é consumida. Se a ação estivesse vinculada ao limiar intermediário, um assinante com cota de 100 MB seria bloqueado já após 10 MB.
O fracionamento tem um limite inferior
Quanto menor cada parte da cota, mais relatórios há, e se a cota for fracionada demais, a troca interna também se torna uma carga considerável. Por isso o limiar tem um valor mínimo. Se o orçamento de risco não puder ser respeitado nem com esse mínimo, o PCEF gera um alerta: ultrapassar o orçamento sem avisar a operadora não é aceitável.
Ponto dois: rebalanceamento
As perdas durante o rebalanceamento são menos visíveis do que as perdas por falha. Quando a distribuição de assinantes entre os nós é calculada em função da lista de nós ativos, qualquer mudança nessa lista transfere parte das sessões para outros nós. O assinante perde a conexão, e isso é perceptível. Mas o volume acumulado no nó anterior desde o último relatório desaparece junto com a sessão.
O rebalanceamento não é causado apenas por falhas, mas também pela inclusão planejada de um nó DPI, uma operação rotineira para ampliar a capacidade. Ou seja, os dados de contabilização se perdem justamente quando a rede, em tese, está sendo melhorada.
Saiba como crescer sem afetar os assinantes em nosso artigo Escalabilidade no modelo CUPS: como crescer sem afetar os assinantes.
Para que o volume não se perca, a sessão é transferida para o novo nó de forma controlada:
- O PCEF cria uma sessão no nó de destino, transfere os serviços e perfis do assinante e define o limiar com base na cota restante.
- O tráfego do assinante é comutado para o nó de destino.
- O PCEF encerra a sessão no nó de origem, e este envia um relatório final.
- O PCEF soma os volumes contabilizados pelos dois nós e define um novo limiar no nó de destino.
Figura 3. Transferência de uma sessão sem perda de contabilização: soma dos volumes e limiar absoluto no nó de destino
Com esse tipo de transferência, nada se perde. O nó de origem encerra a sessão normalmente e, antes disso, envia todo o volume acumulado. Também não há contabilização em dobro. Cada byte é contabilizado por apenas um dos dois nós, e o novo limiar do nó de destino é definido como um valor absoluto, calculado a partir do consumo total nos dois nós, e não como um acréscimo ao que o nó de destino já contabilizou.
A transferência controlada tem mais uma vantagem. A conexão do assinante não é interrompida, e o consumo é conhecido com precisão. Isso significa que a sessão de tarifação não precisa ser encerrada e reaberta. Com um grande número de sessões, a diferença é significativa. Encerrar e reabrir uma única sessão de tarifação exige quatro mensagens: uma requisição e uma resposta para encerrá-la e uma requisição e uma resposta para abri-la. Se um nó de processamento com quatro milhões de sessões for retirado de operação encerrando e reabrindo as sessões, o sistema de tarifação receberá até dezesseis milhões de mensagens. Com a transferência controlada, não há nenhuma troca com o sistema de tarifação.
Ponto três: troca do nó de controle
O PCEF mantém na memória o estado das sessões de tarifação: cotas concedidas, volumes consumidos, prazos de validade das cotas e números das requisições enviadas ao sistema de tarifação. Com o fracionamento de cotas, os totais acumulados dos relatórios intermediários também ficam armazenados ali. Quando um nó de controle falha, suas sessões são assumidas por outro nó de controle. Sem esse estado, o novo nó não sabe quanto resta da cota nem quando ela expira. Por isso, o estado das sessões é mantido em um armazenamento compartilhado, acessível a todos os nós PCEF. Esse armazenamento precisa atender a dois requisitos.
Os prazos de validade das cotas são armazenados como horário absoluto de expiração, e não como tempo restante
Um registro que diz “a cota é válida por mais 400 segundos” é inútil para um novo nó de controle, porque ele não sabe quando o registro foi criado. Um registro que diz “a cota é válida até 14:32:07” é inequívoco a qualquer momento. Esse requisito pressupõe que os relógios de todos os nós PCEF estejam sincronizados.
O número da requisição ao sistema de tarifação é salvo no armazenamento antes do envio da requisição, e não depois
Cada requisição ao OCS dentro de uma sessão recebe seu próprio número. O OCS descarta como duplicada uma requisição com número já utilizado. Suponha que um nó de controle enviou uma requisição e falhou antes de salvar o número no armazenamento. O novo nó de controle pegará do armazenamento o último número salvo e o reutilizará. O OCS descartará a requisição, nenhuma nova cota será concedida e a sessão ficará sem cota. Para evitar isso, basta salvar primeiro o número da requisição no armazenamento e só depois enviar a requisição. Isso é simples de implementar no código. Muito mais difícil é perceber o erro. Ele ocorre raramente e parece uma falha aleatória que afeta um único assinante.
Ponto quatro: mudança do conjunto de regras durante a sessão
O PCRF pode mudar o conjunto de regras no meio da sessão, por exemplo, na passagem de um plano tarifário diurno para um noturno. O volume contabilizado antes da mudança deve ser tarifado pelas regras antigas. Caso contrário, o tráfego consumido no plano diurno será tarifado pela tarifa noturna.
O mecanismo é simples, mas exige uma ordem rigorosa de etapas:
- O DPI recebe as novas regras do PCEF.
- O DPI envia um relatório sobre o volume acumulado.
- O DPI aplica as novas regras.
- O DPI confirma ao PCEF a mudança de regras.
A confirmação é enviada depois do relatório, então, quando o PCEF fica sabendo da mudança de regras, todo o volume das regras antigas já foi contabilizado.
Entre o envio do relatório e a aplicação das novas regras, existe um intervalo em que a configuração de contabilização não está definida. Durante esse período, deve vigorar uma regra padrão que bloqueia o tráfego do assinante:
Não espere pela conciliação com o billing
Os erros de contabilização não aparecem imediatamente, e ao final do período de faturamento já não é possível rastrear sua causa. Para identificar um problema a tempo, acompanhe estas seis métricas.
| Métrica | O que um aumento significa |
| Diferença entre o número de sessões de tarifação abertas e encerradas | Parte das sessões não é encerrada normalmente, e o consumo final delas não é informado |
| Número de sessões transferidas sem relatório final | Aumenta o número de casos de volume perdido |
| Intervalo médio entre relatórios das sessões ativas | Aumenta o multiplicador da fórmula de perda na falha de um nó de processamento |
| Soma dos limiares de todas as sessões em um nó de processamento | Aumenta o limite superior da perda se esse nó falhar. Aproximar-se do orçamento de risco é motivo para rever o fracionamento das cotas |
| Atraso dos nós em relação às atualizações da tabela de distribuição de sessões | Os nós usam uma tabela de distribuição desatualizada. O tráfego do assinante pode chegar a um nó DPI que já não atende a sessão dele |
| Número de relatórios de um nó de processamento que já não atende a sessão | Aumenta o número de relatórios atrasados |
A última métrica precisa de uma explicação. Quando uma sessão é transferida para outro nó DPI, o nó anterior pode enviar um relatório com atraso. Por exemplo, o relatório foi enviado antes da comutação, mas chegou ao PCEF depois dela. Esse relatório contém tráfego real do assinante que ainda não foi contabilizado em lugar nenhum. Se o PCEF o descartar só porque esse nó já não atende a sessão, o volume será perdido. Ou seja, o gateway de serviços perderá dados de contabilização por conta própria, sem falha alguma. Por isso, os relatórios atrasados devem ser aceitos e somados ao consumo da sessão a que pertencem.
Conclusão
As perdas na contabilização de tráfego ocorrem em quatro situações, e apenas uma delas é inevitável: a falha de um nó de processamento. O nó não tem tempo de enviar o volume acumulado, e esse tráfego fica fora da contabilização. Mas, mesmo nesse caso, a perda pode ser mantida sob controle: seu limite superior é igual à soma dos limiares do nó e, com o orçamento de risco, a operadora decide quanto está disposta a perder. Em nossa solução, o PCEF ajusta sozinho os limiares a esse orçamento, de modo que o limite de perda na falha de qualquer nó é conhecido antecipadamente, e a carga sobre o OCS não aumenta.
Nas outras três situações, as perdas podem ser evitadas se a ordem correta das operações for prevista desde o início:
- no rebalanceamento, as sessões são transferidas para outro nó de processamento de forma controlada;
- os prazos de validade das cotas são armazenados como horário absoluto;
- o número da requisição é salvo antes do envio da requisição;
- o volume acumulado é informado antes da mudança de regras.
Tudo isso é fácil de prever. Já encontrar a causa de uma discrepância depois da conciliação com o billing é quase impossível.
