# USP Agent vs Controller: what is the difference, and what is an Endpoint ID? Dodderware engineering team · Published 2026-10-28 · https://blog.dodderware.com/usp-agent-vs-controller/ [Leer en español](https://blog.dodderware.com/es/agente-vs-controlador-usp/) > **Short answer:** In USP (TR-369), an Agent is the Endpoint that exposes Service Elements to one or more Controllers, and a Controller is the Endpoint that manipulates those Service Elements through one or more Agents. Each Endpoint is named by an Endpoint ID built as authority-scheme:[authority-id]:instance-id, such as oui:00256D:my-unique-bbf-id-42, where the scheme decides who guarantees that the ID is unique. Every USP exchange has two ends, and TR-369 gives each one a fixed job. Whether you run a NOC or build the platform behind it, you will meet both roles, Agent and Controller, and the identifier that names each of them, the Endpoint ID, in USP Records, WebSocket handshakes and certificates. This guide explains both, using only what the specification says. ## What is the difference between a USP Agent and a Controller? In USP, anything that sends or receives a Message is an **Endpoint**, “a termination point for a Message” (§1.4), and every Endpoint acts as one of two roles (§2.1): - An **Agent** “is an Endpoint that exposes Service Elements to one or more Controllers” (§1.4). Service Elements are the Objects, Sub-Objects, Commands, Events and Parameters that make up a piece of functionality (§2.3). - A **Controller** “is an Endpoint that manipulates Service Elements through one or more Agents” (§1.4). It usually acts as the interface to a user application or a policy engine (§2.1.2). The direction is fixed: “Controllers only send messages to Agents, and Agents send messages to Controllers” (§2.1). If you come from TR-069, the specification draws the parallel itself: it calls the Auto-Configuration Server “the CWMP equivalent of a Controller” (§7.6.1). The difference is the “one or more”. A Controller and an Agent have a USP Relationship when they can exchange messages, which usually means the Controller has been added to the Agent’s Controller table (§1.4), and that table can hold more than one Controller. ## What does each side hold and need to know? The two roles keep different things and need different facts about each other: | Question | Agent | Controller | | --------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | What it holds | An Instantiated Data Model and a Supported Data Model (§2.1.1) | Possibly a database of Agents, their capabilities and their states (§2.1.2) | | What it must know about the other | The Controller’s Endpoint ID, credentials and authorized Role, and how to reach it (§3.1) | The Agent’s Endpoint ID, connectivity for the Agent’s MTPs, and credentials (§3.2) | | Where it keeps the other | The `Device.LocalAgent.Controller` Object of its data model (§3.1, R-DIS.0) | Its own record of known Agents (§3.2) | | Requests it sends | Notify, Register, Deregister | Get, GetInstances, GetSupportedDM, GetSupportedProtocol, Set, Add, Delete, Operate | The two data models answer different questions on a support call. The **Instantiated Data Model** holds the Service Elements the Agent represents right now, with their state (§2.4.1). The **Supported Data Model** holds what the Agent understands (§2.4.2), and GetSupportedDM lets a Controller learn “what an Agent understands, rather than its current state” (§7.5.3). A Controller acquires the Agent’s Endpoint ID, MTP details and credentials when the Agent first connects (§3.2). How the Agent finds its Controller in the first place is covered in [how a USP Agent finds its Controller](https://blog.dodderware.com/usp-discovery-dhcp-mdns/). ## How is a USP Endpoint ID built? Every Endpoint is named by an **Endpoint Identifier**, a USP-layer identifier that is unique, locally or globally depending on the scheme used to assign it (§2.2). It has three parts: `authority-scheme ":" [authority-id] ":" instance-id` - The **authority-scheme** says which kind of authority assigns the ID, and it dictates the format of the authority-id (§2.2). - The **authority-id** identifies that authority. Some schemes require it to be empty, which is why IDs such as `os::00256D-0123456789` contain a double colon (§2.2.1). - The **instance-id** names the Endpoint itself. It may use only letters, digits, `-`, `.`, `_` and percent-encoded characters (R-ARC.5), and it may be no more than 50 characters long (R-ARC.6). Shorter is better, “as end users could be exposed to Endpoint IDs” (§2.2.2). In a certificate the ID is written as a URN in the Broadband Forum namespace, `urn:bbf:usp:id:` followed by the same three parts. Everywhere else, for example in the `to_id` and `from_id` fields of a USP Record, the namespace is left out (§2.2). ## Which authority schemes can an Endpoint ID use? The specification defines twelve schemes (§2.2.1), and requirement R-ARC.2a makes their rules mandatory: | Scheme | authority-id | instance-id | Example | | ------- | ------------------------------------------------ | ----------------------------------------------- | -------------------------------------------- | | `oui` | An IEEE OUI, in 6, 7 or 9 hex characters | Set by the OUI owner, unique within that OUI | `oui:00256D:my-unique-bbf-id-42` | | `cid` | An IEEE CID, in 6 hex characters | Set by the CID owner | `cid:3AA3F8:my-unique-usp-id-42` | | `pen` | An IANA Private Enterprise Number, in decimal | Set by the number’s owner | `pen:3561:my-unique-bbf-id-42` | | `self` | Optional, 1 to 6 characters made by the Endpoint | Generated by the Endpoint | `self::my-Agent` | | `user` | 0 to 6 characters | Assigned through a user or management interface | None in the spec | | `os` | Empty | OUI, a hyphen, then the serial number | `os::00256D-0123456789` | | `ops` | Empty | OUI, product class and serial number | `ops::00256D-STB-0123456789` | | `uuid` | Empty | A UUID | `uuid::f81d4fae-7dec-11d0-a765-00a0c91e6bf6` | | `imei` | Empty | An IMEI as defined by GSMA | `imei::990000862471854` | | `proto` | 0 to 6 characters, no period | Anything; for prototyping only | `proto::my-Agent` | | `doc` | 0 to 6 characters | Anything; for documentation only | `doc::agent` (§4.3.2.1) | | `fqdn` | Empty | A fully qualified domain name, no wildcards | `fqdn::www.example.org` | The scheme also decides who answers for uniqueness: the owner of the OUI, CID, enterprise number or domain name (including the OUI inside `os` and `ops`), the assigning user or machine for `user`, and the Endpoint itself for `self` (§2.2.1). Before you assign IDs to a fleet, check three more requirements: - **R-ARC.3**: the Broadband Forum OUI `00256D` and Private Enterprise Number `3561` are reserved for BBF documentation and prototyping and must not be used by anyone else. That is why they appear in the examples above. - **R-ARC.4**: the `proto` and `doc` schemes must not be used in production environments. - **R-ARC.4a**: an Endpoint that uses `fqdn` must present TLS certificates with a subjectAltName that allows that domain name. > **Did you know?** > > The Broadband Forum’s IANA Private Enterprise Number, 3561, is “the ADSL Forum entry” in IANA’s registry (§3.4.2). The > same number marks Broadband Forum options when an Agent asks DHCP for its Controller’s details (R-DIS.1). ## Where does the Endpoint ID appear on the wire? Over a secure WebSocket connection, the Endpoint ID appears three times, in this order: 1. **In the certificate** (TLS handshake): The subjectAltName carries the Endpoint ID in its URN form. - urn:bbf:usp:id:… 2. **In the opening request** (WebSocket handshake): The client offers the v1.usp subprotocol and puts its own Endpoint ID in the request URI. - eid=… 3. **In every Record** (USP Record): Two required fields name the target and the source Endpoints. - to_id - from_id *Where an Endpoint ID appears when a USP session runs over WebSocket with TLS, in order. Diagram by Dodderware, based on TR-369 §2.2, §4.1.3.1, §4.3.2.1 and §8.1.* 1. **In the certificate.** When an X.509 certificate authenticates an Endpoint, its subjectAltName must carry the URN form of the Endpoint ID, or for `fqdn` the domain name itself. When certificates authenticate at the MTP layer, Endpoints must not process Records whose `from_id` does not match the ID in the certificate (R-SEC.0a, §8.1). 2. **In the WebSocket handshake.** No USP Record is sent until TLS is complete, so the server cannot tell who the client is without looking inside the certificate (§4.3.2.1). The client sends the `Sec-WebSocket-Protocol` header with the value `v1.usp` (R-WS.9, R-WS.10) and adds its Endpoint ID to the request URI query as `eid` (R-WS.10b). A percent character in the ID is itself percent-encoded, so `doc::agent%21` travels as `doc::agent%2521` (R-WS.10c). 3. **In every Record.** Each USP Record carries the target Endpoint ID in `to_id` and the source in `from_id`, and both fields are required (§4.1.3.1). Because the other side checks identity against this value, treat an Endpoint ID as permanent: one that changes after it has been used can also cause unpredictable behavior (§2.2.1). Certificates, trust and Controller roles are covered in [TR-369 security](https://blog.dodderware.com/tr-369-security/). > **Where DWS Support fits** > > In a USP deployment, DWS Support takes the Controller role. Its native USP Controller connects to Agents over > WebSocket and runs next to TR-069, served through GenieACS or a built-in ACS, so each device is driven over TR-069 or > TR-369, chosen per device. It was developed and tested against obuspa, the Broadband Forum’s open-source USP Agent. > > [See DWS Support](https://dodderware.com/products/dws-support/) ## Can an Agent and a Controller share an Endpoint ID? Yes, within limits. An Agent and a Controller in the same USP Domain may use the same Endpoint ID, and every Endpoint must tolerate that (R-ARC.0, R-ARC.1). But Endpoints that share an ID must not talk to each other over USP (R-ARC.2), and unless the assigning authority says so, no relationship between them can be assumed (§2.2.1). In software modularization, sharing is even recommended: a USP Service that embeds both an Agent and a Controller should use one Endpoint ID for both, or the USP Broker cannot correlate them as a single USP Service (Appendix VI.2). What USP does not give you is a safety net for duplicates within one role. It defines no process to identify or resolve an Endpoint ID that is not unique among all Agents or all Controllers, and the result is “unpredictable behavior” (§2.2.1). The only built-in rule is for `self`: an Endpoint that meets another one using the identical ID must change its own (§2.2.1). For the bigger picture, messages, transports and data models included, start with [what is TR-369](https://blog.dodderware.com/what-is-tr-369/). ## Did you know? - An Agent and a Controller in the same USP Domain may share one Endpoint ID, but Endpoints that share an ID must never talk to each other over USP. (TR-369 §2.2.1 (R-ARC.0, R-ARC.2)) - USP defines no process to detect or resolve duplicate Endpoint IDs. A non-unique ID “will result in unpredictable behavior”. (TR-369 §2.2.1) - The OUI 00256D and the Private Enterprise Number 3561 are reserved for Broadband Forum documentation and prototyping, and no other entity may use them. (TR-369 §2.2.1 (R-ARC.3)) - The instance-id of an Endpoint ID may be no more than 50 characters long, because end users could be exposed to it. (TR-369 §2.2.2 (R-ARC.6)) - In a certificate, an Endpoint ID is written as a URN that starts with urn:bbf:usp:id:. Everywhere else the namespace is left out. (TR-369 §2.2) ## Questions people ask ### What is the difference between a USP Agent and a USP Controller? The Agent exposes Service Elements, the Objects, Parameters, Commands and Events of its data model, to one or more Controllers. The Controller manipulates those Service Elements through one or more Agents. Controllers only send messages to Agents, and Agents send messages to Controllers. ### What is the format of a USP Endpoint ID? Three parts separated by colons, authority-scheme:[authority-id]:instance-id, where the authority-id can be empty. In a certificate the same ID is written as a URN that starts with urn:bbf:usp:id:. ### What does os:: mean in a USP Endpoint ID? os is an authority scheme whose authority-id is always empty, which is why the ID contains a double colon. Its instance-id is an OUI, a hyphen and the serial number, as in os::00256D-0123456789. The related ops scheme adds the product class between the two. ### Can a USP device have more than one Controller? Yes. The specification defines an Agent as an Endpoint that exposes Service Elements to one or more Controllers, and an Agent that supports USP configuration of Controllers keeps them in the Device.LocalAgent.Controller Object of its data model. ### Can I use proto:: or doc:: Endpoint IDs in production? No. Requirement R-ARC.4 says the proto and doc authority schemes must not be used in production environments. They exist only for prototyping and for documentation such as tutorials and examples. ### Which characters can a USP Endpoint ID contain? The instance-id may use letters, digits, the hyphen, the period, the underscore and percent-encoded characters, and it may be no more than 50 characters long. The specification prefers shorter values because end users may see them. ## Sources - Broadband Forum, TR-369 – The User Services Platform, Issue 1 Amendment 5 (USP 1.5), January 2026. - Dodderware, DWS Support product and engineering documentation. - §1.4: Definitions (Agent, Controller, Endpoint, Endpoint Identifier, USP Domain, USP Relationship) - §2.1, §2.1.1, §2.1.2, §2.3: Endpoints, Agents, Controllers and Service Elements - §2.2, §2.2.1, §2.2.2: Endpoint Identifier, authority schemes (R-ARC.0 to R-ARC.4a), instance-id rules (R-ARC.5, R-ARC.6) - §2.4.1, §2.4.2, §7.5.3: Instantiated and Supported Data Models, GetSupportedDM - §3.1, §3.2, §3.3, §3.4.2: What Agents and Controllers need to know about each other, the Broadband Forum enterprise number - §4.1.3.1, §4.3.2, §4.3.2.1: Record fields to_id and from_id, the WebSocket session handshake (R-WS.9 to R-WS.10c) - §7.3.3.2, §7.6.1: Request types, and the ACS as the CWMP equivalent of a Controller - §8.1: Endpoint IDs in certificates (R-SEC.0a) - Appendix VI.2: USP Brokers and USP Services that embed both an Agent and a Controller [Read the TR-369 specification](https://usp.technology/specification/index.htm) TR-369 © The Broadband Forum. All rights reserved. Quoted briefly and paraphrased for commentary; the diagrams are Dodderware’s own. --- **Manage TR-069 and TR-369 devices from one console.** DWS Support brings every ONT and home router into one web console, whichever protocol it speaks: TR-069 through GenieACS or a built-in ACS, TR-369 through a native USP controller. Self-hosted on your infrastructure. [Request a demo](https://dodderware.com/products/dws-support/#get-started)