Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Sv translation

Technical Report 069 (TR-069) is a technical specification of the Broadband Forum that defines an application layer protocol for remote management of customer-premises equipment (CPE) connected to an Internet Protocol (IP) network. TR-069 uses the CPE WAN Management Protocol (CWMP) which provides support functions for auto-configuration, software or firmware image management, software module management, status and performance managements, and diagnostics.

The CPE WAN Management Protocol is a bidirectional SOAP- and HTTP-based protocol, and provides the communication between a CPE and auto configuration servers (ACS). The protocol addresses the growing number of different Internet access devices such as modems, routers, gateways, as well as end-user devices which connect to the Internet, such as set-top boxes, and VoIP-phones.


Table of Contents



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), the CPE acts as client and ACS as HTTP server. This essentially means that control over the flow of the provisioning session is the sole responsibility of the device.

Image Added

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 initiated by a previously issued Download or Upload request. This 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 the CPE via CWMP, it is essential to provide a 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 the 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

Initialization and control of the provisioning session flow is the sole responsibility of the device, but it is possible for the ACS 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.

Connection request 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 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 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. 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 or read-only, depending on what it represents. Writable objects allow dynamic creation and removal of their children. For example, if an object represents four physical ports on an Ethernet switch, then 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 cannot change during the life-cycle of the device, except by 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 fulfill the order a proper error must be returned to the ACS – the device should never break the provisioning session.

GetParameterNamesRetrieve list of supported parameters from the device.
GetParameterValuesRetrieve current value of the parameter(s) identified by keys. A variation of this call takes an object as its key. It retrieves all of the object's parameters
SetParameterValuesSet the value of one or more parameters
GetParameterAttributesRetrieve attributes of one or more parameters
SetParameterAttributesSet attributes of one or more parameters
DownloadOrder CPE to download and use a file, specified by URL. File types include Firmware Image, Configuration File, Ringer file, etc.
UploadOrder CPE to upload a file to a specified destination. File types include the current configuration file, log files, etc.
AddObjectAdd new instance to an object
DeleteObjectRemove instance from an object

High-level operations possible through TR-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


The compromise of an ISP ACS or the link between an ACS and CPE by unauthorized entities can yield access to the TR-069-enabled devices of a service provider's entire subscriber base. Customer information and device operation would be available to the potential attackers, including other MAC addresses on client's networks. Covert redirection of DNS queries to a rogue DNS server might be possible, and even surreptitious firmware updates with backdoor features. TR-069 ACS software has been found to be often implemented insecurely.Flaws in combined implementations of TR-064 (LAN side DSL CPE configuration) and TR-069 (CWMP), that reused the same HTTP endpoint over public internet for Connection Requests without proper protections, were found in devices by various vendors and are exploited by Mirai-based botnet and other malware.


Include Page
Howto Footer - uni-en
Howto Footer - uni-en

Content by Label
cqllabel = "glossary" and label = "network" and type = "page"
labelsdect dect-multicell

Sv translation

TR-069 ist ein Protokoll zum Datenaustausch zwischen dem Server eines Kommunikationsanbieters und einem damit verbundenen Endgerät beim Kunden. Ein typischer Anwendungsfall ist die Fernkonfiguration von DSL-Routern durch einen Breitbandanbieter. Technisch gesehen handelt es sich um ein bidirektionales SOAP-Protokoll für die HTTP-basierte Kommunikation zwischen Kundengeräten (engl. Customer Premises Equipment, kurz CPE) und Auto-Configuration-Servern (ACS). Es ist daher auch bekannt als CPE WAN Management Protocol (CWMP).


Table of Contents

Fernzugriff auf Konfiguration

Im DSL-Breitbandmarkt stellt TR-069 den dominierenden Anschaltstandard für Zugangsgeräte dar. Die technischen Spezifikationen (TR-069) werden vom Broadband Forum veröffentlicht.

Das Protokoll umfasst Methoden für die Autokonfiguration als auch zur (An-)Steuerung anderer CPE-Funktionen in einem einheitlichen Framework. Dabei werden verschiedene Arten von CPEs unterschieden. Beim Grundtyp handelt es sich um Breitband-/DSL-Ausrüstung, wie z. B. DSL-Router.


TR-069 im :

InternetIP (IPv4, IPv6)

