Remote Access
TR-369 USP para gestão moderna MikroTik
O TR-369 (USP) substitui o TR-069 com mensagens bidirecionais via WebSocket/MQTT — e funciona hoje em MikroTik via pontes de agente e tradutores MQTT.
Resumo O TR-369 (também conhecido como USP, User Services Platform) é o sucessor do TR-069 definido pelo Broadband Forum. Enquanto o TR-069 dependia de HTTP/SOAP baseado em polling, o USP usa canais bidirecionais persistentes sobre WebSocket, MQTT ou CoAP para controle quase em tempo real de roteadores, ONUs, APs Wi-Fi, dispositivos IoT e CPEs em larga escala. O RouterOS ainda não traz um agente USP nativo, mas três padrões práticos — pontes de agente externo, tradutores MQTT e implementações híbridas TR-069+USP — já permitem adotar os benefícios do USP em frotas MikroTik hoje.
O que é TR-369 (USP)?
O TR-369 é o padrão do Broadband Forum criado como sucessor do TR-069 (CWMP). Onde o TR-069 usava HTTP/SOAP com um modelo de polling de request/response, o USP mantém canais bidirecionais persistentes entre Controllers (o plano de gestão) e Agents (rodando no dispositivo ou ao lado dele) para troca de baixa latência de eventos, comandos e telemetria. As opções de transporte são WebSocket, MQTT e CoAP — protocolos leves otimizados para dezenas de milhares de dispositivos por controller. Múltiplos controllers podem gerenciar o mesmo dispositivo simultaneamente, cada um delimitado por permissões.
O impacto prático na operação é significativo. O polling do TR-069 forçava trade-offs entre frescor e carga; o modelo orientado a eventos do USP permite que controllers se inscrevam em mudanças específicas de objetos e reajam imediatamente. O modelo de dados (USP Data Model, baseado no TR-181) representa as capacidades do dispositivo como objetos, então um controller pode se inscrever em WiFi.SignalStrength e receber um push no momento em que o RSSI cair abaixo de um limiar, em vez de fazer polling a cada cinco minutos torcendo para pegar a queda.
Arquitetura central
Os quatro blocos de construção:
- Controller — emite comandos, se inscreve em eventos, armazena o estado dos dispositivos gerenciados.
- Agent — roda no dispositivo ou ao lado dele, implementa o modelo de dados USP, executa os comandos do controller.
- Transport — WebSocket, MQTT ou CoAP para fluxos persistentes de baixa latência.
- Data Model — USP Data Model baseado no TR-181, onde os parâmetros do dispositivo são objetos endereçáveis.
Juntos eles permitem notificações push, inscrições em eventos e gestão verdadeiramente em tempo real — nada disso o modelo de polling do TR-069 conseguia entregar com elegância.
Destaques de segurança
O USP foi projetado para redes hostis e escala operacional, e isso fica visível no seu modelo de segurança:
- TLS 1.3 com autenticação mútua por certificado entre Controller e Agent.
- Permissionamento por objeto e por comando, para que um Agent possa recusar comandos que estejam fora de sua política.
- Audit logging nativo para cada comando e cada mudança de inscrição.
- Sandboxing de operações potencialmente perigosas, reduzindo o raio de impacto de um Controller comprometido.
Esses mecanismos endereçam as classes de risco que assolavam as implantações de TR-069: comandos remotos indesejados a partir de ACS comprometidos, ataques de replay contra payloads não autenticados e a ausência de fronteiras de política finas em um modelo de permissões plano.
Integrando o MikroTik com o TR-369 hoje
O RouterOS ainda não traz um agente USP nativo no momento desta redação. Isso não bloqueia a adoção — três padrões práticos entregam os benefícios do USP em frotas MikroTik sem precisar esperar pelo suporte nativo.
Padrão 1: Agente USP externo / ponte de protocolo
Rode um agente intermediário (container ou VM) que fale USP com o Controller a montante e use a RouterOS API, SSH ou SNMP para gerenciar o MikroTik a jusante:
Controller ↔ Agent (USP) ↔ MikroTik (RouterOS API / SNMP)
Esse é o caminho mais limpo. Não são exigidas mudanças de firmware no RouterOS e você ganha um adaptador centralizado onde mapeamento e sanitização de entrada ficam em um único lugar. O trade-off é um componente extra para implantar e proteger.
Padrão 2: Ponte MQTT (MQTT ↔ RouterOS)
Use MQTT como um barramento de mensagens leve. Uma pequena ponte se inscreve em tópicos e traduz mensagens em comandos RouterOS:
network/mikrotik/<id>/command/rebootnetwork/mikrotik/<id>/telemetry/wifi_rssi
Encaixa-se em ambientes que já usam MQTT — plataformas IoT, barramentos de eventos em nuvem, automação predial. É simples, escala horizontalmente e oferece semântica natural de pub/sub. O trade-off é que o desenho cuidadoso de tópicos e o controle de acesso no broker passam a ser críticos.
Padrão 3: Híbrido TR-069 + USP
Rode os dois protocolos lado a lado: TR-069 para CPE legado sem caminho USP, USP para dispositivos novos e implantações totalmente novas. Uma migração em fases reduz risco e permite validar o USP sob carga antes de assumir o compromisso completo. Para contexto sobre o baseline TR-069, veja nosso guia de gestão TR-069 Intelbras e o guia OMCI Intelbras.
Casos de uso além de roteadores
O USP não é só para roteadores. Ele gerencia qualquer coisa na rede de acesso que exponha um agente USP: ONTs e ONUs, pontos de acesso Wi-Fi 6/7, câmeras IP, set-top boxes, sensores e atuadores IoT. Essa universalidade é o que torna o USP um bloco fundacional para Network-as-a-Service (NaaS) e operações automatizadas — um único Controller pode orquestrar todo o lado do assinante em um edge residencial ou corporativo.
TR-369 vs TR-069 em resumo
| Aspecto | TR-069 | TR-369 (USP) |
|---|---|---|
| Modelo de comunicação | Polling / request-response | Bidirecional, orientado a eventos |
| Transporte | HTTP / SOAP | WebSocket, MQTT, CoAP |
| Segurança | TLS básico | TLS 1.3 + auth mútua + audit nativo |
| Escalabilidade | Limitada (ciclos de polling dominam) | Projetado para dezenas de milhares de dispositivos |
| Multi-controller | Não | Sim |
Boas práticas de migração e implantação
- Comece pequeno. Um Controller, alguns Agents, um subconjunto representativo de dispositivos. Aprenda os modos de falha antes de atingir a frota inteira.
- Use TLS mútuo com certificados de curta duração. Esse é o maior upgrade de segurança em relação ao TR-069 na operação real.
- Centralize logs e construa dashboards de auditoria. O USP entrega a trilha de auditoria; cabe a você dar a ela um lugar onde aterrissar.
- Defina políticas RBAC por Controller e por grupo de dispositivos. Multi-controller é uma feature, mas precisa de escopo intencional.
- Automatize o deploy de Agents via containers ou ferramentas de orquestração. Instalações manuais em escala não sobrevivem ao contato com a realidade.
Não exponha Controllers ou Agents diretamente à internet pública sem proteções em camadas — WAF, VPN ou ACLs de rede. O modelo de segurança do USP é forte, mas pressupõe que você não vai sabotá-lo deliberadamente.
O futuro: automação e telemetria amigável à IA
O modelo de eventos e a granularidade de objetos do USP fazem dele o substrato certo para remediação automatizada e analítica orientada a ML. Controllers podem se inscrever em sinais finos — qualidade de canal Wi-Fi, pressão de CPU, contagens de flap de link — e ajustar canais automaticamente, reiniciar APs problemáticos ou rerrotear tráfego com base em sinais preditivos. Os dados são estruturados, os eventos são em tempo real e o schema é consistente entre fornecedores. Esse é o substrato que a gestão de rede dirigida por IA esperava.
Dê o próximo passo
O USP é um upgrade geracional sobre o TR-069: eventos em vez de polling, segurança moderna e desenho em escala IoT. Mesmo sem suporte nativo no RouterOS, pontes de agente e tradutores MQTT já permitem adotar os benefícios do USP em frotas MikroTik hoje.
Se você prefere não rodar sua própria infraestrutura USP, o NATCloud do MKController oferece acesso remoto centralizado, coleta de eventos e controles que reduzem a necessidade de agentes por dispositivo ou IPs públicos. Para padrões complementares de acesso remoto em MikroTik, veja nosso guia de gestão remota WireGuard e o guia de gestão baseada em VPS.