In the previous blog, I outlined some of the key differences between the TR-069 and USP (née TR-369) protocols and why USP provides a solid improvement. But (as you may have noticed), I also left a few strategic spoilers about some unique features which make USP truly awesome; and that’s what we’re going to address today.

Behind you — a fancy feature! Or two, or three…

Multiple Controller Support
Have you ever wondered people give you funny looks or tormented faces when you’re laying out your sparkling ideas about exciting new operational functions (of course, to be rolled out in the existing environment, with deployed devices in the field and utilising the one and only TR-069 connection)? The reason for that is: it is a major pain to plan and implement, and comes with a high risk for severe consequences, potentially up to the “hey, we knocked out the whole network for a week or two” class. That is the main reason why a lot of businesses are wary of adding new functionality to a working setup.

But it doesn’t have to be this way! With USP, a single Agent implementation can easily hook up to Multiple Controllers. Want do deploy a new feature? Deploy your infrastructure, configure the new Controller in your installed device base (via USP, of course!) and off you go… what, the feature didn’t provide the anticipated benefit? Undo the above, done.  No weird side-effects on established use cases, no intense interaction and coordination between different business units, no person months of work and long nights — win-win-win-win…

“But wait!”, I hear you say: “What about Controllers stomping on other Controllers feet (err, data)?”, ”What about data privacy?”, ”Or maybe a hijacked Controller attempting to do nefarious things to the devices?”. No worries, USP has got you covered on that front as well! Thanks to a built-in dynamic Role and Permission model, Controllers can be easily limited to only have access to the parts of the data model actually required to do their particular job, and since every capability of a device is now part of the data model, there’re also no blindspots not guarded by this mechanism.

Partial Success
In device management (just like in real life), success is relative and always in the eye of the beholder: Is it okay to ignore if you try to create an object and that exact same object already exists or should that be flagged as an error? What about if you try to set a convenience parameter which happens to not exist in one particular device model?

In USP, the Controller gets to decide how such cases should be handled by the Agent, i.e. which actions must fully succeed and which are allowed some slack and are considered successfully executed anyways.

This indeed becomes very important when considering that individual actions are typically part of complex workflows and (both real and false) failures may require aborting the workflow and likely even a tedious undo of all previously done steps. Now if an errors occurs in the rollback… nah, let’s not go there today. This certainly reminds me of the next feature of USP to cover…

Mighty powerful messages
As alluded to in the previous section, workflows can become crazily complex when each step has to be a small one and might return an unjustified error (thereby also invalidating the changes the step would have caused), which potentially requires a dedicated (and possibly complex) recovery procedure, too. In TR-069, some procedures force you to make multiple small steps, e.g. if you want to create a new object: you first have call AddObject, and if that succeeds, it will yield an instance number which then can be used to execute a SetParameterValues to change the parameters inside the object. That might be okay for a single trivial object, but in reality we’re talking about whole trees of objects, requiring dozens or even hundreds of actions which (again) can individually fail for any number of reasons. And of course one would rather create such a beast once rather than duplicate and manage a number of them for different device vendor/models/versions.

On the other hand, with USP, you can not only create multiple objects with a single Add message but also (and atomically) fill the created object(s) with the actual data (for some, you actually have to, because values can only be changed during object creation; no more objects in a limbo state, yay!) and you can actually allow things to go wrong and still carry on which can dramatically simplify workflows and hence boost productivity.

Speaking of which: another excellent and timesaving feature is built-in edge computing! Oh wait, we’re calling them Search Expressions, but the point is: Rather than having the Agent sample, pack, and send a ton of data to the Controller, only to have the Controller waste energy to filter the actually interesting bit(s) out of the bunch and throwing the rest away, you can use Search Expressions to do a limited query for the data of interest or even change it conditionally. Fancy (if I say so myself)!

(Notification) Subscriptions
Rather than having a fixed set of event codes that will trigger communication and a weird set of attributes in the data model to enable value change notifications, USP works with Subscription Objects in the instantiated data model, allowing a Controller (each individually) to subscribe to relevant notifications and control their behaviour. Not only does that provide much more flexibility, but it also offers greater power due to new notification types (e.g object creation/deletion) and the ability to use recursive paths and Search Expressions. Oh, and subscriptions apply dynamically, too, so you can subscribe to notifications that are not available at the time.

Last words…
You’ve reached the end of yet another blog article, brave reader! However, as you might imagine, in around 1000 words, I can still only capture and present a small selection of my favourite subtopics, so I guess I might have to continue this series since we’re still far from done…

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.

Related Info:
Blog post: A Gentle Introduction to USP/TR-369
Knowledge Base: What is TR-369?