Pathways towards Network-as-a-Service: the CAMARA project
(Invited Paper)
Jose Ordonez-Lucena
Telefonica I+D, CTIO Unit
Madrid, Spain
joseantonio.ordonezlucena@telefonica.com
ABSTRACT
Network as a Service (NaaS) allows operators to expose network
capabilities to 3rd parties in a programmatic manner (through APIs),
offering them consumer-like experience with choice, scalability,
visibility and control. After several years in scope of research, NaaS
is now gaining momentum in industry. Proof of this is that the
Linux Foundation and the GSMA have together unveiled a new
open source project called CAMARA, which has the mission to cre-
ate an open, global and accessible portfolio of APIs for developers
and customers, so that they can access operator capabilities and
consume them as per their service needs. This exposure allows for
service-tailored network programmability and frictionless network-
application integration, strengthening ties between operators and
3rd parties for service co-creation. In this article, we present the
"Quality on Demand API", the first NaaS API published and vali-
dated by CAMARA. The implementation and validation of this API
is showcased in a relevant business case for operators, based on
connecting end-users with a 3rd party video streaming server using
a 5G stand-alone network.
CCS CONCEPTS
• Networks → Programming interfaces.
KEYWORDS
Network as a Service, capability exposure, network-application
integration, Quality on Demand API, CAMARA, 5G
ACM Reference Format:
Jose Ordonez-Lucena and Felix Dsouza. 2022. Pathways towards Network-
as-a-Service: the CAMARA project (Invited Paper). In ACM SIGCOMM
2022 Workshop on Network-Application Integration (NAI ’22), August 22,
2022, Amsterdam, Netherlands. ACM, New York, NY, USA, 7 pages. https:
//doi.org/10.1145/3538401.3546825
1 INTRODUCTION
Network-as-a-Service (NaaS) represents a paradigm shift whereby
a network operator makes network capabilities available for ex-
ternal consumption, including monitoring and configuration re-
lated capabilities, through Application Programming Interfaces
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.
NAI ’22, August 22, 2022, Amsterdam, Netherlands
© 2022 Association for Computing Machinery.
ACM ISBN 978-1-4503-9395-9/22/08. . . $15.00
https://doi.org/10.1145/3538401.3546825
Felix Dsouza
Deustche Telekom AG, S&TI Unit
Bonn, Germany
felix.dsouza@telekom.de
(APIs). These APIs provide the operator with controllability and
auditability means when exposing capabilities to applications from
3rd parties, typically B2B and B2B2C customers such as hyper-
scalers, developers and industry specific enterprise customers (i.e.,
the verticals). Controllability means that the provider can regulate
the particular set of resources each application is allowed to ac-
cess and under which conditions, leveraging Role Based Access
Control (RBAC). Auditability means that every interaction between
operator and 3rd party systems needs to be logged with accurate
timestamps (for traceability) and support non-repudiation (for SLA
verification).
NaaS paves the way for transforming telco networks into pro-
grammable service platforms, enabling the integration of the net-
work with 3rd party applications, with direct and open interactions
between them. This is a win-win situation for the two stakeholders
involved. For operators, this represents a business opportunity to
generate new revenue streams, and one of the ways to monetize in-
vestment made in fiber, edge computing and 5G over the past years
(CAPEX amortization). For 3rd parties, it allows them to flee from
traditional over-the-top, best-effort service delivery approaches,
tapping now into offered capabilities to provide enhanced user
experiences and contribute to digital ecosystem with new services.
To ensure wide market adoption of NaaS (and empower the
ecosystem around it), it is essential to push the development and
industrialization of APIs featuring these tenets:
• Open. NaaS APIs need to be designed, developed and tested
in short cycles, following transparent processes, as occurs
today in top-tier developer communities. The recommenda-
tion is to move from the waterfall approaches existing in
traditional telco standards (e.g. 3GPP or ETSI) towards more
agile, "code-first" approaches, eventually opening the source
code so that industry community can adopt it, becoming a
de-facto standard solution.
• Global reach. The adoption of NaaS APIs by network opera-
tors provide 3rd parties with uniform and consistent 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 com-
mon data structure is key to onboarding 3rd parties, allowing
for an attractive economy of scale for them.
• User-friendly. Potential consumers of NaaS APIs will be
3rd parties with no telco background. Therefore, it is needed
to design these APIs such that i) they hide telco complexity,
avoiding low-level network configuration parameters; and ii)
their semantics focus on the business and operational needs
of 3rd parties.
NAI ’22, August 22, 2022, Amsterdam, Netherlands J. Ordonez-Lucena and F. Dsouza

