What's new in the TR-181 Device 2.16 data model for USP?

The data model that defines what can be managed, monitored, and manipulated by the User Services Platform (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 USP Agents was updated in June of 2023. Here is a quick overview of the capabilities available in Device:2.16 for developers building USP products and applications, and for operators looking to deploy them. (You can view the diffs online yourself here).

Managing Containers on the Gateway

Device 2.16 includes major enhancements to the Device.SoftwareModules. object. One of the major benefits of USP over TR-069 is that most operations were pushed out of the protocol itself (i.e., TR-069 RPCs) and into the data model - this allows improvement on these features without a major forklift to the baseline protocol.

To make way for the new world of containerized components and applications running on broadband CPE several updates were made to the software module management part of the data model. These updates include more powerful mechanisms for managing Execution Environments (EE’s) in the context of a larger, interoperable platform for installing and managing subscriber applications. In addition to having much more information about resource requirements and usage, Execution Environments are now associated with a USP role (defined in the ControllerTrust table) that defines the permissions that an application has in relation to the rest of the Agent’s data model.

EE’s can also now be Reset and Removed using specific commands, with appropriate notifications as well.

In addition to these updates to software module management, Device 2.16 contains the Message Transfer Protocol objects necessary to manage a USP endpoint that communicates internally over Unix Domain Sockets. Installed services themselves can now be managed under the Device.USPServices. object, which contains information about which parts of the Agent’s overall data model have been installed by which applications.

This is a big part of the overall managed containers solution in USP 1.3! More information on how this works can be found in the USP 1.3 spec.

Bulk data collection and monitoring enhancements

Bulk data collection (handled in Device.BulkData.) is a mechanism that was created for TR-069 and enhanced in USP to allow large amounts of data model information to be transferred all at once in either JSON or CSV. Device 2.16 enhances this by including an “exclude” parameter, a path reference that tells the Agent not to report on certain data. This is used in tandem with the rest of the Parameter object to allow a Controller to provide a wide-ranging request for data while excluding the information it doesn’t need.

Secondly, the PeriodicStatistics object now includes a mechanism to provide those statistics over a USP notification via a Push! event similar to the one provided in BulkData.

Bridging and logical network interfaces

Enhancements were made to provide better control over bridging operations - a critical function for any networking device that interconnects multiple networks. This was achieved by introducing new parameters to Device.Bridging.Bridge. and its sub-objects. These additional parameters offer administrators more granular control over bridge behavior, allowing for better network management and efficiency.

In parallel, the introduction of the Device.Logical. sub-tree creates a framework for defining logical network interfaces. This addition enables the abstraction of physical network interfaces, offering the flexibility to define network paths, policies, and rules in a manner that's not tied to a physical interface.

Firewall and NAT enhancements

The recent updates to the Device.Firewall. object clarify its purpose and extend its capabilities. New support has been added for important firewall features such as DMZ (Demilitarized Zone), Services, Pinholing, and Policies.

A DMZ is a specific part of the network that is exposed to an untrusted network, typically the internet. By adding support for DMZ, the TR-181 model allows administrators to effectively manage and control this crucial layer of security.

'Services' in a firewall context refer to specific network protocols (like HTTP, FTP, etc.) and their corresponding port numbers. The addition of Services allows for a more granular level of control over which protocols are permitted or denied by the firewall, thereby offering enhanced security customization.

Pinholing is a process that allows a user to connect through a firewall to a specific device on the private network, usually for a specific purpose or service. By adding Pinholing, the TR-181 model offers a mechanism to manage such requirements, further enhancing the firewall's flexibility.

Lastly, the addition of Device.NAT.PortTrigger. Allows the configuration of PortTriggering, so that specific outgoing traffic can 'trigger' incoming traffic to be directed to a specific device within the network. This is particularly useful for applications that require specific ports to be open for effective communication, such as video conferencing or gaming applications.

Additional updates

There was a lot that went into Device 2.16. In addition to the features outlined above, the version includes:

  • Notification and Subscription Control: The addition of Device.LocalAgent.Subscription.{i}.TriggerAction parameter enables better control over notification behavior.
  • Secured Parameters: The introduction of the concept of SecuredRoles in ControllerTrust and converted several "hidden" parameters to "secured" ones, to allow Controllers with the Secured role to read formerly “hidden” parameters.
  • Expanded Quality of Service (QoS) Features: Device.QoS. features were extensively extended with the addition of Queues, Shapers, and Schedulers.
  • XPON Support: The addition of Device.XPON. to model xPON interfaces.
  • Cleanup and Updates: Cleanup for Wi-Fi objects/parameters to line up with Wi-Fi Alliance documents, removed some activeNotify attributes, and updated status according to the deprecation policy.

Testing with CDRouter

At QA Cafe, we remain at the forefront of testing solutions for connected devices and services. We've watched closely as the TR-181 Device:2 data model for the User Services Platform protocol has evolved, introducing a suite of enhancements that revolutionize device management.

As always, CDRouter's extensive validation test cases ensure that each aspect of the updated data model, from new firewall features to improved network bridging capabilities, is examined rigorously. Look for future versions of CDRouter to support testing for some of the more advanced USP features, such as the new commands in software module management, as we track the progress of Broadband Forum TP-469 (the Certification Test Plan for USP Agents).

At QA Cafe, we are steadfast in our mission to provide comprehensive and accurate testing tools. With the advent of the updated TR-181 data model, we're poised to help you validate your implementations effectively, contributing to the ongoing advancement of IoT and device management.