Skip to content 
Introduction
Often, many of us conclude that automating large-scale communication service provider networks is difficult because there are many different components and complexities. Case in point, a typical communications service provider (CSP) on average can purchase hardware and software from 50 to 100 vendors.
The network automation industry often speculates whether a CSP network’s automation entails more than just automating network components and the associated services, and for good reason. Typically, automation also encompasses the business processes and systems such as commerce, accounts, party management, CRM, engagement management, production, and more.
To automate all of the operations of a CSP, the most crucial requirement is that these systems communicate with each other seamlessly or, in layperson’s terms, speak the same language.
A survey by TM Forum posed a series of questions to 170 individuals from the network and operations roles of 93 CSPs around the globe. All of these CSPs had implemented 5G services in their respective countries and regions. The survey was designed to understand the maturity of network lifecycle automation solutions within different CSPs. Two of the most important survey questions were:
The first three answers to the second question all point, to some extent, to the inefficiencies of the business processes to deal with the nature of network services that these CSPs offer.
APIs, whether REST or RPC, are key to having logical or application-level interaction between two pieces of software. A philosophy of exposing standard API endpoints by independent software vendors (ISVs) is maturing, but it is still a challenging proposition.
The resulting value lies in increasing the productivity of CSPs and decreasing time-to-market for existing and new services, in the form of the ability to provide Network as a Service (NaaS).
Hypothesis
Every CSP has its own, often proprietary way of handling service orders. Each is handled by a carefully designed chain of systems that focus on the immediate requirements but not the complete hierarchy of systems working within any CSP. For Example, the billing systems need more understanding of the Network Orchestration Systems.
Consequently, this gives rise to human intervention, to stitch processes together, creating unnecessary data entry-like peripheral tasks that are not value add. Ultimately, this compresses the time spent on primary tasks of analytical thinking and decision-making that drive the business forward.
How do we resolve the disconnect between the internal systems in the communication industry?
Well, there seems to be light at the end of the tunnel. The answer comes with the TM Forum, a consortium of leading CSPs and supporting vendors that provide services, solutions, software, and hardware to these CSPs.
You can find an extensive list of member CSPs and Vendors here.
Additionally, it is worth reviewing two more questions from the survey.
TMF Offerings
You might wonder what precisely this consortium does, and it’s a valid question. The primary objective of the TM Forum is advancing and promoting the use of Open APIs. These APIs go far to provide a standardization framework to simplify inter-system communication and standardize, as well as streamline payloads, URL creation, and operational methodologies.
Furthermore, an Open API becomes a working REST API when incorporated into a given tool or app- with some or all of its endpoints mapped to various resources within the tool.
To better understand this, imagine you are a developer for a well-known video streaming service (like Netflix) and creating an app that is compatible with Apple’s iOS platform (iPhone). One of the requirements might dictate that a movie be available for search on Google, and the results reflect a direct app link. When the user clicks on the app link, it should launch that app. The following video captures this process flow.
Apple documentation specifies how this action is performed. Now, if we plan to incorporate this in our App, it will make the content in our App searchable and easily accessible directly from the Google search results in your browser. Besides improving the customer experience, it aligns our app API with Apple’s guidelines and ensures that all browser apps following the same guidelines can effectively do handoffs to our App.
TMF is like Apple in our case and provides its own set of documents and Open APIs that tools or products (like Apps on an iPhone) meant for CSPs to inter-operate like the browser app and Netflix app.
Most tools already have their native REST/RPC APIs. How may these Open APIs be incorporated into the tools? Do they require a complete overhaul of product design, or is there any other way out? Please read the following section below to learn how we responded to that query for our product Anuta ATOM.
Note: Find the detailing of important Open APIs TMF here.
Anuta Networks ATOM- The TMF API Gateway
Anuta Networks strives to make ATOM an end-to-end service manager as defined in the Open Digital Architecture (ODA) standard. ODA is a document that redefines the high-level roles and their components for all the business processes and network infrastructure within a CSP.
Fig: Open Digital Architecture – Functional Architecture
The TM Forum’s Open Digital Architecture enables members to build highly complex but adaptable solutions using loosely coupled components that expose business functionality through a set of standard Open APIs.
Fig: Placement of ATOM in the ODA
When managing or deploying a service, interactions with four to five different systems are not uncommon, and these systems may also be part of other operational domains. Let’s use an illustration to clarify: To deploy a Layer 2 reachability service between a Mobile Base Station (4G/5G eNodeB) and the Packet core network elements placed in an MSC (Mobile Switching Center), it would be necessary for network devices to interact with various systems and domains. These domains might include the Radio Access Network, Transmission domain, Carrier ethernet network, Packet core network, and other BSS/ OSS elements like billing, accounts, etc. The request to deploy such services can also come from within organizations and outside parties such as customers and other external stakeholders.
Today, these multiple domains are siloed, and the evolution of Operational Domain Managers (ODMs) in various organizations is at varying stages of development. Most services are assembled by the IT/CCM (Core Commerce Management) domain. Each IT group, such as Order to fulfillment or Assurance or Billing, must navigate the intricacies of different domains or communication technologies to build service catalogs and other offerings quickly and easily.
Before proceeding further, it would be helpful to understand the components of Open Digital Architecture.
- Core Commerce Management: Traditional Business Support Systems (BSS) reside here.
- Production: Traditional Operational Support Systems (OSS) reside here. This also includes domain controllers/devices belonging to the aforementioned domains.
- Intelligence Management: This would include systems that provide intent-based actions or advice gleaned from insights derived from data collected during the service life cycle and other network operations. It also aims to provide “closed-loop” capabilities and functionality.
- Decoupling and Integration: This block in the ODA Functional Architecture represents all of the API interactions between the Engagement, Production, Core Commerce, and Intelligence Management components.
- Engagement Management: This is where inbound or outbound connectors and portals reside. This would mostly be where customers, partner CSPs, or Internal Teams might interact with the CSP’s NaaS infrastructure.
With an understanding of the ODA concept, let’s focus on the Production block. The E2E Service manager (ATOM), various ODM controllers, and network elements are all located here. This system can accept high-level instructions from other function blocks and translate them into more network/ODM-friendly instructions. The relevant operational domain controllers may receive instructions from the E2E Service Manager or give them directly to the network elements. Additionally, all ODMs involved have access to the resources related to the underlying network infrastructure, as defined by the E2E Service Management domain.
The image below demonstrates this flow:
Fig: The new NaaS Architecture’s E2E service management domain makes it easier to stitch together cross-domain services
Let’s point to another example to deepen the understanding of the E2E Service Management Domain. Imagine that a CSP offers an intersite L3VPN located across multiple geographies to its customers. Today, if a customer needs to order a similar service from a CSP, this will require a call to the CSPs Service Ordering Platform. This platform has minimal functionality because even though it can capture the customers’ requirements, the processes ahead of it require heavy human intervention. In most CSPs, the platform seems to be nothing more than an Order to Billing App run by personnel from the Core Commerce Management Domain.
As per TMF CSPs should broaden the scope of this platform and give it sufficient functionality so that it can process data provided by customers, internal teams, and stakeholders for a specific service that needs to be deployed or managed and be able to communicate precise instructions to the E2E Service Management Domain. It can deploy, modify, debug, and manage the services’ life cycle because of its knowledge of the resources and the Services catalog. Additionally, after completing any of the listed steps, update the platform by sending out various event notifications.
The TMF Client and the Event Listener represent two distinct functionalities that can be used to implement the features above. These functionalities perform the following:
- TMF Client: Create a “serviceOrder.json” file from the service order the customer put on the platform and send it as payload to an E2E service manager like ATOM so that it can deploy, modify, or cancel the service.
- Event Listener: This functionality can receive service-related notifications from the E2E Service Manager.
TMF Open APIs are critical in realizing the mentioned functionality. However, it’s crucial to also remember that ATOM had its own Northbound API. This begs the question- how are TMF Open APIs incorporated?
Fig: Example Event Notification
The TMF API Gateway is the answer. It is a feature that Anuta Networks created, allowing our platform to provide URI Endpoints, Methods, and Payload parsers that comply with TMF Open API guidelines. The following video illustrates the flow:
Fig: Flow of Service Order Northbound, Southbound, and within E2E Service Manager (ATOM).
Once the relevant service actions have finished, the Event Listener receives an event notification(s), which are then updated in the Customer View on the Service Ordering Platform. The diagram below illustrates this workflow during an L2VPN/L3VPN service deployment within a CSP.
Fig: A Service Deployment use case Flow Diagram.
Summary
The world is increasingly becoming more connected while CSP’s internal systems and processes seem to be disconnected. Today when we deploy a service between locations that span multiple geographies, CSPs often partner with one another as every CSP cannot have a strong presence worldwide.
Fig: Block diagram of CSP’s internal resources and different entities that interact with these resources to get a service provisioned
In a perfect world, CSPs that follow the same Open API standards (from TMF) in their internal systems and operations can benefit from uniform outbound connectors (Service Ordering Platforms) to their customers and partner CSPs. Simply stated, incorporating TMF Open API guidelines in all tools and systems within a CSP goes far to achieve this objective. Anuta Networks ATOM offers the right set of capabilities that allow CSPs to truly automate their network functions and realize the benefits that TMF has to offer for the overall organization.
Additional Contributors: Sukirti Bhawna, Manisha Dhan
