Vendor Agnostic CPE Management

When you start looking for a solution to manage your CPE fleet with different vendors and models, you end up stumbling across the TR-069 and TR-369 protocols. They promise to kill that pain: manage all your multitude of CPEs through a single platform, consolidating the whole operation in a single place, following the same patterns.

And that's indeed what problem these protocols solve. Then you start diving deeper and find out about data models, which are responsible for defining how the data is placed. Currently, there are two: TR-181 and TR-098.

There is a combination of standards your CPE may follow: TR-069 + TR-181, TR-069 + TR-098, or TR-369 + TR-181. And among these, there are a few other TRs that influence the CPE behavior and its capabilities.

If you feel overwhelmed by the amount of jargon and technical content, it's due to the diversity of use cases these standards accommodate. It's too hard, if not impossible, to turn things simpler without cutting features, use cases, and advanced configurations. Also, the standards were created by some of the most important telecom operators, vendors, etc, in association, making sure the best interest of interoperability is met, for the most diverse scenarios.

You may take some time to get used to the terminology and how things work, but if you want to skip that part, you can even just hire a company to handle it for you. Still, it's important to keep at least a superficial knowledge of some concepts, so here it goes:

• TR-181 = Latest data model from BBF for broader and modern CPE use cases.
• TR-098 = First data model defined. Famously starting with "InternetGatewayDevice".
• TR-069 = Widely used protocol for CPE management with 1+ billion CPEs across the globe.
• TR-369 = Successor of the 20-year-old TR-069. Bringing significant upgrades.

Now things start to get really interesting. To continue to read the text, I suggest you grab a cup of coffee — I did.

Protocols in Theory and in Practice

Until here, things look good; you have a single pane of glass for your CPEs, no vendor lock-in, interoperability, the promise to be able to run QoE analysis, diagnostics, zero touch provisioning, telemetry, remote configuration, etc. OK. The hard thing is that each vendor implements the protocol using their own imagination.

This means that although protocols and standards are in place, everyone implements it their own way. Happily, there are open source projects for CWMP and USP agents, as well as open source TR-069 ACS and USP Controllers like Oktopus hat bring uniformization to real-world production solutions that run on those platforms.

In terms of protocol implementation, CPEs run very similar operations because of the community projects available as open source and vendors' efforts. Then there's a layer on the device architecture called the "Vendor Layer", which is basically responsible for gluing the protocol functionality with the CPE specifics functionality. Defining, for example, how to get the 2.4ghz data, how to set/retrieve VoIP attributes, or rebooting the equipment.

All the commands necessary to achieve the functionality above are abstracted by the CPE data model. For instance, the operators only have to worry about the parameters and paths declared in the specification. e.g., "Device.WiFi.SSID.*.Name" (TR-181 parameter for Wi-Fi SSID name) or the "InternetGatewayDevice.LANDevice.*.WLANConfiguration.*.SSID" (TR-098 parameter for Wi-Fi SSID name).

Some vendors also define parameters starting with "X_VENDOR"; these are custom parameters created by the CPE vendor to extend the data model in cases where what they want to expose is not available in the standard definition.

Creating a PPPoE WAN in a CPE model can be totally different from another model/vendor. And it's not an easy task to accommodate all the different behaviors under the same umbrella. You get have a lot of patience and skin in the game to understand each vendor's functionality and necessary flows to achieve a specific objective, such as the PPPoE creation, Voice service definition, Mesh topology, DHCP configuration, etc.

In conclusion, you may end up with slightly different protocol implementations, and surely every CPE vendor will have different data models with divergent data model vendor extensions, capabilities, and functionality.

Appendices

As technologies evolve and consumer needs change, the need to improve the protocols to achieve such results also changes. So instead of creating other specifications, the protocol is extended with annexes that define new behaviors and allow for different use cases or enhanced flows based on new technologies and field usage feedback.

Deprecation

As well as new features and enhancements are launched, other functions are deprecated to end support and open space for the latest definitions.

Modernization Inflection Point

You can keep up with changes, improvements, adding annexes, appendices, and deprecating old operations. But it reached a point where it is not sustainable to keep the same core of the protocol, as the world now differs radically from the time the specification was created.

That was the case for TR-069 deprecation and the emergence of TR-369. This is a totally different protocol, although working with the same bids: remote CPE management. It goes even a bit further, acknowledging the connected home ecosystem to integrate with IoTs and a broader range of devices that interfere with the use experience and perception of the network.

It also comes with a lot of improvements regarding efficiency, real-time communication, and mass data collection/telemetry.

Think about TR-069 and TR-369 as IPv4 and IPv6. There's a wide abyss in how they work and the advantages of the latest upon the latter.

Co-Existence

There will be a long time that TR-069 and TR-369 will be running together, in the same equipment or at least in the same CPE fleet. The investments made in the past need to remain as new CPEs with USP enter the market. Rip and replace strategy is mostly not an option. So if you're starting an ISP from zero, opt for a CPE with the latest technology, and if you already have infrastructure in place, look for platforms that can handle both protocols seamlessly, allowing you to move forward with cutting-edge technology, while keeping compatibility with TR-069 to maintain the investment made prior.

Watch Out for Alternative "Open" Standards/Protocols

To start the thesis development correctly, let's first define what it means to be an "open protocol". Nowadays, its meaning is very broad and applies to different cases. Taking in count no vendor lock-in and interoperability, it should have some characteristics:

• Be free to use, no need to pay for a license or anything of that sort
• People need to be able to contribute to its creation
• Have a neutral working ground
• Wide adoption by multiple vendors

Broadband Forum is the organization behind CPE management protocols, among other things, responsible to create work as mentioned above. Other vendors have created "open" protocols or stacks, but all of these lack some of the items mentioned in the bullet points.

It's important to be careful when making a decision that can last for years, as defining the management system and hardware that is going to be deployed in the field, because although some ecosystems may look very attractive, it's a trap to pay high prices and get attached to a single vendor in the mid/long-term.

Some of these ecosystems may come with the badge "open". It is important to question their openness: do they mean it's open to work with multiple vendors? Is it open source? Open core? Source available? The protocol is open, but was created by a single vendor? Is it free or paid? Can other vendors use the same protocol? Does it have a community? etc. The ambiguity in the field of "open something" is dangerous, and the lines for distinction between different approaches are blurred, as there's a lot of ongoing discussion about the matter.

Why TR-x69 Is by Far the Best Option

1. It is the most widely used protocol for CPE management in the world, with more than 1 billion devices communicating.
2. ISPs from all the tiers have deployed it. Proofing it's scalability, but also accessibility, for both large and regional deployments.
3. Vendor neutrality and interoperability are ensured by the BBF (Broadband Forum) organization.
4. It's in network engineers' veins for last-mile in-home network diagnostics, zero-touch-provisioning and remote configuration.
5. Support and upgrades are ongoing as the launch of TR-369 for the next-gen broadband devices.

I could continue with another dozen reasons, but only these should already be enough to convince anyone.

Regarding the concerns about the protocol uniformization and the different vendors' implementations. We know that the TR-x69 stack is not perfect, but it is clearly the best option, and all the issues mentioned are introduced by vendor bias, not the protocol itself. These obstacles can be worked around by choosing the right partners to work with you on the CPEs fleet management strategy.