In pursuit of this goal, industry has launched a new initiative:
CAMARA. Officially announced this year at the Mobile World Con-
gress, CAMARA is an open source community scoping NaaS APIs.
The objective of this paper is to let the reader know how CAMARA
is contributing to NaaS success, and present the results achieved so
far. The structure of this paper is as follows. Section 2 presents the
objectives and ways of working in CAMARA, all framed within a
reference system architecture. Implementation details of this archi-
tecture are captured in Section 3. Section 4 details the first NaaS
API available in CAMARA, which is "Quality on Demand (QoD)"
API, validating its usage in a production-ready video streaming use
case. Finally, Section 5 provides concluding remarks.
2 CAMARA PROJECT
CAMARA is a joint initiative between the GSMA (reference telco
association) and the Linux Foundation (reference cloud association).
Its mission is to foster the definition, development and validation of
APIs enabling NaaS, promoting their usage and de-facto adoption
by using an Apache 2.0 license. In this endeavour, CAMARA counts
on an open and ever-growing community which gathers frontline
industry stakeholders, including vendors, tier-1 operators, hyper-
scalers and solution integrators, among others. The up-to-date list
of companies participating in CAMARA can be found in [6].
External application
(CAMARA API invoker)
Service APIs NBI CAMARA
(CAMARA APIs) solution suite
API GW
Transformation Function
Network APIs SBI
(3GPP, ETSI, E/WBI
TMF,.. APIs)
NW Cloud OAM
Telco X
• Transformation function. It keeps the information on
correspondences between service APIs and network APIs,
and executes workflows to enforce these mappings. This
component can be deployed as a microservice provisioned
with a worflow engine.
• API Gateway. It provides all the capabilities that are needed
to policy the interaction between the operator and the exter-
nal applications, in relation to service API invocation. These
capabilities include service API publication & discovery, ac-
cess control (authentication & authorization of applications),
auditing, accounting and logging.
As seen, the focus of CAMARA work is on service APIs, and
how they can build atop existing network APIs with the help of
transformation function and API Gateway.
3 REFERENCE SOLUTION
As seen in Figure 1, the architectural components building up the
CAMARA solution suite are two: the transformation function and
the API Gateway. The first component can be implemented using
a workflow engine, while for the API Gateway the only mandate
is that it needs to support OAuth2.0 with client credentials grant
[5]. There exists a wide variety of API Gateway solutions, both
open-source and commercial, which are OAuth2.0 compliant. How-
ever, for the sake of consistency when offering service APIs, it is
desirable to agree on a common, standards-based solution for this
gateway. In this regard, CAMARA proposes to use 3GPP Common
API Framework (CAPIF) [1]. The reason for this proposal is twofold.
On the one hand, CAPIF is a normative solution with wide accep-
Exposure Gateway tance at industry. The other main advantage of CAPIF is that though
Transformation Function specified by the 3GPP, it is not tied to 3GPP APIs; indeed, CAPIF
can be used as an API Gateway for any API, regardless of their
semantics. Therefore, it is an ideal candidate to publish CAMARA
NW Cloud OAM APIs, and policy their exposure to the 3rd party applications.
Telco Y

