GSMA Open Gateway is a framework of common network

Application Programmable Interfaces (APIs) designed to

provide universal access to operator networks for
developers1. With the support of 25 mobile network
operators (as of April 2023), GSMA Open Gateway helps
application developers enhance and deploy services more
quickly across operator networks via single points of access
to the world’s largest connectivity platform.

This white paper introduces some concepts of an Open

Gateway Network as a Service (NaaS) architecture and sheds
light on the relevant demarcation points, to let GSMA Open
Gateway stakeholders (customers, operators, aggregators,
and technology providers) know the scope and touchpoints
of the participating organizations and understand how each
of them contribute.

1 For further details: https://www.gsma.com/futurenetworks/gsma-open-gateway/

1
1. Introduction
GSMA Open Gateway allows operators to expose and monetize telco capabilities to third party
service providers in a programmatic manner through Application Programming Interfaces
(APIs). These APIs pave the way for transforming telco networks into programmable service
platforms, enabling the integration of the network with third-party applications, with frictionless
interactions between them.

This is a win-win situation for the stakeholders involved. For Communication Service providers
(CSPs), this represents a business opportunity to generate new revenue streams, and one of
the ways to better monetize investment in fiber, edge computing and 5G. For third parties, it
releases them from the constraints of traditional over-the-top, best-effort service delivery
approaches, tapping into new capabilities to provide enhanced user experiences and contribute
to the digital ecosystem with new services.

To ensure wide market adoption of NaaS, it is essential to push the development and
industrialization of third party-facing APIs, featuring these tenets:
• Scale. Third party-facing APIs need to be massively adopted by customers (both
application service providers and enterprises) by reaching into their ecosystems, where
they typically use a rich set of functionality, libraries, and tools.
• Global reach. The implementation of these user APIs by network operators provides third
parties with an easily deployable and consistent API developer and service experience in
a global footprint, facilitating the effortless portability of their applications (and therefore
easy service replicability) across different telco platforms. The fact that operators expose
APIs with the same capabilities and common data structures is key to onboarding and
integrating third parties, enabling an attractive economy of scale for them. This is achieved
through both the wide federation of operator capabilities and through existing and new
marketplaces.
• Simple. Potential third-party API consumers typically have no telco expertise and demand
APIs to be easy-to-use and require low coding effort. Therefore, operators need to offer
third party APIs that hide unnecessary telco complexity, avoiding, for example, low-level
network or IT system configuration parameters; and with semantics which focus on their
business and operational needs.
• Security & privacy: API consumers (application developer and aggregator) must trust
these APIs, both from a technical security (data storage, etc..) point of view as well as
regulation conformance (GDPR rules, consent management, Net neutrality), for the
benefit of the end users. To achieve these objectives, the APIs are to be secure by design
and use industry approved standards.
• Demand-driven, customer-oriented: developed as a result of the interaction and
collaboration with customer communities.

2
To make the above happen, standards is the only path. But we need to follow a modern
approach to standards development, where the APIs are designed, developed, and tested in
short cycles, following transparent and inclusive processes, as it occurs today in top-tier
developer communities. As shown in Figure 1, the recommendation is to move from classical
waterfall towards more agile, “code-first” and crowd-sourcing approaches, eventually
opening the source code so that industry community can adopt it, becoming a de-facto
standard solution.

Figure 1. Evolution from standard-first to code-first in the Telco industry.

This approach has been followed to develop most of the current software and cloud standards
and has also been proven in the Telco Industry by the TM Forum Open API program (for
Operation and Management APIs) which, through its Open Digital Architecture program, has
created more than 70 Apache 2.0 licensed Open APIs that are now widely adopted across the
telecoms IT market.

To comply with the recommendations noted above, several industry partners launched a new
initiative at MWCB22: CAMARA.

CAMARA is an open-source project launched at Linux Foundation with the collaboration of the
GSMA whose mission is to foster the definition, development, and validation of user NaaS
APIs. To promote the usage of these APIs, CAMARA has adopted an open-source
approach, based on using Apache 2.0 license for API definitions and reference
implementations. This IPR-free spirit reduces entry barriers for developers, encouraging more
use cases which ultimately accelerates industrialization. CAMARA counts on an open and ever-
growing community which gathers frontline industry stakeholders, including vendors, CSPs,
Hyperscalers, solution integrators, and customers.

