# ¿Qué es TR-369, la User Services Platform (USP)? Equipo de ingeniería de Dodderware · Publicado 2026-10-28 · https://blog.dodderware.com/es/que-es-tr-369/ [Read in English](https://blog.dodderware.com/what-is-tr-369/) > **Respuesta corta:** TR-369 es la especificación del Broadband Forum de la User Services Platform (USP), una arquitectura, protocolo y modelo de datos para gestionar, monitorear, diagnosticar y controlar dispositivos conectados. El software del equipo, el Agente, expone su modelo de datos a uno o más Controladores, que intercambian con él mensajes Protocol Buffers por WebSocket, MQTT, STOMP o sockets de dominio UNIX. Usa el mismo modelo de datos Device:2 (TR-181) que TR-069. 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. **Plataforma del operador, app del cliente, servicio de un socio** (Controladores): Leen, configuran y operan el equipo, cada uno con su propio rol. 2. **El canal** (Message Transfer Protocol) - WebSocket - MQTT - STOMP - UNIX Domain Socket 3. **En el equipo** (Agente): Expone sus Service Elements: los Objects, Parameters, Commands y Events de su modelo de datos. *Un Agente, varios Controladores. Cada Controlador llega al Agente por un Message Transfer Protocol y recibe solo los permisos que le da su rol. Diagrama de Dodderware, basado en TR-369 §1.1, §2.1 y §8.* 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](https://blog.dodderware.com/es/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 Protocol**: WebSocket, MQTT, STOMP o UNIX Domain Socket lleva el Record como carga útil. - **USP Record**: Lleva 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 Message**: Exactamente un encabezado y un cuerpo. El cuerpo es un Request, un Response o un Error. (header, body) *Qué envuelve a qué en USP. Diagrama de Dodderware, basado en TR-369 §1.4, §4.1.3 y §7.3.* 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](https://blog.dodderware.com/es/mtp-usp-websocket-mqtt-stomp/). > **¿Sabías que…?** > > El Broadband Forum acuñó “Message Transfer Protocol” a propósito. “Transporte” ya significaba dos cosas distintas para > los ingenieros de redes, así que USP llama MTP al protocolo de capa de aplicación que lleva sus Records (§4). ## ¿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): | Mensaje | Lo envía | Qué hace | | -------------------- | ----------- | ------------------------------------------------------------------------------- | | Get | Controlador | Lee Objects y Parameters del estado actual del Agente | | GetInstances | Controlador | Lista las instancias de los Multi-Instance Objects (tablas) y sus claves únicas | | GetSupportedDM | Controlador | Pregunta qué Objects, Parameters, Commands y Events soporta el Agente | | GetSupportedProtocol | Controlador | Intercambia las versiones de USP que soporta cada lado | | Set | Controlador | Actualiza valores de Parameters | | Add | Controlador | Crea nuevas instancias de Objects | | Delete | Controlador | Elimina instancias de Objects | | Operate | Controlador | Ejecuta un Command, de forma síncrona o asíncrona | | Notify | Agente | Entrega una Notification a un Controlador que se suscribió a un Event | | Register | Agente | Le indica a un Controlador qué Service Elements representa el Agente | | Deregister | Agente | Retira Service Elements que registró antes | 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](https://blog.dodderware.com/es/notificaciones-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](https://blog.dodderware.com/es/tr-069-vs-tr-369/). > **Dónde encaja DWS Support** > > La mayoría de los parques de equipos va a convivir con ambos protocolos durante años. DWS Support gestiona cada equipo por > TR-069 o por TR-369, según el equipo, desde una sola consola: TR-069 a través de GenieACS o de un ACS integrado, y TR-369 > a través de un controlador USP nativo que se conecta a los Agentes por WebSocket. Se desarrolló y probó contra obuspa, el > Agente USP de código abierto del Broadband Forum. > > [Conoce DWS Support](https://dodderware.com/es/productos/dws-support/) ## ¿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](https://blog.dodderware.com/es/seguridad-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](https://blog.dodderware.com/es/actualizacion-firmware-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](https://blog.dodderware.com/es/tr-369-iot-hogar-inteligente/). - **Modularización del software**: servicios del equipo que exponen su propio modelo de datos a través de un USP Broker (Apéndice VI). > **¿Sabías que…?** > > La especificación explica por qué los operadores quieren software modular en sus equipos: les permite acortar los plazos > de versionado del firmware, que suelen ser de 12 a 18 meses, e introducir servicios nuevos a un ritmo mucho más rápido > (Apéndice VI.1). 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](https://blog.dodderware.com/es/descubrimiento-usp-dhcp-mdns/). ## ¿Sabías que…? - USP 1.0 se publicó en abril de 2018. La versión actual, USP 1.5, es de enero de 2026. (TR-369, Issue History) - Un mismo equipo puede responder a varios Controladores. La especificación define al Agente como un Endpoint que expone sus Service Elements a uno o más Controladores. (TR-369 §1.4) - Los mensajes USP siguen un modelo CRUD-ON, crear, leer, actualizar y borrar, más Operate y Notify. (TR-369 §2) - CoAP fue un transporte de USP. Se declaró en desuso en USP 1.2 y quedó obsoleto en USP 1.3. (TR-369 §4.2) - Todo Message y todo Record de USP se codifica con Protocol Buffers versión 3. (TR-369 §5) ## Preguntas frecuentes ### ¿Qué significa USP? USP significa User Services Platform. TR-369 es el número del informe técnico del Broadband Forum que la especifica, por eso “TR-369” y “USP” se usan para hablar del mismo estándar. ### ¿TR-369 reemplaza a TR-069? La especificación no usa la palabra “reemplazar”. Entre los casos de uso de USP incluye la migración sencilla desde CWMP (TR-069), gracias al mismo modelo de datos y las mismas herramientas de modelado, y conserva un mecanismo de CWMP para que los equipos USP y CWMP de una misma LAN se reconozcan. ### ¿Qué transportes usa USP? Los mensajes USP viajan sobre un Message Transfer Protocol (MTP). La especificación actual define bindings para WebSocket, STOMP, MQTT y UNIX Domain Socket. El binding de CoAP está obsoleto. ### ¿Qué modelo de datos usa USP? El Device:2 Data Model, especificado en TR-181 Issue 2, con su esquema y sus reglas definidos en el TR-106 del Broadband Forum. Es la misma familia de modelo de datos que usan los equipos TR-069. ### ¿Puede más de un Controlador gestionar el mismo equipo? Sí. Un Agente expone sus Service Elements a uno o más Controladores, y cada Controlador recibe sus propios permisos mediante los roles que define la sección de autenticación y autorización de la especificación. ### ¿Cuál es la versión más reciente de TR-369? La versión más reciente es USP 1.5, publicada como TR-369 Issue 1 Amendment 5 en enero de 2026. ## Fuentes - Broadband Forum, TR-369 – The User Services Platform, Issue 1 Amendment 5 (USP 1.5), enero de 2026. - Dodderware, documentación de producto e ingeniería de DWS Support. - Issue History: Fechas de publicación, de USP 1.0 (abril de 2018) a USP 1.5 (enero de 2026) - §1.1, §1.2: Resumen ejecutivo, propósito y alcance - §1.4: Definiciones (Agent, Controller, Endpoint, Message, Record, MTP) - §2, §2.1, §2.4: Arquitectura, Endpoints y modelos de datos - §3.4: Uso de DHCP para intercambiar GatewayInfo con equipos CWMP - §4, §4.1.2, §4.2: Message Transfer Protocols, seguridad de los MTP y el binding obsoleto de CoAP - §5: Codificación de los mensajes - §7.3, §7.6.1: Estructura de los mensajes y suscripciones - §1.6, §6.4, §8: Seguridad, intercambio seguro de mensajes, autenticación y autorización - Apéndice VI.1: Modularización del software [Leer la especificación TR-369](https://usp.technology/specification/index.htm) TR-369 © The Broadband Forum. Todos los derechos reservados. Citado brevemente y parafraseado con fines explicativos; los diagramas son de Dodderware. --- **Gestiona equipos TR-069 y TR-369 desde una sola consola.** DWS Support reúne cada ONT y router del hogar en una consola web, hable el protocolo que hable: TR-069 por GenieACS o un ACS integrado, TR-369 por un controlador USP nativo. Se instala en tu propia infraestructura. [Solicita una demo](https://dodderware.com/es/productos/dws-support/#get-started)