NOTE: E/WBI stands for East/Westbound Interface, and calls for federation capabilities across telco External application
operators. This is transparent to 3rd parties, and therefore out of scope of CAMARA project CAPIF-1e (CAMARA API invoker) CAPIF-2e

Service
Service
Service
Figure 1: CAMARA architectural framework. CAPIF APIs
APIs
APIs
APIs
API discovery API publishing CAPIF-3
API Exposure Function (AEF)

solution suite
CAPIF-4
Figure 1 depicts the reference architectural framework of CA-

CAMARA
API Publishing Function (APF)
CAPIF-5 API Management Function
MARA. As seen, it includes the following components: CAPIF Core Function (CCF) (AMF)

• Network APIs. These are the APIs which are implemented API provider domain functions
Service APIs
in telco assets, including network resources (core, access,
API registry Access Control Transformation Function
transport functions), cloud resources (virtualized and cloud-
native workload hosting infrastructures) and IT resources Network APIs
API Gateway == {CCF + API SA2, NFV, SA5,

(OSS and orchestration tools). These APIs are typically de- provider domain functions}
IETF..
APIs APIs
CNCF,…
APIs
TMF..

fined in standard bodies or industry fora, and quiet tied to NW Cloud

Telco X functions
OAM

the underlying technology. Examples of these APIs include

