Bringing intelligent automation to multi-operator network as a service
This proof of concept Catalyst project shows how operators whose stacks, business operations and processes that do not comply with TM Forum’s open APIs can use them to automate operations.
Bringing intelligent automation to multi-operator network as a service
Intelligent automation is high on every communication service provider’s (CSP’s) agenda as we move into the era of 5G. This Catalyst proof of concept shows how operators whose stacks, business operations and processes that do not comply with TM Forum’s open APIs can use them to automate operations, even beyond their geographic footprint, with minimal impact. The project, Automating service problem management business operations using the TM Forum Network-as-a-Service APIs, is championed by BT and Vodafone, supported by participants Cortex, The OpenNMS Group, Solent University and Tech Mahindra.
The team chose an IoT type of service that runs on an IP VPN, where the primary or providing CSP extends its reach beyond its geographic footprint by using a second operator’s infrastructure to connect end devices. The approach to gaining interoperability using TM Forum’s Open APIs is to put a software “wrapper” around a CSP’s legacy stack and legacy business operations.
Wrap it up
Steve Connor is the project lead and Pre-Sales Specialist OSS/BSS at Cortex. He explains, “The wrapper has knowledge of the internal processes and operations that the CSP uses and so has the intelligence to know how to convert those inbound TM Forum API requests into the right event or driver for the existing business operations of the CSP without disruption.”
This is key as every CSPs has its own processes, reporting tools, management structures and so on. As Connor states, “Intelligent automation is not just a technical technology integration, it's a business operations integration. What we want to show is how we can help CSPs evolve to TM Forum API compliance, without a radical overhaul of their existing internal systems and processes that do the job”.
The focus of the Catalyst is on service assurance for this multi-CSP IoT service. The service architecture is shown below.
Three kinds of failure
The team identified three types of failure to address: In all three scenarios, we are looking at how the three parties involved – the primary and secondary CSPs and their customers – should be using TM Forum’s NaaS API components. To be effective, they must share information so problems can be solved more rapidly, by providing visibility of the problem. The advantages are faster time to repair and that all the parties have complete visibility all of the time, which reduces the burden on the CSP in terms of customers and supplier or provider partners demanding to know what's going on.
- First is a failure on a directly connected IoT device, that is on the primary or providing CSP’s customer site, to demonstrate how the customer and the CSP use TM Forum’s network as a service (NaaS) APIs to report and manage that that service fault.
- Second is a failure in the last mile part of connectivity to an end device that is on the second or supplier CSP’s infrastructure. From the customer’s point of view, the process is the same in that it notifies the providing CSP, but for the operators, there are many different internal processes that come into play between the two of them.
- Third is when a failure happens at the interconnect between the two CSPs where a failure on that is likely to affect not just a handful of devices for one customer, potentially but thousands for another.
Extending CSPs’ geographic reach
Connor says, “We are working on a solution that really takes all those incompatibilities out of the equation so that CSPs can with confidence buy and use services from other CSPs to extend their geographic footprint, and, importantly, sell their own services to other CSPs that in turn want access beyond their geographic footprint”.
The team intends to make a three-fold contribution to TM Forum’s assets. First by providing a real world reference of message sequences and message payloads for service assurance multi-CSP services. Second by verifying that the Information Framework’s (also known as SID) model is appropriate for use in this kind of service assurance process. The third is to identify gaps, errors and omissions in the current APIs then, as Connor concludes, “We will propose some changes to make the APIs more readily useful and usable, through extended capabilities and more precise definitions of their role and the information they contain”.
The team is still at the early stages of this Catalyst, but their progress will be demonstrated in the Digital Catalyst Showcase on July 30. Not all the areas described will be addressed in this first phase, but the team expects the proof of concept to run to a second and even third phase, and are already discussing extending the scope to include service provisioning.
Watch Cortex’s Steve Connor preview of the Catalyst in the video below: