Evolving Operations towards TM Forum’s Open Digital ...

Evolving Operations towardsTM Forum’s Open Digital Architecture

A Cortex Intelligent Automation White Paper

Cortex Ltd © All Rights Reserved 2020

The TM Forum is defining the future architecture

for Communication Service Providers (CSPs),

known as the Open Digital Architecture (ODA).

One principle of this architecture is the ability for

CSPs to communicate with their wider ecosystem

(partners, suppliers, customers) by standardised

RESTful APIs.

But how do companies evolve their current IT

infrastructure and business processes to that

future vision whilst maintaining their current

level of service operations, and without putting

their business at risk?


As part of a TM Forum Catalyst project championed

by service providers Vodafone and BT, Cortex

has demonstrated an innovative approach for

operators to take.

This strategy will enable them to realise rapidly

the benefits of the TM Forum standardised APIs,

with minimal risk to existing business operations,

and in a fashion that is compatible with the

telecommunications industry’s future vision, the

Open Digital Architecture.

The current model in which operators expose services using manual processes or

legacy standards like ebXml, is complex, expensive and creates friction, like a

barrier, for our customers.

We really need to transform to a model where all service fulfilment and service

assurance functions are exposed over standard REST-based APIs. This will really

allow us to rapidly launch innovative new products that are easy to consume by

our customers

Milind Bhagwat, Principal Enterprise Architect, BT

EXECUTIVE SUMMARY

Automating service problem management business operations in a multi-CSP environment


The TM Forum Open Digital Architecture (ODA) is a blueprint for modular, cloud-based, open digital

platforms than can be orchestrated by AI. It aims to transform business agility and to double OpEx

efficiency by enabling the generation of simpler, more standardised, IT solutions that are easier to deploy,

integrate and upgrade. There are six blocks within the ODA. Each of these blocks provides standardised

interfaces to the other blocks – and, via the Engagement Management block, to external parties in the

CSP ecosystem – through a set of API standards which are grouped together as a Component Suite.

The Engagement Management Block

Represents the interface between the service

provider and its stakeholders (including

customers, partners and suppliers); it provides

the capabilities to assure a digital, secure and

accurate interaction with those stakeholders,

and it provides a managed channel between

those external stakeholders and the functional

capabilities provided by the other blocks in the

ODA.

The Party Management Block

Contains data relating to all internal and external

entities that interact with the service provider,

and the associated processes to create, maintain

and manage them; this block provides capabilities

such as authentication and authorisation, and

billing and payments processing.

The TM Forum Open Digital Architecture


The TM Forum Network-as-a-Service (NaaS)

Component Suite is the set of standardised

interfaces offered by the Production block, and

its aim is to enable the automation of the end-to-

end lifecycle of network services.

The NaaS Component Suite comprises eight TM

Forum API specification standards, covering

everything from exposing available network

services in a catalog (TMF 633), through service

qualification (TMF645), service ordering and

activation (TMF 641, TMF 640), service problem

management (TMF 656) and service usage

consumption (TMF 677).

Network-as-a-Service Component Suite

The Core Commerce Management Block

Contains data and processes relating to the

creation, offering and management of goods and

services that are sold by the service provider; it

is responsible for formalizing business models,

revenue generation and business assurance

processes.

The Production Block

This block is responsible for the data and

processes relating to Customer-Facing Services

(CFS) and Resource-Facing Services (RFS); it

exposes its services via the Network-as-a-Service

(NaaS) Component Suite APIs for consumption by

other blocks.

The Intelligent Management Block

Provides analytical capabilities using the data

available from the other blocks to provide insights

and recommendations to the service provider as

a whole.

The Decoupling and Integration Block

Provides governance and management of the

separation of functional borders of the other

blocks.

These specifications are intended to simplify,

standardise and improve the operations of

service providers in delivering services to their

customers; and their customers are increasingly

other service providers that wish to utilise the

technology, capacity or geographic reach that

they provide.

To date, service providers have invested in IT

infrastructure and business process creation

and execution to deliver to their customers

appropriate levels of service in, especially,

the fulfilment and assurance arenas. That IT

infrastructure will have evolved over a number

of iterations to handle the specifics of the service

provider’s network equipment, and their network

and service architectures – and it continues to

evolve today in response to ongoing large- and

small-scale changes to those specifics.

In the service assurance arena, for example,

small-scale changes are represented by the

introduction of new software or firmware versions

from the equipment vendors in response to

reported faults – this may result in the addition,

modification or removal of a small number of

alarms that might be reported by the equipment.

Large-scale change may be the result of migration

to an SDN/NFV oriented network architecture, or

a merger with another company; in this instance

not only are there large amounts of changes

to the alarms that the assurance system must

handle, but the types of actions that need to be

taken might be radically different – instead of

resetting a port, for example, it may be that a

new VNF instance needs to be spun up in a new

location.


But it’s also important to consider the

associated business operations alongside the

IT infrastructure. These business operations

