TR-069 explained

What TR-069 is and what it does

TR-069 is a protocol published by the Broadband Forum that allows ISPs to remotely configure, monitor, update, and troubleshoot subscriber-side equipment — the routers, ONUs, and access points installed at subscriber premises — without physically visiting each location. DataRadius is ISP billing and management software that includes TR-069 device management, letting providers configure and monitor subscriber equipment alongside billing from one platform.

The protocol's formal name is CWMP (CPE WAN Management Protocol), where CPE stands for Customer Premises Equipment. In conversation, ISP operators refer to it as "TR-069" or simply "CWMP." It was first published in 2004 and has been revised multiple times since, with the current version being Amendment 6.

The problem TR-069 solves is straightforward: an ISP with 5,000 subscribers has 5,000 devices in 5,000 different locations. Without remote management, every configuration change — Wi-Fi password reset, firmware update, speed profile change, diagnostic test — requires either a site visit (expensive, slow) or talking the subscriber through manual steps by phone (frustrating, error-prone). At scale, neither approach works.

TR-069 replaces site visits and phone calls with a centralized management server called an ACS (Auto Configuration Server). The ACS communicates with each subscriber device over HTTPS, using a standardized data model that maps every configurable parameter — Wi-Fi SSID, DNS servers, firewall rules, speed limits, firmware version — to a hierarchical path. The ISP operator changes a parameter on the ACS, and the ACS pushes it to the device. No login to the device's web interface, no SSH session, no phone call.

The value scales linearly with the number of managed devices. An ISP managing 50 devices might handle configuration manually. An ISP managing 500 devices saves hours per week. An ISP managing 5,000 devices cannot operate without remote management.

How TR-069 communication works

TR-069 uses a client-server model where the subscriber's device (CPE) is the client and the ISP's ACS is the server. All communication happens over HTTPS — standard HTTP with TLS encryption — on port 7547 by convention, though any port works.

The protocol has two communication patterns:

Device-initiated: the Inform

The primary communication pattern is device-initiated. The CPE contacts the ACS, not the other way around. This design choice is critical because subscriber devices are almost always behind NAT — they have private IP addresses and cannot receive unsolicited inbound connections from the internet.

The CPE sends an Inform message to the ACS at specific trigger points:

• First boot. When the device powers on for the first time or after a factory reset, it immediately contacts the ACS. This is the entry point for zero-touch provisioning — the device arrives at the subscriber's premises, gets plugged in, and automatically downloads its full configuration from the ACS.
• Periodic interval. The CPE contacts the ACS at a configured interval — typically every 60 to 3600 seconds (1 minute to 1 hour). This heartbeat lets the ACS know the device is online and gives the ACS an opportunity to push pending changes.
• Value change. If a monitored parameter changes (for example, the WAN IP address changes after a DHCP renewal), the CPE sends an Inform notifying the ACS.
• Boot. After every reboot, the CPE sends a BOOT Inform so the ACS knows the device restarted and can re-verify its configuration.

Each Inform message contains the device's serial number, manufacturer, model, firmware version, current WAN IP, and a list of events that triggered the message. The ACS uses the serial number to look up the device in its database and determine what actions are pending.

ACS-initiated: the Connection Request

Sometimes the ACS needs to reach the device immediately — pushing an urgent firmware update or running a diagnostic test. Instead of waiting for the next periodic Inform, the ACS sends a Connection Request to the device.

