Separar o plano de controle e o plano de usuário permite distribuir essas funções em nós diferentes e escalá-las de forma independente. Mas a separação por si só não torna o serviço contínuo: ela apenas cria uma arquitetura na qual a continuidade pode ser garantida.
Para isso, o nó de transporte de dados precisa se tornar substituível, e sua substituição precisa ser uma operação gerenciada que não interrompa as sessões ativas. Essa abordagem arquitetural é chamada de CUPS. Vamos entender por que separar os planos não garante, por si só, a continuidade das sessões, em quais situações essa continuidade pode se romper, como funciona uma transferência gerenciada de sessão e onde essa abordagem encontra seus limites.
Do que é composto o gateway de serviço
Dentro do gateway de serviço há uma divisão em três entidades: os dados de estado do assinante, a lógica de processamento de tráfego e a interface que as conecta.
O plano de controle sabe quem é o assinante e a que ele tem direito. É uma camada em que as mudanças ocorrem com pouca frequência, mas são de importância crítica.
Já o plano de usuário recebe apenas determinada informação por sessão, mas sabe o que está acontecendo com os pacotes. Ele classifica o tráfego de acordo com o serviço, aplica regras já definidas e mantém contadores de consumo para cada serviço. É uma camada de alto desempenho, otimizada para throughput, e não para armazenar conhecimento.
Entre eles permanece uma interface estreita e explícita: o plano de controle envia comandos para baixo, e o plano de usuário devolve relatórios de estado e de consumo.
É justamente por a interface ser estreita que um nó do plano de usuário se torna substituível. Ele não armazena nada permanente — apenas o que pode ser restabelecido por um comando vindo de cima. Se esse nó cair, queimar, for reiniciado ou substituído por um novo, o plano de controle simplesmente reenvia os mesmos comandos, e tudo é restabelecido.
Figura 1 — Entidades do plano de controle e do plano de usuário
Onde a continuidade pode se romper
Poder trocar nós de forma independente ainda não garante que o assinante não perceba a substituição. Um nó de transporte de dados precisa ser retirado de operação não só em caso de falha, mas também de forma planejada: para trabalhos de manutenção ou uma atualização.
A diferença entre esses casos é fundamental. Durante um trabalho técnico, o nó ainda está funcionando, então há tempo para preparar primeiro um substituto e só depois desconectar a origem. Em uma falha, esse tempo não existe. O nó para de responder antes que a rede consiga preparar a transferência das sessões. Parte do estado se perde, e já não é mais possível descartar totalmente uma interrupção.
Daí surge uma regra simples, mas fundamental: enquanto o nó ainda estiver disponível, é preciso transferir a sessão para o novo antes de desconectar o antigo. É exatamente sobre essa regra que se constrói a transferência gerenciada.
Transferência gerenciada: primeiro conectar, depois desconectar
Esse princípio é conhecido em outras áreas como “make before break” (conectar antes de romper). O novo nó é primeiro preparado para atender a sessão, depois o tráfego é transferido para ele, e só então o nó antigo é desconectado. É aqui que se revela o sentido de separar os planos: o plano de controle gerencia por completo a transferência da sessão, enquanto os nós do plano de usuário apenas executam seus comandos.
O estado do assinante fica armazenado no plano de controle. Por isso ele consegue recriá-lo em outro nó, transferindo o perfil, as regras e os serviços permitidos. O novo nó não recebe o estado diretamente do antigo — os nós do plano de usuário não interagem entre si.
É importante notar que a sessão não é simplesmente “jogada” de um nó para outro. Ela é transferida como uma operação sequencial, em etapas, com um ponto de não retorno. Enquanto a sequência não estiver concluída, o sistema sempre mantém um nó pronto para atender a sessão. Por isso, uma substituição planejada não deveria causar queda de conexão.
Figura 2 — Esquema da transferência gerenciada de sessão
E a tarifação?
A continuidade da transferência de dados, por si só, não significa continuidade na contabilização. O assinante pode não perceber a troca de nó, mas se depois surgir uma divergência na cobrança, o problema só está resolvido pela metade. Por isso, durante a transferência, é preciso preservar não só o estado do serviço, mas também as informações de consumo.
Aqui são usados relatórios de ambos os nós. O nó novo recebe um limite: o volume de tráfego que o assinante ainda tem permissão para consumir. Esse limite corresponde ao restante da cota conhecida. Antes de se desconectar, o nó antigo envia ao plano de controle um relatório final do volume efetivamente consumido. O plano de controle soma esses valores e estabelece no nó novo um limite já absoluto.
É importante que o volume não seja reconstruído a partir dos próprios limites. Ele é obtido a partir dos relatórios de consumo real. Isso evita dois problemas:
- a perda de parte do volume consumido;
- a contagem em duplicidade do mesmo volume.
Disso decorre outra consequência: não é necessário encerrar uma sessão de tarifação ativa apenas porque o nó foi substituído. O assinante continuou usando o serviço, e o volume consumido é conhecido com precisão. Portanto, não há motivo para enviar à cobrança uma mensagem de queda.
Com 20 milhões de assinantes e cinco nós de transporte de dados, isso fica especialmente evidente. Se um nó fosse retirado fechando as sessões à força, até 16 milhões de mensagens poderiam ser enviadas à cobrança. Com a transferência gerenciada, essas mensagens não chegam a existir.
Onde a continuidade termina
Todo mecanismo tem limites de aplicabilidade. Uma arquitetura não deve apenas mostrar o que consegue preservar, mas também indicar com honestidade o que não pode ser preservado.
Tradução de endereços NAT
Vale observar que o User Plane do PCEF não conta apenas com a função de DPI, mas também oferece NAT (CG-NAT, NAT64, NAT 1:1).
A tradução de endereços CG-NAT é um mecanismo em que o dispositivo do assinante recebe um endereço IP privado dentro da rede da operadora, enquanto sai para fora sob outro endereço, público. Isso resolve o problema de escassez de endereços e melhora a segurança. Mas a correspondência entre o endereço interno e o externo fica armazenada na memória de um nó específico. Se a sessão for transferida para outro nó, o endereço público e a porta das conexões já estabelecidas vão mudar. Para essas conexões, isso equivale a uma queda.
Por isso, essas conexões não podem ser transferidas de forma contínua. Para elas, usa-se a interrupção natural das sessões vigentes com o estabelecimento de novas sessões de tráfego: uma remoção planejada do nó implica transferir o tráfego de um endereço privado para outro User Plane com um pool diferente de endereços IP públicos.
Existe também outra abordagem: a sincronização de conexões entre NATs. Nesse caso, a tabela de traduções NAT é sincronizada entre vários nós. Mas essa já é uma decisão arquitetural à parte, que também afeta o plano de endereçamento. Por isso, não pode ser tratada simplesmente como uma configuração que elimina automaticamente a limitação.
Balanceamento de tráfego entre vários UPs
O tráfego das sessões é bidirecional: do assinante para o servidor e de volta. Os sentidos de ida e volta são balanceados por mecanismos diferentes.
O tráfego de saída é balanceado por um balanceador L3, com base no IPorigem e no IMSI. O tráfego de entrada é atraído pelo próprio User Plane (DPI+NAT) por meio de anúncios BGP.
Falha do nó
Em caso de falha do User Plane, não há transferência gerenciada: o DPI simplesmente para de responder. Nesse caso, parte do volume consumido pode não chegar ao relatório final. Mas mesmo aqui, o tamanho da possível perda pode ser limitado com antecedência. Ele é determinado pela soma dos limites definidos no nó. O plano de controle pode fracionar as cotas concedidas, definindo limites de relatório menores e coletando os dados intermediários por conta própria. Ainda assim, é enviado à cobrança o valor original da cota, quando o volume acumulado atinge o valor necessário.
Assim surge um orçamento de risco gerenciado. A operadora define com antecedência qual volume é aceitável perder caso um nó falhe. A frequência dos relatórios dos nós é determinada por esse orçamento, enquanto a frequência do envio de informações à cobrança é determinada pelo tamanho da cota. A troca com a cobrança em si não se torna mais frequente por causa disso.
Como verificar a continuidade
A continuidade do serviço não pode ser comprovada pelo simples fato de o sistema não ter enviado uma mensagem de erro. Ela precisa ser medida durante uma transferência real.
O teste só deve ser realizado se houver tráfego real passando pela sessão ativa no momento da transferência. Se aparecer uma interrupção no fluxo, a continuidade não foi garantida, não importa com que precisão o sistema tenha registrado a própria troca. Por isso, o teste de aceitação deve verificar a transferência de dados em si, não a correção das mensagens de sinalização.
O que a separação dos planos entrega, no final
O valor do CUPS não se resume ao escalonamento independente do controle e da transferência de dados. Muito mais importante é que o plano de usuário se torne substituível. E, quando um nó pode ser substituído, é possível transformar sua retirada de um evento de emergência em uma operação gerenciada.
Para trabalhos planejados, isso significa uma sequência clara: preparar o novo nó, transferir as sessões para ele, desconectar o antigo e conferir os contadores. Para as falhas, resta outro mecanismo: um orçamento de perdas aceitáveis definido com antecedência.
É exatamente aqui que surge a continuidade do serviço. A separação permite gerenciar o estado das sessões durante as mudanças de infraestrutura. Assim, a promessa de “manutenção planejada sem impacto para os assinantes” deixa de ser uma formulação genérica e passa a ser um procedimento concreto, com resultado mensurável e exceções claramente definidas.
