CSPs see CAMARA collaboration as a model for standards

As telcos seek to monetize 5G and network-as-a-service (NaaS), they need collaboration among standards-development organizations (SDOs) and open-source groups to increase interoperability and avoid reinventing the wheel. Some operators are pointing to the collaboration among TM Forum, GSMA and the CAMARA Project on GSMA’s Open Gateway API ecosystem as a model for success. In November, TM Forum members began developing new “Operate APIs” to complement CAMARA network APIs, with a goal of providing a standardized way for mobile operators to make the interfaces commercially available to aggregators and developers.

“It is a turning of a new corner,” says Steve Harrop, Principal Integration Architect at Vodafone Group and the leader of TM Forum’s work with CAMARA and GSMA. “TM Forum members are effectively writing APIs with their tooling and constructs to submit to GSMA.”

CAMARA is an open-source project within Linux Foundation Networking that works in close collaboration with the GSMA Operator Platform Group (OPG). OPG brings together operators, developers and platform providers to transform multi-access edge computing (MEC) services. Its Open Gateway initiative aims to drive universal adoption of APIs designed to expose network capabilities without the need for end-user developers to understand telecoms network technology or terminology.

While CAMARA is developing the APIs to expose network capabilities such as quality on demand (QoD) and device location to developers, APIs for IT operations are needed to automate service delivery, track usage and provide billing capabilities, “so that a third party can find the CAMARA API and buy the right to use it,” Harrop explains. Some operators are already planning to demonstrate the Operate APIs working with CAMARA APIs at Mobile World Congress in February, he adds.

TM Forum members from Vodafone, Orange, Telefónica, Ericsson and other companies are working within TM Forum with CAMARA members (in some cases the same people from the companies are working in both groups) to develop the Operate APIs in phases. “The Operate APIs will be mandated by GSMA as the standardized way to make CAMARA APIs commercially available to developers and support delivery of services ordered through the APIs,” says TM Forum Chief API Architect Pierre Gauthier.

Domain context specialization

Some of the work leading to extension of TM Forum’s Open APIs has happened within a joint TM Forum Catalyst proof of concept championed by more than a dozen of the world’s largest CSPs (AT&T, Axiata Group, the Bridge Alliance, China Telecom, Deutsche Telekom, Dialog, Jio, Orange, STC, TIM, Telefónica, Telenor Group, Telstra, Vodafone Group and XL Axiata in the latest iteration).

The Catalyst, which was demonstrated in two phases at Digital Transformation World events in 2023, has been looking at how service APIs from CAMARA and operations APIs from TM Forum can work together to provide quality-on-demand (QoD), device location and payment capabilities for applications such as videoconferencing and gaming. For example, the project has demonstrated the ability to provision and bill for “boostable” QoD in a gaming scenario. A joint white paper that incorporates learnings from the Catalyst is available here.

To develop the Operate APIs, TM Forum is using an approach called domain context specialization, or DCS, which standardizes Open API payloads for specific applications like 5G slicing or wholesale access. Using DCS, a single Open API can carry different standardized payloads, which eliminates the need for technology-specific management and orchestration APIs. This makes the overall management and maintenance of APIs much easier and less expensive.

DCS “specializes” the interface for certain scenarios or domains in order to constrain it and therefore make it easier to implement, explains TM Forum CTO George Glass. The designer of the DCS can specify that normally optional attributes are mandatory or that specific entity values are restricted, for example.

A model to follow

While the GSMA Open Gateway project focuses on abstraction from technology-specific APIs to service APIs to simplify telco complexity, CSPs hope it can be used as a model in many other areas where agreement among SDOs and open-source groups is needed to automate ordering, provisioning, orchestration, assurance and billing of services end to end across multiple domains such as mobile radio access and core, multi-access edge computing (MEC), IP, and optical networks.

Indeed, a large number of SDOs and open-source groups are working on the deployment and management of next-generation telecoms networks. The table below, which is not exhaustive, shows some of the projects that CSPs and their suppliers are supporting. Joining any one of the groups usually involves spending money on membership and the commitment of an employee’s (or multiple employees’) time. Sometimes a single staff member has responsibility for a company’s participation in more than one group. It’s easy to see why collaboration is essential.

A main issue for CSPs is that simply agreeing to adopt standard APIs isn’t enough. They also need the domain context specialization and agreement on common API design principles.

“At the moment, we have this big push on interfaces…but what we want to see in the next level of maturity is to have uniform functions with DCS APIs that enable us to truly just plug things together,” says Joel Ferreira, Technical Product Owner, Networks as a Service, at Telstra. He would like to see collaboration similar to what’s happening between TM Forum, CAMARA and GSMA for other APIs.

Abdul Majid Hussain, Principal Architect at Telstra, agrees: “There is a need for a unified and common view across various SDOs to enhance the maturity of API interfaces and functions.” He points to the absence of a common view, which leads to implementation disparities.

Abdul Majid advocates for:

1. Uniformity across SDOs – stressing the need for consistency not only in API alignment, but also in architectural aspects, aiming for a cohesive approach.
2. Unified design guidelines – a unified design guideline avoids having multiple variants of the same API, such as ordering APIs.
3. Resolution of ambiguities and differences – urging the need to iron out any discrepancies or ambiguities in the implementation approaches among the SDOs.

He highlights the importance of unifying the approach towards DCS APIs across different levels, aiming to promote enhanced consistency and collaboration among SDOs.

Vodafone’s Harrop and Dr. Lester Thomas, the company’s Head of New Technologies and Innovation, believe the collaboration between TM Forum, CAMARA and GSMA can be the model. Thomas explains the problem like this: “We have one standards body for IT management and operations, but in the networks every domain has its own standards body – it’s not that we’ve got just two; we’ve got six or seven”, and all the domains have their own slightly different way of designing APIs.

Harrop adds: “At the moment there is no mechanism or liaison between the SDOs at the design level, so it doesn’t happen. The API designs are not terribly inconsistent – they all are trying to follow internet best practice – but ask two architects what the internet’s best practice is, and you’ll get three answers.”

The solution is for the organizations to collaborate. “The tough nut to crack in that is that one or the other is probably going to have to make some backwards-incompatible changes to accommodate consolidation, and that's a tough pill to swallow,” Harrop acknowledges.

New API Partner Program

TM Forum recognizes the problem of multiple SDOs potentially creating variations of the same API. To avoid an unnecessary divergence of standards and the complexity that divergence creates for operators, TM Forum has created an API Partner Program to support other organizations in specializing Open APIs for their product sets. The alignment between TM Forum, CAMARA and GSMA is an example of the program’s potential.

“This involves the creation of context-specific APIs, using DCS payloads,” says Glass. “The partner program reduces the risk of groups duplicating effort to build APIs that already exist or forking from industry standards.”

He adds: “Within the program the relevant bodies agree to use standardized APIs and design guidelines, and then each individual partner assumes responsibility for defining its domain-specific payloads, offering its own conformance certification process if required.”