¿Qué es TR-369, la User Services Platform (USP)?

Si gestionas ONTs, gateways residenciales o sistemas Wi-Fi, te vas a topar una y otra vez con dos números: TR-069 y TR-369. El primero es el protocolo que hoy habla la mayoría de los equipos de cliente en campo. El segundo, TR-369, es la especificación del Broadband Forum de la User Services Platform (USP). Esta guía explica qué define, cómo funciona y dónde se cruza con TR-069, usando solo lo que dice la propia especificación.

¿Qué define exactamente TR-369?

TR-369 describe la arquitectura, el protocolo y el modelo de datos con los que se construye una User Services Platform inteligente (§1.1). Su propósito declarado es amplio: USP está pensado para electrónica de consumo e IoT, redes domésticas y gateways, sistemas Wi-Fi inteligentes, y para desplegar y gestionar otros servicios y aplicaciones de valor agregado (§1.2.1).

La especificación enumera los casos de uso que soporta (§1.1):

• Gestionar dispositivos IoT mediante objetos de modelo de datos reutilizables.
• Permitir que los usuarios interactúen con sus equipos y servicios desde portales de cliente o puntos de control en sus propios dispositivos inteligentes.
• Desplegar y gestionar microservicios en contenedores mediante la modularización del software y aplicaciones habilitadas para USP.
• Permitir que el proveedor de la aplicación y el proveedor del servicio de red gestionen cada uno la parte del servicio de la que es responsable, lo que abre la puerta a alianzas entre proveedores.
• Una experiencia de usuario coherente del móvil al hogar.
• Una migración sencilla desde CWMP (TR-069), gracias al mismo modelo de datos y las mismas herramientas de modelado.

Dentro de ese alcance cubre la arquitectura, cómo interactúan los Controladores con el modelo de datos de un equipo, la estructura de los Records y Messages, los bindings con los transportes que los llevan, el descubrimiento, la seguridad y el cifrado, y un conjunto de extensiones: proxy, gestión de módulos de software, ciclo de vida del firmware, recolección masiva de datos y una teoría de operación para IoT (§1.2.2).

¿Quién habla con quién? Agentes y Controladores

En USP todo es un Endpoint, y cada Endpoint cumple uno de dos roles (§2.1):

• Un Agente (Agent) es, según la definición del §1.4, un Endpoint que expone Service Elements a uno o más Controladores. En la práctica es el software del equipo gestionado. Mantiene un Instantiated Data Model, el estado actual de lo que representa, y un Supported Data Model, lo que es capaz de representar (§2.1.1).
• Un Controlador (Controller) es un Endpoint que manipula Service Elements a través de uno o más Agentes (§1.4). Puede llevar una base de datos de Agentes, con sus capacidades y sus estados, y normalmente está al servicio de una aplicación de usuario o de un motor de políticas (§2.1.2).

La dirección es fija: los Controladores solo envían mensajes a Agentes, y los Agentes envían mensajes a Controladores (§2.1).

1. ControladoresPlataforma del operador, app del cliente, servicio de un socioLeen, configuran y operan el equipo, cada uno con su propio rol.
2. Message Transfer ProtocolEl canal
   • WebSocket
   • MQTT
   • STOMP
   • UNIX Domain Socket
3. AgenteEn el equipoExpone sus Service Elements: los Objects, Parameters, Commands y Events de su modelo de datos.

Ese “uno o más” importa. En TR-069, un equipo reporta a un único servidor de autoconfiguración (ACS). La propia especificación marca la diferencia: como CWMP tiene un solo ACS, el equipo no le notifica al ACS los cambios de valor que el mismo ACS provocó, mientras que en USP el Agente atiende cada suscripción sin importar quién originó el cambio (§7.6.1). Un equipo puede atender al operador, a la app del cliente y a un socio al mismo tiempo, cada uno con sus propios permisos.

Cada Endpoint se identifica con un Endpoint ID de la forma authority-scheme:[authority-id]:instance-id, por ejemplo oui:00256D:my-unique-bbf-id-42 (§2.2). Desarmamos el formato en Agente vs Controlador USP.

¿Cómo viajan los mensajes USP?

USP separa lo que se dice de cómo se transporta. Hay tres capas, una dentro de otra:

Message Transfer ProtocolWebSocket, MQTT, STOMP o UNIX Domain Socket lleva el Record como carga útil.

USP RecordLleva la versión de USP y los Endpoint ID de origen y destino, más metadatos de integridad, protección de la carga y segmentación.

• version
• to_id
• from_id

USP MessageExactamente un encabezado y un cuerpo. El cuerpo es un Request, un Response o un Error.

• header
• body