will utilise the functional capabilities of the

IT infrastructure to deliver the fulfilment or

assurance service, but also provide the necessary

management, reporting and planning activities

to ensure continued operations delivery. And like

the IT infrastructure, these business operations

will have evolved over time in response to small-

scale and large-scale changes.

Here, small-scale changes might be caused by

changes in staffing or in responsibility, while

large-scale changes might be the result of

network evolution, of regulatory requirements

or of major organisational restructuring.

Service Provider Evolution


We believe that the fastest, most cost-efficient

and least-risk approach is to implement a NaaS

‘wrapper’ or gateway based upon the Cortex

Intelligent Automation product. Such a gateway

performs two separate yet related functions.

Firstly, it is able to ‘talk’ in the language of the

NaaS APIs – it can send and receive messages

in the correct format and in the appropriate

sequence, and it can convert those into API calls

supported by legacy applications.

The co-evolution of both IT infrastructure and its associated business operations will have resulted

in the ability to deliver the required fulfilment or assurance service at a cost and to a quality that is

acceptable to the service provider. Obviously, introducing the Network-as-a-Service capabilities into this

stable operation represents a risk; how can service providers deliver NaaS APIs whilst minimising both

the risk to their existing business operations, and the cost of implementation?

Removing Risk - Increasing Efficiency - Maximising Compliance

Secondly, and in some ways more importantly, it

has knowledge of the internal business operations

which enables it to make decisions about when

and how to involve the systems or the people that

currently perform those operations. It’s not just

a data re-formatting function, it’s about being

able to recognise how the NaaS API end-to-end

process maps to the internal business process,

and vice versa.

This gateway function, then, needs to have an

understanding of the service provider’s internal

business operations and its IT infrastructure,

and of the mapping between those and the NaaS

messages.

Because every service provider may have

different legacy IT infrastructure – even multiple

different systems that perform similar functions

dependent upon the service (e.g., mobile vs

fixed) or customer type (e.g., residential vs

enterprise) the NaaS Gateway is not just another

piece of software that service providers can buy

off the shelf.

But it need not be fully bespoke, either,

because the outward-facing, NaaS side of it is

standardised.


The Cortex Intelligent Automation and

Orchestration platform delivers both aspects of

this. Its in-built capability to invoke and receive

any API defined by an openAPI specification –

including those defined by the TM Forum as

part of the Network-as-a-Service Component

Suite – provides the outward facing integration

capabilities; and its wide range of pre-built

integrations mean that it can be easily integrated

with any legacy IT infrastructure environment in

place within the service provider.

The Cortex no-code, graphical user interface for

authoring automation flows lets organisations

quickly implement the mapping between the

TM Forum NaaS Component Suite operations and

their own internal business operations. Using

the Cortex Intelligent Automation platform,

companies can offer rapidly an industry-standard,

future-proofed interface to the outside world,

whilst minimising the risk to their existing

business operations, the cost of upgrading

their capabilities and protecting their existing

investment in their current IT infrastructure.


Cortex, the OpenNMS Group, Tech Mahindra and Solent University participated in a TM Forum Catalyst

project championed by Vodafone and BT. The project investigated how the TM Forum’s Service Problem

Management API specification could be used in a multi-provider, IoT service scenario, and how a NaaS

Gateway can be used to wrap legacy IT infrastructure to provide a NaaS-compliant integration interface.

TM Forum Catalyst: Evolving theory to reality

Three failure modes were investigated: loss of

connectivity between the service provider’s

network and a customer’s IoT device; loss of

connectivity between a last-mile provider’s

network and a customer’s IoT device; and loss

of connectivity between the service provider’s

network and the last-mile provider’s network.

For each of these failure modes, the interactions

between the three parties were identified. These

interactions took the form of messages defined in

the TM Forum Service Problem Management API

Specification (TMF656).

A simple service model was developed, illustrated

above. A customer orders an IoT service from a

Providing CSP; the IoT devices are either directly

connected to the providing CSP’s network, or

indirectly connected over a last mile connection

provided by another CSP, the Supplying CSP. The

customer has access to a cloud-hosted Service

Management System (SMS) which is monitoring

each of the IoT devices. The Providing CSP

and the Supplying CSP each have their own

internal IT infrastructure for fault management,

consisting of a managed network and a Network

Management System.

Message sequence diagrams and message

payloads were identified. Additionally, for the

Providing CSP and the Supplying CSP, interactions

with the relevant Network Management System

for alarm notification and fault management

were identified.


Consider, for example, the first failure mode

investigated – where there is a loss of connection

to a directly connected IoT device. This will be

identified by both the Providing CSP’s Network

Management System, and by the Customer’s

Service Management System. The Providing CSP’s

NMS will initiate existing fault reporting and

rectification activities – possibly raising trouble

tickets and assigning engineers to investigate

and fix; but for Service Problem Management

the providing CSP needs to notify all customers

affected by the fault that have previously

reported a desire to be notified.

