What's new in the TR-181 Device 2.13 data model for TR-069 and USP

5 min read

The latest elements in TR-181

Tied with the release of version 1.1 of the User Services Platform/TR-369, the Broadband Forum also released version 2.13 of the Device:2 data model for TR-069 endpoints and USP agents. This update incorporated a lot of key features meeting critical industry needs such as managed Wi-Fi multi-AP (mesh) networks, real-time “Internet of Things” controls and capabilities, and the ability to initiate and recover packet capture diagnostics from CPE. Here’s a quick look at some of these features for developers and service providers that want to add these to their products and test their implementations with CDRouter TR-069 or CDRouter USP. 

More about USP and Device:2 in the industry

With the release of Device:2.13 and USP 1.1, QA Cafe gave a webinar alongside industry experts from Axiros, Domos, Arris/CommScope, Incognito, and Greenwave Systems covering these updates and more.

Request the video

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 Enterprise

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 Enterprise 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 CloudShark 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.

Learn more about how Operators can benefit from packet capture management in our whitepaper here.

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: