# TR-069 vs TR-369: what changes from CWMP to USP? Dodderware engineering team · Published 2026-10-28 · https://blog.dodderware.com/tr-069-vs-tr-369/ [Leer en español](https://blog.dodderware.com/es/tr-069-vs-tr-369/) > **Short answer:** TR-069 (CWMP) and TR-369 (USP) are Broadband Forum protocols for managing customer devices, and they share the Device:2 data model of TR-181, so the same parameter paths carry over. What changes is everything around it. CWMP has a single ACS, while a USP Agent answers to one or more Controllers, each with its own Role, and exchanges Protocol Buffers messages over WebSocket, MQTT, STOMP or UNIX domain sockets. If your devices answer to a TR-069 ACS today, someone has probably asked when you will move to TR-369. Before planning anything, it helps to know exactly what changes. The short version: the data model stays, and almost everything around it changes. This comparison sticks to what the TR-369 specification says about CWMP, plus the basics of how a CWMP session works. ## What do TR-069 and TR-369 have in common? TR-069 is the CPE WAN Management Protocol (CWMP). TR-369 cites it as TR-069 Amendment 6, published by the Broadband Forum in 2018 (§1.3.2), and ties the two together through the data model. Among the use cases USP supports, it lists simple migration from CWMP “through use of the same data model and data modeling tools” (§1.1). Concretely, USP supports the **Device:2 Data Model**, specified in TR-181 Issue 2, and the schema and rules for its Objects, Parameters, Events and Commands come from TR-106 (§2.4). TR-106’s own title says who it serves: “Data Model Template for CWMP Endpoints and USP Agents” (§1.3.2). For a support engineer, that means a path such as `Device.WiFi.SSID.1.SSID` keeps its meaning in both protocols. Some query behavior carries over too: the specification notes that people who know TR-069 will recognize how a USP Get handles Partial Paths and Complete Paths (§7.5.1). One caution. TR-369 lists a single supported data model, Device:2 (§2.4). Some TR-069 fleets still include older devices that report under the `InternetGatewayDevice.` root of TR-098, and for those devices the paths your team knows today are not the ones USP will use. - **Message Transfer Protocol**: New in USP: WebSocket, MQTT, STOMP or UNIX Domain Socket carries each Record. - **USP Record and Message**: New in USP: Protocol Buffers version 3, with the Endpoint IDs of the source and the target. (usp-record-1-5.proto, usp-msg-1-5.proto) - **Device:2 Data Model (TR-181)**: Shared with CWMP: the same Objects, Parameters, Events and Commands, defined with TR-106. *What stays and what changes from TR-069 to TR-369: the data model at the core is shared, the layers around it are new. Diagram by Dodderware, based on TR-369 §1.1, §2.4, §4 and §5.* ## How do TR-069 and TR-369 differ? Side by side, the differences are about who manages the device and how messages get there: | | TR-069 (CWMP) | TR-369 (USP) | | --------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------ | | Who manages the device | A single Auto-Configuration Server (ACS) (§7.6.1) | One or more Controllers, each with its own Roles (§1.4, §8) | | Software on the device | The CWMP client | The Agent, identified by its Endpoint ID (§1.4, §2.2) | | Data model | Device:2 (TR-181); older devices may still use TR-098 | Device:2 (TR-181), with rules from TR-106 (§2.4) | | Encoding | SOAP messages | Protocol Buffers version 3 (§5) | | Transport | HTTP sessions that the device opens with an Inform | A Message Transfer Protocol: WebSocket, MQTT, STOMP or UNIX Domain Socket (§4) | | Reaching the device on demand | Connection Request, an HTTP GET to a URL the device reported | A long-lived session, kept open and reused (§4.3.2, §4.4.1, §4.5.1) | | Where the manager’s address lives | `Device.ManagementServer.` | `Device.LocalAgent.Controller.{i}.` (§3.1) | | Value changes the manager made | Not notified back to the ACS (§7.6.1) | Notified as each subscription specifies (§7.6.1) | ## Who manages the device: one ACS or several Controllers? This is the biggest architectural change. TR-369 describes the ACS as “the CWMP equivalent of a Controller” and points out that CWMP has only one (§7.6.1). That is why a TR-069 device does not notify the ACS of value changes the ACS requested: there is nobody else to tell. USP drops that shortcut. An Agent follows the behavior each subscription specifies, “regardless of the originator” (§7.6.1), because it exposes its Service Elements to one or more Controllers (§1.4). Several managers on one device means permissions matter. Controllers are authenticated, and each one is granted Roles that set what it may read, change, operate or subscribe to (§8). The operator’s platform, a customer app and a partner service can share one gateway without sharing the same rights. Each side is identified by an Endpoint ID, and two of its schemes, `os` and `ops`, build it from the manufacturer OUI, the product class and the serial number (§2.2.1), fields operators already use to identify CPEs. More in [USP Agent vs Controller](https://blog.dodderware.com/usp-agent-vs-controller/). ## How do messages reach the device? In CWMP, the device starts the conversation. It opens an HTTP session to the ACS with an Inform, and the ACS sends its requests, such as GetParameterValues or SetParameterValues, as SOAP messages inside that session. When the ACS needs the device right away, it sends a Connection Request, an HTTP GET to a URL the device reported. If that fails, the work waits for the device’s next periodic Inform. TR-369 defines no Connection Request. USP Records travel over a Message Transfer Protocol (§4): WebSocket, STOMP, MQTT or UNIX Domain Socket, and an Agent may support more than one (§4.1.1). The network MTPs keep long-lived sessions that are reused for later Records (§4.3.2, §4.4.1, §4.5.1). With WebSocket either side can open the session, and an Agent must be able to do both (R-WS.5, R-WS.6), but the specification expects that Agents “will establish the WebSocket session” rather than expose an open port toward the Internet (§4.3.2). What travels inside changes too. Instead of SOAP envelopes, USP Records and Messages are encoded with Protocol Buffers version 3, against the schemas `usp-record-1-5.proto` and `usp-msg-1-5.proto` (§5). For the trade-offs between the transports, read [USP transports compared](https://blog.dodderware.com/usp-mtp-websocket-mqtt-stomp/). > **Did you know?** > > Protocol Buffers did not erase TR-069’s heritage. Parameter values inside USP Messages are Protocol Buffers strings that > follow the string forms of TR-106 data types, and TR-106 says those types use “a limited subset of the default SOAP data > types”. So the ultimate reference for how USP writes a value such as a `dateTime` is still XML Schema (§5.1). ## Can TR-069 and TR-369 devices share a network? Yes, and the specification plans for it. TR-369 keeps a mechanism originally defined in CWMP, in which a gateway and an end device exchange information through DHCP options so that an ACS or a Controller can tell whether they sit on the same LAN (§3.4). USP devices implement it “without changing any CWMP functionality” (§3.4). The Agent includes its manufacturer OUI, serial number and product class in vendor-specific DHCP options, and the gateway’s DHCP server answers with its own. The Agent stores what it learns in `Device.GatewayInfo`, with `ManagementProtocol` set to “CWMP”. If an mDNS record from the same IP address announces a USP Endpoint, the Agent sets it to “USP” and records that Endpoint ID (R-DIS.2a to R-DIS.2d). The option codes are in [how a USP Agent finds its Controller](https://blog.dodderware.com/usp-discovery-dhcp-mdns/). ## How do you move a fleet from TR-069 to TR-369? TR-369 does not prescribe a migration plan, and it never says that USP replaces CWMP. What it provides is the material for a gradual one: the same data model, so configurations and support know-how carry over (§1.1, §2.4); GatewayInfo, so mixed LANs keep working (§3.4); and a `Device.LocalAgent.Controller` table that an already-trusted Controller can configure (§3.1). A device only speaks USP once its firmware includes a USP Agent, so in practice fleets move model by model and device by device, not on a single date. The real operational question is how to run both protocols side by side for as long as the transition takes. The full picture of USP is in [what is TR-369](https://blog.dodderware.com/what-is-tr-369/). > **Where DWS Support fits** > > A move to TR-369 does not have to be a big-bang ACS swap. In DWS Support, TR-069 and USP devices coexist in the same > fleet and workflows, and one console drives each device over TR-069 or TR-369, chosen per device. TR-069 devices run > through GenieACS or a built-in ACS option, switchable per device, and USP devices through a native controller that > connects to Agents over WebSocket. > > [See DWS Support](https://dodderware.com/products/dws-support/) ## Did you know? - TR-369 lists simple migration from CWMP, “through use of the same data model and data modeling tools”, among the use cases USP supports. (TR-369 §1.1) - In CWMP a device does not notify the ACS of value changes the ACS itself caused, because there is only one ACS. A USP Agent follows each subscription “regardless of the originator”. (TR-369 §7.6.1) - The rulebook for the shared data model, TR-106, is titled “Data Model Template for CWMP Endpoints and USP Agents”. (TR-369 §1.3.2) - A USP Agent records whether its LAN gateway is managed over “CWMP” or “USP” in Device.GatewayInfo, learned through DHCP options and mDNS. (TR-369 §3.4.1) - A USP Agent must be able to open a WebSocket session and to accept one from a Controller. Accepting became a MUST in USP 1.2, for in-home use. (TR-369 §4.3.2) ## Questions people ask ### Is TR-369 replacing TR-069? The TR-369 specification does not say it replaces TR-069. It lists simple migration from CWMP, through the same data model and data modeling tools, as one of the use cases USP supports, and it keeps a CWMP mechanism, GatewayInfo over DHCP, so that CWMP and USP devices on the same LAN can recognize each other. ### Do TR-069 and TR-369 use the same data model? Yes. USP supports the Device:2 Data Model, specified in TR-181 Issue 2, with the rules for its Objects, Parameters, Events and Commands defined in TR-106. It is the same data model family that TR-069 devices use. TR-369 lists Device:2 as its only supported data model. ### What is the TR-369 equivalent of an ACS? The Controller. TR-369 itself describes the Auto-Configuration Server as the CWMP equivalent of a Controller. The difference is that a CWMP device reports to a single ACS, while a USP Agent can serve one or more Controllers, each with its own Role. ### Does TR-369 still use SOAP and HTTP? Not for its messages. USP Records and Messages are encoded with Protocol Buffers version 3 and carried by a Message Transfer Protocol, which the current specification defines for WebSocket, STOMP, MQTT and UNIX Domain Socket. TR-069 exchanges SOAP messages over HTTP sessions that the device opens with an Inform. ### Does a USP device need a Connection Request like a TR-069 device? TR-369 defines no Connection Request. Its network MTPs keep long-lived sessions that are reused for later Records. Over WebSocket the specification expects the Agent to open the session, so the device does not expose an open port toward the Internet, although an Agent must also accept a session opened by a Controller. ### Can TR-069 and TR-369 devices run on the same LAN? Yes. TR-369 keeps a mechanism first defined in CWMP, the exchange of GatewayInfo through vendor-specific DHCP options, so a USP Agent can recognize a CWMP gateway and a CWMP client can recognize a USP Agent, without changing any CWMP functionality. ## 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.1: Executive summary, including simple migration from CWMP - §1.3.2: References (TR-069 Amendment 6, TR-106, TR-181 Issue 2) - §1.4, §2.2.1: Agent and Controller definitions, Endpoint ID authority schemes - §2.4: Data models (Device:2, TR-181, TR-106) - §3.1: Controller information on the Agent (Device.LocalAgent.Controller) - §3.4, §3.4.1: Use of DHCP for exchanging GatewayInfo with CWMP devices - §4, §4.1.1, §4.3.2, §4.4.1, §4.5.1: Message Transfer Protocols, multiple MTPs, long-lived sessions - §5, §5.1: Message encoding and Parameter value encoding - §7.5.1, §7.6.1: The Get Message and subscriptions, with their notes for CWMP readers - §8: Authentication and authorization (Controller Roles) [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)