TR-069

TR-069
TR-069 (Technical Report 069) is a Broadband Forum (formerly known as DSL Forum) technical specification
entitled CPE WAN Management Protocol (CWMP). It defines an application layer protocol for remote management
of end-user devices. As a bidirectional SOAP/HTTP-based protocol, it provides the communication between
customer-premises equipment (CPE) and Auto Configuration Servers (ACS). It includes both a safe auto
configuration and the control of other CPE management functions within an integrated framework. The protocol
addressed the growing number of different Internet access devices such as modems, routers, gateways, set-top boxes,
and VoIP-phones for the end-users. The TR-069 standard was developed for automatic configuration of these
devices with Auto Configuration Servers (ACS). The technical specifications are managed and published by the
Broadband Forum. TR-069 was first published in May 2004, with amendments in 2006, 2007, 2010, July 2011 to
version 1.3. and November 2013 to version 1.4 (am5)
Other forums, such as the Home Gateway Initiative (HGI), Digital Video Broadcasting (DVB) and WiMAX Forum
endorsed CWMP as the protocol for remote management of home network devices and terminals (such as the DVB
IPTV set-top box). There is a growing trend to add TR-069 management functionality to home networking devices
behind the gateway, as well as many other access devices like M2M,[1] FTTH CPE/ONTs, WIMAX CPE[2] and
other carrier access equipment.

Communication between the device and ACS

Transport details
CWMP is a text based protocol. Orders sent between the device (CPE) and auto configuration server (ACS) are
transported over HTTP (or more frequently HTTPS). At this level (HTTP) CPE is behaving in the role of client and
ACS in the role of HTTP server. This essentially means that control over the flow of the provisioning session is the
sole responsibility of the device.

Provisioning session
All communications and operations are performed in the scope of the provisioning session. The session is always
started by the device(CPE) and begins with the transmission of an Inform message. Its reception and readiness of the
server for the session is indicated by an InformResponse message. That concludes the session initialization stage.
The order of the next two stages depends on the value of the flag HoldRequests. If the value is false the initialization
stage is followed by the transmission of device requests, otherwise ACS orders are transmitted first. The following
description assumes the value is false.
In the second stage, orders are transmitted from the device to the ACS. Even though the protocol defines multiple
methods that may be invoked by the device on the ACS, only one is commonly found - TransferComplete which is
used to inform the ACS of the completion of a file transfer previously issued Download or Upload request. This

TR-069
stage is finalized by transmission of empty HTTP-request to the ACS.
In the third stage the roles change on the CWMP level. The HTTP-response for the empty HTTP-request by the
device will contain a CWMP-request from the ACS. This will subsequently be followed by an HTTP-request
containing a CWMP-response for the previous CWMP-request. Multiple orders may be transmitted one-by-one. This
stage (and the whole provisioning session) is terminated by an empty HTTP-response from the ACS indicating that
no more orders are pending.
Security and authentication
As vital data (like user names and passwords) may be transmitted to CPE via CWMP, it is essential to provide secure
transport channel and always authenticate the CPE against the ACS. Secure transport and authentication of the ACS
identity can easily be provided by usage of HTTPS and verification of ACS certificate. Authentication of the CPE is
more problematic. The identity of the device is verified based on a shared secret (password) at the HTTP level.
Passwords may be negotiated between the parties (CPE-ACS) at every provisioning session. When the device
contacts the ACS for the first time (or after a factory-reset) default passwords are used. In large networks it is the
responsibility of the procurement to ensure each device is using unique credentials, their list is delivered with the
devices themselves and secured.

Connection request
Because initialization and control of the provisioning session flow is the sole responsibility of the device, it is
necessary for the ACS to be able to request a session start from the device. The connection request mechanism is
also based on HTTP. In this case the device (CPE) is put in the role of HTTP-server. The ACS requests a connection
from the device by visiting a negotiated URL and performing HTTP Authentication. A shared secret is also
negotiated with the device in advance (e.g. previous provisioning session) to prevent the usage of CPEs for DDoS
attacks on the provisioning server (ACS). After confirmation is sent by the device the provisioning session should be
started as soon as possible and not later than 30 seconds after confirmation is transmitted.
CR over NAT
The CWMP protocol also defines a mechanism for reaching the devices that are connected behind NAT (e.g.
IP-Phones, Set-top boxes). This mechanism, based on STUN and UDP NAT traversal, is defined in document
TR-069 Annex G (formerly in TR-111).
Amendment 5 of the protocol introduces alternative method of executing Connection Request via NAT based on
XMPP (see Annex K of TR-069 Amendment 5 [3] for details).

Data model
Most of the configuration and diagnostics is performed through setting and retrieving the value of the device
parameters. These are organized in a well defined hierarchical structure that is more or less common to all device
models and manufacturers. Broadband Forum publishes its data model standards in two formats - XML [4] files
containing a detailed specification of each subsequent data model and all of the changes between their versions and
PDF files containing human-readable details. Supported standards and extensions should be clearly marked in the
device data model. This should be in the field Device.DeviceSummary or InternetGatewayDevice.DeviceSummary
which is required starting from Device:1.0 and InternetGatewayDevice:1.1 respectively. If the field is not found
InternetGatewayDevice:1.0 is implied. As of Device:1.4 and InternetGatewayDevice:1.6 new field (
'<RO>'.SupportedDatamodel) for supported standard specification was introduced.
The model is always rooted in the single key named Device or InternetGatewayDevice depending on the
manufacturer's choice. At each level of the structure objects and parameters (or array-instances) are allowed. Keys
are constructed by concatenating the names of objects and parameter using '.'(dot) as a separator, e.g.

