Packaging Open APIs for NaaS

TM Forum’s Open API Project team is working on several API component suites which show how specific APIs can be used together to address business challenges. Now the team is rolling out a NaaS (network as a service) Component Suite aimed at automating the end-to-end lifecycle of network services.

Component suites are highly cohesive sets of APIs that support end-to-end scenarios or execution flows across resources. For example, TM Forum already provides a Customer Self-care Component Suite, which defines the minimum mandatory APIs required to deliver a self-care service to customers. The specification also captures the resources and functions required by a self-care application used by a communications service provider (CSP) to allow customers to manage services they’ve subscribed to.

Why NaaS?

“With the NaaS Component Suite, we have focused on the service layer as a result of the NaaS concept spearheaded by Telstra,” says Steve Harrop, Principal Integration Architect, Vodafone Group, and Co-leader of TM Forum’s Open API Project. “This is also of great relevance for Vodafone’s work in ONAP and service orchestration, where we have a number of proofs of concept ongoing with vendors and academia.”

The beauty of NaaS is that it decouples operational and business support systems (OSS/BSS) from the network itself. Say a CSP wants to use a new virtual firewall in a managed firewall service offered to enterprise customers that previously had been served using a physical firewall. In a traditional environment, the IT systems that manage firewalls interact directly with each vendor’s firewall using a bespoke set of commands and instructions. This drives unnecessary complexity into the OSS/BSS that enables a vendor’s firewall service to be ordered, managed, assured, billed for, and fixed if there is a problem.

With NaaS, the network domains expose network services without IT systems having to know how the service is composed at the underlying network resource level. Consequently, a change from physical to virtual resources or a change in supplier, creates no impacts to the IT systems. The magic that makes this simplicity possible is TM Forum Open APIs.

Most CSPs are transforming their networks by moving network functionality into software. With NaaS, operators can create catalogs of “exposed” network services, which they can mix and match to build offers for customers. Telstra is doing this by deploying NaaS capabilities as a network abstraction layer (see graphic below). This offers a unified, standard way to publish and consume network-exposed services using TM Forum Open APIs, which improves agility and saves time and money. Read this case study to learn more about Telstra’s approach.

What is the NaaS Component Suite?

“We are excited to see the publication of the NaaS Component Suite,” says Pierre Gauthier, Chief API Architect, TM Forum. “The capability of binding APIs as being part of a logical component providing a highly cohesive set of capabilities is a major step in creating the building blocks for the next generation of BSS/OSS architectures.”

The NaaS Component Suite includes Open APIs classified in four main lifecycle areas of a CSP’s business, each of which relies on different OSS/BSS:

• From the sales’ prospect to the customer placing the order


• From ordering a service to activating it


• Resolving problems once it’s activated


• Usage and payment for the service

Specifically, the suite initially includes six Open APIs with two more to be added in the next release. All eight are described below to show how they function together in an end-to-end flow:

1. Service Catalog API (TMF633) – the first step is exposing the available network services, which is done through a service catalog


2. Service Qualification API (TMF645) – then a qualification check must be performed to determine whether a network service can be delivered


3. Service Ordering API (TMF641) – if qualification is successful, the network service can be ordered (this API will be included in the next release of the suite)


4. Service Activation and Configuration API (TMF640) – once it’s been qualified, the network service is reserved, activated and configured


5. Service Inventory API (TMF638) – when the service has been successful ordered, the service inventory is updated to show that the service is now assigned to that customer; this can be queried by the Service Inventory API (this API will be included in the next release)


6. Service Test API (TMF653) – then the network service must be tested to ensure that it’s performing properly


7. Service Problem API (TMF656) – if there is a problem with a network service, steps to fix it must be initiated


8. Usage Consumption API (TMF677) – finally usage information is collected for billing purposes

Telstra, Vodafone and other CSPs are hoping to use the NaaS Component Suite as a catalyst for a new conversation among teams and to lead the convergence of Networks & IT. This will result in breaking down the silos that typically exist within telcos, with an overall goal of facilitating an end-to-end customer outcome.

“Today each of the APIs (e.g. O2A, U2C, T2R, P2O) belongs to a different group within IT or Network, and although by investing in standard and open APIs we are reducing our testing, increasing our agility and creating one language, it can still be difficult to break down the silos,” explains, Guy Lupo, Network Transformation, Telstra. “The NaaS Component Suite enables a true solution-oriented, end-to-end conversation, allowing an agile delivery model with one product owner to focus on the customer outcome rather than the different APIs that make it.”

Improving the APIs

An important discovery the Open API team made during its work on the component suite is that all of TM Forum’s 50+ Open APIs need to be improved and homogenized to be more useful. This means standardizing the definition of terms, making sure all APIs use “polymorphic” patterns and characteristics, and ensuring that they are well documented.

“Now every entity, within each Open API is feeding off a single ‘master’ definition, which is maintained internally within the Forum as a newly established library of JSON-Schema files, but collapsed inline into Swagger files as appropriate,” Harrop explains. “There will be no more contradictory definitions of the same ‘thing’, such as a Service Specification, Error, Party, etc., in any Open API.”

Polymorphism is also important in APIs because it allows them to present the same interface for different underlying forms. “All Open APIs will now have a ‘polymorphic pattern’ capability – allowing you to extend the payload by referencing additional external schema. Characteristics are now also polymorphic, allowing you to use any native or complex type,” Harrop explains.

The Open API team also has improved documentation, with specification documents now largely auto-generated from the Swagger file. “The data-model diagrams are completely auto-generated from the Swagger (using the open source PlantUML tool),” he adds, “so they will be fully in-sync with the specification rather than drawn up separately.”

Developers can access the APIs that are part of the NaaS Component Suite here.

What’s next?

The Open API Project team will continue its work to improve all APIs and will continue developing and enhancing component suites. In addition to the NaaS and self-care suites, the team is working on component suites for IoT device and ecosystem management and a joint agile delivery testing suite.

To learn more about TM Forum’s Open API Project or to join the collaboration team, please contact George Glass, VP, Architectures & APIs, via wgglass@tmforum.org.