There’s many use cases for TR-069 from a service provider’s perspective. Beyond onboarding, firmware upgrades, and service configuration, however, is the ability to monitor various statistics on devices and network interfaces to help troubleshoot an end-user’s service.
Nearly all of the interfaces in the TR-069 Data Models have statistics on the amount of data sent and received through them, which can be used for this kind of troubleshooting. This is particularly true for the data models that cover Set Top Boxes, which is comprised mostly of this kind of status information.
The other way to accomplish this is to use active diagnostics to go through the troubleshooting process. Objects such as Device.IP.Diagnostics.IPPing. or Device.IP.Diagnostics.TraceRoute. can be used when a device is having connectivity problems.
Diagnostic objects are “command” objects, which means they represent additional stateful functionality beyond what is defined in the RPCs of TR-069. Diagnostic objects in particular also use a TR-069 event called “8 DIAGNOSTICS COMPLETE” when the Diagnostic command completes (whether successfully or not).
The order of events when using a Diagnostic object (for example, IPPing) is as follows:
Using a diagnostic command in TR-069
The Broadband Forum defined some additional active diagnostics in TR-143, “Enabling Network Throughput Performance Tests and Statistical Monitoring”. These tests are designed to test the throughput of a given link in real time, using the CWMP Endpoint as a “sink” or test endpoint.
The endpoint connects to a “Network Test Server”, which can be used to do any of the following active diagnostics:
These download diagnostics are built to measure the throughput of a link between the network test server and the CWMP Endpoint. There’s a number of use cases for this, but much of it originated from demands by service providers to be able to validate the data rate of a WAN connection. However, it can also be used on a TR-069 device in the LAN to measure the throughput through a gateway, or to troubleshoot in-home network links if the network test server can be located on the gateway or elsewhere.
The full description of all of these tests is covered in Appendix A of TR-143, which explains the Theory of Operations of each test. This includes the proper test sequence and the correct way to calculate the results that are presented by the Endpoint.
Ladder diagram of TR-143 upload diagnostic
Graph of TR-143 conversation and uploaded traffic
The tr143_http.tcl test module in CDRouter* ensures that a DUT executes TR-143 based tests correctly as defined in TR-143 and in the IntegetGatewayDevice:1 and Device:2 data models. This includes the performance of HTTP downloads and uploads themselves, the use of DNS versus direct addressing for the network test server, and whether the error conditions are presented correctly. The steps are generally:
Take a look at this capture on CloudShark:
We’ve annotated it so you can see the sequence unfold for an example UploadDiagnostics test.
CDRouter focuses on HTTP download/upload specifically, as this was the most common test scenario we encountered in our own labs when building the test module and verifying the module was ready for our users. If you’re looking for the others, be sure to let our support team know!