TR-069

InternetGatewayDevice.Time.NTPServer1 .
Each of the parameters may be marked as writable or non-writable. This is reported by the device in
GetParameterNamesResponse message. The device should not permit the change of any parameter marked as
read-only. Data model specifications and extensions clearly mark required status of most of the parameters.
Values applicable for the parameter, their type and meaning are also precisely defined by the standard.

Multi-instance objects
Some parts of the data model require the existence of multiple copies of the subtree. The best examples are those
describing tables, e.g. Port Forwarding Table. An object representing an array will only have instance numbers or
alias names as its children.
A multi-instance object may be writable (enabling dynamic creation and/or removal of its children) or read-only
depending on the data represented. If for example the object represents four physical ports on a switch it should not
be possible to add or remove them from the data model. If an instance is added to an object an identifier is assigned.
After being assigned, identifiers may not change during the life-cycle of the device except for factory-reset.

Common problems
Even though the list of the parameters and their attributes is well defined most of the devices do not follow standards
completely. Most common problems include missing parameters, omitted instance identifiers (for multi-instance
objects where only one instance is present), wrong parameter access level and correctly using only defined valid
values. For example, for the field that indicates supported standard of WLAN protocols, the value 'g' should indicate
support of 802.11b and 802.11g, and 'g-only' support only of 802.11g. Even though values such as 'bg' or 'b/g' are not
legal according to the Broadband Forum standards, they are very commonly found in device data models.

Common operations
The whole provisioning is built on top of a defined set of simple operations. Each order is considered atomic, though
there is no support of transactions. If the device cannot fulfil the order a proper error needs to be returned to the ACS
- the device should never break the provisioning session.
Message

Description

GetParameterNames

Used to retrieve list of supported parameters from the device.

GetParameterValues

Retrieve current value of the parameters identified by keys. Could be used to retrieve one or multiple parameters at once.
The version of the call with object as the key allows for retrieval of all of the parameters associated with that object

SetParameterValues

Sets the value of one or multiple parameters

GetParameterAttributes Retrieves attributes of one or multiple parameters

SetParameterAttributes Sets attributes of one or multiple parameters
Download

Orders CPE to download the file specified by URL and use it (depending on specified file type) as a Firmware Image,
Configuration File, Ringer file, etc.

Upload

Orders CPE to upload specified file type to the specified destination. This could cover, for example, the current
configuration file or log files.

AddObject

Adds new instance to an object

DeleteObject

Removes instance from an object

TR-069

High-level operations possible through Technical Report-069

Service activation and reconfiguration
Initial configuration of the service as part of zero-touch or one-touch configuration process
Service re-establishment (ex. after device is factory-reset, exchanged)
Remote Subscriber Support
Verification of the device status and functionality
Manual reconfiguration
Firmware and Configuration Management
Firmware upgrade/downgrade
Configuration backup/restore
Diagnostics and monitoring
Throughput (TR-143) and connectivity diagnostics
Parameter value retrieval
Log file retrieval

References
[1] TR-069: Still Sexy After All These Years (http:/ / www. lightreading. com/ tr-069-still-sexy-after-all-these-years/ a/ d-id/ 706234)
[2] Architecture, detailed Protocols and Procedures WiMAX Device Reported Metrics & Diagnostics (DRMD) - Release 2 (http:/ / www.
wimaxforum. org/ resources/ documents/ technical/ T33)
[3] http:/ / www. broadband-forum. org/ technical/ download/ TR-069_Amendment-5. pdf
[4] http:/ / www. broadband-forum. org/ cwmp. php

External links
TR-069 Issue 1 Amendment 5 (http://www.broadband-forum.org/technical/download/
TR-069_Amendment-5.pdf) CPE WAN Management Protocol v1.4
CPE WAN Management Protocol (http://www.broadband-forum.org/cwmp.php) CWMP XML Schemas and
Data Model Definitions
Marketing Report (http://www.broadband-forum.org/marketing/download/mktgdocs/MR-230.pdf) TR-069
Deployment Scenarios, Issue: 1, August 2010

Article Sources and Contributors

Article Sources and Contributors

TR-069 Source: http://en.wikipedia.org/w/index.php?oldid=623208262 Contributors: 777sms, A kalhori, Advancedtelcotv, Amontero, Arjayay, Bcarrick, Beetstra, Benw01, Bitrot, Canaima,
Caract7777, Dank, David.howarth, Enricog, Francis Henry, Francoislaurent, Fredriku, Guy Harris, Hu12, Itusg15q4user, Janushao, Jaysonks, Jithu.222, John of Reading, Jsam000, JzG,
KenSharp, Ksharf, Ksteuernagel, Kurt subzero, Mannyvel1, Mcleveland, MichaelPloujnikov, Mypslim, Nkopsias, Paul, Peeterko2, Pierky, Pnagalap, RBayliss2009, Realityondemand, Reedy,
Rich257, Rory096, Senexcanis, Smcanby, Snaxion, Starbois, Stephan Leeds, Sternagel, Stevevogelnu, Subash.majety, Sumanshailesh, TheGoblin, Trusilver, W Nowicki, WODUP, Woohookitty,
Wwwhizz, Ykikuchi, Zamarlik, Zukin, 260 anonymous edits

Image Sources, Licenses and Contributors

File:Remote CPE Control via TR-069.jpg Source: http://en.wikipedia.org/w/index.php?title=File:Remote_CPE_Control_via_TR-069.jpg License: GNU Free Documentation License
Contributors: de:user:Sternagel

License
Creative Commons Attribution-Share Alike 3.0
//creativecommons.org/licenses/by-sa/3.0/