Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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?
Cortex Ltd © All Rights Reserved 2020
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
Cortex Ltd © All Rights Reserved 2020
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
Cortex Ltd © All Rights Reserved 2020
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.
Cortex Ltd © All Rights Reserved 2020
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
Cortex Ltd © All Rights Reserved 2020
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.
Cortex Ltd © All Rights Reserved 2019
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 Ltd © All Rights Reserved 2020
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.
Cortex Ltd © All Rights Reserved 2020
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.
Cortex Ltd © All Rights Reserved 2020
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 Ltd © All Rights Reserved 2020
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]
Cortex Ltd © All Rights Reserved 2020