TR-369, también conocida como Plataforma de Servicios al Usuario(USP), es una norma técnica que describe el protocolo de la capa de aplicación y el modelo de datos para la gestión remota de dispositivos conectados de consumidores y empresas, tanto por parte de proveedores como de usuarios finales. Fácil, ¿verdad? Pues es más fácil decirlo que hacerlo: encontrar una solución que no sólo responda a las necesidades actuales del sector, sino que además se adapte bien a un entorno de brownfield es una tarea ingente.
Es imposible hablar del protocolo TR-369 sin mencionar primero a su predecesor: TR-069. Cuando Broadband Forum presentó el protocolo CPE WAN Management Protocol (CWMP), también llamado TR-069 por el nombre de su especificación técnica, era la solución perfecta para la gestión remota de módems, routers o pasarelas. El caso es que corría el año 2004, así que es muy probable que sólo tuvieras un PC en casa, que no pudieras hacer streaming de películas en Netflix y que tu nevera seguramente no te avisara con antelación de que estás a punto de quedarte sin berzas. Todo esto quiere decir que una conexión bidireccional entre el CPE y el servidor de autoconfiguración (ACS) que caracteriza a TR-069 parecía una solución razonable en aquel momento. Si avanzamos 15 años hacia todo un mundo de dispositivos conectados, puede que CWMP ya no sea suficiente cuando se despliegan servicios que permiten a varios usuarios finales gestionar por su cuenta los dispositivos que se multiplican sin cesar.
En 2018 era claramente el momento de rehacerlo. Teniendo en cuenta el éxito de CWMP, no era de extrañar que el Foro de la Banda Ancha lo utilizara como marco a la hora de crear TR-369, razón por la que a veces se denomina "TR-069 de nueva generación" o "TR-069 para dispositivos IoT". De hecho, la idea era crear un protocolo que permitiera la gestión del ciclo de vida de los dispositivos inteligentes y de IoT, garantizando al mismo tiempo la interoperabilidad entre proveedores. Pero los creadores del protocolo TR-369 no se detuvieron ahí. Está claro que la fuerza de los aparatos inteligentes reside en que son accesibles y manejables por los usuarios finales, lo que tuvo mucho que ver en el proceso de desarrollo. Pero el protocolo también ofrece un valor increíble a los proveedores de servicios. Muchos consideran que la posibilidad de implantar servicios WiFi gestionados, es decir, la gestión externalizada de redes WiFi, en su oferta comercial es una de las principales ventajas de pasarse a TR-369.
La principal diferencia entre los dos protocolos es que en lugar de clientes que se comunican con servidores de autoconfiguración, ahora hay agentes y controladores. Puede parecer un cambio de nomenclatura artificioso, pero en realidad agentes y controladores funcionan con un principio diferente. Mientras que con CWMP sólo hay un ACS por cliente, con el protocolo TR-369 pueden suscribirse a un agente varios controladores con distintas configuraciones de permisos. Esto abre una nueva puerta para que múltiples proveedores, vendedores e incluso usuarios finales interactúen con los dispositivos. Con esta flexibilidad, tanto los proveedores de aplicaciones como los de servicios de red pueden gestionar al mismo tiempo sus respectivos servicios para los mismos dispositivos, lo que fomenta las asociaciones entre proveedores.
A diferencia de su predecesor, TR-369 admite múltiples protocolos de transporte de mensajes (MTP), no sólo HTTP. Entre ellos están Websockets, Constrained Application Protocol (CoAP), Simple Text-Oriented Messaging Protocol (STOMP) y Message Queuing Telemetry Transport (MQTT).
Mientras que con CWMP la conexión entre el cliente y el ACS la inicia siempre el cliente con un propósito específico y se optimiza para que sea lo más corta posible, TR-369 está diseñado para una comunicación directa y siempre abierta. Una vez establecida la conexión en el arranque, las sesiones Websockets o STOMP quedan abiertas indefinidamente y los controladores pueden enviar libremente mensajes a los agentes.
Esta necesidad de capacidad de respuesta exige que TR-369 sea a su vez ligero. De hecho, la cantidad de sobrecarga se ha reducido considerablemente en comparación con su precursor. Por ejemplo, las sesiones abiertas antes mencionadas eliminan la necesidad de repetidas solicitudes de conexión que generaban un montón de handshaking innecesario. Este tipo de mejoras son especialmente importantes para los despliegues de IoT que dependen de un bajo consumo de datos, pero las telecomunicaciones tampoco pueden subestimarlas. Antes, los operadores tenían que sopesar las ventajas de la supervisión frecuente de dispositivos con el impacto que tenía en la red. Como el protocolo TR-369 es tan eficiente, permite una supervisión más frecuente y precisa del dispositivo, lo que garantiza una mejor calidad de servicio para el cliente.
La capa de aplicación de TR-369 se envuelve en un búfer de protocolo antes de encapsularse en cualquier MTP. Los protobufs, como se les denomina abreviadamente, son algo así como XML, pero no son legibles tras la codificación y necesitan un esquema (un archivo .proto) para ser descodificados. La existencia de esquemas facilita la aplicación de la estructura de datos.
Elmensaje USP se envuelve en un registro USP que puede cifrarse con TLS.El mensaje también puede protegerse en la capa MTP: para Websockets con HTTPS, para CoAP - DTLS, y para STOMP - con TLS. Además, la función de intercambio de mensajes de extremo a extremo (E2E) permite establecer un contexto de sesión que garantiza la integridad, la protección y la segmentación de los datos si el mensaje es demasiado grande para su transferencia.
El protocolo TR-369 se basa en gran medida en el modelado de datos, en particular en el modelo de datos Device:2 Root (TR-181) ligeramente modificado, cuya versión 1 se aplicó a TR-069. La especificación TR-181 del Foro de la Banda Ancha lo define como un conjunto de objetos de datos, como "información básica del dispositivo, configuración de la hora del día, configuración de la interfaz de red y la pila de protocolos, gestión de enrutamiento y puentes, estadísticas de rendimiento y pruebas de diagnóstico". Dado que las interfaces de red y los protocolos se consideran objetos, pueden apilarse libremente para adaptarse a la configuración del dispositivo.
TR-369 se diseñó para cubrir un nicho que surgió cuando el panorama de los dispositivos inteligentes empezó a cambiar rápidamente. Sin embargo, el protocolo no estaba pensado para sustituir siempre a su antecesor, ya que sigue habiendo casos de uso en los que es más que suficiente para una implantación, sobre todo si ya existe una arquitectura compatible. A pesar de todo, TR-069 sigue siendo un estándar de referencia con un historial probado de muchos casos de éxito. Sin embargo, si está listo para dar el siguiente paso, debe tener en cuenta que su servidor de autoconfiguración, ya esté en la nube o en sus instalaciones, puede admitir estos dos protocolos simultáneamente.Después de todo, es probable que no vaya a actualizar toda su flota de una sola vez y es muy posible que haya algunos dispositivos que no quiera actualizar en absoluto.Por eso es importante que su plataforma de gestión de dispositivos sea capaz de gestionar tanto TR-069 como TR-369, para que puedan coexistir en su despliegue.
No cabe duda de que hay argumentos a favor de una norma emergente desarrollada en colaboración con expertos del sector por un organismo de normalización bien establecido, como el Foro de la Banda Ancha. Pero hay que tener en cuenta que existen muchas soluciones en el mercado. Y muchas vienen con credenciales similares, como por ejemplo LwM2M, un estándar también desarrollado en respuesta a las necesidades del creciente mundo del IoT. Como siempre, no hay una respuesta clara a la pregunta de cuál es el mejor estándar. Sólo cabe preguntarse: ¿cuál es el mejor para su implantación?