TR069 Related Introduction

Background Introduction

With the rapid development of the information industry, the type of business and the volume of traffic on the WAN are increasing, the scale is expanding, and a large number of terminal access devices are widely used, which requires effective management of these user-side equipment (CPE).

Traditionally, user-tested devices need to be configured or diagnosed through a management interface, either at the very beginning of the installation, in late-running business configuration changes, or in the event of a failure that requires maintenance. Most devices provide a management configuration interface and interface on the LAN side, so the traditional practice is that the operator's maintenance personnel are on-site to install or debug the device and do some device configuration or troubleshooting work via the LAN-side management interface. However, this one-to-one approach to manual service is obviously inefficient and requires a lot of manpower. With the development of the business, there will be a large number of equipment to be placed in the user's home, the use of artificial methods to maintain and manage these devices will become a huge burden. While the branch devices of wide area network are scattered, the traditional remote management methods such as Telnet, SSH, SNMP (Simple Network Management Protocol) and Remote Web login have many limitations: such as multi-vendor Device command line, SNMP inconsistency, device address changes frequently, terminal is behind NAT Gateway, SNMP is based on UDP protocol transmission is unreliable, different devices of the Web interface and configuration methods, can not be a large number of CPE for batch automation management, and so on.

In this context, the DSL forum (digitally subscriber line digital Subscriber Loop, now renamed the Broadband Forum) introduced the TR069 protocol in May 2004, commonly referred to as the user Terminal Equipment WAN Management protocol (CWMP,CPE WAN Management Protocol). The TR069 protocol, along with other related protocols, defines a new set of network management architectures, including the administrative model, interface, and basic management parameters. TR069 main Functions

The TR069 protocol describes a mechanism for establishing a secure, automated configuration Management framework for CPE by ACS, while adding its CPE management capabilities to this framework. The goal is to implement a variety of functions to manage a CPE or CPE collection. provide automatic configuration and dynamic service: The parameters of this mechanism are both general parameters and user-defined parameters, which leave more autonomy space for the software implementation. software and firmware image file management: CPE can download and upload files, the protocol provides a way to check the version of the software or firmware, you can also process the signature data file. After the file transfer is complete, the ACS is notified and returns success or failure. Diagnosis: The TR069 protocol provides support for the CPE to generate effective diagnostic information that ACS can use to diagnose and resolve connectivity or business problems, while providing the ability to perform pre-defined diagnostic tests. Alarm: CPE proactively sends event reports to enable real-time alarm of the device. To traverse a NAT connection: The TR069 itself allows ACS to manage devices after NAT, but it restricts ACS from initiating the session proactively. The TR111 mechanism is a supplement to this part of the TR069, which allows ACS to initiate the session proactively. At the initial installation, the CPE automatically looks for the ACS server (the CPE is factory configured with a default URL address that the user points to the ACS server), communicates with ACS after the connection is established, downloads the configuration, and so on, which solves the management challenges behind the Nat gateway perfectly. TR069 Protocol Introduction TR-069 Network Architecture

In the administrative model defined by TR069, there are two main types of logical devices: Managed user devices (Cpe,customer premises equipment) and automatic configuration servers (Acs,auto-configuration Servers). The core idea of TR069 is to realize the automatic configuration process of the terminal by defining a set of auto-negotiated interactive protocols between ACS and CPE. The following figure depicts the positioning of the TR069 protocol in the automatic configuration of the network architecture. The interface between ACS and CPE is a South interface, and the interface between ACS and the third party network management system and the Business Administration system is the North interface. The TR069 protocol primarily defines the south-to-interface standard.

protocol Stack Structure

protocol Layer	Description
Cpe/acs Management Application	Applications can implement the CWMP protocol separately on the CPE and ACS side, and the application can be defined locally without having to be part of the CWMP
RPC Methods	Various RPC methods defined in CWMP to enable the interaction between ACS and CPE
Soap	XML syntax-based standard for encoding remote procedure calls, avoiding conflicts with firewalls
HTTP	HTTP 1.1
SSL/TLS	Standard Internet Transport Layer Security Protocol (optional)
Tcp / ip	The Standard TCP/IP