3
2. GSMA Open Gateway NaaS system
architecture
At MWC Barcelona 23, The GSMA announced the GSMA Open Gateway initiative, in which
operators committed to launch universal NaaS API services in 2023. Operators participating in
the GSMA Open Gateway initiative have agreed that the interaction between CSPs and
customers (enterprise customers, application developers, application service providers) shall be
implemented using the APIs provided by the CAMARA project. The reason is that these APIs
are purposely built following the design tenets: scale (developer-oriented), global reach (they
are offered and federated by multiple operators) and simple (user-friendly semantics, easy to
use and operate).

Figure 2: Open Gateway NaaS Architecture and contributing stakeholders.

Figure 2 illustrates a simple graphical representation of an Open Gateway NaaS system

architecture. As shown, CAMARA APIs have implications in the third-party domain (how APIs
are made available for consumption) and CSP domain (how APIs are implemented based on
the operators’ internal capabilities).

To maximize availability and uptake, CAMARA APIs can be exposed to the actual tenant either
directly, through an aggregator (e.g., hyper-scaler or OTT) or through federation (in this case,
one or several operators act as aggregators).

4
Figure 3: Different relationship models for Open Gateway.

In the aggregator model (as already stated, applicable as well to an inter-operator federation),
the marketplace enables a single channel for tenant applications to gain access to capabilities
from multiple CSPs, without the need for the customer to set up a contractual relationship with
each of them. This marketplace may optionally enrich/combine CAMARA APIs with other
functionality, or abstracting it even more, to facilitate third party use and adoption. The
federation and aggregation models could allow fast reach to third parties, which include
application service providers and enterprise customers, as these are used to working with
existing marketplaces, either from third parties or from operators, that offer them a rich
development environment.

From a CSP domain standpoint, it is noted that third party-facing APIs are constructions that
result from the abstraction, aggregation, and enrichment of the operator’s internal APIs
(technology-specific APIs and OAM APIs). This abstraction is performed by the “transformation
function”. A summary of their scope is as follows:
• CAMARA APIs: these are the APIs exposed to customers, directly or through
aggregators. Depending on their semantic scope, CAMARA APIs can be clustered into
two groups:
- Service APIs, each providing a purpose-specific capability to third parties, e.g.,
Quality on Demand (QoD), Device Location, Edge Discovery and Selection, etc.
Service APIs are defined in separate CAMARA Subprojects. These APIs are
provided by operators directly or with the support of bodies like GSMA, 5GFF,
CableLabs, BridgeAlliance, TM Forum, etc, and are typically developed and
validated in collaboration with customers.
- Service Management APIs, allowing the application developer to run certain
management functions from within the application, like ordering the enablement of a
certain functionality for that application, monitoring, eligibility check or consumption

5
 check. These APIs constitute specific families and may have its own Subprojects.
The requirements for these APIs are intended to be defined in the CAMARA
Commonalities Workstream. These APIs may be contributed by CAMARA partners
from TM Forum and are typically designed and tested, partnering with application
developers. The design and development of Service Management APIs follow the
same guidelines and scale, reach and simplicity principles that are applied for the
Service APIs.

• Operate APIs: offering programmable access to Operation, Administration and

Management (OAM) capabilities to facilitate the integration of the Open Gateway NaaS
Platform with portals, marketplaces and other aggregator platforms.
- They provide all the transversal/non-service specific functionality that is required to
make a commercial product out of the Service APIs, making them operable and
monetizable. Examples of functions provided by the Operate APIs include ordering,
monitoring, trouble ticketing, accounting, billing, payment, etc, but also API
discovery, user registration and consent management, etc.
- They are made available by the operator’s IT stacks, which typically includes
operating and business support systems, and on-line charging systems, now
structured following a new digital architecture. TM Forum is the body leading the
definition and development of these APIs, with over 70 Open APIs available and
widely implemented today under the Apache 2.0 license. TM Forum is assisted by
3GPP SA5 for those cases where OAM APIs trigger FCAPS management
operations on 5G configurable resources (e.g., network functions, network slices).
- Because of the extensible design of TM Forum Open APIs, these Operate APIs
may make use of a TM Forum approach called Domain Context Specialization to
create targeted APIs focused on facilitating the integration with non-telco
environments (aggregators, third-party marketplaces and portals) by defining a
simplified, restricted API payload for specific scenarios, and taking into
consideration the third-party requirements and way of working.
- These APIs are typically contributed by GSMA Open Gateway partners from TM
Forum and are developed and validated in collaboration with aggregators and
marketplaces.