In response to an internal fault, then, the providing

CSP’s internal fault management infrastructure

will notify the NaaS Gateway, which will take

responsibility for the communication with

customers. At much the same time, the Customer’s

SMS will detect a loss of connectivity to the IoT

device, and will report this to the Providing CSP

using the Service Problem Management API.

Whether the Providing CSP’s internal trouble

ticket for the fault was originally raised because

of the internal fault management applications,

or in response to a Service Problem being

reported by the Customer, the lifecycle of that

internal ticket needs to be monitored by the

NaaS Gateway and reflected in the state of

the customer-facing Service Problem. Once

the trouble ticket identifies that the fault has

been fixed, following the legacy alarm and fault

management operations within the Providing

CSP, the NaaS Gateway needs to transition the

Customer’s Service problem to a ‘resolved’ status

and notify the Customer of this. Subsequently

the Customer may choose to close the Service

Problem.

The lifecycle of the Service Problem, then,

is related to but separate from the lifecycle

of the Providing CSP’s internal fault tracking

tools, and the NaaS Gateway needs to be able

to map the Service Problem lifecycle changes

to those for the Providing CSP’s trouble ticket.

The NaaS Gateway needs to have knowledge of

not only the interface into the Providing CSP’s

existing fault management applications, but also

of the lifecycle of the internal fault tracking

mechanisms, and of the business processes and

operations that update them.

FIND OUT MORE ABOUT THE CATALYST PROJECT

The NaaS Gateway will receive and acknowledge

this report and will need to relate it to an internal

fault or trouble ticket that has already been

raised, or will need to raise a new one within the

existing fault management IT infrastructure.

https://inform.tmforum.org/catalyst/2020/07/bringing-intelligent-automation-to-multi-operator-network-as-a-service/

https://inform.tmforum.org/catalyst/2020/07/bringing-intelligent-automation-to-multi-operator-network-as-a-service/


Given the significant investment companies have already made both in their existing IT infrastructure

and in their associated business processes, transitioning to this new architecture and APIs represents a

business risk to many.

Using Cortex Intelligent Automation to operate as a NaaS Gateway enables CSPs to quickly realise the

benefits of the TM Forum future vision, whilst minimising the amount of change to existing legacy

applications and processes. The TM Forum Catalyst project has proven that this is a realistic approach

for operators.

The TM Forum Open Digital Architecture is the industry vision for CSPs, and it is supported by a set of

standardised APIs, including those in the Network-as-a-Service Component Suite which are used for

ordering, provisioning, activating and assuring complex, multi-CSP services.

Operators that adopt these standardised APIs will be able to offer a wider range of services to more

customers in a more cost-efficient, higher-quality and more automatable manner. There is therefore

much pressure on CSPs to adopt these standards as quickly as possible.

CONCLUSION

“We can’t afford to throw away all our existing investments; we need to incrementally evolve the architecture we’ve already got, enabling us to deliver benefits back to the business earlier”

Lester Thomas,Chief IT Systems Architect & Distinguished Engineer, Vodafone

API – Application Programming Interface

CFS – Customer Facing Service

CSP – Communications Service Provider

IoT – Internet of Things

IT – Information Technology

NaaS – Network-as-a-Service

NFV – Network Function Virtualisation

NMS – Network Management System

ODA – Open Digital Architecture

OpEx – Operating Expenditure

REST – Representational State Transfer

RFS – Resource Facing Service

SDN – Software Defined network

SMS – Service Management System

VNF – Virtual Network Function

GLOSSARY


Cortex Intelligent Automation is the first unified platform specifically built to solve the challenges

preventing organisations’ acceleration to an autonomous future. Cortex rapidly creates value, using

multi-purpose intelligent automation software to transform telecommunications operations.

A unified, no-code, automation and orchestration platform, Cortex Intelligent Automation delivers

Workflow, Orchestration, Automation, Reasoning, Integration and Event processing. Unique, decision-

driven, closed- loop, and self-adjusting automation technology seamlessly integrates into existing and

legacy technologies, automating processes to increase accuracy, speed, agility, and to deliver tangible

ROI.

Process design within the Cortex Intelligent Automation platform requires no programming experience,

underpinned by Cortex’s mission statement of “A world where everyone can automate”, and puts the

business process owners and subject matter experts at the core of the automation project. Web based

and highly scalable, the platform supports a simple managed process for the migration of a process

design from development to test to production environments.

With strategic global delivery partners including TCS, Tech Mahindra, and Wipro, Cortex applies proven

strategies and methodologies for Intelligent Automation deployment, together ensuring that the most

successful outcomes and ongoing autonomous operations are achieved.

ABOUT CORTEX

START YOUR INTELLIGENT AUTOMATION JOURNEY TODAY +44 23 8254 8990 www.cortex-ia.com [email protected]


Evolving Operations towards TM Forum’s Open Digital ...

Documents

Transcript of Evolving Operations towards TM Forum’s Open Digital ...