TR-069 Overview
TR-069, which stands for Technical Report 069, is a technical specification developed and published by the ADSL Forum (now called Broadband Forum). This report is entitled CPE WAN Management Protocol, and defines a protocol for remote management of end-user devices.
As shown in the next figure, together with TR-069, a number of protocols and specifications have been developed to fully cover the remote management and configuration of any end-user networked device as well as integrating this management system into the operator’s backend. However, since TR-069 was the first one of these standards, “TR-069” is commonly the term used to refer to the set of functionalities provided by many of these protocols.

TR-069 and associated protocols overview
The motivation for this family of standards comes from the current complexity of CPE device configurations, where more and more services are converging (broadband data, VoIP, IPTV…). This fact sets configuration complexity too high for the end user, making it necessary for the operator to manage the device to guarantee high QoS for the end user.
TR-069 is access and device type agnostic. It is currently widely used in DSL broadband market for CPE activation, while it starts being adopted by other bodies as Home Gateway Initiative (HGI) and DVB (for example, for managing IPTV STBs).
The goal of TR-069 and its associated protocols is offering the operator the remote management (including configuration, software/firmware updates, activation, troubleshooting…) of not only the CPE (understood as the border device), but also the inhome networked devices. The main protocols and standards are:
- TR-069. Remote management protocol and routing gateway configuration and management.
- TR-106 and TR-111. Combine to allow the remote management of devices on a LAN, even those using the private IP space behind a NAT gateway
- TR-98. Services differentiation (QoS) in the home network.
- TR-135 and TR-140. Object model for the STB and a network storage respectively. Goals of TR-135:
- Support various types of STB, e.g. satellite, cable, terrestrial and IP STBs, with or without PVR
- STB may be embedded in an Internet Gateway
- Enable troubleshooting and remote configuration
- Note that, unless the STB or network storage are edge devices, TR-106 and TR-111 support will also be required.
- TR-104. VoIP Object model.
TR-069. Components and operation
TR-069. Components
To implement the TR-069 family of protocols, there are two main components required for the operator to deploy, the Auto Configuration Server (ACS), and the TR-069 client.
The ACS is located in the operator premises and it is ideally connected to both the operator OSS/BSS and the operator call center. Connection to the OSS/BSS will allow the ACS to access firmware/software/and configuration files in order to send them to the managed devices while connection to the call center will ease troubleshooting.
The TR-069 client is embedded in the different end-user devices (DSL CPE, home gateway, IPTV STB, VoIP phone…) supporting TR-069.
If both components are fully compliant with the standard specifications, any vendor ACS should work with any vendor client, making it possible for the operator to reuse any existing component and just include the complementary one.
TR-069 Operation
Connection
- TR-069 is based on sending Remote Procedure Calls (RPC) methods in SOAP messages (standard XML-based syntax), transported over a SSL/TLS, over HTTP, over TCP/IP connection, between a CPE and a Management Server.
- TR-069 is running on top of IP, and is transparent to any access technology (example TR-142: TR-069 for PON and fiber access).
Session
- A TR-069 session is always started from the side of the CPE, after the CPE has successfully authenticated. However, it is also possible to have asynchronous ACS initiated notifications.
Data structure
- In TR-069, parameters are arranged in an object model. The object model is build up as a tree like structure.
- TR-069: use of XML-open standard and human readable, easy to share info with other applications.
- Under a root object (a CPE) different service objects can be grouped. A service object can contain basic parameters, an object or multiple instances of an object. Those are building blocks that can be used to create a full object model for a complex device with different services.
- Notion of profiles, the object models are generic.
- TR-106 (template for TR-069 devices), TR-104: VoIP, TR-98: QoS differentiation, TR-135: STB, …
Security
- Security is enhanced with TR-069 by the CPE initiating all communication
- TR-069 utilizes a SSL/TLS connection to provide a single secure connection via x.509 certificate with Public / Private key technology to provide high security encryption and Certificate based authentication
- Moreover, the CPE can use the same x.509 certificate to provide encryption. Client devices are authenticated via the widely implemented HTTP authentication.
Software upgrade\Configuration\Download\File upload
- TR-069 defines separate methods to be used for download and upload of files and software (https). By using the TransferComplete RPC, the CPE can report the results of the download or upload action to the ACS.
Eventing
- The TR-069 eventing mechanism is based on providing active or passive notification on parameter changes. The notification mechanism can be activated by setting, with the SetParameterAttributes RPC, the appropriate Notification attribute on a parameter, an object or a path in the object model.
Functionalities and advantages for the operator
TR-069 family of standards is now described mentioning the functionality offered together with the advantages and added value offered to the operator as a result of these implemented functionalities.
TR-069. Main functionalities
- Auto-configuration and dynamic service provisioning
- Initial CPE configuration
- Re-provisioning at any subsequent time
- Allow vendor-specific parameter configuration
- Software/firmware image management
- Version identification
- File download initiation
- Notification of the success or failure of a file download
- Status and performance monitoring
- Log file and dynamic notification
- Diagnostics
- Connectivity and service issues
- End-users devices (RG, STB, VoIP,…) management
- TR-069 can go directly to end-users devices
- TR-111 defines a mechanism for the ACS to learn which Gateway is associated with a given device.
- TR-111 defines a standard mechanism to ensure the ACS can initiate contact with the Device using the TR-069 Connection Request mechanism (CPE maintains the NAT binding alive using the STUN process)
- Or TR-069 can manage services on the remote gateway for other end-user devices (for example, manage the VoIP client for a telephone)
TR-069 / TR-135. Use cases for IPTV operators
A number of remote management use cases can be considered for remote management of TV platform devices. Some of them are presented here. The STB data model supports at least the functionality that is implied by these use cases. Classification of remote management activities can be done by making reference to the FCAPS model for systems management, where FCAPS stands for:
- Fault
- Configuration
- Accounting
- Performance
- Security
The STB data model does not need to account for all of the FCAPS functions. Usually, the FCAPS functions supported are Fault, Configuration and Performance. Accounting and Security functions usually take advantage of pre-existing infrastructure, so the relevant use cases are not considered here.
Configuration of the STB is done both by the IPTV Service Platform and by higher layer OSSs via the ACS. It can also be done by a trained technician, usually as a reaction to an end user complaint. This latter activity is here referred to as Trouble Management.
Performance Management can be performed by the ACS on a regular basis, to try and identify a malfunction as soon as it occurs, or by trouble management personnel on a limited set of STBs for special purposes.
Fault Management is generally driven by fault notifications from the STB. It is usually carried out automatically by higher layer OSS systems, based on signaling from the ACS.
Configuration
The ACS may perform some initial configuration of a newly installed STB. For example, it might initiate a channel scan in order to populate a DTT service list database, or it might set some user preferences such as audio and subtitling languages. During the initial configuration, the ACS can also update the STB firmware. Most of the initial configuration will be performed by the IPTV Service Platform.
Trouble Management
A trained technician may take control of the STB, generally in response to a customer complaint. The STB malfunction may be the result of improper customer settings, or may be due to network or hardware problems. Access to the STB data model allows the technician to carry out a number of tasks, namely:
- Verify/Restore the STB configuration. The STB data model parameters under the ACS control can be re-configured to the correct values contained in the ACS.
- Verify/Update software version. Incorrect software version (e.g. the STB was switched off for a long time and was not included in the last software upgrade campaign) can cause improper operation. In this case the operator can force an upgrade of the STB software to the latest release.
- Perform diagnostics. The technician can run diagnostic tests to identify whether the trouble is in the network (and at which point) or the STB and try to classify the trouble.
Depending on the cases, the technician can carry out actions on specific subsets of STBs (identified e.g. by a range of serial numbers, by a specific software/hardware version, by the geographical area they are in) or on single devices.
Performance Management
The ACS carries out automatic monitoring of STB performance. Performance reports can include QoS parameters (e.g. network parameters such as average bit rate, jitter and packet loss ratio), QoE parameters (e.g. visual quality indicators or indicators of how fast on the average the channel change is), usage statistics (e.g. how many STBs were on at a certain time, or for how long each of them remained tuned to a certain channel). Monitoring campaigns may be performed:
- Periodically on all STB devices to check that network and devices are working properly.
- On subsets of STB devices, for instance after identifying problems by means of periodic tests. Criteria to select subsets can be geographical or tied to specific characteristics of the STBs (manufacturer, hardware and/or software version).
- Periodically on specific STB devices. The problem here could be the management of a SLA (Service Level Agreement) with subscribers to premium services. Performance management could be used to identify problems on these lines as soon as they show up. Trouble management technicians could then act to (try to) solve them.
STB QoS and QoE reporting capabilities allow for “in service” “passive” measurements done at the service level. These are of fundamental importance to an operator in a number of cases, a number of which are listed hereinafter. Other cases are possible beyond those listed here:
• Understand and measure the QoE delivered to individual end users, via collection and aggregation of STB reports across the user base.
- Troubleshoot the service delivered: STB reporting allows near real time processing of collected reports and correlation of indicators that let the operator determine where the fault lies: in the head end, in the network, in the local loop, in the home network, or in the STB itself.
- Assess and measure the IPTV service as delivered in the mid to long term, and define and control whether performance objectives are being met.
- Pro-actively catch some hidden behavior which is increasing, and is reducing service performance, but has not yet been noticed by the end user.
- Pro-actively manage certain end users who are receiving a poor level of service but who have not yet called customer care.
- Configure and define operations management service quality thresholds on aggregated reports that can be tuned in order to take action before problems are noticed or reported by the end users.
- Understand loop and end-to-end behavior in order to design and assess error correction strategies for the IPTV service.
- Manage service maintenance and understand the impact on the IPTV service of any changes in the network, device upgrades or new device insertion.
Fault Management
The ACS automatically collects events from the STB for various reasons, including detection of faults. A way to detect faults taking advantage of TR-069 notification features could be the following: the data model contains parameters describing the operational status of specific functional blocks in the STB, and Active Notification is enabled for these parameters. In case of an STB error these parameters change their values and the Active Notification mechanism delivers information about the STB fault to the ACS. The ACS recognizes the fault and consequently notifies the OSS in charge of the End-to-End Fault Management operations.