-RPC: A remote procedure call is a protocol that requests services from a remote computer program over a network without needing to know the underlying network technology. TR069 defines 9 basic RPC methods for the CPE, 6 optional RPC methods, 2 basic RPC methods for ACS, 2 optional RPC Methods (CPE method, CPE device support, can be called by ACS, ACS method, ACS device support, can be called by CPE). In addition, TR069 defines the data types used in RPC methods and can only use portions of the data types defined by SOAP.
-SOAP, HTTP: There is an important problem to be solved in implementing distributed component interoperability in Internet environment, which is called firewall problem. Most firewalls are port-based, and CORBA-based RPC is not used by commonly used ports. CORBA-based distributed component calls are rejected as malicious access if they are not specially configured. Therefore, the TR069 uses the SOAP Simple Object Access Protocol as the encapsulation of RPC packets, using the standard HTTP protocol to transmit the method. TR069 Specifies that soap is bound to HTTP, and RPC method calls are used to implement device management. Binding soap to HTTP provides the benefits of leveraging soap's dispersion, flexibility, and HTTP-rich feature libraries. Transmitting SOAP over HTTP does not mean that soap overwrites existing HTTP semantics, but rather that the soap semantics on HTFP are naturally mapped to HTTP semantics. When using HTTP as the binding protocol, an RPC call is naturally mapped to an HTTP request, and the RPC response is mapped to the HTTP reply as well. In general, the structure of a complete SOAP package consists of an envelope (Envelope), a header (optional), and a SOAP body (the body) (required). It is not stated in the SOAP protocol that a SOAP package can contain multiple envelope,tr069 with multiple envelope mechanisms, which increases the amount of information in a single exchange and reduces the number of data exchanges between network devices.
SSL: The SSL protocol specifies a mechanism to provide data security tiering between the application protocol and the TCP/IP protocol, which provides data encryption, server witness, message integrity, and optional client witness for TCP/IP connections, ensuring that the data is not changed in the transmission. The TR069 protocol implements remote management, and secure information exchange is required. The security information exchange between CPE and ACS is realized by using 128bit encryption algorithm and digital authentication mechanism.Business Process

Software architecture and the specific parsing process of the Protocol

Communication Process

Let's look at a complete communication process for the TR069 protocol.

Once Getparametervalues is first initiated by the CPE to send inform messages.

POST /openacs/acs HTTP/1.1  
Host: 192.168.7.1:9090  
User-Agent: BCM_TR69_CPE_04_00  
Connection: keep-alive  
SOAPAction:  
Content-Type: text/xml  
Content-Length: 2452

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cwmp="urn:dslforum-org:cwmp-1-0">  
  <SOAP-ENV:Header> 
    <cwmp:ID SOAP-ENV:mustUnderstand="1">2044897763</cwmp:ID> 
  </SOAP-ENV:Header>  
  <SOAP-ENV:Body> 
    <cwmp:Inform> 
      <DeviceId> 
        <Manufacturer>Bellmann</Manufacturer>  
        <OUI>001F8F</OUI>  
        <ProductClass>HA930e</ProductClass>  
        <SerialNumber>27FD6001F8F748602</SerialNumber> 
      </DeviceId>  
      <Event SOAP-ENC:arrayType="cwmp:EventStruct[1]"> 
        <EventStruct> 
          <EventCode>8 DIAGNOSTICS COMPLETE</EventCode>  
          <CommandKey/> 
        </EventStruct> 
      </Event>  
      <MaxEnvelopes>1</MaxEnvelopes>  
      <CurrentTime>2012-12-10T13:21:37+00:00</CurrentTime>  
      <RetryCount>0</RetryCount>  
      <ParameterList SOAP-ENC:arrayType="cwmp:ParameterValueStruct[0008]"> 
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.DeviceSummary</Name>  
          <Value xsi:type="xsd:string">InternetGatewayDevice:1.1[](Baseline:1, EthernetLAN:1, USBLAN:1, WiFiLAN:1, EthernetWAN:1, Time:1, IPPing:1, DeviceAssociation:1), VoiceService:1.0[1](Endpoint:1, SIPEndpoint:1)</Value> 
        </ParameterValueStruct>  
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.DeviceInfo.SpecVersion</Name>  
          <Value xsi:type="xsd:string">1.0</Value> 
        </ParameterValueStruct>  
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.DeviceInfo.HardwareVersion</Name>  
          <Value xsi:type="xsd:string">HA930e_N_V2.0</Value> 
        </ParameterValueStruct>  
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.DeviceInfo.SoftwareVersion</Name>  
          <Value xsi:type="xsd:string">HA930e_N_V1.00S</Value> 
        </ParameterValueStruct>  
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.DeviceInfo.ProvisioningCode</Name>  
          <Value xsi:type="xsd:string"/> 
        </ParameterValueStruct>  
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.ManagementServer.ConnectionRequestURL</Name>  
          <Value xsi:type="xsd:string">http://192.168.7.143:30005/</Value> 
        </ParameterValueStruct>  
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.ManagementServer.ParameterKey</Name>  
          <Value xsi:type="xsd:string">unsetCommandKey</Value> 
        </ParameterValueStruct>  
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.ExternalIPAddress</Name>  
          <Value xsi:type="xsd:string">192.168.7.143</Value> 
        </ParameterValueStruct> 
      </ParameterList> 
    </cwmp:Inform> 
  </SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