the ones defined by 3GPP, ETSI or TMForum, among others.
• Service APIs. These are the NaaS APIs, the ones to be made
available for consumption to 3rd party applications, a.k.a. ex-
ternal applications. They are designed according to the princi-
ples listed in Section 1: open (API source code is Apache 2.0),
global reach (they are offered by different telco operators)
and user-friendly (service APIs result from the abstraction
of network API semantics, hiding telco complexity).
Figure 2: CAPIF as reference API GW for CAMARA
CAPIF framework consists of four main modules: (i) CAPIF
Core Function (CCF), responsible for applying access control to
the external applications, while keeping track of their service API
invocations; ii) API Exposure Function (AEF), which provides
the endpoints of service APIs, authorizes the API invocations, and
Pathways towards Network-as-a-Service: the CAMARA project (Invited Paper)
Figure 3: Generic workflow for Service API invocation.
records them in log files; iii) API Publishing Function (APF), re-
sponsible for the publication of service APIs to CCF, to make them
discoverable to the applications; and iv) API Management Func-
tion (AMF), auditing service API invocation logs and managing
the on-/off-boarding of applications into operator’s system.
Figure 2 illustrates the use of CAPIF modules in CAMARA so-
lution suite. If we map these modules to API Gateway internals,
one can notice that CCF plays the role of OAuth2.0 Authorization
Server (authenticates the API invoker and grants access token)
while the AEF behaves as resource server (validates access token
and authorizes API invocation).
Figure 3 shows the workflow sequence that govern NaaS in CA-
MARA. As seen, upon receiving the OAuth2.0 access token from the
CCF, the application is allowed to invoke service APIs. Each service
API invocation is captured by the AEF and forwarded to the Trans-
formation Function, which maps it one or more network API calls.
After receiving the responses from the function(s) acting as net-
work API producer(s), the Transformation Function de-map them
into the service API response, which is sent back to the application.
NAI ’22, August 22, 2022, Amsterdam, Netherlands
4 QUALITY ON DEMAND API
CAMARA has an ever-evolving backlog with different service APIs.
These APIs are prioritized based on i) technology maturity / stan-
dards readiness, ii) availability of commercial products, and iii) the
demand from 3rd parties. According to these criteria, the first API
developed in CAMARA has been "Quality on Demand (QoD) API".
This API provides the invoker with the ability to set certain QoS
parameters for a session between an UE and an application server
(AS), receiving configuration from the network on whether they
can be granted or not. The QoS parameters that the API invoker
can configure/modify for the mobile connection are two:
• Bandwidth, with the ability of the consumer to choose among
different flavors: large ("throughput_L"), medium ("throug
hput_M") and small ("throughput_S").
• Latency, with the ability of the consumer to activate sta-
ble latency behavior for the session, to minimize jitter and
therefore aspire having quasi-deterministic dataflows.
In this section, we will show the usage of QoD API on a video
streaming use case . It is worth noting that the first version of the
QoD API only allows modifying either bandwidth or latency, but
not both simultaneously. For further details, see Swagger code [4].
NAI ’22, August 22, 2022, Amsterdam, Netherlands J. Ordonez-Lucena and F. Dsouza

BSS
QoD API
OSS (3GPP mgmt. system + NFV stack)
CAMARA solution (Service API)
Streaming platform
N2
AMF UDM AUSF NEF suite
(API GW + Transformation
application
CU-UP CU-CP

N1 AsSessionWithQoS API (CAMARA API invoker)

N4 Function)
SMF NSSF PCF (3GPP network API)
RU+DU

UEs

UE<-> AS traffic flows

Streaming
UPF
server (AS)
TN TN TN
@Cell site @Edge node @Regional DC
@Internet

Tag Flow ID 5QI ARP Resource Type Maximum Flow Bit Rate (MFBR)

best-effort 2 9 90 Non-GBR n/a

THROUGHPUT_L 3 6 80 GBR 100 Mbps
THROUGHPUT_M 3 6 80 GBR 50 Mbps
THROUGHPUT_S 3 6 80 GBR 20 Mbps
stable-latency 4 7 70 GBR 2 Mbps

Figure 4: Application scenario for QoD API usage.

4.1 Scenario description
Figure 4 pictures the application scenario exemplified for QoD API
usage. In this scenario, the 3rd party is a company that provides
video streaming service to their subscribers. To provision and op-
erate this service, the 3rd party has a streaming platform with
different built-in applications.
At the infrastructure level, one can notice that the service deliv-
ery consists is based on connecting the individual subscribers (i.e.,
UEs) with the 3rd party owned streaming server (i.e., AS) through
a 5G standa-alone (5GSA) network. This network consists of i) one
gNB, which providing mass-market 5GNR coverage to UEs; and ii)
a cloud-native 5G Core (5GC), built-in with 3GPP Rel-15 features.
The 5GC solution follows a service-based architecture, with the
definition of a disaggregated and modular, containerized control
plane which is fully decoupled from the User Plane Function (UPF).
The operator takes advantage of this control user plane separation
(CUPS) principle to deploy UPF closer to UEs, in an edge node.
The traffic flows steered on a UE↔AS session can be set to
one of these tags: "best-effort" (default QoS), "throughput_L",
"throughput_M" or "throughput_S" (enhanced QoS, by increas-
ing throughput), and "stable-latency" (enhanced QoS, by mini-
mizing jitter). The table depicted in the figure provides a full char-
acterization of these tags, associating each with a combination of
3GPP network parameters, including 5G Quality Indicator (5QI), Al-
location and Retention Priority (ARP), Resource Type (either Guar-
anteed Bit Rate [GBR] or Non-Guaranteed Bit Rate [Non-GBR]) and
Maximum Flow Bit Rate (MFBR). For further details on the usage of
these parameters, and their impact on gNB and 5GC, see [2]. Based
on this rationale, it is clear that associating the UE↔AS session to a
specific tag means setting the 3GPP parameters with corresponding
values, so 5G network can be configured accordingly. This configu-
ration can be injected via the Network Exposure Function (NEF),
by passing these parameter values through the AsSessionWithQoS
API. The API structure, including supported REST operations and
input attributes, is pictured in the top side of Figure 4.
The 3rd party wants to ensure that their subscribers always
have optimal user experience, regardless of network conditions. To
that end, the streaming platform has an application called "traffic
management". In congestion scenarios, this application is provi-
sioned with the ability to modify the tag associated to individual
UE↔AS session, in order to avoid these UEs to suffer from perfor-
mance degradation. The question that arises is now as follows: how
this streaming platform application can modify the QoS for a given
UE↔AS session, on demand?.According to the above description,
the application could directly invoke AsSessionWithQoS API, thus
becoming NEF consumer. However, this option is not realistic, as it
would require the application to pass in the API call a number of
3GPP network parameters; in fact, it is difficult to assume that the
application has the know-how to specify these low-level configu-
ration parameters. To bridge this gap, CAMARA proposes a much
more user-friendly API, which is the QoD API. By looking at this API
structure, one can notice that the application only needs to specify
Pathways towards Network-as-a-Service: the CAMARA project (Invited Paper)
Figure 5: QoD API activation: sequence diagram. Green and yellow color represent operator and 3rd party administrative
domains, respectively.
the sockets of endpoints (the UE and the AS), the transport protocol
used for in-session traffic (TCP or UDP), the tag describing session
performance ("best-effort", "throughput_L", "throughput_M",
"throughput_S" or "stable-latency") and an URL (for the ap-
plication to receive callbacks upon subscribed notifications).
Based on the above rationale, the streaming platform application
becomes the invoker of QoD API. Upon receiving the API call from
the application, CAMARA solution suite transforms it into the
corresponding AsSessionWithQoS API call. This QoD-to-NEF API
transformation means translating the tag into the corresponding
3GPP network parameter values, according to the mapping rules
captured in the table from Figure 4.
4.2 Testing campaign
To validate the QoD API usage, we configure the network depicted
in Figure 4 as follows: single-cell gNB serving 6 UEs, each connected
NAI ’22, August 22, 2022, Amsterdam, Netherlands
to the data network through a Rel-15 5GSA network. The system
parameter settings are described below:
• Cell capacity: {BW=90 MHz; DL/UL=800/90 Mbps}.
• UE1 and UE2 act as traffic generators, assigned with {5QI=9;
ARP=88; Resource Type=GBR}. These UEs will allow stress-
ing the system, producing data volumes that represent the
95-98% of cell capacity.
• UE3 and UE4 represent users who access data network tom
consume Internet services. They are not streaming service
subscribers, and are assigned best-effort tag by default.
• UE5 and UE6 represent users who access data network to
consume cloud gaming service. They are streaming service
subscribers, and are assigned best-effort tag by default.
The aim of this test scenario is to demonstrate the QoD API
usage on a particular congestion scenario, by setting the tag for
NAI ’22, August 22, 2022, Amsterdam, Netherlands J. Ordonez-Lucena and F. Dsouza

