For telecom operators managing thousands—or hundreds of thousands—of customer premises equipment (CPE) devices, the device management protocol is not a technical footnote. It determines provisioning speed, diagnostic capability, firmware update reliability, and ultimately, operational cost per subscriber. The Broadband Forum’s TR-369 User Services Platform (USP) is the designated successor to the aging TR-069 (CWMP) protocol, and its adoption is accelerating across carrier-grade CPE deployments worldwide.
This guide provides a practical overview of TR-369 USP: what it does, why it matters, how to plan a migration from TR-069, and what procurement teams should verify when sourcing USP-compatible CPE.
What Is TR-369 USP and Why Is It Replacing TR-069?
TR-069 (CPE WAN Management Protocol, or CWMP) has been the workhorse of broadband CPE management since 2004. It enabled auto-configuration servers (ACS) to provision, monitor, and update CPE remotely. However, TR-069 was designed in an era of DSL modems and simple NAT routers. It struggles with modern deployment realities: multi-WAN CPE, mesh Wi-Fi systems, IoT gateways, containerized applications on CPE, and the low-latency telemetry that operators now expect.
TR-369 USP, first published in 2018 and now at version 1.3 (2023), addresses these limitations with a fundamentally modern architecture:
- REST/WebSocket-based messaging instead of SOAP/HTTP. This reduces overhead, supports real-time push notifications, and integrates naturally with cloud-native operator OSS/BSS stacks.
- Multi-controller support. A single CPE can be managed simultaneously by multiple controllers—for example, the operator’s ACS for provisioning, a separate analytics platform for telemetry, and an end-user mobile app for Wi-Fi optimization.
- Data model based on TR-181. USP reuses and extends the mature TR-181 Device Data Model (also used by TR-069), so operators can map existing parameter paths. But USP adds new objects for Wi-Fi 6/7, 5G NR, IoT sensors, and virtualized network functions.
- End-to-end security with TLS 1.3 and mutual certificate authentication. USP mandates encrypted transport and device-to-controller certificates, eliminating the plaintext HTTP provisioning vectors that vexed TR-069 deployments.
- Bulk data collection with USP’s “Trusted Broker” and “Subscription” mechanisms. Operators can define periodic telemetry subscriptions—for signal strength, throughput, and Wi-Fi channel utilization—without polling each device individually.
USP Architecture: Controllers, Agents, and the Message Transfer Protocol
USP defines a clean separation between three components:
1. USP Agent — embedded in the CPE firmware. Exposes the device’s data model (TR-181 objects) and executes commands from controllers.
2. USP Controller — the operator-side management system (ACS replacement). Sends commands, creates subscriptions, and processes notifications.
3. MTP (Message Transfer Protocol) — the transport layer. The primary binding is WebSocket with TLS 1.3, but USP also supports MQTT and CoAP bindings for constrained IoT devices—a flexibility TR-069 never offered.
This architecture enables a critical operational improvement: always-on connectivity. In TR-069, the ACS could only reach the CPE when the device initiated a session (typically via periodic inform messages). In USP, the WebSocket connection is persistent, allowing the controller to push commands instantly—vital for time-sensitive operations like firmware security patches or QoE remediation.
Checklist: What Operators Should Verify When Procuring USP-Compatible CPE
Not all CPE marketed as “USP-compatible” delivers the full operational benefit. Procurement teams should validate the following before committing to large-volume orders:
| Verification Item | Why It Matters | How to Test |
|---|---|---|
| USP Agent version (≥1.2) | Version 1.2+ supports bulk data, trusted broker, and firmware management improvements | Request GetInstances on Device.LocalAgent.Controller. |
| WebSocket MTP with TLS 1.3 | Mandatory for persistent connectivity; older MQTT-only implementations limit real-time control | Attempt WebSocket connection from controller to agent endpoint; verify TLS cert chain |
| TR-181 data model coverage (Device.WiFi., Device.Cellular., Device.Bridging.) | Full coverage enables Wi-Fi optimization, cellular signal monitoring, and VLAN configuration | Run GetSupportedDM to enumerate exposed objects; compare against TR-181 spec |
| Multi-controller registration | Enables concurrent management by operator ACS + end-user app + analytics platform | Register two controllers with different credentials; verify both can query |
| Firmware update with USP (DUStateChangeNotif) | USP-native firmware management is more reliable than TR-069 download methods | Push a test firmware image via USP; verify download, validation, and install notification |
| Subscription/Notify mechanism | Push-based telemetry eliminates polling overhead; critical for QoE monitoring at scale | Create a subscription for Device.Cellular.SignalStrength; verify periodic value-changed notifications |
TR-069 to TR-369 Migration: A Phased Approach
Most operators cannot flip a switch and replace TR-069 overnight. A practical migration follows three phases:
Phase 1 — Dual-stack deployment (months 1–6). Deploy new CPE with both TR-069 and USP agents running. The existing ACS continues to manage day-to-day operations, while the USP controller is validated against a subset of devices for provisioning, telemetry, and firmware management. This is the lowest-risk entry point.
Phase 2 — Controller cutover (months 6–12). Once the USP controller has been validated against all critical workflows, begin routing new device activations exclusively through USP. Existing devices remain on TR-069 or dual-stack until natural hardware refresh occurs.
Phase 3 — TR-069 deprecation (months 12–24). As the installed base refreshes, the TR-069 ACS can be scaled down and eventually decommissioned. USP-native capabilities—bulk telemetry, multi-controller support, application lifecycle management—become the operational baseline.
Why USP Matters for the CPE Supply Chain
For distributors and system integrators, TR-369 compliance is becoming a hard requirement in operator RFPs—particularly in Europe, where Deutsche Telekom, BT Group, and Orange have all published USP roadmap requirements for CPE vendors. In North America, the Broadband Forum’s BBF.369 certification program is driving similar momentum. CPE models that lack USP support will face increasing procurement barriers in carrier tenders from 2026 onward.
When evaluating OEM/ODM partners, verify that the manufacturer has completed USP Agent implementation with a Broadband Forum-recognized test tool (such as the USP Agent Conformance Test or CDRouter USP), and that their roadmap includes support for upcoming USP 1.4 features, including enhanced IoT proxy capabilities and application container management.
Frequently Asked Questions
What is the difference between TR-069 and TR-369 USP?
TR-069 (CWMP) uses SOAP/HTTP for periodic device polling through an ACS. TR-369 USP uses REST/WebSocket for persistent, real-time bidirectional communication. USP supports multi-controller management, bulk data subscriptions, and modern encryption (TLS 1.3), while TR-069 is limited to a single ACS controller with periodic inform-based communication. USP also extends the TR-181 data model to cover Wi-Fi 6/7, 5G NR, and IoT functions that TR-069 cannot represent.
Does USP work with existing TR-069 ACS platforms?
No. USP requires a dedicated USP Controller, not a TR-069 ACS. However, many modern device management platforms (including those from Axiros, Friendly Technologies, and Incognito) now offer dual-protocol support, managing both TR-069 and USP devices from a single administrative interface. This dual-protocol capability is essential for operators managing a mixed installed base during migration.
Is USP mandatory for 5G FWA CPE?
USP is not a 3GPP requirement for 5G, but it is increasingly specified in operator procurement RFPs for 5G FWA CPE, particularly in Europe and parts of Asia-Pacific. The protocol’s ability to handle multi-WAN scenarios (cellular + fixed backup) and real-time signal quality telemetry makes it well-suited for 5G FWA management. Some operators accept TR-069 for initial deployments but require a USP roadmap within 12–18 months.
How does USP handle firmware upgrades at scale?
USP uses the DUStateChangeNotif (Download Update State Change Notification) mechanism for firmware management. The controller can push firmware images to device groups, monitor download progress in real time via WebSocket notifications, verify image integrity before installation, and schedule installations during maintenance windows. This is more reliable than TR-069’s download methods, which often relied on the device periodically polling for available updates.
Can USP manage non-Broadband CPE like industrial routers and IoT gateways?
Yes. USP’s flexible data model and MTP options (WebSocket, MQTT, CoAP) make it suitable for industrial routers, IoT gateways, and even constrained sensor devices. The protocol’s subscription mechanism is particularly valuable for industrial use cases where periodic sensor readings or equipment status updates need to flow to a central management platform without constant polling.
Plan Your TR-369 USP CPE Deployment
Honlly Telecom’s carrier-grade 4G/5G CPE and industrial routers support TR-369 USP alongside TR-069 for seamless migration. Our engineering team can provide USP Agent conformance test reports, data model coverage documentation, and integration support for your operator management platform. Contact us to discuss your USP CPE requirements and request a test sample.