TR-069 vs TR-369 is no longer a theoretical debate. In 2024 the Broadband Forum said it would make no more updates to TR-069, because TR-369, the User Services Platform (USP), “has become the cornerstone for future developments in device management” (Broadband Forum). If you run a large CPE fleet, the question isn’t whether USP matters. It’s which devices to move, when, and what to keep.
We write this from the TR-069 side of the fence. Our team built and maintains a TR-069 NMS that manages 1.5 lakh+ (150,000+) ADSL, VDSL and ONT devices for an ISP. That platform is CWMP-only today. So this isn’t a pitch for a USP product. It’s the view of people who know what a big TR-069 estate looks like and have thought hard about how to move one. If you want a refresher on how TR-069 works day to day, our guide to TR-069 remote device management for ISPs covers it.
TR-069 vs TR-369 at a glance
The short version first, then the detail.
- Transport: TR-069 (CWMP): SOAP 1.1 over HTTP 1.1, secured with TLS. TR-369 (USP): Protocol Buffers messages over an MTP: WebSocket, MQTT, STOMP or Unix Domain Socket.
- Session model: TR-069 (CWMP): CPE opens every session with an Inform; ACS responds inside it. TR-369 (USP): optional sessions; either side can send messages over a persistent connection.
- Reaching the device: TR-069 (CWMP): Connection Request (HTTP GET, or STUN/XMPP behind NAT) asks the CPE to call in. TR-369 (USP): controller sends directly over the open MTP connection or broker.
- Real-time capability: TR-069 (CWMP): periodic polling plus value-change notifications; latency tied to session setup. TR-369 (USP): event-driven Notify messages and subscriptions.
- Security: TR-069 (CWMP): TLS to the ACS, HTTP digest auth for connection requests. TR-369 (USP): TLS at the MTP layer, plus optional end-to-end integrity through USP Records.
- Controllers per device: TR-069 (CWMP): one ACS. TR-369 (USP): multiple controllers, each with its own access role.
- Data model: TR-069 (CWMP): Device:2 (TR-181). TR-369 (USP): Device:2 (TR-181), extended.
The data model point is the one to hold on to. It’s why migration is possible at all.
How CWMP works, and where it strains
In CWMP the CPE is always the one that opens the session. It sends an Inform with event codes such as 0 BOOTSTRAP, 1 BOOT, 2 PERIODIC or 6 CONNECTION REQUEST. The ACS replies, then issues RPCs inside that same session: GetParameterValues, SetParameterValues, AddObject, Download for firmware, Reboot and so on. When neither side has anything left to send, the CPE posts an empty HTTP request and the ACS closes the session with a 204. All of this is defined in the TR-069 specification.
If the ACS wants something now, it sends a Connection Request, an HTTP GET to the CPE’s ConnectionRequestURL. Behind carrier NAT that URL often isn’t reachable, which is why the spec added STUN (Annex G) and XMPP (Annex K) as workarounds.
This model has held up for two decades, and it still works. Our own NMS depends on it at scale. But three things strain it in a modern home network:
- Latency. Every action waits for a session to be set up, and SOAP/XML is heavy on the wire.
- One manager. A CPE reports to a single ACS. If a Wi-Fi optimisation vendor, a smart-home app and your support portal all want access, they queue behind it.
- Telemetry. Polling thousands of parameters across a fleet on a periodic Inform is an expensive way to get Wi-Fi quality data.
For a fleet of ADSL modems that need a config push and the occasional firmware update, none of this hurts much. For Wi-Fi 6 and 7 gateways, mesh extenders and anything with apps running on it, it hurts a lot.
What USP changes
USP keeps the idea of a managed device and a management server but renames the roles and loosens the plumbing. The TR-369 specification is published openly by the Broadband Forum.
Agents and controllers
A USP agent runs on the device and exposes its data model. A USP controller manages it. One agent can have several controllers, each with a role defined in the agent’s ControllerTrust configuration. Your operations platform can hold full control while a Wi-Fi analytics partner gets read access to radio statistics and nothing else. CWMP has no clean way to do that.
Message transfer protocols
USP separates the message from the transport. The current spec defines four MTPs: WebSocket, MQTT, STOMP and Unix Domain Socket (for communication inside the device). CoAP was deprecated in USP 1.2 and made obsolete in 1.3. With WebSocket, MQTT or STOMP, the connection stays open or runs through a broker, so there’s no Connection Request step. The controller sends the message and the agent acts on it.
Messages and data model
USP messages are compact Protocol Buffers: Get, Set, Add, Delete, GetInstances, GetSupportedDM, Operate, Notify and Register. They map closely to what CWMP RPCs already do against the same Device:2 (TR-181) objects. That shared model is the biggest reason your existing parameter mappings and provisioning templates aren’t wasted.
Security and provisioning
TLS protects each MTP hop, and USP Records can carry an end-to-end session context so a message’s integrity survives a broker in the middle. Provisioning changes too. Under CWMP, zero-touch setup is about getting the CPE to find the ACS URL on first boot. Under USP it’s about getting the agent the right controller and MTP settings, often through a broker, plus the certificates to trust it. Our zero-touch provisioning guide covers the CWMP side; plan the USP bootstrap as a separate workstream, not an afterthought.
Which devices justify USP
Here’s our opinion. Don’t migrate a device class because the standard is newer. Migrate it because you have a job CWMP can’t do well.
Good candidates:
- Wi-Fi gateways and mesh systems where you want near-real-time radio telemetry and steering.
- Devices where third parties need scoped access, such as a Wi-Fi optimisation vendor or a security service.
- New CPE models you haven’t bought yet. Put USP agent support in the RFP now.
Poor candidates:
- Legacy ADSL and VDSL modems with a few years of life left. The vendor probably won’t ship a USP agent, and you’d gain little if they did.
- Devices whose only management needs are config push and firmware upgrade. CWMP does that fine.
Most ISPs will end up with a mixed estate for years. That’s normal, and it’s fine.
Can TR-069 and TR-369 run together?
Yes, and for most operators they will. There are two common patterns.
Parallel stacks. Legacy CPE stays on your ACS. New devices ship with a USP agent and report to a USP controller. Your OSS/BSS talks to both, ideally through one abstraction layer so the helpdesk sees one device view.
Dual-stack devices. Some CPE firmware includes both a CWMP client and a USP agent. Because both expose the same TR-181 model, the ACS can use ordinary SetParameterValues calls to configure the agent’s controller and MTP entries, then hand over. It’s a practical bridge, but check it with your CPE vendor before you plan around it, because firmware support varies.
What doesn’t work well is two management systems fighting over the same parameters. Decide which system owns each device, and each object, and write it down.
What your TR-069 investment keeps
A lot, as it turns out. Here’s what carries over from a mature CWMP estate:
- Your TR-181 parameter mappings, vendor quirks and provisioning templates.
- Device inventory, subscriber-to-device mapping and firmware catalogues.
- Diagnostics workflows and the helpdesk runbooks built on them.
- Reporting pipelines, though you’ll want to feed them from USP events rather than polls.
This is where our own experience comes in. For SCOM Technologies we built a full TR-069 implementation with an Auto-Configuration Server for provisioning and firmware management, SNMP-based reporting and a real-time monitoring dashboard, managing 1.5 lakh+ ADSL, VDSL and ONT devices. The hard-won parts of that system are the device knowledge and the operational workflows, not the SOAP handling. Those are exactly the parts a USP rollout reuses.
What doesn’t carry over is the transport layer, the session logic, the connection-request handling and the security model. That’s new build or new integration either way, and it’s where custom software development usually comes in: adapters between a USP controller and your existing OSS, a unified device view, and broker infrastructure.
A phased TR-369 migration plan
This is the sequence we’d follow.
- Inventory the fleet by model, firmware and remaining life. Tag which models have, or could get, a USP agent.
- Pick one device class with a clear USP use case, usually a current Wi-Fi gateway.
- Choose the MTP. WebSocket is the simplest start. MQTT makes sense if you already run brokers at scale.
- Stand up a USP controller in a lab alongside the production ACS. Test bootstrap, firmware update and diagnostics against real CPE.
- Build the abstraction layer so support staff see one device record regardless of protocol.
- Pilot on a few thousand devices in one region. Compare telemetry, support call handling and failure rates against the CWMP baseline.
- Make USP a requirement in every new CPE purchase.
- Let legacy CPE age out on the ACS. Don’t force it across.
Frequently asked questions
Should ISPs migrate from TR-069 to TR-369?
Yes, gradually. The Broadband Forum has stopped updating TR-069 and put new work into USP, so new CPE should support TR-369. Legacy devices near the end of their life can stay on CWMP. Migrate device classes where USP solves a real problem, such as real-time Wi-Fi telemetry or third-party access, rather than moving the whole fleet at once.
Can TR-069 and TR-369 run together?
Yes. Most ISPs will run both for years, either as parallel systems with an ACS for legacy CPE and a USP controller for new devices, or on dual-stack firmware that supports both protocols. Both use the Device:2 (TR-181) data model, which keeps the mapping work manageable. Assign clear ownership so two systems never manage the same parameters at once.
TR-369 MQTT vs WebSocket: which should we use?
WebSocket is the simpler start: the agent holds a persistent connection to the controller, with no extra infrastructure. MQTT routes messages through a broker using publish and subscribe, which suits very large fleets and operators already running MQTT for IoT. STOMP is also broker-based. Choose based on the infrastructure you can operate reliably, not on benchmark claims.
Does TR-369 replace the TR-181 data model?
No. USP uses and extends the same Device:2 data model defined in TR-181, which CWMP also uses. Objects such as WiFi, IP and DeviceInfo keep their meaning across both protocols. USP adds objects for its own needs, like controller trust roles and MTP settings, so parameter mappings built for TR-069 remain useful after migration.
Is USP more secure than CWMP?
USP gives you more security options. Both protocols use TLS for transport, but USP can also protect message integrity end to end through USP Records, which matters when messages pass through a broker. Its per-controller access roles also limit what each system can touch. Real security still depends on certificate management, firmware quality and how carefully you configure roles.
Does Atomquark’s TR069 NMS support USP?
Our production NMS is a TR-069/CWMP platform today, managing 1.5 lakh+ devices. We don’t sell it as a USP controller. What we do offer is help planning a TR-369 migration and building the pieces around it, such as OSS adapters, a unified device view and pilot tooling, using the device and workflow knowledge from our TR-069 work.
Where to start
The TR-069 vs TR-369 decision is really made device class by device class, so start with the inventory, not the protocol. Knowing which models can run a USP agent, and which will retire first, answers half the migration questions before you pick a controller.
If you want a second opinion from a team that works with TR-069 at scale, our product engineering group built and maintains the NMS behind the SCOM deployment. Book a TR-069 to USP readiness review and we’ll go through your fleet, your ACS and your CPE roadmap, and tell you where USP earns its place and where it doesn’t.