• Technology-specific APIs: operator internal APIs offering programmable access to

telco infrastructure and network, service and IT capabilities. They are made available by
operator’s underlying systems, including network systems (e.g., network
functions/elements from fiber access mobile access, transport, and core domains),
cloud systems (including edge platforms) and IT systems (e.g. ordering, billing). These
APIs are typically defined in standardization bodies (e.g., 3GPP, IETF, ETSI, TM
Forum) and cloud communities (CNCF) and are typically tied to the underlying
technology.

• Transformation Function: Translates CAMARA API calls into calls to technology

specific APIs, executing the workflows that implement this mapping. Apart from
decoupling customer-facing call flows from operator-facing processes, this component
shall be featured with scalability and observability capabilities. In this vein, a modern

6
 cloud-native architecture, based on microservices, is expected for the transformation
function. GSMA and TM Forum will both provide support for the implementation of the
transformation functions via non-prescriptive guidelines and recommendations. GSMA
OPAG (Operator Platform API Group) provides advice on the mapping of CAMARA
Service APIs to internal APIs, mainly technology-specific ones, while TM Forum plays
the same role for the CAMARA Service Management APIs, mapping mainly to internal
OAM APIs. These guidelines and recommendations are not a prerequisite to start the
development, testing and validation cycles in CAMARA, but intend to facilitate APIs to
achieve scale in terms of market reach once the API is consolidated in CAMARA.
• Operator Federation and Interconnection. Transparent federation between operators
through simple APIs will allow developers to deploy CAMARA API-based applications
across wide regions without concern of identifying the serving operator and without the
need for establishing technical or commercial relationship with multiple operators.

Finally, when coming down to production networks, a CSP shall offer a single entry-point for
third parties to gain quick and easy access to CAMARA APIs. This is captured in Figure 2 with
the definition of the Open Gateway NaaS platform. This platform provides all the features that
are needed to policy manage the interaction between the CSP and the third-party domains
(other operators and third party aggregators), including API publication & discovery, access
control (registration, authentication, authorization), auditing and user consent management,
among others.

7
3. Roles and contribution of the different
stakeholders
The Open Gateway NaaS system architecture reported in this white paper aims to shed light on
the intended demarcation points, so that different stakeholders (customers, operators, and
aggregators) know the scope and touchpoints of the participating organizations and understand
how each of them contribute. The bullets below summarize the key points.
• Third party-facing APIs: these are the APIs exposed to third parties, including
enterprise customers and aggregators. They are defined as abstraction, aggregation,
and enrichment of operator internal APIs (technology-specific APIs and OAM APIs).
This definition is a “top-down” journey that compares third party expectations against
CSP managed capabilities, looking for simplifications in the API data model and
structure. The result are APIs which are easy-to-consume (CAMARA “Service” APIs, the
“run-time” APIs) and easy-to-manage (via CAMARA “Service Management APIs” and
TM Forum “Operate APIs”). CAMARA is a contribution-driven open-source project that
hosts the development of the “Service” and “Service Management” APIs. Its APIs are
provided by different organizations, operators, and stakeholders, that commit to
maintain and evolve them.
• Operator internal APIs: Incumbent telco standard bodies and cloud communities lead
the specification of technology-specific APIs, whereas TM Forum Open API program
(backed by 3GPP SA5) accounts for the definition and development of OAM APIs.

Role of the different entities using the APIs

Figure 4. Usage of the different API types by each stakeholder.

8
Telcos expose through its service exposure platform CAMARA APIs to be sold by several
aggregators/channels, or by the telco itself using its portal. These CAMARA APIs are used by
the API Consumers in their applications (yellow lines in Figure 4). The Aggregators may
develop and expose additional “Enriched APIs” by adapting or combining CAMARA APIs (pink
line).

Telcos expose Operate APIs for integration with marketplaces and portals (own or from third
parties, green lines).

Role of the different organization in the API business and technical

development
Figure 5. Main organizations in the NaaS Ecosystem.

CAMARA, GSMA and TM Forum are the main organizations contributing to the NaaS API
development, as shown in Figure 2, whose role is specific and complementary:
• CAMARA represents the “exposure” doctrine, i.e., how capabilities are exposed for
external consumption via APIs. CAMARA provides the repositories for the different
families of Consumer-facing APIs. The definition, development and validation of Service
APIs is done in the different CAMARA Sub-Projects. The Service Management APIs are
worked out as specific API families in CAMARA. The CAMARA Commonalities working
group defines and documents the API design guidelines, which prescribe how APIs in
CAMARA must be written in terms of header, naming convention, error codes, etc. to
facilitate a uniform API language for the developers. Every Service API must comply
with these guidelines, which have been drafted following a developer-friendly approach.

