# ¿Qué permite TR-369 (USP) en IoT y servicios para el hogar inteligente? Equipo de ingeniería de Dodderware · Publicado 2026-10-29 · https://blog.dodderware.com/es/tr-369-iot-hogar-inteligente/ [Read in English](https://blog.dodderware.com/tr-369-iot-smart-home/) > **Respuesta corta:** TR-369 se pensó con el IoT en mente. Gestionar dispositivos IoT mediante objetos de modelo de datos reutilizables es el primer caso de uso que enumera. Cualquier equipo se describe con unas pocas capacidades de sensor y de control, y el Agente USP de un gateway puede representar equipos Z-Wave o ZigBee como dispositivos proxy. Con eso, el operador puede ofrecer servicios de hogar, edificio y energía inteligentes. Antes, en una casa había un solo equipo conectado que le importaba al operador. Hoy hay un gateway, varios puntos de acceso y cada vez más sensores, luces, enchufes y termostatos. TR-369 se escribió para esa casa. Su resumen ejecutivo señala que, con teléfonos, tabletas y wearables inteligentes y el Internet de las cosas que está surgiendo, el número de equipos conectados de un hogar crece en varios órdenes de magnitud (§1.1). Esta guía explica qué le da la especificación al operador para gestionar todos esos equipos y qué servicios abre, usando solo lo que dice TR-369. ## ¿Por qué el IoT es parte de TR-369? Porque USP se diseñó pensando en él. TR-369 dice que USP está pensado para electrónica de consumo e IoT, redes domésticas y gateways, sistemas Wi-Fi inteligentes y otros servicios y aplicaciones de valor agregado (§1.2.1). El primer caso de uso que enumera es la gestión de dispositivos IoT mediante objetos de modelo de datos reutilizables (§1.1). Los demás apuntan en la misma dirección: - usuarios que interactúan con sus equipos y servicios desde portales de cliente, o desde puntos de control en sus propios dispositivos inteligentes; - microservicios en contenedores desplegados y gestionados para el usuario final; - el proveedor de la aplicación y el proveedor del servicio de red gestionando cada uno la parte del servicio que le corresponde, lo que hace posibles las alianzas entre proveedores; - una experiencia de usuario coherente del móvil al hogar. El impacto que declara la especificación es igual de directo. USP llega a más equipos conectados, y más nuevos, incluida la gestión de su energía, y habilita directamente aplicaciones de hogar inteligente, edificio inteligente y otras de energía inteligente (§1.6.1). La teoría de operación para el control de IoT llegó con USP 1.1, en octubre de 2019 (Issue History). ## ¿Cómo describe USP miles de equipos distintos? Con unos pocos bloques. Existen miles de equipos IoT diferentes, así que el modelo de datos no define un modelo por producto. Describe cada equipo por lo que puede medir y lo que puede controlar (Apéndice V.1). El modelo de datos Device:2 define objetos de capacidad genéricos, y un conjunto pequeño de ellos cubre un ecosistema enorme de equipos. Cada capacidad es una instancia de `Device.IoTCapability.{i}.`, con un `Class` y un subobjeto de esa clase (Apéndice V.2.1): | Capacidad | Qué hace | Ejemplo en la especificación | | ------------------ | ----------------------------------------------- | ------------------------------------------------------------- | | `BinaryControl` | Fija un valor binario, como encendido o apagado | Un interruptor de luz (V.5.2) | | `LevelControl` | Fija un valor dentro de un rango declarado | Una temperatura objetivo de 14 a 25 °C (V.5.1) | | `EnumControl` | Fija un valor de una lista predefinida | El modo de un termostato: calor, frío, apagado, auto… (V.5.1) | | `BinarySensor` | Lee un estado verdadero o falso | Movimiento detectado, una ventana abierta (V.4.3.1.1) | | `LevelSensor` | Lee un valor en una unidad | El nivel de una batería en porcentaje (V.4.3.2.1) | | `MultiLevelSensor` | Lee varios valores relacionados a la vez | Una ubicación como latitud y longitud (V.4.3.2.3) | | `EnumSensor` | Lee un valor de un conjunto predefinido | Un semáforo: rojo, amarillo o verde (V.4.3.3) | Cada capacidad lleva además un `Type`, un valor predefinido que dice qué representa, como un interruptor, una temperatura o una batería, y las capacidades de nivel llevan una `Unit` (Apéndice V.4.1.1, V.4.1.2). Un equipo formado por varias partes agrupa sus capacidades en objetos Node: en el ventilador de techo de la especificación, un nodo es la luz y el otro es el ventilador (Apéndice V.2.2, V.5.5). > **¿Sabías que…?** > > El modelo de datos IoT es métrico a propósito. Las unidades imperiales se dejaron fuera de forma intencional para > facilitar la interoperabilidad, y el Controlador que las necesite puede convertir los valores métricos con rutinas de > conversión bien definidas (Apéndice V.4.1.2). ## ¿Y los equipos que no hablan USP? La mayoría de los sensores y luces nunca tendrán un Agente USP, y no lo necesitan. La especificación modela los equipos IoT de dos formas (Apéndice V.3): - **Equipos individuales.** Un equipo capaz de tener su propio Agente USP aporta su propio modelo de datos, expone sus capacidades de sensor y de control y se registra ante el Controlador como una entidad individual (V.3.1). El termostato de radiador a batería de la especificación funciona así (V.5.7). - **Equipos a través de proxy.** Un equipo conectado por otro protocolo, como ZigBee, se modela en el modelo de datos del equipo de control que aloja el Agente USP, como una instancia de `Device.ProxiedDevice.{i}.` (V.3.2). Cada instancia de `ProxiedDevice` es un punto de montaje para un hardware distinto. `Device.ProxiedDevice.1.TemperatureStatus.` y `Device.ProxiedDevice.2.TemperatureStatus.` describen sensores de temperatura de dos equipos separados, y un gateway IoT puede usar la tabla para los equipos a los que llega por Z-Wave, ZigBee, Wi-Fi y otras tecnologías (Apéndice III). 1. **Operador o app** (Controlador): Envía mensajes USP al Agente del gateway. 2. **Gateway IoT** (Agente USP): Mantiene una representación USP de cada equipo y traduce a su protocolo propio. 3. **Equipos a través de proxy** (Z-Wave · ZigBee · Wi-Fi) - ProxiedDevice.1: termostato - ProxiedDevice.2: luz - ProxiedDevice.3: regleta *Un gateway IoT que representa equipos que no usan USP. Diagrama de Dodderware, basado en TR-369 Apéndice III, IV.5 y V.3.2.* El gateway de este esquema es lo que el Apéndice IV llama un proxy de USP a protocolos no USP. Mantiene una representación USP de los datos de otro protocolo de gestión o de control, como ZigBee, UPnP DM, NETCONF o RESTCONF, y se presenta ante el Controlador como un Agente completo (Apéndice IV.5). Así ve un Controlador parte del termostato de aire acondicionado sobre Z-Wave de la especificación (Apéndice V.5.1): ``` Device.ProxiedDevice.1.Type = "Thermostat" Device.ProxiedDevice.1.ProxyProtocol = "Z-Wave" Device.ProxiedDevice.1.IoTCapability.1.EnumControl.Value = "Cool" Device.ProxiedDevice.1.IoTCapability.2.LevelControl.Value = 17 Device.ProxiedDevice.1.IoTCapability.6.LevelSensor.Value = 19.5 ``` La temperatura objetivo de frío es un `LevelControl` que declara un mínimo de 14 y un máximo de 25 °C. Las implementaciones tienen que publicar esos límites para que el Controlador sepa qué valores aplican, y un `StepUp()` o un `StepDown()` que los superaría se detiene en el límite en lugar de fallar (Apéndice V.4.2.2, V.5.1). ## ¿Los sensores pueden actuar por su cuenta? Pueden hacer más que informar un valor. Los objetos de sensor agregan umbrales, tiempos y enrutamiento (Apéndice V.4.3, V.4.4): - **Umbrales.** Un `BinarySensor` con `Sensitivity` pasa su valor a verdadero cuando la medición supera el umbral y vuelve a falso cuando baja. El ejemplo de la especificación es una alarma de dióxido de carbono (V.4.3.1.2). Un `LevelSensor` también puede tener umbrales bajo y alto: una batería al 19 % con un umbral bajo de 20 informa `LowLevel` como verdadero (V.4.3.2.2). - **Tiempos.** `HoldTime` mantiene activo un estado disparado durante un tiempo mínimo, y `RestTime` ignora nuevos disparos durante un rato después del primero, lo que calma a un detector de movimiento ante un movimiento continuo (V.4.3.1.3, V.4.3.1.4). - **Bindings.** Un IoTCapability Binding lleva los datos de una capacidad de sensor a una capacidad de control de la clase equivalente, como `BinarySensor` a `BinaryControl` o `LevelSensor` a `LevelControl`. Mientras el binding está habilitado, cada nuevo valor del sensor actualiza el control. La especificación lo llama orquestación del flujo de datos entre sensores y actuadores (V.4.4). 1. **Movimiento detectado** (Sensor): La capacidad de sensor actualiza su Value. 2. **Habilitado** (Binding): Lleva el valor a una capacidad de control de la clase equivalente. 3. **Alarma o luz** (Control): La capacidad de control toma el nuevo valor. *Un sensor que acciona un actuador mediante un IoTCapability Binding. Diagrama de Dodderware, basado en TR-369 Apéndice V.4.4, V.5.8 y V.5.9.* En los ejemplos de la especificación, un sensor de movimiento alimenta un actuador como una alarma o una luz, tanto si el gateway representa al sensor a través de proxy como si el sensor tiene su propio Agente (Apéndice V.5.8, V.5.9). El Controlador que necesite saber cuándo cambia un valor se suscribe a él como a cualquier otro parámetro, como se explica en [notificaciones y suscripciones USP](https://blog.dodderware.com/es/notificaciones-usp/). ## ¿Qué servicios puede construir un operador? Aquí el modelo de datos se convierte en ingresos. Los ejemplos de la propia especificación parecen un catálogo de productos: | Servicio | Qué aporta TR-369 | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Energía inteligente | Una regleta que informa la energía total de la regleta y, para cada toma, un interruptor, la potencia actual en vatios y la energía acumulada en kWh (V.5.6) | | Confort y calefacción | Un termostato de radiador con su propio Agente: modo, temperatura deseada, temperatura para vacaciones, temperatura actual, posición de la válvula y nivel de batería (V.5.7) | | Seguridad y alertas | Sensores con umbral, como una alarma de dióxido de carbono o una batería baja, y bindings que permiten que un sensor accione una alarma (V.4.3, V.4.4) | | Control para el cliente | Portales de cliente o puntos de control en los propios dispositivos inteligentes del usuario, con una experiencia coherente del móvil al hogar (§1.1) | | Servicios con aliados | El proveedor de la aplicación y el proveedor del servicio de red gestionando, diagnosticando y controlando cada uno la parte que le corresponde (§1.1) | | Nuevas apps en el hogar | Módulos de software que se instalan, inician, actualizan y eliminan en el equipo (Apéndice I), y USP Services como un test de velocidad, una vista de la topología de red o un controlador de malla Wi-Fi en la nube (VI.3) | La última fila es la que cambia el ritmo. Los equipos con entornos de ejecución como contenedores Linux o Docker a menudo pueden descargar aplicaciones nuevas, incluso de proveedores de software externos, y USP gestiona su ciclo de vida: instalación, activación, configuración, actualización y eliminación (Apéndice I). La especificación es directa sobre por qué importa: esas aplicaciones pueden aumentar el ingreso por cliente, ayudar a diferenciarse y reducir la pérdida de clientes, siempre que la ganancia no se pierda en costos crecientes de activación y soporte (Apéndice I). Gestionarlas con USP acorta el tiempo de salida al mercado de los servicios y reduce los costos de aprovisionamiento, soporte y mantenimiento (Apéndice I). Y el software modular le permite al operador reducir los plazos de versionado del firmware, “normalmente de 12 a 18 meses” según la especificación, e introducir servicios nuevos mucho más rápido (Apéndice VI.1). ## ¿Y los equipos que duermen? Los equipos a batería no siempre están en línea, y USP lo tiene previsto. El Connectivity Proxy y el MTP Proxy que describe el Apéndice IV pueden guardar en caché los mensajes USP para los Endpoints con conectividad intermitente y entregarlos cuando el Endpoint vuelve a conectarse. Los mensajes no se alteran, así que ningún Endpoint necesita saber que la caché existe (Apéndice IV, IV.1, IV.3). Encontrar los equipos también está cubierto. En el ejemplo de mDNS de la especificación, un Agente se anuncia bajo el subtipo `_iot-device` con el nombre “kitchen light” (luz de la cocina) (§3.7.3). Cómo se encuentran Agentes y Controladores se explica en [cómo encuentra un Agente USP a su Controlador](https://blog.dodderware.com/es/descubrimiento-usp-dhcp-mdns/). > **Dónde encaja DWS Support** > > El controlador TR-369 / USP nativo de DWS Support se conecta a los Agentes por WebSocket y ejecuta Get, Set, Add y > Operate, con los equipos TR-069 en la misma consola. Su vista de equipo incluye una pestaña de IoT / clientes > conectados: cada host de la LAN del cliente, por Wi-Fi, Ethernet o MoCA, con su MAC, su IP y el tiempo que le queda de > concesión DHCP, además de búsqueda, filtros y actualización bajo demanda desde el equipo. > > [Conoce DWS Support](https://dodderware.com/es/productos/dws-support/) ## ¿Quién controla los datos del hogar? Un hogar lleno de sensores es un hogar lleno de datos personales. TR-369 define la privacidad como el derecho a controlar qué información se recoge, procesa y almacena, y quién lo hace, y afirma que USP incluye mecanismos rigurosos de control de acceso y autorización para que los datos solo los usen quienes el usuario haya habilitado (§1.6.3). La seguridad pesa lo mismo: la especificación destaca las aplicaciones inteligentes de alto riesgo, como la medicina o los servicios de emergencia, e incorpora a USP sus propios mecanismos de seguridad (§1.6.2). Cada Controlador, sea del operador o de un aliado, actúa dentro del Rol que le concede el Agente, como se explica en [seguridad en TR-369](https://blog.dodderware.com/es/seguridad-tr-369/). ## ¿Por dónde empieza un operador? Por el gateway. Los equipos a través de proxy viven en el modelo de datos del equipo que aloja el Agente USP (Apéndice V.3.2), y USP usa y amplía el mismo modelo de datos Device:2 que usa TR-069 (§1.1, §1.2.2), así que el camino hacia los servicios IoT puede empezar por un equipo que el operador ya gestiona. Cómo se comparan los dos protocolos, y cómo pasar una flota de uno a otro, está en [TR-069 vs TR-369](https://blog.dodderware.com/es/tr-069-vs-tr-369/). Para lo básico, empieza por [qué es TR-369](https://blog.dodderware.com/es/que-es-tr-369/). ## ¿Sabías que…? - Gestionar dispositivos IoT mediante objetos de modelo de datos reutilizables es el primer caso de uso que TR-369 enumera para USP. (TR-369 §1.1) - USP describe cualquier equipo IoT con un conjunto pequeño de capacidades genéricas, como BinaryControl, LevelControl y LevelSensor, en lugar de un modelo por producto. (TR-369 Apéndice V.1, V.2.1) - Un gateway IoT puede representar los equipos a los que llega por Z-Wave, ZigBee o Wi-Fi como entradas de la tabla Device.ProxiedDevice., cada una con sus propias capacidades. (TR-369 Apéndice III, V.3.2) - El modelo de datos IoT deja fuera a propósito las unidades imperiales. Los valores son métricos, y el Controlador que necesite unidades imperiales las convierte por su cuenta. (TR-369 Apéndice V.4.1.2) - La teoría de operación para el control de IoT llegó con USP 1.1, en octubre de 2019. (TR-369 Issue History) ## Preguntas frecuentes ### ¿TR-369 soporta dispositivos IoT? Sí. La especificación enumera la gestión de dispositivos IoT mediante objetos de modelo de datos reutilizables entre los casos de uso de USP, y su Apéndice V es una teoría de operación para el modelo de datos IoT. Un equipo puede tener su propio Agente USP o estar representado por el Agente de un gateway. ### ¿Cómo gestiona USP un equipo que habla Z-Wave o ZigBee? A través de un proxy. El Agente USP del gateway representa cada equipo como una instancia de Device.ProxiedDevice., con sus capacidades de sensor y de control debajo, y traduce entre USP y el protocolo propio del equipo. Para el Controlador, el equipo es una parte más del modelo de datos del gateway. ### ¿Qué son las capacidades IoT en TR-369? Bloques genéricos de la tabla Device.IoTCapability.. Los controles cambian un valor (BinaryControl, LevelControl, EnumControl) y los sensores leen uno (BinarySensor, LevelSensor, MultiLevelSensor, EnumSensor). Cada uno tiene un Type que dice qué representa, como un interruptor, una temperatura o una batería. ### ¿Un sensor USP puede accionar otro equipo directamente? Sí, con un IoTCapability Binding. Un Binding en una capacidad de sensor apunta a una capacidad de control de la clase equivalente, como BinarySensor a BinaryControl. Mientras está habilitado, cada nuevo valor del sensor pasa al control, así que un sensor de movimiento puede activar una alarma o una luz. ### ¿Qué servicios puede construir un operador sobre el IoT de TR-369? La especificación nombra aplicaciones de hogar, edificio y energía inteligentes, portales de cliente y puntos de control en los propios dispositivos del usuario, y servicios en contenedores instalados como módulos de software. Sus ejemplos incluyen un termostato Z-Wave, una luz regulable y una regleta que mide la potencia de cada toma. ### ¿Quién puede ver los datos de los equipos IoT gestionados con USP? En palabras de la especificación, solo quienes el usuario haya habilitado. USP incluye mecanismos de control de acceso y autorización para eso, y cada Controlador actúa dentro del Rol que le concede el Agente. ## 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. - §1.1, §1.2.1, §1.2.2: Casos de uso, propósito y alcance, incluidos el IoT y el modelo de datos Device:2 - §1.6.1, §1.6.2, §1.6.3: Eficiencia energética, seguridad y privacidad - §3.7.3: Registros DNS-SD del Agente, con el subtipo para dispositivos IoT - Apéndice I: Gestión de módulos de software y los servicios que habilita - Apéndice III: Proxy de dispositivos y la tabla ProxiedDevice - Apéndice IV, IV.1, IV.3, IV.5: Tipos de proxy, caché de mensajes y el proxy de USP a protocolos no USP - Apéndice V: Modelo de datos IoT, capacidades, nodos, umbrales, bindings y ejemplos - Apéndice VI.1, VI.3: Modularización del software y casos de uso de los USP Services - Issue History: USP 1.1 y la teoría de operación para IoT - DWS · Brief de producto: El controlador USP y la pestaña IoT / clientes conectados de DWS Support [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)