O gerenciamento remoto permite que provedores e fabricantes configurem equipamentos, atualizem firmware, executem diagnósticos e acompanhem indicadores sem intervenção presencial.
Durante mais de duas décadas, o TR-069 consolidou-se como o principal protocolo para essa finalidade. O TR-369, também conhecido como User Services Platform (USP), surgiu como uma evolução desse modelo, utilizando uma arquitetura orientada a mensagens e diferentes protocolos de transporte.
Para avaliar o comportamento dessas tecnologias em escala, realizamos um teste comparativo com 150 mil CPEs simuladas, observando a inicialização dos dispositivos e a coleta periódica de telemetria.
Como o teste foi realizado
Foram montados dois laboratórios com soluções de código aberto:
- TR-069: GenieACS como ACS;
- TR-369: Oktopus como USP Controller e MQTT como transporte;
- Banco de dados: Tanto o GenieACS quanto o Oktopus utilizam o MongoDB
- CPEs: simuladores desenvolvidos internamente;
- Infraestrutura: Intel Core i5-10400 e 32 GB de memória;
- Duração: uma hora por experimento.
Após a inicialização das 150 mil CPEs, um coletor consultou, a cada minuto, os contadores de bytes enviados e recebidos pelas interfaces Ethernet dos dispositivos simulados.
O menor intervalo que permitiu concluir a inicialização de forma estável foi de 10 milissegundos entre CPEs no TR-069 e 1 milissegundo no TR-369. Os dois ambientes concluíram o processo, embora tenham ocorrido falhas transitórias e novas tentativas. No cenário TR-069, o intervalo de Periodic Inform foi configurado em 5 minutos.
Principais resultados
Comparação de desempenho no gerenciamento de 150 mil CPEs,
destacando os ganhos de eficiência proporcionados pelo TR-369.
TR-069 x TR-369
Indicador
TR-069
TR-369
Ganho de Eficiência no TR-369
CPEs inicializadas
150 mil
150 mil
-
Tempo de inicialização
30min 54s
3min 20s
+89%
CPU média durante a telemetria
5,74 núcleos
0,40 núcleo
+93%
Tráfego médio durante a telemetria
179,03 Mbps
21,11 Mbps
+88%
Escrita média em disco
2,45 MiB/s
0,014 MiB/s
+99%
Pico de memória
6,9 GB
16,8 GB
-143%
Inicialização das CPEs
O TR-369 concluiu a inicialização em aproximadamente 3 minutos e 20 segundos, enquanto o TR-069 precisou de mais de meia hora.
Nas condições avaliadas, a combinação de USP, Oktopus e MQTT suportou uma taxa de entrada de dispositivos consideravelmente maior. Com intervalo de 1 milissegundo, o laboratório TR-069 não conseguiu inicializar as 150 mil CPEs dentro do tempo do experimento devido ao alto número de falhas nas sessões CWMP.
Desempenho durante a telemetria
Após todas as CPEs estarem registradas, o backend TR-069 utilizou, em média, mais de 14 vezes a CPU do ambiente TR-369. O tráfego médio foi 88% menor no TR-369, enquanto a escrita em disco caiu 99%.
No TR-069, as operações ocorreram em sessões CWMP, com mensagens SOAP sobre HTTP. No laboratório TR-369, as mensagens USP foram transportadas por MQTT, utilizando conexões persistentes entre as CPEs, o broker e o controlador.
Além disso, o controlador USP consultou os parâmetros diretamente nos dispositivos, sem manter no backend uma cópia equivalente de todos os valores coletados, como ocorreu no ambiente com GenieACS.
Essas diferenças ajudam a explicar a menor sobrecarga observada, mas não são os únicos fatores envolvidos. Banco de dados, persistência, frequência de coleta, implementação do backend e configuração dos simuladores também influenciam os resultados.
Maior consumo de memória
O principal ponto desfavorável ao TR-369 foi o consumo de memória. Durante a telemetria, o ambiente TR-069 atingiu um pico próximo de 6,9 GiB, enquanto o TR-369 chegou a aproximadamente 16,8 GiB.
Esse aumento pode estar relacionado às conexões MQTT persistentes, ao broker, à manutenção do estado das CPEs e às decisões internas da implementação. Como o consumo de cada componente não foi isolado, não é possível atribuir toda a diferença diretamente ao protocolo USP.
O resultado indica, portanto, uma troca entre recursos: o ambiente TR-369 reduziu drasticamente o uso de CPU, rede e disco, mas exigiu mais memória.
O que os resultados indicam
No cenário analisado, o TR-369 apresentou vantagens para operações com grande volume de dispositivos e coleta frequente de informações. A redução de CPU, tráfego e escrita em disco pode diminuir a pressão sobre a infraestrutura e facilitar sua expansão.
O TR-069 apresentou menor consumo de memória e continua sendo uma tecnologia madura, amplamente suportada e adequada para muitas operações de provisionamento e diagnóstico.
Os resultados não tornam uma tecnologia universalmente superior à outra. Eles mostram que a arquitetura TR-369 avaliada foi mais eficiente em grande parte das métricas, mas também trouxe novos requisitos de dimensionamento.
Quando a escala realmente importa
A capacidade de inicializar dispositivos rapidamente é especialmente importante durante interrupções de energia, falhas em equipamentos de rede ou restabelecimentos em massa da conectividade. Nessas situações, milhares de CPEs podem tentar se reconectar, solicitar provisionamento e transmitir informações de diagnóstico em um curto intervalo.
Embora o experimento tenha utilizado intervalos controlados, os resultados demonstram a importância de conhecer a capacidade de entrada de dispositivos de cada ambiente. Para arquitetos de rede e administradores de ACSs e Controladores USP, a questão central é se a infraestrutura conseguiria absorver uma reconexão massiva sem comprometer o gerenciamento da rede.
Mais do que escolher entre TR-069 e TR-369, é fundamental conhecer os limites da implementação, realizar testes de carga e dimensionar a infraestrutura para os momentos de maior demanda.
Conclusão
No cenário avaliado, o TR-369 apresentou inicialização mais rápida e menor consumo de CPU, tráfego de rede e escrita em disco, ao custo de maior uso de memória.
A escolha deve considerar a base instalada, o volume de dispositivos, a frequência das operações e os recursos disponíveis. Em muitos projetos, também pode ser necessário manter TR-069 e TR-369 em paralelo durante uma adoção gradual.
A Venko Networks atua na implementação e implantação de TR-069 e TR-369 em dispositivos embarcados, por meio de SDK própria ou plataformas baseadas em OpenWrt. O trabalho inclui integração com ACS e Controladores USP, adaptação de modelos de dados, testes de carga, validação de interoperabilidade e otimização de desempenho.
Se preferir, fale com um de nossos especialistas clicando aqui, e receba toda orientação necessária no seu projeto.
Fonte: Venko Networks
Imagem: Canva, ChatGPT e Magnific/Montagem