UE5 and UE6 sessions from best-effort to THROUGHPUT_S. The before QoD API activation -> 5QI = 9 (priority level 90)
user story for this test scenario is captured in Table 1.

Table 1: Test scenario description.

Step Description
UE5 and UE6 start sessions towards the AS, each profiled with best-effort tag.
1
Status: No service degradation.
UE3 and UE4 are introduced, setting up sessions with best-effort tags.
2 Status: UE5 and UE6 still not affected (resource shared fairly as all users
have the same priority)
UE1 and UE2 are introduced.
3 Status: UE3-UE6 are severely affected, as UE1 and UE2 consume the whole
cell capacity (congestion situation).
The streaming platform application activates QoD API for UE5 and UE6,
setting their individual session tags to THROUGHPUT_S.
4
Status: UE5 and UE6 get the required capacity and service guaranteed. UE3
and UE4 continue to suffer, because of congestion.

4.3 Evaluation results

The invocation of QoD API over UE5 and UE6 triggers a set of
procedures and request-response message in the operator’s system.
For illustrative purposes, Figure 5 depicts a simplified version of After QoD API activation: 5QI = 6 (priority level 80)
these workflows, considering QoD API is activated for a given UE.
First, the external application shall get the sockets of the stream-
ing server (AS) and the UE (steps 1-2). With this information, the
application can then invoke QoD API (step 3), sending a "POST
/session". This request includes a body request with parameters
specified with {key-value} pairs, which are filled out as shown in
the bottom-right corner of Figure 4.
Upon capturing the QoD API call, CAMARA solution suite pro-
ceeds with the steps that were shown in Figure 4, consisting in
application authentication and access token validation, followed
by QoD API↔AsSessionWithQoS API mapping. The result of this
mapping is sent to the NEF (step 4), which authenticates the CA-
MARA’s Transformation Function as trusted NEF consumer.
With the information received in the AsSessionWithQoS API
call, the NEF requests the PCF to update the UE↔AS session policies
(steps 5-6), and forwards them to the SMF for their enforcement
(steps 8-9). The SMF first notifies the UPF about the new user plane
configuration parameter values (e.g. 5QI=9; MFBR=20), sending
them over the N4 interface, using PFCP protocol [3]. Next, the SMF
sends to AMF updated values for QoS Profile and QoS Rules
Figure 6: UPF traces, before and after API activation.
constructions (steps 12–14). These two constructions allows AMF
to update RAN and UE configuration files accordingly (steps 15–
18), replacing old 5QI/ARP/Resource Type/MFBR values with the
new ones: 5QI=9; ARP=80; Resource Type=GBR; MFBR=20. For
further details on how this update is done, see [2] [7] [8]. After one goals, all framed within a reference system architecture responsible
further interaction between the UE and the RAN (steps 19-20), the for abstracting (low-level) network APIs into (user-friendly) ser-
UE↔AS session session is successfully updated. Notifications are vice APIs. We have also presented the architectural internals, and
sent back until reaching the application, who receives a 200 OK provide reference implementations for them. Finally, we have pre-
(step 24) as a response to the original request (step 3). sented the first CAMARA API, i.e. QoD API. In particular, we have
To showcase the actual modification of the session, UPF traces detailed API code and showcased its usage in a production-ready
have been captured with Wireshark, before and after the API invo- scenario, where UEs are connected to a 3rd party streaming server
cation. As pictured in Figure 6, the focus is on 5QI value change. through a 5GSA network.

