The data model that defines what can be managed, monitored, and manipulated by TR-069, and its successor, USP/TR-369, is frequently updated to include new capabilities and interfaces to enable service provider control of the home network. As new technologies emerge, Broadband Forum members contribute to the next version of TR-181 in a fairly fast revision cycle.
The Device:2 data model for TR-069 endpoints and USP Agents was updated in January of 2022, including new updates for Wi-Fi management that syncs with the Wi-Fi Alliance Data Elements specification. Here is a quick overview of the capabilities available in Device:2.15 for developers building TR-069 or USP products and applications, and for operators looking to deploy them.
TR-069 has been a part of the DOCSIS 3.x specification for some time, used by Cable and MSO operators to configure, manage, and monitor certain aspects of their eRouter deployments (particularly around Wi-Fi interfaces). The User Services Platform, now a part of the RDK-B codebase, is also being used more and more for management telemetry and other uses that are enabled by USP/TR-369.
However, the physical interface for Data over Cable had not been modeled in the Device:2 data model, until now. Device:2.15 adds the Device.DOCSIS interface object, which provides configuration and monitoring capabilities to the management system. It includes data statistics much like any other Device:2 interface (data sent, received, etc.), training and connectivity status and statistics, and a spectrum analyzer function for troubleshooting.
Device:2.13 introduced a new object to synchronize with and provide access to the Wi-Fi Alliance’s Wi-Fi Data Elements specification. This specification provides Key Performance Indicators (KPIs) for use by management systems to actively optimize Wi-Fi performance and the overall end-user experience in a huge number of different deployment scenarios.
Device:2.15 takes this further by updating the Device.WiFi.DataElements object to align with Release 2 (R2) of the WFA Data Elements specification. This step, performed with wide industry input, also combined some of the parameters and commands defined in the Device.WiFi.MultiAP. object into the Data Elements object, creating an overall robust mechanism for designing managed Wi-Fi solutions.
The Bulk Data Collection mechanism defined in TR-069, and expanded in USP, is one of the key features of the protocols. Originally defined to be performed over HTTP, USP added the ability to report bulk data over a USP notification as well.
Device:2.15 goes further and adds support for reporting bulk data over a Message Queue Telemetry Transport (MQTT) connection. MQTT has quickly become the transport mechanism of choice for IoT applications, and was added as a USP transport in USP 1.1. Operators and application providers who have built out MQTT deployments want to make the most use out of the existing infrastructure, and proposed adding MQTT as an option for use in CWMP/USP bulk data collection.
You can read more about how bulk data collection works here, but to summarize the changes, Device:2.15 adds an MQTT object to the Device.BulkData.Profile.{i}. object to allow Controllers to set the MQTT interface and topic information for use in the bulk data reports.
The bulk data mechanism in general has also been updated with a ForceCollection() command to allow a Controller to immediately request a telemetry report outside of the scheduled report that has been configured in a profile.
The Device.Users object was originally made (somewhat uncearly) to manage users who have access to a device’s Graphical User Interface (GUI). This left the data model lacking a good way to model system users in a way that provided management capabilities for groups, permissions, etc.
The revisions to the Device.Users. object in Device:2.15 restructures the object completely, adding sub-objects for defining individual users, groups, roles, and shell support. This aligns more closely with the Linux user model and makes the object more useful than before.
To the CWMP version of the data model, Device:2.15 adds the ability to configure USP Controllers, MTPs, and other elements necessary to enable USP on a device. Consequently, the USP version of the data model adds the ability to manipulate the EnableCWMP parameter to disable (or re-enable) CWMP protocol capability on a device.
This allows users to smoothly transition to USP from CWMP, or to easily allow both protocols to co-exist on a device fulfilling different uses.
There are a number of additional features that were added to Device:2.15, including updates to the IPLayerCapacity diagnostic (defined in Broadband Four TR-472) and the addition of the Babel routing protocol defined in IETF 8966.
You can find a “diff” of the updates here for USP and here for the TR-069 version. Have any questions? Let us know!
