Inango blog

Inango Service Orchestration and USP

By Jonathan Masel, CEO

13 April, 2022

There is a growing amount of discussion about how to incorporate new software services into the gateways that we use in our homes to connect to the Internet. After all, it makes sense – Service Providers have enormous networks of users and a foothold in all of our homes via the gateways (or routers or modems…) they deploy there as part of their Internet access products. Our networks, with all our computers, phones, gaming stations, Set-Top Boxes, IoT devices and much more have also grown in power and complexity. Back in the days when I went to university, the entire campus was powered by a super-computer whose power and memory are far exceeded today by my children’s phones. So the stage looks ripe for new technologies that our Providers can use in innovative ways to help us manage our increasingly digital lives.

One of the more promising directions is a standards-based initiative called USP (User Service Platform), which is part of the TR-369 standard. In a nutshell, USP is about putting software services inside containers and then downloading and running them on a gateway via management-like mechanisms. There is more to it, but that is the gist of it.

If you’ve been following our previous blogs, you may see an overlap with what Inango is doing with our Service Orchestration. We too give mechanisms for incorporating services into the gateway functions. We too let Providers add these services without re-building the whole software image on the gateway (a process no-one likes doing). So what is the difference?

Put very simply, USP is a mechanism. Inango Service Orchestration is a solution, that may use USP or other mechanisms. There is no contradiction or even tension between the two.

What do we mean by this in practical terms?

USP defines ways in which containers can be loaded into gateways. Inango Service Orchestration can load containers into gateways – using USP or other schemes. But the standards don’t address a whole range of issues that our Service Orchestration does, which is precisely why we call USP a mechanism and Inango Service Orchestration a solution. Examples? Some services need to run inside Virtual Machines (not containers) – Inango supports this, USP doesn’t. We have the ability to add services to the gateway while running these services on external servers (i.e. if your gateway is out of memory) – USP does not address this. Inango Orchestration uses a system architecture that provides maximum isolation between the services and the basic gateway software (the “SDK”) so the system is far simpler to maintain and upgrade. Again, not contradictory to anything in USP, just not addressed by it at all. We offer ways of sharing things like event notifications, history logs, alarm indications and more. And we could go on – these are just some examples.

Inango supports the standardization efforts – after all, communication could not exist without it. But we equally believe that these standards need to be part of a complete system to be used in commercial products. That means having a system architecture and functionality.

Are you are experiencing unacceptable delays in time to market for new services due to CPE software integration issues, or have limited ability to deploy more services due to legacy equipment that is out of memory or using unsupported software? If so, we should certainly be talking – we can help! To see how this works in real-life and dive further in to details, please contact us and we’d be happy to arrange a presentation or live demo.

All rights reserved to Inango Systems Ltd, © 2020. Coded by Forma