The User Services Platform (USP/TR-369) is the evolution of the wildly successful TR-069 (CPE WAN Management) protocol broadband service providers use to manage, monitor, and onboard customer premises equipment. While USP is designed to accommodate many other types of connected devices, traditional broadband gateways are a prime target for making the transition from TR-069 to USP, given the benefits it provides that include efficiency, the capability to gather and process larger amounts of data, and the ability to support more numerous connected devices.
The Broadband Forum has officially stated that TR-069 will no longer be updated (with a focus on USP in the future). However, TR-069 is so widely deployed and valuable that it will be here for many years. The task for operators and their vendors is to design deployment plans that use both protocols. In some cases, this means using USP only on newer devices and for different use cases (for example, starting with set-top boxes), but in most cases, this means deploying USP and TR-069 together on the same device to take advantage of the powerful legacy capabilities of TR-069 while exercising the new capabilities of USP.
This type of co-existence needs to be thoroughly tested on the broadband CPE and Wi-Fi devices you build or deploy. As the official test platform for both TR-069 and USP certification, CDRouter contains several core test collections that apply. Here are the top three things to focus on when testing TR-069 and USP co-existence and transition.
One of the most significant advantages of USP is the mostly backward-compatible use of the Broadband Forum TR-181 Device:2 data model. Most interface, statistics, and application features manageable through TR-069 can still be done using the same data model via USP.
Note: For operators still using the long-deprecated TR-098, the first step in transitioning to USP is to move to TR-181. TR-098 does not support USP, and the backward compatibility benefits are lost on legacy deployments that use this deprecated data model.
Data model validation testing is essential for devices that support both protocols. In particular, make sure that what you expect to set and get with TR-069 is the same as what you expect to set and get with USP for parameters that are supported by your device for both protocols. There may be differences here, and that’s important, too, as you may wish to expose different data models via different protocols for different use cases (for example, if you only plan to do advanced Wi-Fi management via USP, but only plan to do firmware upgrades via TR-069).
It should be noted that there is no mandate to separate your data model implementation for each protocol, which can cause interoperability issues (though this may be standardized in the future), so it’s important to test how your device will handle situations where the underlying API is only exposing one data model via both protocols. For example, since TR-069 does not have a Role-Based Access Control (RBAC) concept, how will your device respond when an ACS configures a parameter secured by USP?
With the TR-069 and USP Expansions, CDRouter can thoroughly validate your device’s data model implementation through both protocols, iterating through thousands of objects, parameters, and commands in an automated and repeatable manner. This includes support for your own custom data model and data models published by third-party open-source implementations (such as RDK-B and prpl).
In addition to the standard data models published by the Broadband Forum, the two major open-source broadband gateway software organizations, RDK and prpl Foundation, produce their own data models that contain some of TR-181 plus additional vendor extensions.
Both solutions support TR-069 and USP, and their specialized data models can and should be tested over both protocols. CDRouter’s data model test cases include access to the RDK-B data model, and CDRouter is the official test platform for the prpl HL-API and prplOS certifications.
When considering transitioning to USP, the most important thing is whether or not the things you want to do that were previously done with TR-069 operate as you expect them to with USP. For this, creating specific real-world test scenarios that model the use cases you want to achieve can reveal this and guarantee whether or not your transition will be seamless.
CDRouter’s Scenario test cases are supported for both TR-069 and USP, which let you create simple custom test scenarios that can set and retrieve the parameters you specify, matching them against what you expect to see. Creating the same scenarios for TR-069 and USP on your device will demonstrate whether the functionality behaves the same way using either protocol.
While the Device:2 USP data model is mostly backward-compatible with Device:2 for TR-069, some key differences exist in how certain features operate. Notably, features like diagnostics and firmware upgrades use the USP Operate message to invoke Commands that are defined in the data model. This contrasts to CWMP, which uses parameters to initiate diagnostics, or an actual protocol-defined RPC (Download) for firmware upgrades.
For a device that supports both CWMP and USP, then, it is important to ensure that these features will work the same way when initiated over each protocol, and that your underlying data model - even if not entirely identical for both protocols - supports the necessary USP Commands to perform these functions.
The move from TR-069 to USP can seem intimidating, but regular testing backed with full automation will ensure your devices are ready for whatever the device management world throws at them. The QA Cafe team is directly involved in creating and updating both CWMP and USP, and CDRouter is designed with the needs of developers in mind. Some additional steps you can take include:
The transition from TR-069 to USP depends significantly on the use cases of operators, now and in the future. Rigorous testing will always make the process easier for those who support both protocols in their systems!