The

ACS side responds inform Response.

HTTP/1.1  
Host: 192.168.7.1:9090  
User-Agent: BCM_TR69_CPE_04_00  
Connection: keep-alive  
SOAPAction:  
Cookie: JSESSIONID=5CEB426075A42489AC3A7E6BAE004C61  
Content-Type: text/xml  
Content-Length: 0  

Then the CPE end responds with an empty HTTP POST request.

http/1.1  
host:192.168.7.1:9090  
user-agent:bcm_tr69_cpe_04_00  
connection:keep-alive  
SOAPAction:  
cookie:jsessionid=5ceb426075a42489ac3a7e6bae004c61  
Content-type:text/xml  
content-length:0  

The following begins the RPC phase. The RPC request is sent by ACS, this is getparametervalues, to get the value of internetgatewaydevice.devicesummary.

HTTP/1.1 200 OK  
Server: Apache-Coyote/1.1  
X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181439)/JBossWeb-2.0  
Content-Type: text/xml  
Content-Length: 722  
Date: Sat, 01 Nov 2014 07:53:48 GMT

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:cwmp="urn:dslforum-org:cwmp-1-0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <SOAP-ENV:Header>
    <cwmp:ID SOAP-ENV:mustUnderstand="1">ID:intrnl.unset.id.GetParameterValues1414832028729.539118694</cwmp:ID>
    <cwmp:NoMoreRequests>0</cwmp:NoMoreRequests>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
    <cwmp:GetParameterValues>
      <ParameterNames SOAP-ENC:arrayType="xsd:string[1]">
        <string>InternetGatewayDevice.DeviceSummary</string>
      </ParameterNames>
    </cwmp:GetParameterValues>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The

CPE invokes a background script to find the value of internetgatewaydevice.devicesummary and then responds to ACS.

POST /openacs/acs HTTP/1.1  
Host: 192.168.7.1:9090  
User-Agent: BCM_TR69_CPE_04_00  
Connection: keep-alive  
SOAPAction:  
Cookie: JSESSIONID=5CEB426075A42489AC3A7E6BAE004C61  
Content-Type: text/xml  
Content-Length: 941

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:cwmp="urn:dslforum-org:cwmp-1-0">  
  <SOAP-ENV:Header> 
    <cwmp:ID SOAP-ENV:mustUnderstand="1">ID:intrnl.unset.id.GetParameterValues1414832028729.539118694</cwmp:ID> 
  </SOAP-ENV:Header>  
  <SOAP-ENV:Body> 
    <cwmp:GetParameterValuesResponse> 
      <ParameterList SOAP-ENC:arrayType="cwmp:ParameterValueStruct[0001]"> 
        <ParameterValueStruct> 
          <Name>InternetGatewayDevice.DeviceSummary</Name>  
          <Value xsi:type="xsd:string">InternetGatewayDevice:1.1[](Baseline:1, EthernetLAN:1, USBLAN:1, WiFiLAN:1, EthernetWAN:1, Time:1, IPPing:1, DeviceAssociation:1), VoiceService:1.0[1](Endpoint:1, SIPEndpoint:1)</Value> 
        </ParameterValueStruct> 
      </ParameterList> 
    </cwmp:GetParameterValuesResponse> 
  </SOAP-ENV:Body> 
</SOAP-ENV:Envelope>