El Message Transfer Protocol (MTP) es el protocolo que va debajo de USP y lo transporta. El nombre se eligió para evitar confusiones con la palabra “transporte”, que se usa tanto para la capa de aplicación, como WebSocket, como para la capa de transporte del modelo OSI, como TCP (§4). La especificación actual define cuatro MTP: WebSocket, STOMP, MQTT y UNIX Domain Socket. Un quinto, CoAP, se declaró en desuso en USP 1.2 porque solo servía en redes de área local y bajo condiciones muy acotadas, y quedó obsoleto en USP 1.3 (§4.2).

Un Agente y un Controlador pueden soportar más de un MTP, y los Endpoints siempre responden por el mismo MTP por el que llegó el mensaje (§4.1.1). Los Records y Messages se serializan con Protocol Buffers versión 3, con los esquemas usp-record-1-5.proto y usp-msg-1-5.proto (§5). Para ver los cuatro transportes lado a lado, lee transportes USP comparados.

¿Qué mensajes usa USP?

USP se apoya en un modelo CRUD, crear, leer, actualizar y borrar, más un mecanismo de operaciones y otro de notificaciones: CRUD-ON (§2). La especificación define once tipos de request (§7.3.3.2):

Cada request recibe un Response o un Error. Register y Deregister llegaron con USP 1.3, sobre todo para la modularización del software (Issue History). Las notificaciones se explican en notificaciones y suscripciones USP.

¿Qué tiene que ver TR-369 con TR-069?

TR-069 es el CPE WAN Management Protocol (CWMP). La especificación TR-369 incluye entre sus casos de uso la migración sencilla desde CWMP, conocido por su número de documento, TR-069, gracias al mismo modelo de datos y las mismas herramientas de modelado (§1.1). USP soporta el Device:2 Data Model, especificado en TR-181 Issue 2, con el esquema y las reglas de Objects, Parameters, Events y Commands definidos en TR-106 (§2.4).

Así, un ingeniero de soporte que sabe dónde guarda TR-069 la configuración Wi-Fi o WAN de un equipo la va a encontrar bajo las mismas rutas Device. en USP. Lo que cambia es todo lo que rodea al modelo de datos: quién puede hablar con el equipo, cómo viajan los mensajes y cómo se protegen. La especificación incluso conserva un mecanismo de CWMP, el intercambio de GatewayInfo por DHCP, para que un Agente USP y un cliente CWMP de la misma LAN puedan reconocerse (§3.4).

Comparamos ambos lado a lado en TR-069 vs TR-369.

¿Cómo se protege USP?

La especificación trata la seguridad como parte del protocolo, no como un agregado. Como USP conecta componentes que también pueden usar protocolos fuera de su alcance, la seguridad tiene que pensarse de extremo a extremo, y por eso USP trae sus propios mecanismos de seguridad (§1.6.2). Funciona en tres niveles:

• El transporte. Un MTP debe usar transporte seguro cuando los mensajes cruzan fronteras entre redes, y se espera que los MTP que corren sobre TCP implementen al menos TLS 1.2 (§4.1.2).
• De extremo a extremo. El Secure Message Exchange ejecuta TLS dentro de los USP Records, así el mensaje sigue protegido entre los dos Endpoints aunque pase por brokers o proxies (§6.4).
• La autorización. Los Controladores se autentican, y a cada uno se le asignan roles que definen qué puede leer, escribir u operar, y a qué puede suscribirse (§8).

Sobre la privacidad, la especificación indica que USP incluye mecanismos rigurosos de control de acceso y autorización para que los datos solo los usen quienes el usuario habilitó (§1.6.3). Los detalles están en seguridad en TR-369.

¿Qué más cubre la especificación?

Más allá del protocolo central, TR-369 incluye teorías de operación para tareas que los operadores hacen todos los días:

• Gestión del ciclo de vida del firmware: descarga y activación de imágenes de firmware, incluidos los equipos con más de una imagen. Mira actualizaciones de firmware con USP.
• Recolección masiva de datos: reporte periódico de grandes conjuntos de valores del modelo de datos (Anexo A).
• Gestión de módulos de software: instalar, actualizar y quitar software del equipo (Apéndice I).
• Proxy e IoT: Agentes que representan dispositivos a los que se llega por otros protocolos (Apéndices IV y V). Mira qué permite TR-369 en IoT.
• Modularización del software: servicios del equipo que exponen su propio modelo de datos a través de un USP Broker (Apéndice VI).

Y antes de todo esto, un Agente tiene que encontrar a su Controlador. Ese proceso, el descubrimiento por DHCP, DNS o mDNS, se explica en cómo un Agente USP encuentra a su Controlador.