5 CONCLUSIONS ACKNOWLEDGMENTS
In this paper, we have presented the CAMARA as the top-tier in- This work is partially supported by the H2020 European Project
dustry initiative regarding NaaS. We have surveyed the CAMARA Hexa-X (grant agreement No. 101015956).
Pathways towards Network-as-a-Service: the CAMARA project (Invited Paper)
REFERENCES
[1] 3GPP TS 23.222. 2022. Common API Framework for 3GPP Northbound APIs,
v17.6.0 (Release 17).
[2] 3GPP TS 23.502. 2022. 5G; Procedures for the 5G System, v17.5.0 (Release 17).
[3] 3GPP TS 29.244. 2022. LTE; 5G; Interface between the Control Plane and the User
Plane nodes, v17.5.0 (Release 17).
[4] CAMARA. 2021. QoD API Swagger. Retrieved June 30, 2022 from https://github.
com/camaraproject/QualityOnDemand/tree/main/code/API_definitions
[5] CAMARA. 2022. Authentication and Authorization Concept for Service APIs.
Retrieved June 30, 2022 from https://github.com/camaraproject/WorkingGroups/
NAI ’22, August 22, 2022, Amsterdam, Netherlands
blob/main/Commonalities/documentation/Working/CAMARA-AuthN-AuthZ-
Concept.md
[6] CAMARA. 2022. Consortium members. Retrieved June 30, 2022 from https:
//github.com/camaraproject/Governance/blob/main/PARTICIPANTS.MD
[7] D. Cheung. 2021. 5G Core Part 4 —- Dedicated QoS Flow and PDU Session Modifi-
cation. Retrieved June 30, 2022 from https://derekcheung.medium.com/5g-core-
part-4-dedicated-qos-flow-and-pdu-session-modification-49c3db44417f
[8] 5G Fundamental. 2021. 5G NR: Session Rules. Retrieved June 30, 2022 from
https://www.5gfundamental.com/2021/03/5g-nr-session-rules.html