Mit dem Markterfolg von Breitbandzugängen zum Internet steigt die Anzahl sonstiger Zugangsgeräte (z. B. neben Modems und Routern auch Residential Gateways, Set-Top-Boxen, Spielkonsolen, IP-Telefone und IP-TV-Streaminglösungen).

Da sich die Komplexität dieser Geräte erhöht, überfordert deren Konfiguration viele Benutzer. Daher wurde mit TR-069 ein Protokoll entworfen, das einem Zugangsprovider die Fernwartung dieser Geräte ermöglicht. Via TR-069 können Endgeräte Kontakt zum Auto-Configuration-Server (ACS) des Providers aufnehmen und automatisch konfiguriert werden.

Neben dem TR-069-Kernstandard für DSL-Router gibt es Nebenstandards für andere Endgeräte hinter der NAT/Firewall des DSL-Routers – und mit dem Zugriff auf diese. Das Broadband Forum möchte den Standard TR-069 auch auf Glasfaser-Technologien und Femtocell-Router ausdehnen.

Image Added


TR-069 erlaubt dem Provider, automatische Aktualisierungen in DSL-Router einzuspielen. Diese können sogar zielgerichtet für bestimmte Benutzer oder Benutzergruppen eingerichtet werden.

Zudem ermöglicht es TR-069 auch, andere Geräte zu konfigurieren, die sich im „sicheren Bereich“ hinter der Box oder dem Modem befinden, also hinter der Firewall. Durch Fernzugriff könnten so auch Daten auf bestimmten Kundengeräten, auf die der Netzbetreiber Zugriff hat, geändert oder gelöscht werden.

Von TR-069 unterstützte Funktionen

  • Autokonfiguration und dynamische Dienstaktivierung
    • Initiale CPE-Konfiguration
    • Remote-CPE-Konfiguration
  • Firmware-Management
    • Versionsverwaltung
    • Aktualisierungsverwaltung
  • Passwörter des Gerätes ändern/zurücksetzen
  • Status- und Leistungskontrolle
    • Logdateiauswertung und dynamische Mitteilungen
  • Diagnose
    • Konnektivität und Service-Kontrolle
    • 100%ige Interoperabilität zwischen Management-Server und CPEs.

In Zukunft wird TR-069 über reine Anschaltstandards hinaus auch viele Zusatzfunktionen der CPEs steuern, wie zum Beispiel:

  • Abfrage der Gerätefunktionen
  • Informationsabfrage, Diagnose, Status und Leistungswerte
  • Automatische Ereignis-getriggerte Alarmfunktionen
  • Unabhängiges Gateway-Daten-Modell; in Verbindung mit TR-064 erweiterbar, um zusätzliche Geräte und Funktionen einzubinden
  • Das Router-Frontend (die Bedienoberfläche) ist zur Konfiguration nicht unbedingt erforderlich, alle Funktionen können vom Management-Server überwacht und gesteuert werden.


Das Broadband Forum veröffentlicht bereits verabschiedete Standards, sogenannte TRs (Technical Reports) auf seiner Webseite.

Die Entwürfe sind nicht öffentlich und werden als Working Text (WT) oder Proposed Draft (PD) bezeichnet. Working Texts sind Entwürfe zu Standards und werden in der Regel zu TRs. Proposed Drafts sind weitere Dokumente der Arbeitsgruppen, die interne Verwendung finden (z. B. PD-128, Interoperabilitäts-Testplan für TR-069-Plugtests), sie können aber auch eine Vorstufe zu Working Texts sein.

Die Nummerierung der Standards ist dreistellig und linear, d. h., sie beginnt bei 001 und wird fortlaufend hochgezählt. Wird ein WT zum TR, ändert sich die Nummerierung nicht. Zum Teil werden Nachträge (Amendments) unter der gleichen Nummer mit dem Zusatz „Amendment“ und einer weiteren Nummerierung (Amendment 1, …) versehen, die das vorherige Dokument ersetzen. Dafür können zum Beispiel, trotz verabschiedetem TR, WTs mit gleicher Nummer existieren (z. B. TR-106 Amendment 1 und WT-106 für ein Amendment 2 (geplant für November 2008)).


Include Page
Howto Footer - de
Howto Footer - de

Content by Label
cqllabel = "glossary" and label = "network" and type = "page"
labelsdect dect-multicell