9
• GSMA presents the “technical” and business principle, i.e., how CAMARA APIs are to
be supported by underlying telco capabilities and commercial arrangements. GSMA
conducts the technical work through GSMA OPAG (Operator Platform API Group), that
a) aligns the service API roadmap with the roadmap of network/cloud vendors, making
sure the corresponding technical capabilities are commercially available on time, b)
defines the technical elements of the federation, interconnection and roaming aspects
(such as identification, discovery & routing) that allow the NaaS APIs to become a
universal service and c) drafts non-prescriptive recommendations on mapping between
CAMARA APIs and technology-specific APIs (from bodies like 3GPP SA2/SA6, IETF,
CNCF, ETSI NFV…) including requesting further study in those bodies where additional
functionality is required to service proposed CAMARA APIs. This provides guidance to
less qualified operators and partners in their implementation of transformation functions
towards cloud/network resources, facilitates certain uniformity in the CAMARA API
behavior and performance and ensures the availability of the required telco capability to
support the development of the CAMARA APIs. The implementation of the APIs
remains the responsibility of each individual operator.
- Next to the work in OPAG, GSMA WAS Working Group defines the voluntary
agreement templates for federation between the operator networks and for
relationship with third parties (aggregators, marketplaces…) ensuring a consistent
commercial framework for exposing services.

• TM Forum presents the “operational” doctrine, i.e., how API services are to be operated
and managed and, in general, how the IT capabilities of the operator are used to deliver
the CAMARA API service. Representing the IT side of CSPs, that includes the OAM
functions for NaaS capabilities e.g. service provision, service activation etc., as per the
Telco industry Open Digital Architecture (ODA) patterns, TM Forum will have a key role
in the design and guide of the implementation of the OAM functionality, by a) providing a
modular design and a standard APIfication of the IT systems (ODA-based) utilizing their
widely used Apache 2.0 Open APIs, facilitating their integration with network & cloud
resources for FCAPS management purposes, and b) drafting non-prescriptive
guidelines on mapping between Operate APIs and internal OAM APIs (TMF Open APIs,
occasionally assisted by SA5 APIs). This may facilitate the implementation of the
transformation function towards ODA systems to less skilled operators and partners and
result in a more uniform way to operate API services across different platforms.

10
4. Conclusions
NaaS represents a paradigm shift with great impact on the industry landscape. Its development
requires a collaborative workspace that brings together incumbent telco standards bodies with
IT and cloud communities, industry associations and open-source projects. An effective
collaboration among organizations needs to be based on a clear demarcation on their scope
of work, avoiding that participating organizations run overlapping activities or duplicate
efforts; otherwise, NaaS may risk ending up with a fragmented ecosystem. CSPs and vendors
must support and adhere to the outcome produced by these bodies, and ensure their internal
teams are aligned.

The NaaS system architecture reported in this white paper aims to shed light on the intended
demarcation points, so that different stakeholders (customers, operators, and aggregators) can
know the scope and touchpoints of the participating organizations and understand how each of
them contribute.

11
5. Glossary and Acronyms
API: Application Programming Interface
CNCF: Cloud Native Computing Foundation
CSP: Communication Service Provider
ETSI: European Telecommunications Standards Institute (etsi.org)
FCAPS: Fault, Configuration, Accounting, Performance and Security
GSMA: Association representing the Mobile Industry (Groupe Speciale Mobile Association)
IETF: Internet Engineering Task Force (ietf.org)
IT: Information Technology
MWCB: Mobile World Congress Barcelona (GSMA’s annual event in Barcelona)
OAM: Operation, Administration and Management
ODA: (TM Forum) Open Digital Architecture
OPAG: (GSMA) Operator Platform API Group
NaaS: Network as a Service
NFV: Network Function Virtualization
3GPP: Third Generation Partnership Project, the Mobile Broadband Standards Partnership
Project (3gpp.org)
SA5: (3GPP) Service Architecture 5 Group, dedicated to Management, Orchestration and
Charging requirements, solutions and protocol specific definitions.
TMF: TM Forum (tmforum.org)
WAS: (GSMA) Wholesale Agreements and Solutions Group

12