This value is: internetgatewaydevice:1.1[] (baseline:1, Ethernetlan:1, Usblan:1, Wifilan:1, Ethernetwan:1, Time:1, IPPing:1, Deviceassociation:1), Voiceservice:1.0[1] (endpoint:1, sipendpoint:1.

Finally, ACS ends this session.

http/1.1 204 No Content  
server:apache-coyote/1.1  
x-powered-by:servlet 2.4; Jboss-4.2.3.ga (Build:svntag=jboss_4_2_3_ga date=200807181439)/jbossweb-2.0  
Date:sat, 07:53:53 GMT

We need to pay attention to the following points throughout the communication process. when did inform and EventCode

Each inform escalation represents the beginning of a session, so the timing of the inform is important. At a minimum, we need to implement: When the CPE is first installed. EventCode for Bootstrap. When power is on or restarted. EventCode is boot. Every time the Periodicinforminterval cycle arrives. EventCode for Periodic. ACS requests connection request from the CPE via the CPE httpd service. EventCode for connection REQUEST. When the value of monitor changes. EventCode to include the value change.

More detailed support is required to view the manual. the role of Cookies

We note that ACS and CPE use the same cookie to communicate until the end of the session when the inform is complete. In fact, because the HTTP protocol is a stateless protocol, in order to be able to establish the sequence of communication processes, to maintain the normal operation of the state machine, both sides are through the cookie. the type of the XML node

We notice that in the SOAP message, the XML node is of the category. For example, xsi:type= "xsd:string", indicating that the value is of type string. Although it is possible to work on some ACS even if these values are removed, the different ACS does not have the same degree of checking on the parameters, so it is recommended to add them. RPC Method

In our example above, we mentioned the RPC method, and take getparametervalues to the example, the TR069 protocol prescribes the methods that the CPE can support.

Where optional is optional, required must be achieved, but this can only be used as a reference, but also to see the standards of the various equipment vendors.

RPC unified the interface of the device, the RPC operation of the data how to unify it, Tr069 therefore proposed Datamodel.

Datamodel

Tr069 many different devices are abstracted out of the device model, hanging to the public device tree, the root node is called Internetgatewaydevice, using the unified RPC interface, we only need to manipulate the nodes on these device tree value and Atribute, You can change the configuration of the box.

In fact, I think this design is a bit cumbersome, I would like to give an example, we look at how to use the protocol to test the ping function of the device.

Intuitively, if we want to test whether the CPE is able to ping the other device addresses, we typically log on to the device directly with Ssh/telnet/uart and then directly tap the ping command. In the tr069 we scored two, First we set the ping parameter through Setparametervalues.

And then use Getparametervalues to check.

But do not think of a better way, as to why to use XML such a heavyweight protocol format, my explanation is that XML is mature enough to easily define the schema file, easy to verify. In addition, the tr069 protocol is not popular in JSON format, it is exactly the age of XML. opensource ACS Server Openacs : I have been using it to test the CPE client, but unfortunately the author deleted it, and someone fork it to the project, renamed to Libreacs. Genieacs: Written in coffee script, you can try it. Fusion ACS: The authors call themselves I believe this is the most complete open-source (Mit-license) ACS available, with WEB-INTERFAC E, web-services interface, TR-111 support, etc. CPE client easycwmp: It evolved from FREECWMP. Say that you are fully conform with The TR069 CWMP Standard, but the script part actually writes with the shell to be smelly and long. FISHCORECPE: This is not an open source project, but in the country can find some tests on it, readers can download a copy from me, so that you test the CPE behavior. EVCPE: Because Google code is shutting down, I moved it to GitHub. cwmp Client NETCWMP

There are a lot of CWMP clients on GitHub, readers can search by themselves, and here are some typical and some of my own references.

Summary

With LUA development is mainly in the scripting language can be easily processed text, and Lua is here the lightest, in the performance critical place, can also use C very good optimization, at present, the effect is good.

Tr069 's greatest effort is to carefully implement the specific business logic on each node and the ability to test across different ACS platforms. Compared with snmp,tr069 in security, configuration, compatibility and so on are doing better, should believe that its application prospects will be wider.

This article just briefly put oneself can think of some things to record down, there are many aspects did not mention, if the reader has any questions, welcome through the comments proposed, together explore ~

Reference

The BroadBand specification is here.
Tr069 Central A blogger who writes Tr069.

(End of full text)

more
-FISHCORECPE and Openacs docking test report
-More Details about TR069 CPE WAN Management Protocol

This article was reproduced in: https://forestgump.me/2015/03/14/about-tr069/