O TR-369, também conhecido como User Services Platform(USP), é um padrão técnico que descreve o protocolo da camada de aplicativos e o modelo de dados para o gerenciamento remoto de dispositivos conectados de consumidores e empresas, tanto por provedores quanto por usuários finais. Fácil, certo? Bem, é mais fácil falar do que fazer - criar uma solução que não apenas atenda às necessidades atuais do setor, mas que também se encaixe bem em um ambiente de área industrial é uma tarefa difícil.
É impossível discutir o protocolo TR-369 sem antes mencionar seu antecessor: TR-069. Quando o Broadband Forum criou o CPE WAN Management Protocol (CWMP), também chamado de TR-069 pelo nome de sua especificação técnica, ele era a solução perfeita para o gerenciamento remoto de modems, roteadores ou gateways. O problema é que o ano era 2004, portanto, é muito provável que você tivesse apenas um PC em casa, não podia fazer streaming de filmes na Netflix e sua geladeira certamente não avisava com antecedência que estava prestes a ficar sem couve. Tudo isso quer dizer que, na época, uma conexão bidirecional entre o CPE e o servidor de autoconfiguração (ACS) que caracteriza o TR-069 parecia uma solução razoável. Avançando 15 anos para um mundo inteiro de dispositivos conectados, pode ser que o CWMP não seja mais suficiente quando se está implantando serviços que permitem que vários usuários finais gerenciem sozinhos os dispositivos que surgem eternamente.
Em 2018, era claramente hora de refazer. Considerando o sucesso do CWMP, não era de surpreender que o Broadband Forum o usasse como estrutura ao criar o TR-369, e é por isso que ele às vezes é chamado de "TR-069 de última geração" ou "TR-069 para dispositivos IoT". De fato, a ideia era criar um protocolo que permitisse o gerenciamento do ciclo de vida de dispositivos inteligentes e de IoT e, ao mesmo tempo, garantisse a interoperabilidade entre os provedores. Mas os criadores do protocolo TR-369 não pararam por aí. Claramente, a força dos aparelhos inteligentes está no fato de serem acessíveis e gerenciáveis pelos usuários finais, o que pesou muito no processo de desenvolvimento. Mas o protocolo também oferece um valor incrível para os provedores de serviços. Muitos consideram a capacidade de implementar serviços WiFi gerenciados, ou seja, gerenciamento de rede WiFi terceirizado, em sua oferta comercial como um dos principais benefícios da mudança para o TR-369.
A principal diferença entre os dois protocolos é que, em vez de clientes que se comunicam com servidores de configuração automática, agora você tem agentes e controladores. Isso pode parecer uma mudança de nomenclatura, mas, na verdade, os agentes e controladores operam com base em um princípio diferente. Enquanto no CWMP há apenas um ACS por cliente, no protocolo TR-369 vários controladores com diferentes configurações de permissão podem ser inscritos em um agente. Isso abre uma nova porta para que vários provedores, fornecedores e até mesmo usuários finais interajam com os dispositivos. Com essa flexibilidade, os provedores de serviços de rede e de aplicativos podem gerenciar seus respectivos serviços para os mesmos dispositivos ao mesmo tempo, o que promove parcerias com os provedores.
Diferentemente de seu antecessor, o TR-369 oferece suporte a vários protocolos de transporte de mensagens (MTPs), não apenas ao HTTP. Esses protocolos incluem Websockets, CoAP (Constrained Application Protocol), STOMP (Simple Text-Oriented Messaging Protocol) e MQTT (Message Queuing Telemetry Transport).
Enquanto no CWMP a conexão entre o cliente e o ACS é sempre iniciada pelo cliente para uma finalidade específica e otimizada para ser a mais curta possível, o TR-369 foi projetado para uma comunicação direta e sempre ativa. Depois que a conexão é estabelecida na inicialização, as sessões Websockets ou STOMP ficam abertas indefinidamente e os controladores podem enviar mensagens livremente aos agentes.
Essa necessidade de ser ágil exige que o TR-369 seja leve em troca. A quantidade de sobrecarga foi, de fato, significativamente reduzida em comparação com seu precursor. Por exemplo, as sessões abertas mencionadas acima eliminaram a necessidade de solicitações de conexão repetidas que geravam muito handshaking desnecessário. Melhorias como essa são particularmente importantes para implementações de IoT que dependem de baixo consumo de dados, mas também não podem ser subestimadas pelas empresas de telecomunicações. Anteriormente, as operadoras precisavam equilibrar os ganhos do monitoramento frequente de dispositivos com o impacto que isso causava na rede. Como o protocolo TR-369 é muito eficiente, ele permite um monitoramento mais frequente e preciso do dispositivo, garantindo efetivamente uma melhor qualidade de serviço para o cliente.
A camada de aplicativo no TR-369 é envolvida em um buffer de protocolo antes de ser encapsulada em qualquer MTP. Os protobufs, como são chamados abreviadamente, são semelhantes ao XML, mas não são legíveis por humanos após a codificação e precisam de um esquema (um arquivo .proto) para serem decodificados. A existência de esquemas facilita a aplicação da estrutura de dados.
A mensagem USP é envolvida em um registro USP que pode ser criptografado com TLS.A mensagem também pode ser protegida na camada MTP: para Websockets com HTTPS, para CoAP - DTLS e para STOMP - com TLS. Além disso, o recurso de troca de mensagens de ponta a ponta (E2E) possibilita o estabelecimento de um contexto de sessão que garante a integridade, a proteção e a segmentação dos dados se a mensagem for muito grande para ser transferida.
O protocolo TR-369 depende muito da modelagem de dados, em particular do modelo de dados Device:2 Root (TR-181) ligeiramente modificado, cuja versão 1 foi aplicada ao TR-069. A especificação TR-181 do Broadband Forum o define como um conjunto de objetos de dados, como "informações básicas do dispositivo, configuração da hora do dia, configuração da interface de rede e da pilha de protocolos, gerenciamento de roteamento e bridging, estatísticas de rendimento e testes de diagnóstico". Como as interfaces de rede e os protocolos são considerados objetos, eles podem ser empilhados livremente para corresponder à configuração do dispositivo.
O TR-369 foi projetado para preencher um nicho que surgiu quando o cenário dos dispositivos inteligentes começou a mudar rapidamente. No entanto, o protocolo não foi projetado para sempre substituir seu antecessor, pois ainda há casos de uso em que ele é mais do que suficiente para uma implementação, especialmente se já houver uma arquitetura compatível em vigor. Apesar de tudo, o TR-069 continua sendo um padrão de referência com um histórico comprovado de muitas histórias de sucesso. No entanto, se você estiver pronto para dar o próximo passo, deve estar ciente de que seu servidor de configuração automática, seja na nuvem ou no local, pode oferecer suporte a esses dois protocolos simultaneamente.Afinal, você provavelmente não atualizará toda a sua frota de uma só vez e é bem possível que haja alguns dispositivos que você não queira que sejam atualizados. Por isso, é importante que sua plataforma de gerenciamento de dispositivos seja capaz de lidar com o TR-069 e o TR-369, para que eles possam coexistir em sua implementação.
Certamente, há um argumento a favor de um padrão emergente desenvolvido em conjunto com especialistas do setor por um órgão de padrões bem estabelecido, como o Broadband Forum. No entanto, lembre-se de que há muitas soluções no mercado a serem consideradas. E muitas vêm com credenciais semelhantes, como, por exemplo, o LwM2M, um padrão também desenvolvido em resposta às necessidades do crescente mundo da IoT. Como sempre, não há uma resposta clara para a pergunta sobre qual padrão é o melhor. Você só pode perguntar: qual é o melhor para sua implementação?