Menu-Submenu

TR


Broadband Forum Technical Specifications


TR-069 (Technical Report 069)
TR-069 (also known as CWMP, CPE WAN Management Protocol) is an Internet protocol based on XML/SOAP.
It is intended for communication between a CPE and Auto-Configuration Server (ACS). It is an application layer protocol for remote and safe management (configuration) of network devices [customer-premises equipment (CPE) connected to an Internet Protocol (IP) network]. Configuration is managed by a central server (ACS - Auto Configuration Server).
It defines a mechanism into a common framework to support a variety of functions to manage a collection of CPE, including following primary capabilities,
  • secure auto-configuration and dynamic service provisioning of a CPE,
  • software or firmware image management,
    • firmware upgrade/downgrade
  • software module management,
  • status and performance management/monitoring, and
    • Parameter value retrieval
    • Log file retrieval
  • diagnostics
    • Throughput (TR-143) and connectivity diagnostics
  • Configuration management
    • configuration backup/restore
  • 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
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.
It is a text based protocol, a bidirectional SOAP/HTTP-based protocol. Orders sent between the CPE and ACS are transported over HTTP (or more frequently HTTPS). At this level (HTTP), the CPE acts as client and ACS as HTTP server.


Device connection to ACS

A proper connection between a device and the ACS requires following parameters to be configured on the device:
  1. ACS URL    - accessible from this device,
  2. Periodic Inform Interval    - as frequency of communication with the ACS,
  3. Username and password    - (optional) for data verification, as per security level

Communication between Device & ACS

The connection between the device and the ACS is not permanent. The device establishes the connection with the ACS only at specific points in time. It usually lasts several seconds, just enough to exchange all necessary messages between CPE and the ACS. This short exchange of messages is called a provisioning session.
Provisioning session
All communications and operations are performed in the scope of the provisioning session. It is divided into following few phases,
  1. Session initialization    : The session is always initialized by the device that connects to the ACS. Similar to Initialization, control of the provisioning session flow is the sole responsibility of the device.
  2. Authentication    : The ACS must verify a username and a password provided by the device to continue the session. By default the password is not sent publicly because HTTP Digest method is used. Additional security of the authentication can be achieved by using the HTTPS protocol with mutual certificates verification.
  3. Device identification : Devices are identified on the basis of information sent during initialization of the provisioning session. Namely, a device's serial number and manufacturer's unique identifier that together constitute a main identifier of the device in the ACS. A MAC address is not used as an identifier but it is saved by the ACS, making it easier to find the device in the ACS GUI later on.
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.
  1. Tasks execution on the device : When the device is identified and its communication part ends, a key phase of the session starts - the ACS orders various tasks on the device. These might include reading (GET) or saving (SET) parameters, performing diagnostics, rebooting or ordering file transfers.
The CPE keeps sending HTTP POST requests during the session.
  1. Session closure : When all planned tasks have been ordered, the device closes the session; as soon as both CPE & ACS  have indicated that they have nothing more to send (response or new RPC). Any further tasks need initialization of a new session.

Events when device contacts ACS
Device communicate using following reason on respective events,
  • BOOTSTRAP : The ACS URL is saved or changed on the device or the device is reset to factory settings
  • PERIODIC : A new periodic visit is to begin according to the value set in Periodic Inform Interval
  • CONNECTION REQUEST : The device responds to the ACS request for immediate connection
  • VALUE CHANGE : A value of a parameter for which active notification is enabled changes
  • BOOT : The device is reset or is reconnected to the power supply
  • SCHEDULED : During one of the previous sessions the ACS ordered the device to initiate the contact with ScheduleInform command
  • TRANSFER COMPLETE : The device wants to report execution of previously ordered download or upload methods
  • DIAGNOSTIC COMPLETE : The device wants to confirm a previously ordered diagnostic
The manufacturer of the device can add custom events that will also make the device connect to the ACS.
Knowing reasons for Session Initialization is useful,
  • to order the device to perform various tasks depending on a particular context. eg, when the device connects for the first time.
  • to analyze reasons for last visits and find out abnormalities regarding device’s activities.
NOTE : The session can be started only by the device. However, the ACS can send a request to establish a connection, that is CONNECTION REQUEST, which makes the device contact the ACS if it is properly implemented. CONNECTION REQUEST is used when changes in the configuration require to be deployed immediately. Instead of waiting for the device to connect, the ACS can in advance inform the device about a need of connecting to the server, and introduce changes when it happens.

Security

TR-069 provides several mechanisms that guarantee robust security.
  • Authentication
    • Device authentication uses username and password (by default HTTP Digest, so the password is not sent publicly).
    • SSL/TLS certificates can be used to mutually verify ACS' and device's identities.
    • Usage of unique usernames per device as well as random and individual passwords can significantly improve security.
  • Communication
    • using HTTPS is highly recommended, for whole communication with the ACS to be encrypted and resistant to eavesdropping.
  • Other
    • A proper strict configuration of the device's firewall to improve the security (a range of IP addresses that perform Connection Request should be limited to a safe pool).

Benefits

Managing devices via TR-069 has benefits as,
  • Greater control over devices’ settings in comparison to managing using configuration files.
  • Sending initial configuration automatically, shortens time needed for installing the devices at the customers’ premises.
  • Performing crucial operations remotely, reduces manual maintenance & visits. Operations such as changing configuration, turning services off/on and performing diagnosis. Long lasting operations such as upgrading device's firmware and backing up its configuration can be scheduled to take place off-peak hours.
  • Network optimization settings for devices reduces failures. Setting for the best Wi-Fi channels.
  • Facilities Monitoring, which automates the control of the network state.
  • Collects data that can be used in business analysis, for example, detecting active users to whom additional offers can be made.




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.
Data model standards is available in two formats,
  1. XML files containing a detailed specification of each subsequent data model and all of the changes between their versions, and
  2. PDF files containing human-readable details. Supported standards and extensions should be clearly marked in the device data model.
GetParameterNamesResponse message
Each of the parameters may be marked as writable or non-writable, which is reported by the device in this message.
Writable objects allow dynamic creation and removal of their children.
In case of Multi-instance objects, 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.
Data Model requires TR-181-2-2-0 Device-2.3 + Custom data model
TR-098: Internet Gateway Device Data Model for TR-069
TR-104: Provisioning Parameters for VoIP CPE
TR-135: Data Model for a TR-069 Enabled STB
TR-140: TR-069 Data Model for Storage Service Enabled Devices
TR-143: Enabling Network Throughput Performance Tests and Statistical Monitoring
TR-181: Device Data Model for TR-069


References :
  1. "TR-069" https://en.wikipedia.org/wiki/TR-069
  2. "Crash course in TR-069 (CWMP)" https://www.avsystem.com/crashcourse/tr069/
  3. "CPE WAN Management Protocol" https://www.broadband-forum.org/download/TR-069_Amendment-5.pdf
  4. "QA Cafe TR-069 Training Series - Overview of a TR-069 Session" https://www.youtube.com/watch?v=FeI9xYu51_8
  5. "How do you test TR 069 enabled devices" https://www.youtube.com/watch?v=NJY0MF5xyYw

Labels: