O TR-069 é amplamente utilizado por provedores para gerenciar remotamente roteadores, ONTs e outros equipamentos. Por meio dele, é possível alterar configurações, atualizar firmware, executar diagnósticos e coletar informações das CPEs. Porém, um desafio aparece quando o ACS precisa iniciar uma operação em um equipamento localizado atrás de NAT ou CGNAT.
Como mostramos anteriormente no artigo “Como o XMPP torna o TR-069 mais responsivo em redes com NAT e CGNAT” , o XMPP pode ser utilizado como mecanismo complementar ao TR-069. A CPE mantém uma conexão persistente de saída com um servidor XMPP, permitindo que o ACS solicite que ela inicie uma nova sessão TR-069 mesmo quando não é possível alcançá-la diretamente.
O principal benefício, portanto, não é simplesmente desempenho: é capacidade de comunicação. O XMPP cria um caminho pelo qual o ACS pode acionar dispositivos que, de outra forma, estariam inacessíveis para conexões iniciadas pelo servidor. Entretanto, manter dezenas de milhares de conexões persistentes também possui um custo. Para medir esse impacto, comparamos dois ambientes TR-069 com 30 mil CPEs simuladas: um utilizando XMPP e outro operando sem XMPP.
O principal ganho do XMPP: alcançar a CPE
O aumento no consumo de recursos precisa ser analisado junto ao principal benefício oferecido pelo XMPP. Em redes com NAT ou CGNAT, o ACS normalmente não consegue simplesmente abrir uma nova conexão para a CPE. O endereço visível externamente pode pertencer ao equipamento de NAT do provedor e ser compartilhado entre diversos clientes.
O XMPP resolve esse problema utilizando uma conexão iniciada pela própria CPE. Como essa conexão permanece aberta, o ACS pode enviar uma mensagem solicitando que o equipamento inicie imediatamente uma nova sessão TR-069 via XMPP. Isso é especialmente útil em operações iniciadas pela equipe de suporte ou pela própria plataforma, como:
Sem um mecanismo desse tipo, o ACS pode precisar aguardar uma nova sessão iniciada pelo próprio equipamento, o que pode levar horas e inviabilizar um diagnóstico ou atualização num período efetivo. Portanto, o XMPP adiciona ao TR-069 uma capacidade operacional importante: acionar rapidamente uma CPE mesmo quando ela está atrás de NAT ou CGNAT.
Como o teste foi realizado
Foram montados dois cenários, um para o TR-069 com a utilização XMPP e outro sem a utilização do XMPP. Para os experimentos, foi utilizado o GenieACS como ACS e o ejabberd como servidor XMPP, ambas soluções amplamente utilizadas nesse tipo de ambiente.
Os dois cenários foram executados durante uma hora, com 30 mil CPEs.
Foram monitorados principalmente:
Os consumos de CPU e memória foram separados entre TR-069 (GenieACS + MongoDB) e XMPP (ejabberd) e foram utilizados apenas os valores após a inicialização completa das CPEs, representando os recursos para manter as conexões ativas.
Os testes foram realizados em uma única máquina com Ubuntu 24.04, processador Intel Core i5-10400, 32 GB de memória RAM e armazenamento NVMe. O GenieACS, MongoDB, ejabberd e o simulador das CPEs foram executados nesse mesmo servidor.
Principais resultados
| Indicador | Com XMPP | Sem XMPP | Redução sem XMPP |
|---|---|---|---|
| CPU média TR-069 | 1,04 núcleos | 0,921 núcleo | 11,9% |
| Memória média TR-069 | 5,3 GiB | 4,581 GiB | 13,6% |
| CPU média XMPP | 0,08 núcleo | — | — |
| Memória média XMPP | 2,187 GiB | — | — |
| Tráfego médio (RX+TX) | 59,4 Mbps | 49,2 Mbps | 17,2% |
| Tempo de inicialização das CPEs | 324 segundos | 308 segundos | 4,9% |
Após a inicialização das CPEs, o cenário sem XMPP apresentou aproximadamente 11,9% menos utilização média de CPU, 13,6% menos memória e 17,2% menos tráfego de rede.
Custo de infraestrutura
Em média, o cenário com XMPP utilizou 1,04 núcleos de CPU, contra 0,921 núcleos sem XMPP. O consumo de memória total passou de 4,581 GiB para 7,487 GiB, sendo que o servidor XMPP utilizou 2,187 GiB, representando a maior parte desse aumento. Enquanto isso, o tráfego médio agregado aumentou de 49,2 Mbps para 59,4 Mbps.
Parte desse custo está diretamente associada ao servidor XMPP. Após a inicialização das CPEs, o ejabberd utilizou em média cerca de 0,08 núcleo de CPU e 2,187 GiB de memória para manter as conexões XMPP com as CPEs ativas, o que representa cerca de 76 KiB de memória por conexão XMPP/CPE.
Os números ajudam a mostrar o impacto de manter um canal persistente com dezenas de milhares de CPEs simultaneamente. Individualmente, o custo por dispositivo é pequeno, mas em bases maiores passa a influenciar diretamente o dimensionamento de CPU, memória e capacidade de rede do backend.
Inicialização de 30 mil CPEs
Durante a inicialização das CPEs, o comportamento foi um pouco diferente:
| Indicador | Com XMPP | Sem XMPP | Redução sem XMPP |
|---|---|---|---|
| CPU média TR-069 | 4,991 núcleos | 2,885 núcleos | 42,2% |
| Pico de memória TR-069 | 5,111 GiB | 4,896 GiB | 4,2% |
| CPU média XMPP | 1,795 núcleos | — | — |
| Pico de memória XMPP | 2,131 GiB | — | — |
| Tráfego médio (RX+TX) | 201,7 Mbps | 153,8 Mbps | 23,7% |
| Tempo de inicialização das CPEs | 324 segundos | 308 segundos | 4,9% |
O custo adicional também apareceu quando os dispositivos entraram no ambiente. As 30 mil CPEs concluíram a inicialização em aproximadamente:
Apesar do aumento expressivo no uso de CPU durante a entrada simultânea das CPEs, o impacto no tempo total de inicialização foi relativamente pequeno: 324 segundos com XMPP contra 308 segundos sem XMPP, uma diferença de aproximadamente 5%. Esse tipo de comportamento pode ser relevante em situações nas quais muitos equipamentos tentam se conectar simultaneamente, como após interrupções de energia ou conectividade em uma região.
O que os resultados mostram
Nos testes realizados, o XMPP apresentou um custo adicional de infraestrutura mensurável, especialmente em memória, associado principalmente à manutenção das conexões persistentes. Sem ele, o ambiente consumiu aproximadamente 11,9% menos CPU, 13,6% menos memória e 17,2% menos tráfego de rede após a estabilização. Com XMPP, por outro lado, o ACS ganhou a capacidade de acionar CPEs atrás de NAT e CGNAT por meio de um canal persistente, permitindo a execução de operações TR-069 sem a espera de uma sessão CWMP.
A decisão, portanto, não se resume a escolher a opção com menor consumo. O XMPP adiciona uma funcionalidade que pode ser essencial em redes nas quais o ACS precisa executar operações sob demanda em dispositivos que não são diretamente alcançáveis. O custo dessa capacidade aparece no dimensionamento do backend. Em ambientes com dezenas ou centenas de milhares de CPEs, medir esse impacto ajuda a determinar quanta infraestrutura é necessária para obter a responsividade e a capacidade operacional desejadas.
Conclusão
Nos testes com 30 mil CPEs simuladas, o ambiente sem XMPP apresentou consumo um pouco menor de CPU, memória e banda. O ambiente com XMPP exigiu mais recursos, mas permitiu manter um canal persistente com as CPEs. Mais importante que a diferença de desempenho é a funcionalidade adicionada pelo protocolo.
Em redes com NAT e CGNAT, o XMPP fornece ao ACS um mecanismo para solicitar imediatamente uma nova sessão TR-069, mesmo quando não existe um caminho direto até o equipamento. O resultado é um trade-off entre custo de infraestrutura e capacidade operacional. Em larga escala, compreender esse equilíbrio é essencial para dimensionar corretamente uma plataforma de gerenciamento TR-069.
Se preferir, fale com um especialista da Venko clicando aqui e receba suporte para todas as etapas do seu projeto.
Fonte: Venko Networks
Imagem: Canva/OpenAI
