# Agente vs Controlador USP: ¿en qué se diferencian y qué es un Endpoint ID? Equipo de ingeniería de Dodderware · Publicado 2026-10-28 · https://blog.dodderware.com/es/agente-vs-controlador-usp/ [Read in English](https://blog.dodderware.com/usp-agent-vs-controller/) > **Respuesta corta:** En USP (TR-369), el Agente es el Endpoint que expone Service Elements a uno o más Controladores, y el Controlador es el Endpoint que manipula esos Service Elements a través de uno o más Agentes. 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, y el scheme define quién garantiza que el ID sea único. Toda conversación USP tiene dos extremos, y TR-369 le asigna a cada uno un trabajo fijo. Ya sea que operes un NOC o construyas la plataforma que hay detrás, te vas a encontrar con los dos roles, Agente y Controlador, y con el identificador que nombra a cada uno, el Endpoint ID, en los USP Records, en los handshakes de WebSocket y en los certificados. Esta guía explica ambos usando solo lo que dice la especificación. ## ¿En qué se diferencian un Agente y un Controlador USP? En USP, todo lo que envía o recibe un Message es un **Endpoint**, un punto de terminación de un Message (§1.4), y cada Endpoint cumple uno de dos roles (§2.1): - Un **Agente** (Agent) es un Endpoint que expone Service Elements a uno o más Controladores (§1.4). Los Service Elements son los Objects, Sub-Objects, Commands, Events y Parameters que forman una funcionalidad (§2.3). - Un **Controlador** (Controller) es un Endpoint que manipula Service Elements a través de uno o más Agentes (§1.4). Normalmente funciona como interfaz 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). Si vienes de TR-069, la propia especificación hace el paralelo: describe al Auto-Configuration Server (ACS) como el equivalente en CWMP de un Controlador (§7.6.1). La diferencia está en ese “uno o más”. Un Controlador y un Agente tienen una USP Relationship cuando pueden intercambiar mensajes, lo que normalmente significa que el Controlador ya está en la tabla de Controladores del Agente (§1.4), y esa tabla admite más de un Controlador. ## ¿Qué guarda cada lado y qué necesita saber del otro? Los dos roles guardan cosas distintas y necesitan datos distintos del otro: | Pregunta | Agente | Controlador | | --------------------------- | ------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------- | | Qué guarda | Un Instantiated Data Model y un Supported Data Model (§2.1.1) | Puede llevar una base de datos de Agentes, con sus capacidades y estados (§2.1.2) | | Qué necesita saber del otro | El Endpoint ID, las credenciales y el Role autorizado del Controlador, y cómo llegar a él (§3.1) | El Endpoint ID del Agente, la conectividad de sus MTP y las credenciales (§3.2) | | Dónde guarda al otro | El Object `Device.LocalAgent.Controller` de su modelo de datos (§3.1, R-DIS.0) | Su propio registro de Agentes conocidos (§3.2) | | Requests que envía | Notify, Register, Deregister | Get, GetInstances, GetSupportedDM, GetSupportedProtocol, Set, Add, Delete, Operate | Los dos modelos de datos responden preguntas distintas en una llamada de soporte. El **Instantiated Data Model** contiene los Service Elements que el Agente representa en este momento, con su estado (§2.4.1). El **Supported Data Model** contiene lo que el Agente entiende (§2.4.2), y GetSupportedDM le permite al Controlador saber qué entiende un Agente, en lugar de cuál es su estado actual (§7.5.3). El Controlador obtiene el Endpoint ID, los datos de MTP y las credenciales del Agente cuando este se conecta por primera vez (§3.2). Cómo encuentra el Agente a su Controlador se explica en [cómo un Agente USP encuentra a su Controlador](https://blog.dodderware.com/es/descubrimiento-usp-dhcp-mdns/). ## ¿Cómo se arma un Endpoint ID de USP? Cada Endpoint se identifica con un **Endpoint Identifier**, un identificador de la capa USP que es único, a nivel local o global según el scheme con el que se asigna (§2.2). Tiene tres partes: `authority-scheme ":" [authority-id] ":" instance-id` - El **authority-scheme** indica qué tipo de autoridad asigna el ID y define el formato del authority-id (§2.2). - El **authority-id** identifica a esa autoridad. Algunos schemes exigen que vaya vacío, y por eso IDs como `os::00256D-0123456789` llevan dos signos de dos puntos seguidos (§2.2.1). - El **instance-id** nombra al Endpoint. Solo puede usar letras, dígitos, `-`, `.`, `_` y caracteres con codificación porcentual (R-ARC.5), y no puede pasar de 50 caracteres (R-ARC.6). Mejor si es corto, porque los usuarios finales podrían ver los Endpoint IDs (§2.2.2). En un certificado, el ID se escribe como un URN en el espacio de nombres del Broadband Forum: `urn:bbf:usp:id:` seguido de las mismas tres partes. En cualquier otro lugar, por ejemplo en los campos `to_id` y `from_id` de un USP Record, se omite el espacio de nombres (§2.2). ## ¿Qué authority schemes puede usar un Endpoint ID? La especificación define doce schemes (§2.2.1), y el requisito R-ARC.2a hace obligatorias sus reglas: | Scheme | authority-id | instance-id | Ejemplo | | ------- | ------------------------------------------------------- | ---------------------------------------------------- | -------------------------------------------- | | `oui` | Un OUI del IEEE, en 6, 7 o 9 caracteres hexadecimales | Lo define el dueño del OUI, único dentro de ese OUI | `oui:00256D:my-unique-bbf-id-42` | | `cid` | Un CID del IEEE, en 6 caracteres hexadecimales | Lo define el dueño del CID | `cid:3AA3F8:my-unique-usp-id-42` | | `pen` | Un Private Enterprise Number de IANA, en decimal | Lo define el dueño del número | `pen:3561:my-unique-bbf-id-42` | | `self` | Opcional, de 1 a 6 caracteres generados por el Endpoint | Lo genera el Endpoint | `self::my-Agent` | | `user` | De 0 a 6 caracteres | Se asigna desde una interfaz de usuario o de gestión | La especificación no da uno | | `os` | Vacío | OUI, un guion y el número de serie | `os::00256D-0123456789` | | `ops` | Vacío | OUI, product class y número de serie | `ops::00256D-STB-0123456789` | | `uuid` | Vacío | Un UUID | `uuid::f81d4fae-7dec-11d0-a765-00a0c91e6bf6` | | `imei` | Vacío | Un IMEI según la definición de la GSMA | `imei::990000862471854` | | `proto` | De 0 a 6 caracteres, sin punto | Libre; solo para prototipos | `proto::my-Agent` | | `doc` | De 0 a 6 caracteres | Libre; solo para documentación | `doc::agent` (§4.3.2.1) | | `fqdn` | Vacío | Un nombre de dominio completo (FQDN), sin comodines | `fqdn::www.example.org` | El scheme también define quién responde por la unicidad: el dueño del OUI, del CID, del número de empresa o del nombre de dominio (incluido el OUI dentro de `os` y `ops`), el usuario o la máquina que asigna el ID en `user`, y el propio Endpoint en `self` (§2.2.1). Antes de asignar IDs a todo un parque de equipos, revisa tres requisitos más: - **R-ARC.3**: el OUI del Broadband Forum, `00256D`, y su Private Enterprise Number, `3561`, están reservados para la documentación y los prototipos del BBF, y nadie más puede usarlos. Por eso aparecen en los ejemplos de arriba. - **R-ARC.4**: los schemes `proto` y `doc` no se deben usar en entornos de producción. - **R-ARC.4a**: un Endpoint que usa `fqdn` debe presentar certificados TLS con un subjectAltName que permita ese nombre de dominio. > **¿Sabías que…?** > > El Private Enterprise Number del Broadband Forum en IANA, el 3561, figura en el registro de IANA como la entrada del > ADSL Forum (§3.4.2). Ese mismo número identifica las opciones del Broadband Forum cuando un Agente le pide a DHCP los > datos de su Controlador (R-DIS.1). ## ¿Dónde aparece el Endpoint ID durante una sesión? En una conexión WebSocket segura, el Endpoint ID aparece tres veces, en este orden: 1. **En el certificado** (Handshake TLS): El subjectAltName lleva el Endpoint ID en su forma URN. - urn:bbf:usp:id:… 2. **En la solicitud de apertura** (Handshake WebSocket): El cliente ofrece el subprotocolo v1.usp y pone su propio Endpoint ID en el URI de la solicitud. - eid=… 3. **En cada Record** (USP Record): Dos campos obligatorios nombran al Endpoint de destino y al de origen. - to_id - from_id *Dónde aparece un Endpoint ID cuando una sesión USP corre sobre WebSocket con TLS, en orden. Diagrama de Dodderware, basado en TR-369 §2.2, §4.1.3.1, §4.3.2.1 y §8.1.* 1. **En el certificado.** Cuando un certificado X.509 autentica a un Endpoint, su subjectAltName debe llevar la forma URN del Endpoint ID o, en el caso de `fqdn`, el nombre de dominio. Cuando los certificados autentican en la capa del MTP, los Endpoints no deben procesar Records cuyo `from_id` no coincida con el ID del certificado (R-SEC.0a, §8.1). 2. **En el handshake de WebSocket.** No se envía ningún USP Record hasta que termina TLS, así que el servidor no puede saber quién es el cliente sin mirar dentro del certificado (§4.3.2.1). El cliente envía el encabezado `Sec-WebSocket-Protocol` con el valor `v1.usp` (R-WS.9, R-WS.10) y agrega su Endpoint ID al query del URI de la solicitud como `eid` (R-WS.10b). Si el ID lleva un signo de porcentaje, ese signo también se codifica, así que `doc::agent%21` viaja como `doc::agent%2521` (R-WS.10c). 3. **En cada Record.** Cada USP Record lleva el Endpoint ID de destino en `to_id` y el de origen en `from_id`, y ambos campos son obligatorios (§4.1.3.1). Como el otro lado verifica la identidad contra este valor, trata el Endpoint ID como permanente: uno que cambia después de haberse usado también puede causar un comportamiento impredecible (§2.2.1). Los certificados, la confianza y los roles de los Controladores se explican en [seguridad en TR-369](https://blog.dodderware.com/es/seguridad-tr-369/). > **Dónde encaja DWS Support** > > En un despliegue USP, DWS Support cumple el rol de Controlador. Su controlador USP nativo se conecta a los Agentes por > WebSocket y convive con TR-069, a través de GenieACS o de un ACS integrado, así que cada equipo se gestiona por TR-069 o > por TR-369, según el equipo. 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/) ## ¿Un Agente y un Controlador pueden compartir Endpoint ID? Sí, con límites. Un Agente y un Controlador del mismo USP Domain pueden usar el mismo Endpoint ID, y todo Endpoint debe tolerarlo (R-ARC.0, R-ARC.1). Pero los Endpoints que comparten ID no deben comunicarse entre sí por USP (R-ARC.2), y salvo que la autoridad que asignó el ID indique que están relacionados, no se puede suponer ninguna relación entre ellos (§2.2.1). En la modularización del software, compartirlo incluso se recomienda: un USP Service que lleva dentro un Agente y un Controlador debería usar el mismo Endpoint ID para ambos, o el USP Broker no podrá relacionarlos como un solo USP Service (Apéndice VI.2). Lo que USP no te da es una red de seguridad contra duplicados dentro de un mismo rol. No define ningún proceso para identificar o resolver un Endpoint ID que no sea único entre todos los Agentes o entre todos los Controladores, y el resultado es un comportamiento impredecible (§2.2.1). La única regla incorporada es la de `self`: un Endpoint que se encuentra con otro que usa su mismo ID debe cambiar el suyo (§2.2.1). Para el panorama completo, con mensajes, transportes y modelos de datos, empieza por [qué es TR-369](https://blog.dodderware.com/es/que-es-tr-369/). ## ¿Sabías que…? - Un Agente y un Controlador del mismo USP Domain pueden compartir un Endpoint ID, pero los Endpoints que comparten ID nunca deben comunicarse entre sí por USP. (TR-369 §2.2.1 (R-ARC.0, R-ARC.2)) - USP no define ningún proceso para detectar o resolver Endpoint IDs duplicados. Un ID que no es único produce un comportamiento impredecible. (TR-369 §2.2.1) - El OUI 00256D y el Private Enterprise Number 3561 están reservados para la documentación y los prototipos del Broadband Forum, y ninguna otra entidad puede usarlos. (TR-369 §2.2.1 (R-ARC.3)) - El instance-id de un Endpoint ID no puede pasar de 50 caracteres, porque los usuarios finales podrían llegar a verlo. (TR-369 §2.2.2 (R-ARC.6)) - En un certificado, el Endpoint ID se escribe como un URN que empieza por urn:bbf:usp:id:. En cualquier otro lugar se omite el espacio de nombres. (TR-369 §2.2) ## Preguntas frecuentes ### ¿Cuál es la diferencia entre un Agente y un Controlador USP? El Agente expone Service Elements, los Objects, Parameters, Commands y Events de su modelo de datos, a uno o más Controladores. El Controlador manipula esos Service Elements a través de uno o más Agentes. Los Controladores solo envían mensajes a Agentes, y los Agentes envían mensajes a Controladores. ### ¿Qué formato tiene un Endpoint ID de USP? Tres partes separadas por dos puntos, authority-scheme:[authority-id]:instance-id, donde el authority-id puede ir vacío. En un certificado, el mismo ID se escribe como un URN que empieza por urn:bbf:usp:id:. ### ¿Qué significa os:: en un Endpoint ID de USP? os es un authority scheme cuyo authority-id siempre va vacío, por eso el ID lleva dos signos de dos puntos seguidos. Su instance-id es un OUI, un guion y el número de serie, como en os::00256D-0123456789. El scheme ops agrega el product class entre ambos. ### ¿Un equipo USP puede tener más de un Controlador? Sí. La especificación define al Agente como un Endpoint que expone Service Elements a uno o más Controladores, y un Agente que admite la configuración de Controladores por USP los guarda en el Object Device.LocalAgent.Controller de su modelo de datos. ### ¿Puedo usar Endpoint IDs proto:: o doc:: en producción? No. El requisito R-ARC.4 dice que los authority schemes proto y doc no se deben usar en entornos de producción. Existen solo para prototipos y para documentación, como tutoriales y ejemplos. ### ¿Qué caracteres puede llevar un Endpoint ID de USP? El instance-id puede usar letras, dígitos, guion, punto, guion bajo y caracteres con codificación porcentual, y no puede pasar de 50 caracteres. La especificación prefiere valores cortos porque los usuarios finales pueden llegar a verlos. ## 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.4: Definiciones (Agent, Controller, Endpoint, Endpoint Identifier, USP Domain, USP Relationship) - §2.1, §2.1.1, §2.1.2, §2.3: Endpoints, Agentes, Controladores y Service Elements - §2.2, §2.2.1, §2.2.2: Endpoint Identifier, authority schemes (R-ARC.0 a R-ARC.4a) y reglas del instance-id (R-ARC.5, R-ARC.6) - §2.4.1, §2.4.2, §7.5.3: Instantiated y Supported Data Model, GetSupportedDM - §3.1, §3.2, §3.3, §3.4.2: Lo que Agentes y Controladores necesitan saber del otro, el número de empresa del Broadband Forum - §4.1.3.1, §4.3.2, §4.3.2.1: Campos to_id y from_id del Record, handshake de la sesión WebSocket (R-WS.9 a R-WS.10c) - §7.3.3.2, §7.6.1: Tipos de request, y el ACS como equivalente en CWMP de un Controlador - §8.1: Endpoint IDs en certificados (R-SEC.0a) - Apéndice VI.2: USP Brokers y USP Services que llevan dentro un Agente y un Controlador [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)