Back to the future: NGOSS, autonomous networks and ‘ODA Contracts’
A 20-year-old TM Forum concept called Next Generation OSS (NGOSS) Contracts provides a strong foundation for self-healing, self-configuring, self-optimizing and self-monitoring networks, but they need to be modernized as 'ODA Contracts'.
George Glass18 Aug 2020
Back to the future: NGOSS, autonomous networks and ‘ODA Contracts’
In a recent blog, independent analyst and consultant Tom Nolle, Founder and President of CIMI Corp., evaluated some of ETSI’s current standards initiatives in telco transformation and referenced earlier TM Forum work on Next Generation Operational Support System (NGOSS) Contracts. He makes some excellent observations, but there is more to the story.
Today, the industry is trying to move away from building networks and services by connecting physical devices together. We are working toward cloud native software components that can be instantiated and interconnected as needed, whether in virtualized, private data centers or public clouds.
This philosophy underpins the TM Forum Open Digital Architecture (ODA), which replaces traditional operational and business support systems (OSS/BSS) with a new approach to building software for the telecoms industry. ODA is designed to be cloud native from the outset using a services-based integration approach. It does not dictate whether software components are deployed in public clouds or private data centers, but if you want to take advantage of the virtual, elastic nature of the cloud, then you must have cloud native design at the heart of the new architecture.
There is some dissatisfaction around abstraction of network functions virtualization (NFV) infrastructure, in particular the assumption in some standards work that lifecycle management of virtual network functions (VNFs) will be handled on an individual basis rather than collectively via a single virtual infrastructure manager. But the real trouble with NFV has always been that there was little attempt to abstract the management patterns of the network elements that they are representing and expose common business capabilities of the functions.
Recently, a TM Forum proof-of-concept Catalyst project called Real Virtuality took a practical approach to abstracting the management functionality of both traditional and virtualized network resources and their virtualization functions. This project led to publication of a framework for hybrid infrastructure management supported by a TM Forum Open API (the Resource Function Activation and Configuration API), which also incorporates the functionality of the ETSI NFV-SOL 005 interface.
Another area of concern is a proposal to create a new ‘platform class’ of VNFs for multi-access edge computing (MEC), contrary to cloud computing principles. One way to view MEC is as an attempt by telcos to retain an element of infrastructure which is rapidly transitioning to the hyperscale cloud providers. Currently, TM Forum members are working on an approach which could help resolve these tensions, enabling MEC APIs such as location to become embedded functions in the hyperscalers’ cloud APIs.
In other work on ODA and autonomous networks, members are looking at the concept of a cloud continuum from the hyperscale core to edge cloud to device cloud, each layer having different characteristics. For example, the hyperscale core effectively has infinite compute power and storage capacity compared to the edge cloud, but latency is higher which results in slower response times. This makes it unsuitable for some real-time processes.
ETSI’s proposals for closed loop network operations and management leverage AI. However, in his blog Nolle questions how the standards work applies when a coordinated response is needed to an issue that requires configuration changes to multiple elements beyond the operational scope of a single AI application.
TM Forum’s ODA and autonomous networks initiatives include the concept of an autonomous domain which may operate at different levels of autonomy and expose a set of domain-based services. The domain itself is designed to be self-healing, self-configuring, self-optimizing and self-monitoring. It leverages whatever technology is appropriate using business rules or AI to monitor, configure and reconfigure the resources – physical or virtual – to meet the SLAs of the domain service.
While the idea is that the domain is autonomous and should try to sustain itself and meet its SLAs, in reality that will not always possible. For example, if there is a physical failure in the network element that is delivering the autonomous resource domain function, or a failure in the autonomous resource domain management, this will require a hand-back of some decision-making to a superior autonomous domain controller (i.e. the autonomous service domain).
As a result, a cross-domain controller is also required to monitor the individual domains. If it detects that a domain is failing to meet its SLA, or if it appears that it will fail based on previous experience (via AI/machine learning), the cross-domain controller can spin up a new supplementary domain, reconfigure an existing domain, or switch to an alternative domain that delivers an equivalent business capability or service using a completely different technology.
The key is that in this example the input to the resource domain controller comes from the service domain’s intent (which originates with the customer’s SLA requirements) and traverses the layers of business, service and resource operations, with each layer encapsulating its services as an autonomous domain (see the image below).
Today, the industry is trying to move away from building networks and services by connecting physical devices together. We are working toward cloud native software components that can be instantiated and interconnected as needed, whether in virtualized, private data centers or public clouds.
This philosophy underpins the TM Forum Open Digital Architecture (ODA), which replaces traditional operational and business support systems (OSS/BSS) with a new approach to building software for the telecoms industry. ODA is designed to be cloud native from the outset using a services-based integration approach. It does not dictate whether software components are deployed in public clouds or private data centers, but if you want to take advantage of the virtual, elastic nature of the cloud, then you must have cloud native design at the heart of the new architecture.
The trouble with NFV
There is some dissatisfaction around abstraction of network functions virtualization (NFV) infrastructure, in particular the assumption in some standards work that lifecycle management of virtual network functions (VNFs) will be handled on an individual basis rather than collectively via a single virtual infrastructure manager. But the real trouble with NFV has always been that there was little attempt to abstract the management patterns of the network elements that they are representing and expose common business capabilities of the functions.
Ultimately, this has enabled vendors to persist with their bespoke management, control and reporting of the network elements that are being virtualized – and with proprietary operational interfaces. Indeed, there has been little effort to standardize the APIs into or out of the network plane, so in the case of a firewall, for example, while it’s possible to deploy any vendor’s firewall on any virtualized infrastructure, the OSS has remained as complex as ever because management interfaces to the firewalls are still element- and vendor-specific.
Recently, a TM Forum proof-of-concept Catalyst project called Real Virtuality took a practical approach to abstracting the management functionality of both traditional and virtualized network resources and their virtualization functions. This project led to publication of a framework for hybrid infrastructure management supported by a TM Forum Open API (the Resource Function Activation and Configuration API), which also incorporates the functionality of the ETSI NFV-SOL 005 interface.
The MEC angle
Another area of concern is a proposal to create a new ‘platform class’ of VNFs for multi-access edge computing (MEC), contrary to cloud computing principles. One way to view MEC is as an attempt by telcos to retain an element of infrastructure which is rapidly transitioning to the hyperscale cloud providers. Currently, TM Forum members are working on an approach which could help resolve these tensions, enabling MEC APIs such as location to become embedded functions in the hyperscalers’ cloud APIs.
In other work on ODA and autonomous networks, members are looking at the concept of a cloud continuum from the hyperscale core to edge cloud to device cloud, each layer having different characteristics. For example, the hyperscale core effectively has infinite compute power and storage capacity compared to the edge cloud, but latency is higher which results in slower response times. This makes it unsuitable for some real-time processes.
Since the functions of ODA are designed to be cloud native from the outset, they can be moved on demand and in response to service level agreements (SLAs) or customer intent from one cloud environment in the cloud continuum to another as needed.
AI & autonomous networks
ETSI’s proposals for closed loop network operations and management leverage AI. However, in his blog Nolle questions how the standards work applies when a coordinated response is needed to an issue that requires configuration changes to multiple elements beyond the operational scope of a single AI application.
TM Forum’s ODA and autonomous networks initiatives include the concept of an autonomous domain which may operate at different levels of autonomy and expose a set of domain-based services. The domain itself is designed to be self-healing, self-configuring, self-optimizing and self-monitoring. It leverages whatever technology is appropriate using business rules or AI to monitor, configure and reconfigure the resources – physical or virtual – to meet the SLAs of the domain service.
While the idea is that the domain is autonomous and should try to sustain itself and meet its SLAs, in reality that will not always possible. For example, if there is a physical failure in the network element that is delivering the autonomous resource domain function, or a failure in the autonomous resource domain management, this will require a hand-back of some decision-making to a superior autonomous domain controller (i.e. the autonomous service domain).
As a result, a cross-domain controller is also required to monitor the individual domains. If it detects that a domain is failing to meet its SLA, or if it appears that it will fail based on previous experience (via AI/machine learning), the cross-domain controller can spin up a new supplementary domain, reconfigure an existing domain, or switch to an alternative domain that delivers an equivalent business capability or service using a completely different technology.
The key is that in this example the input to the resource domain controller comes from the service domain’s intent (which originates with the customer’s SLA requirements) and traverses the layers of business, service and resource operations, with each layer encapsulating its services as an autonomous domain (see the image below).
Back to basics
Nolle’s comments related to zero-touch network and service management reject the utility of monolithic management applications. Instead, he proposes the principles originally developed under TM Forum’s NGOSS Contracts definition (these contracts are explained in the Business Services Concepts and Principles Guidebook).
Essentially,
an NGOSS Contract captures, in NGOSS component metadata, the lifecycle dependencies on other NGOSS components services – for example, the terms of a contract SLA, minimum volume purchase commitments by the customer, parties authorized to make changes to the service, dependencies on network resources, etc. This lifecycle dependency information can be vital, for instance in quickly determining which SLAs are affected when a particular network resource goes offline.
With the detailed definition of cloud native software components and development of patterns for their implementation and integration underway in TM Forum’s collaboration work, ODA has reached a level of maturity sufficient to address use cases where the need for “ODA Contracts” is becoming apparent. NGOSS Contracts were originally developed in the early 2000s, long before cloud native software architectures and intent-based closed loop automation, and are based on the notion of “design by contract”. These concepts need to be updated with a new ODA Contract to complement ODA components. The earlier work on NGOSS Contracts provides a solid foundation on which to build.
You can learn more about the ODA in this white paper and in this research report. If you’re interested in joining this collaborative work, please contact me directly.
