What is USP?

If you’re familiar with non-mobile Internet technologies, you might have come across a protocol called TR-069, created by a standardisation organisation called the Broadband Forum. This protocol has been first specified in 2004, and is used on hundreds of million devices (some say billions) in the world to automatically configure your internet connection and make it plug-and-play. If you have such an internet connection at home and you just had to plug it in and it just worked, chances are: you’ve witnessed TR-069 at play. Years have gone by, the possible use cases for TR-069 have expanded but there are many use cases for which TR-069 is not quite the ideal protocol which either means they have to be implemented with compromises or couldn’t be implemented at all...

So somewhere around the year 2015, the Broadband User Services Work Area within the Broadband Forum decided to start working on a TR-069 replacement, the first version of which was finally approved and released in March 2018: TR-369 was born, also known as the User Services Platform (or USP). All the lessons learned from wide-spread TR-069 use were considered and taken into account to design a much more modern, efficient and secure protocol that can implement all of the TR-069 use cases but also some which couldn’t be implemented before.

Of course, not everything has changed, an often overlooked but important concept in the domain has been fully taken over into USP: the data models.

What is new in USP?

In short, everything, but that is probably not exactly what you wanted to hear, so allow me to elaborate:

Communication and encoding
Rather than using XML (a reimagination of SOAP), USP has moved to a binary and schema-based encoding called Protobuf. In a nutshell, that means that the overhead of the communication was drastically reduced and the format is very well enforceable, rather than relying on developers reading a verbatim text and figuring out how to implement it correctly. Yes, it’s exactly as bad as it sounds,

vendors are still implanting it incorrectly, trying to meddle with Axiros’s promise to work with and support any device. With USP, this creative freedom was taken away and replaced by tooling which always produces a valid format.

In addition to that, we now have an always-on connection over a variety of different communication channels (dubbed MTP, most prominently WebSocket) instead of an event triggered on-demand HTTP(S) connection. This allows any side to exchange data at any point in time without having to worry about connection establishment and handshake overhead and having to get creative about how to trigger such an event on the device in the field to cause it to establish a connection which can be really cumbersome if that device is not your main internet gateway but a device in the users home.

Oh, and data privacy is now absolutely mandatory, throwing a curve ball for operators still considering encryption to be “nice to have”.

Messaging
The changes don’t stop there. The “language” (called Messages) have also been revamped to allow to do more with fewer messages and also cater for (partial) failure without slowing operations to a complete halt. All of the previous functionality was carried over and can be translated one-to-one into the new messages, however by using the next extended “verbs” as well as additional addressing functionality, a long back-and-forth conversation (plus additional error handling and processing on the server) can now be turned into a single command, e.g. “Please enable the 5GHz Wi-Fi transmitter, tune the channel to 52 with 80MHz channel width and change the network dubbed ‘My home’ from 2.4GHz to 5GHz operation, thank you!”.

It is also possible to subscribe to a variety of events and fine-tune the exact behaviour allowing to instantaneously notify the operator of conditions that require immediate action, the very same can also be used to alert the user or trigger some automated action in the smart home.

And last but not least, the datamodel (carried over if you remember) can now be introspected rather than being a blackbox requiring detailed knowledge and/or guesswork to use.

Relationships and security
One common pain point in the past was that TR-069 only allows an N:1 relationship between devices and the server side. That means that it is not really possible to have multiple use cases implemented on multiple servers and easily roll out new services. Rather all use cases need to be funnelled through a single communication channel which can be very awkward and error-prone. Part of the problem is, that there’s no way to configure multiple servers and define how and when to communicate with them. In USP (as you can probably imagine by now) this has completely changed: Each communication partner (called Endpoint) gets their own unique identifier, allowing true N:M relationships and to properly identify the other side.

This endpoint identifier also ties into additional new concepts: Not only can (and should!) those Endpoint identifiers be used in certificates used for strong encryption, there’s also a built-in end- to-end encryption mechanism, allowing to additionally encrypt all data, if the communication channel can not be assumed provide proper protection and privacy.

And since we absolutely do not want chaos resulting out of the polygamy, there’s now a built-in rights and permissions system allowing fine-grained control of which server may access what data on the device.

Summary
There’s only so much which can be covered in a single blog post but here are the takeaway points from the above:
• Broadband Forum has released a new protocol to replace TR-069 called USP
• USP can implement all use cases from TR-069 but also do a lot more
• Extra care have been taken to keep the data identical and “just” improve the protocol

Written by Daniel Egger
Daniel is a principal Software Engineer and Product Owner of all USP related products at Axiros. He is also one of the authors of the USP specification and a Program Stream Lead for Data Modelling (TR-181, etc.) in the Broadband Forum.