Specification of Technical Report 069
\n\n The operation and control\n
\n\n The TR-069 specification describes the CPE WAN Management Protocol (CWMP). CWMP defines the principles of interaction between customer devices (CPE) and the Auto-Configuration Server (ACS). According to TR-069, ACS is a network device and application server that automates execution of basic methods of control over customer devices (CPE).\n
\nAmong basic methods of control should be mentioned:
\n- \n
- \n Automatic configuration and dynamic reconfiguration of services (the services rendered to the customer by its provider, such as Internet access, VoIP, IPTV)\n \n
- \n Control over CPE software\n \n
- \n Monitoring of the current status and performance parameters of CPE.\n \n
- \n Diagnostics\n \n
\n The southbound interface provides the implementation of the above listed control functions with respect to CPEs. Nowadays the CPEs managed by TR-069 include Integrated access devices (IAD), PON and associated optical devices, VoIP devices, IPTV set-top boxes, and other home network devices.\n
\n\n The northbound interface provides the interaction of ACS with other OSS/BSS systems of provider as part of implementation of unified end-to-end service management processes.\n
\n\n The functions of control\n
\n\n The key and highly demanded CPE management feature is automatic configuration and dynamic reconfiguration of services. The specification defines the possibility of both primary and subsequent configuration of CPE, for example, at the request of customer or in case of changing certain parameters of the service. TR-069 defines the ability to perform configuration operations with respect to one specific CPE or to multiple groups, united by one or several common features, such as the manufacturer of the CPE, model, firmware version, etc. The CPE software control function is responsible for software downloading to device. The protocol defines the mechanisms for identification of the versions of managed software, activation (initiated by ACS or CPE), execution and completion of image files downloading, logging and support desk notification about the downloading performance. In addition to direct CPE configuration management functions, CWMP defines methods for providing access to information that can be used by ACS server for monitoring the status and performance of CPE. CWMP also defines the set of mechanisms that allow CPE separately notify ACS about changes in its functional state. Apart from CPE monitoring capabilities, CWMP also provides diagnostic mechanisms, including list of parameters that may contain diagnostic information and methods for providing of diagnostic information.\n
\n\n CWMP architecture\n
\n\n The architecture of CWMP protocol includes CWMP protocol stack, used for initiation of communication between ACS and CPE, CWMP parameters and CWMP procedures.\n
\n\n CWMP protocol stack\n
\n\n CWMP protocol is implemented as a set of standard and specifically developed protocols.\n
\n\n CWMP parameters\n
\n\n CWMP parameters are represented in a form of data model whose structure is defined by another Broadband Forum document - “TR-106: Data Model Template for TR-069-Enabled Device”. The main purpose of parameters is to provide ACS information about characteristics and status of CPEs, and to manage their configuration. Parameters can be specified as read-only or read-write. The read-only parameters can be used by ACS server for evaluation of specific characteristics of CPE, its current state or for receiving of accumulated statistics. The read-write parameters allow ACS server to change the CPE configuration. In CWMP, all parameters are combined into hierarchical structure. This data structure in CWMP is represented as an object. Each object contains one parameter or set of parameters. Each CPE has only one main object (root), that depending on the type of device will assume the value Device or Internet Gateway Device. In most cases, the main object includes three elements: Common Objects, Components, Service Objects. Common Objects contains parameters that define the type of CPE.\n
\nCommon Object branch parameters are used for identification of CPEs on ACS and include:
\n- \n
- \n DeviceInfo\n \n
- \n ManagementServer\n \n
- \n GatewayInfo\n \n
- \n Time\n \n
- \n Config\n \n
- \n UserInterface\n \n
- \n LAN\n \n
\n The Components contains parameters that provide various functions of TR-069. Their specification is provided in the separate documents of BroadBand Forum. Service Objects contains objects for each type of services provided by a specific CPE model. Accordingly, for multiservice CPEs, several objects of the corresponding type are defined. For the main types of services, the parameters are formalized and issued in the form of the corresponding BroadBand Forum recommendations. We wrap-up our brief description of parameters with the notice that the CWMP does not regulate the number of parameters supported by a specific implementation of CPE. Each manufacturer can add its own, specific parameters that will realize the control functions over specific type and model of equipment the best way. The CWMP protocol defines only set of basic parameters that allow to realize the functions of unified management of the operator’s heterogeneous network.\n
\n\n CWMP procedures\n
\n\n The TR-069 specification defines the following basic procedures that will be performed in the process of managing CPE:\n
\n- \n
- \n Autodetection of CPE\n \n
- \n Connection set up and transmission of informational messages\n \n
- \n File transfer\n \n
- \n Closing of session and disconnection\n \n
\n Autodetection of CPE\n
\n\n The TR-069 specification defines two main variants of primary (or repeated - in case of loss of communication with the current ACS) connection of CPE to ACS (CPE detection):\n
\n- \n
- \n During the initial local configuration (Web GUI, CLI) of the CPE, information about the ACS access parameters can be directly set by the operator.\n \n
- \n If you have the possibility to use DHCP, the ACS access parameters (ip, code) can be transferred to the CPE by a DHCP server. In this case, at the moment of connection to the network, the CPE will receive not only its own dynamic IP address, but also the address (IP) and the access code to ACS server.\n \n
\n In the latter case, Option 43 of DHCP3 protocol is usually used to define the CWMP parameters. The ACS server information is stored on the CPE as the value of parameter ... Management-Server. URL (where ... is the path to the object in accordance with the hierarchy described above). The current version of TR-069 specification assumes that each CPE is bound to only one ACS. Accordingly, if the connection with the ACS server indicated as the value of the parameter ... ManagementServer.URL is lost, the CPE will initiate additional searching of ACS.\n
\n\n Connection setup\n
\n\n As is common for many types of two-way communications, two variants of connection setup are available:\n
\n- \n
- \n Initiated by CPE\n \n
- \n Initiated by ACS\n \n
\n In accordance with TR-069, the CPE may initiate the interaction session with ACS in one of the following cases:\n
\n- \n
- \n Initial detection and configuration of the CPE.\n \n
- \n Power up or reboot of the CPE\n \n
- \n As per schedule, in accordance with the predetermined values of the corresponding parameters\n \n
- \n If a connection request is received from the ACS\n \n
- \n If the address of ACS is changed\n \n
- \n When the values of a number of key parameters for which is defined the function of tracking their values are changing\n \n
- \n In case of abnormal termination of the previous session\n \n
\n In case of successful connection to ACS, the CPE will initiate the INFORM request and finish the session setup procedure.\n
\n\n The opening of the session initiated by ACS will be executed by sending the appropriate request to required CPE. The special port 7547 is allocated for transmission of such requests. The request is formed as HTTP GET to a specific CPE url. No data is transmitted from ACS to CPE. The received request is analyzed by the CPE for verification of authenticity and, in case of successful completion of verification, a response will be generated and the session initiated with ACS. The TR-069 specification also describes various requirements for limiting the fact and intensity of sessions between CPE and ACS.\n
\n\n File transfer\n
\n\n The number of CPE control functions are associated with the transfer to them different files (for example: firmware images). You can transfer files using Unicast (HTTP / HTTPS, FTP, SFTP, TFTP) and Multicast (FLUTE, DSM-CC). As a prerequisite to initiation the file transfer procedure, the TR-069 specification defines the presence of active session between ACS and CPE.\n
\n\n The file transfer can be organized in one of the following ways:\n
\n- \n
- \n CPE can send HTTP GET / PUT within already established connection. When the file is transferred, the CPE can start sending additional messages to ACS, keeping the session going\n \n
- \n CPE may open the second session for file transfer saving, at the same time, the primary session with ACS\n \n
- \n The CPE may terminate the current session with ACS and then initiate the separate session for file transfer\n \n
\n If the address of ACS and the source address of the file do not match, only last two ways for files transfer will be applicable.\n
\n\n Closing of the session\n
\n\n Specification TR-069 defines the following conditions fulfillment of which will be necessary for session closing:\n
\n- \n
- \n The last request received by CPE from ACS is empty\n \n
- \n The CPE has no actual interaction tasks (requests, responses) with ACS\n \n
- \n The CPE received all responses to requests from ACS\n \n
- \n The CPE sent all responses to ACS requests\n \n
\n Closing of connection session is possible only if all above conditions are met simultaneously. Such a solution is aimed at prevention of possible unexpected termination of the session and subsequent data loss or network failure\n
\n