TR-069 vs TR-369: what changes from CWMP to USP?

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 ProtocolNew in USP: WebSocket, MQTT, STOMP or UNIX Domain Socket carries each Record.

USP Record and MessageNew 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.

How do TR-069 and TR-369 differ?

Side by side, the differences are about who manages the device and how messages get there:

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.

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.

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.

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.