Interoperability and validation of the latest TR-069 and USP devices in CDRouter 11.8

January 23, 2020 • 3 min read

It’s known now that managed Wi-Fi is the future of Wi-Fi. Moreover, as more and more devices become active on the network, it is in the best interest of service providers, CPE vendors, and consumer electronics manufacturers to expand and standardize how they gain valuable data to ensure a quality end-user experience.

The Broadband Forum’s (BBF) TR-181 data model, known as “Device:2” has been used by the popular TR-069 management protocol, and its successor, the User Services Platform (USP/TR-369) for more than a decade as a standardized way to manage subscriber networks, perform diagnostics, and receive telemetry. The BBF updates the model frequently (every six to nine months). The latest of these updates is Device:2.13, which contains components for managing Wi-Fi multi-AP networks, WPA3, standardizes IoT sensor and control objects, and provides powerful new packet capture diagnostic capability that can be used in conjunction with CloudShark’s CS Enterprise for packet visibility.

As powerful as it is, it’s vitally important to ensure that devices implementing TR-181 have been tested rigorously with CDRouter as new features are added to your devices. 

Packet capture diagnostics

When troubleshooting customer networks, nothing is as powerful as raw packet capture data. Evidence of performance issues, problems with DNS delays, and even evidence of malware can all be found in the packets.

TR-181 enables several commands that can be run on devices that return valuable diagnostic data, such as IP ping and performance diagnostics defined in TR-143. Device:2.13 adds a command under Device.PacketCaptureDiagnostics. that lets a service or application provider initiate a packet capture (using applications like tcpdump or dumpcap) on a managed interface of a CPE for use in support and troubleshooting.


Using the PacketCaptureDiagnostics command with CloudShark

 cloudshark color 1

The ability to run packet captures on CPE is immensely powerful, but getting the captures to a system where they can be analyzed is necessary to take full advantage of them. Many service providers rely on CloudShark for managing captures from their network, and with the PacketCaptureDiagnostics command, CPE captures can be sent to its web-based analysis system as well.

Here’s how it works. The Device.PacketCaptureDiagnostics. command object (Device.PacketCaptureDiagnostics() in USP) has an argument called “FileTarget”. This can be any URL capable of receiving the resulting packet capture file. Providers can use CloudShark’s powerful upload API to send the capture directly to their CS Enterprise system by setting the upload URL as the FileTarget. Once in CloudShark, they can be searched and analyzed by the entire network support team and stored for retrospective analysis.

Wi-Fi multi-AP management and WFA “Data Elements”

The entire networking industry is desperate for a standardized solution for hi-quality, managed Wi-Fi using technologies like 802.11ax. The Device:2.13 data model unleashes a host of possibilities for managing multi-AP networks by service providers, manufacturers, and third party application providers.

Device:2 already contained elements for managing the Wi-Fi interfaces of gateways and APs themselves. Device:2.13 contains two new objects for managing multi-AP networks.

  • Device.WiFi.MultiAP.

This object can be used to monitor a multi-access-point network of Wi-Fi devices, including steering statistics, failures, and device info. It contains information agreed upon by vendors and providers looking to manage and monitor a multi-AP network.

  • Device.WiFi.DataElements.


This object contains information that matches the exact parameters defined by the Wi-Fi Alliance Data Elements specification, for implementations and applications that rely on this information.


IoT sensors and controls

Device:2.13 contains a powerful model of smart device elements, including sensors and controls defined in a generic way to allow any number of IoT devices to be managed and controlled in real time. This model is defined almost exclusively for USP, since the real-time messages provided by USP are more appropriate to end-user control.

These elements are defined in the Device.IoTCapability. object. The model takes advantage of the USP concept of “mountable” objects, allowing IoTCapability to be added to Device.ProxiedDevice. objects and the .Node. object, which lets complex smart devices with a combination of sensors, controls, and more be modeled for control by USP.

The theory of operations for using USP for IoT control can be found in Appendix V of TR-369.


Can I see the Device:2.13 changes myself?

With each new version of the Device:2 data model, the Broadband Forum produces both a full version of the data model in html, plus a “diffs” version that will show you just the changes since the last version. Take a look at the differences yourself with these links:



Are you developing TR-069 or USP solutions? CDRouter is the industry standard for testing both of these powerful management protocols. Contact us for a free demo and power through your development even faster.