The Connection Request is a simple HTTP GET to a URL on the device (typically http://<device-ip>:7547/). When the device receives it, it initiates a new Inform session to the ACS, and the ACS can then push changes in that session.

Connection Requests require the ACS to reach the device's IP address. This works straightforwardly when the device has a public IP or is on the same private network as the ACS. When the device is behind NAT (common for residential subscribers), the ACS needs either a STUN-based NAT traversal mechanism (defined in TR-111) or the ISP must rely on periodic Informs instead.

In practice, most ISP deployments use a combination: periodic Informs for routine management (checking firmware version, collecting stats) and Connection Requests for time-sensitive operations (pushing a configuration change after a subscriber calls support).

Session flow

A TR-069 session follows a defined sequence:

1. CPE sends Inform — device identifies itself and reports its current state.
2. ACS sends InformResponse — acknowledges receipt.
3. ACS sends RPC methods — one or more remote procedure calls: GetParameterValues, SetParameterValues, Download (firmware), Upload (log file), etc.
4. CPE executes each RPC and responds — returns values, confirms settings, reports success/failure.
5. ACS sends empty HTTP response — signals that no more RPCs are pending.
6. Session closes.

The entire session is a sequence of HTTP POST exchanges within a single HTTPS connection. The ACS queues multiple operations into one session, so a "configure Wi-Fi SSID, set DNS server, and check firmware version" operation happens in a single device contact rather than three separate sessions.

The data model: how parameters are organized

TR-069 organizes every configurable and readable parameter on a device into a hierarchical tree, similar to a file system path. The Broadband Forum publishes standardized data models — TR-181 (Device:2) for home gateways and TR-098 (InternetGatewayDevice:1) for older devices — that define the path, type, and access level (read-only or read-write) for hundreds of parameters.

Here are example parameter paths:

Device.DeviceInfo.Manufacturer
Device.DeviceInfo.SerialNumber
Device.DeviceInfo.SoftwareVersion
Device.WiFi.SSID.1.SSID
Device.WiFi.SSID.1.Enable
Device.WiFi.AccessPoint.1.Security.KeyPassphrase
Device.IP.Interface.1.IPv4Address.1.IPAddress
Device.DNS.Client.Server.1.DNSServer
Device.ManagementServer.PeriodicInformInterval

Each path identifies a specific parameter. Device.WiFi.SSID.1.SSID is the Wi-Fi network name of the first SSID. Device.DeviceInfo.SoftwareVersion is the current firmware version. The tree structure groups related parameters — everything under Device.WiFi relates to wireless configuration.

The ACS interacts with these parameters using four core RPC methods:

• GetParameterValues — read parameter values for monitoring (firmware version, WAN IP, connected clients).
• SetParameterValues — write parameter values for configuration (Wi-Fi SSID, DNS servers, speed limits).
• GetParameterNames — discover what parameters the device supports, since not all devices implement every parameter.
• AddObject / DeleteObject — create or remove instances in multi-instance nodes (for example, port forwarding rules).

The standardized data model makes TR-069 vendor-neutral. One provisioning template that sets Wi-Fi SSID, DNS, and speed limits works on any device implementing TR-181 — regardless of manufacturer. Devices also expose vendor-specific parameters (under paths like X_VENDOR_CustomParameter), but portability is lost when using those.

Common operations for ISPs

TR-069 supports a wide range of operations, but ISPs use a core set repeatedly. These operations eliminate the most time-consuming manual tasks in subscriber equipment management.

Zero-touch provisioning

When a new ONU or router is deployed at a subscriber's premises, it needs a full configuration: WAN connection type (DHCP, PPPoE, static), VLAN tags, Wi-Fi SSID and password, DNS servers, speed profile, and management credentials. Without TR-069, a technician configures each setting manually through the device's web interface — a 10 to 20 minute process per device, assuming no mistakes.

With TR-069, the device boots, contacts the ACS, and receives its entire configuration automatically:

1. The technician installs the device and powers it on.
2. The device sends a BOOTSTRAP Inform to the ACS (it has the ACS URL pre-configured or obtains it via DHCP Option 43).
3. The ACS identifies the device by serial number and looks up the subscriber's plan in the billing system.
4. The ACS pushes the full configuration in a single session: WAN settings, Wi-Fi SSID/password, speed profile, management credentials.
5. The device applies the configuration and reconnects. Total time: under 2 minutes.

For deployments of 50 or more devices per month, zero-touch provisioning saves hundreds of hours annually and eliminates configuration errors caused by manual data entry.

Firmware updates

Keeping subscriber devices on current firmware matters for security patches, bug fixes, and new features. Without remote management, a firmware update requires either a site visit (at a cost of $20 to $50 per visit) or instructions that ask the subscriber to download a file and upload it through their device's web interface (most subscribers will not attempt this).

TR-069 handles firmware updates through the Download RPC method:

1. The ISP uploads the new firmware file to a file server (HTTP or HTTPS).
2. The ACS sends a Download RPC to the device, specifying the firmware file URL, file size, and checksum.
3. The device downloads the file, verifies the checksum, applies the update, and reboots.
4. After reboot, the device sends a TransferComplete message to the ACS confirming the update.

Firmware updates can target individual devices, groups (all devices of a specific model), or the entire fleet. Staged rollouts — updating 10% of devices first, monitoring for issues, then proceeding — reduce the risk of a faulty firmware affecting all subscribers at once.

Speed profile changes

When a subscriber upgrades or downgrades their plan, the ISP needs to update the speed limit on the subscriber's device. For ONUs in bridge mode, this is typically handled at the OLT level. For ONUs in router mode or standalone routers, the device itself enforces the speed limit.

TR-069 sets speed limits through parameters like:

Device.QoS.Queue.1.ShapingRate
Device.QoS.Queue.1.ShapingBurstSize

Or vendor-specific equivalents that control downstream and upstream rate limiting on the device. The ACS pushes the new values, the device applies them, and the subscriber's speed changes within seconds — no disconnection, no site visit.

Remote diagnostics

When a subscriber reports a problem — slow speeds, intermittent disconnection, Wi-Fi issues — the first step in troubleshooting is understanding the current state of their device. Without remote management, this requires a phone call asking the subscriber to read values from their device's status page ("What does it say next to Signal Strength?").

TR-069 provides diagnostic parameters and tests:

• IP Ping diagnostic — the device pings a specified host and reports round-trip time, packet loss, and results. Determines whether the problem is on the subscriber's network or upstream.
• Trace route — the device runs a traceroute and reports each hop. Identifies where in the network path latency or packet loss occurs.
• Wi-Fi neighboring scan — the device scans for nearby Wi-Fi networks and reports their SSIDs, channels, and signal strengths. Helps identify channel congestion causing Wi-Fi performance issues.
• DSL/fiber line diagnostics — for devices with DSL or fiber interfaces, diagnostic parameters report signal-to-noise ratios, error counters, and line attenuation.

The support agent runs these diagnostics from the ACS dashboard in seconds, without asking the subscriber to do anything. The subscriber does not even need to be home — the device responds to the ACS directly.

Parameter monitoring

The ACS can configure the CPE to send an Inform whenever specific parameters change — WAN IP address, connection status, or firmware version. These passive notifications build a real-time view of device fleet health without continuous polling.

Security considerations

TR-069 runs over HTTPS, providing transport-layer encryption. But transport encryption alone does not cover all security concerns.

Device authentication. Each CPE authenticates to the ACS using HTTP Basic or Digest authentication. The ACS authenticates to the CPE via its TLS certificate. The critical vulnerability is default or shared credentials — ISPs should provision unique credentials per device, either pre-configured in the factory or set during first provisioning.

Credential storage. The ACS stores credentials for every managed device. Access controls on the ACS (role-based permissions, audit logging, two-factor authentication) are as important as the wire encryption.

Firmware integrity. The Download RPC includes a checksum that the device verifies before applying an update. ISPs should host firmware files on HTTPS servers and use SHA-256 checksums.

Network segmentation. The ACS should sit behind a firewall with access restricted to known CPE IP ranges, not directly exposed to the public internet.

When TR-069 helps most

TR-069 provides the most value in three scenarios: large ONU deployments (1,000+ subscribers) where zero-touch provisioning eliminates per-device manual setup, heterogeneous device fleets where the standardized data model lets one template work across vendors, and subscriber support at scale where remote diagnostics replace site visits for troubleshooting.

TR-369 (USP): the successor protocol

TR-369, branded as USP (User Services Platform) by the Broadband Forum, is the successor to TR-069. Published in 2018, USP addresses the limitations of TR-069 while maintaining the same fundamental concept of centralized CPE management.

Key differences from TR-069:

Persistent connections. USP supports persistent connections over WebSocket, MQTT, or STOMP, allowing instant pushes without waiting for periodic Informs.

Efficient encoding. USP uses Protocol Buffers instead of SOAP/XML, reducing message sizes by 5 to 10 times.

Bulk operations. USP supports setting hundreds of parameters across hundreds of devices in a single command.

Same data model. USP uses the same TR-181 data model. Parameter paths are identical, so migration preserves all existing provisioning templates.

Multi-controller support. USP allows multiple controllers to manage different aspects of the same device simultaneously, unlike TR-069's single-ACS limit.

For ISPs evaluating the two protocols today: TR-069 has broader device support — nearly every CPE manufactured in the last 15 years supports it. USP support is growing but limited to newer models. Use TR-069 for current fleets and plan for USP in new hardware procurement.

Deploying TR-069 in an ISP operation

A TR-069 deployment has three components: the ACS software, the network path, and billing integration.

ACS software. The management server stores device records, queues configuration changes, hosts firmware files, and provides the operator interface. Key criteria when evaluating an ACS: device capacity (hundreds vs tens of thousands), API availability for programmatic provisioning, TR-181 data model support, and firmware management with staged rollouts.

Network path. CPE devices contact the ACS at the URL configured in Device.ManagementServer.URL. For devices behind NAT, the outbound HTTPS connection works naturally. For Connection Requests (ACS to device), STUN-based NAT traversal (TR-111) or periodic Informs provide alternatives. The ACS must be reachable from every subscriber's network.

Billing integration. The full value emerges when the ACS is integrated with the billing platform. When a subscriber signs up, the billing platform tells the ACS which configuration profile to push. Plan upgrades trigger speed changes. Expiry triggers restrictions. The operator manages subscribers and plans; the billing platform translates those into device configuration; the ACS pushes it to the device. No human touches the device after installation.