Network as a Service

1. Author: Joanne Taaffe, Editor in Chief, Inform
Editor: Ian Kemp, Managing Editor Sponsored by:
labs knowledge
service lines:
the role of
network-as-a-service
in future connectivity

2. 2
contents
03 setting the scene
04 chapter 1:
what is network-as-a-service?
08 chapter 2:
what CSPs are doing – early NaaS implementations
10 chapter 3:
orchestrating change – towards the complete service lifecycle
13 chapter 4:
standardizing NaaS delivery
16 additional feature by Oracle:
NaaS drives operations simplicity and new revenue opportunity
22 meet the Research and Media team
2

3. 3
Network-as-a-service (NaaS) is a concept that has evolved to mean different things to
different people. Its deployment by communications service providers (CSPs) remains
relatively limited, despite ongoing implementation by some of the world’s largest
telcos (more on this in chapter 2). Yet it is a fundamental building block towards future
connectivity and delivering next-generation services to customers, and TM Forum has
a clear definition and approach to implementation.
For many CSPs, NaaS is also a critical foundation for telco-to-techco transformation and
becoming platform service providers. And it is widely seen as a digital enabler to deliver
on-demand network services to enterprises and developer ecosystems.
As we explore in this e-book, there are sound business reasons for telcos to undertake the
operational and technological changes necessary for NaaS. The development of NaaS fits
into telcos’ wider ongoing network automation and service exposure work and the shift of
some of their network functions and workloads to the cloud. And, crucially, NaaS plays a
foundational role in many telcos’ visions of future enterprise and partner services.
As business applications and network functions move from operating within physical, on-
premises enterprise networks towards running in decentralized, cloud-native environments,
companies require a more flexible and seamless way in which services are delivered. CSPs
hope to use a combination of networking and software expertise to give them an edge in
future connectivity markets, with NaaS as a foundation of their overall end-to-end delivery
architecture.
In this e-book, we outline TM Forum members’ role in driving and standardizing NaaS
and its role in the future of connectivity that embraces zero-touch partnering (ZTP) and
intent-driven, automated networking: connectivity-as-a-service (CaaS). We also make
clear TM Forum’s positioning on NaaS in the wider context of delivering future connectivity
and CaaS.
setting the scene
There are sound business
reasons for telcos to
undertake the operational
and technological changes
necessary for NaaS

4. 4
CHAPTER 1
what is network-as-a-service?
TM Forum describes network-as-a-service (NaaS) as: “[A] set of technical and
operational practices that decouples the product lifecycle from the network
technologies by standardizing the exposure and management of network
capabilities ‘as-a-service’, in a consistent service consumption pattern, abstracting
all the network complexities and using a common suite of Open APIs.”
In other words, NaaS is a framework for building network services that decouples the
customer’s service requirements – along with the operational and business support
systems (OSS/BSS) used to create and manage their service – from the network
resources needed to fulfil those requirements. The decoupling happens through an
abstraction layer that hides networking details and complexity, which is central to
simplifying the whole services lifecycle.
With a NaaS model, the IT side does not need to determine – or even know – what
is happening in the network. Instead, networks and IT rely on the same set of open
APIs to establish a shared understanding of network services. This frees networking
domains to determine the most flexible way to create, assure and manage the
exposure of a network function, such as firewall-as-a-service, based on what will best
serve customers’ needs. In addition, production (or networking) domains will be able
to expose services for reuse in a range of different products and services.
“It’s a virtual abstraction layer of the network, enabling ease of exposure of capabilities
from the network upwards into the architecture via standardized and Open APIs.
This simplifies the ability to use these capabilities more dynamically and efficiently
in ever increasingly interesting ways,” says Joann O’Brien, Vice President, 5G Digital
Ecosystems, TM Forum.
Section 4 details recent
standards developments
around NaaS including the
GSMA Open Gateway initiative,
which is being supported by
TM Forum and is part of the
CAMARA open-source project.

5. 5
5
O’Brien adds: “The two key principles of NaaS are abstraction and reuse.” Putting in
place an abstraction layer and decoupling what is going on in the network from the
OSS/BSS is important, because it leaves the network and IT layers to perform their
own roles in service delivery more independently, efficiently and automatically.
Just how NaaS impacts telcos’ service lifecycle to simplify service creation and
delivery can be seen in the diagram.
TM Forum, 2021
CSP service delivery simplifi
cation from a layered NaaS architecture
Customer Retail Enterprise Wholesale
Retail Customers Enterprise Customers Wholesale Customers
Sales &
services
Third pares/
partners
Product
master data
Sales catalog
Offer
management
Open APIs exposed via API gateway or hub
IT systems
services
Federated
resource data
Federated
service data
Order
management
Product
catalog
Integraon via Open APIs
NaaS abstracon layer and Open API component suite
Facilies
Facilies
Exposed
service
catalog
NaaS Gateway
VPN, Ethernet, WAN, Opcal
Data, APN, RAN Slice
Voice SMS, MMS
IaaS, IoT App, Mobile App
IoT Slice
Network
service
operaonal
domains
Mobile
Access
Calling
(voice and video)
Third-party
ecosystem services
(e.g. compute services)
Unified
Comms
IP Domain
Managed
Security
Transport
Media
Content
Rang
...
...
Infrastructure Infrastructure
Common packet
networking
Transmission
Common
fiber
Common
NFVi
Network domains to expose and manage the end-to-end lifecycle of services
through Open APIs = agility
Too much knowledge down to the resource level =
complexity long me to market
Exposed
service
catalog
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
Network
Elements
System n
System 3
System 2
System 1
System n
System C System D
System B
System A
EMS 1 EMS 2 EMS n
Offer management Offer management Offer management
Network
Infrastructure
Element
managers
Network
systems
IT systems
Sales and
services
CSP service delivery simplification from a layered NaaS architechture

6. 6
Partnering imperative
NaaS can be combined with zero-touch partnering (ZTP) to give CSPs the fully
scalable capabilities they need to partner to generate new revenue streams. By using
ZTP, telcos are able to expose their reusable NaaS services as products to trusted
partners and build out collaborations to deliver B2B or B2B2X services.
Based on Open APIs, the ZTP lifecycle covers partner onboarding – which includes
negotiating operating and financial models with partners – partner account
management,partnerproductoffermanagement,negotiatingfinancialagreementsfor
the partners’ product offers – based on the operating and financial models negotiated
during the onboarding process – managing the selling and orchestration rules, billing
and settlement for the partner, and disputes and reconciliation management, for both
B2B and B2B2X.
The diagram below shows the ZTP lifecycle, capturing business and technical
capabilities.
By combining NaaS, ZTP and customer intent, telcos are able to deliver connectivity-
as-a-service (CaaS), addressing enterprise and consumer demand for seamless,
scalable connectivity. CaaS takes away the need for customers to have any knowledge
of which networks underlie dynamic service delivery and instead make connectivity
as easy to consume as any other utility (see box on next page).
In the next chapter we look at some early NaaS implementations by CSPs.
partner
discovery
partner
onboarding
product
onboarding
partner
management
partner
termination

7. 7
Making connectivity-as-a-service as seamless as everyday utilities
Connectivity-as-a-service (CaaS) is the intent-driven, dynamic realization of connectivity solutions based
on customer expectations. CaaS does not have a hard dependency on zero-touch-partnering (ZTP), as
a CSP will often resolve the connectivity requirements through its own services. However, leveraging
partners’ services can close any technology gaps or geographical reach and coverage in the CSP’s own
offerings.
CaaS needs to work similarly to how a utility is consumed today, with no knowledge of the underlying
technology needed from a customer perspective. To realize this, the following characteristics and
relationships are required:
Intent-driven – Customer expectations are captured and delivered by the customer communications
management function to the production function and can be human, machine, explicit or implicit.
Dynamic discovery of customer facing services – CaaS is a framework to enable composite
services from multiple customer-facing services, which can be discovered dynamically, including
from partners.
Intelligent selection – The intelligent selection of the appropriate customer facing service for a given
service from the composite customer-facing service based on the customer intent.
An “intent” is defined as a set of goals – from a human or from software – that a system should meet, and
outcomes that the system needs to deliver. Those goals and outcomes are defined in a declarative manner
without specifying how to achieve or implement them, where a system can be a network, customer
support or other IT application.
Once detected and classified, an intent needs to be formalized and modeled so that it can be managed
through an API from an “intent owner”, and the corresponding “intent handler” is responsible for fulfilling
the Intent, resolving conflicts, reporting and so on.
In simple terms, NaaS + (optionally ZTP) + Intent = CaaS.

8. 8
CHAPTER 2
what CSPs are doing – early
NaaS implementations
As we detailed in our report, NaaS: where it is and where it’s going, Orange
Business Services is one of several telcos that have implemented TM Forum’s
NaaS framework. Other telcos that have launched NaaS include Telus, Verizon and
Vodafone, with an initial focus on service offerings such SD-WAN services with
security and cloud add-ons.
Telstra launched a NaaS platform for enterprise customers using TM Forum’s Open Digital
Architecture and Open APIs as long ago as 2018. The operator was instrumental in the
development of TM Forum’s Network as a Service (NaaS) Requirements released in
October 2018 and the NaaS Open API Component Suite released in 2019.
Building on these early implementations by Orange and Telstra, it’s the abstraction of
the network and the use of common open APIs that is the real game-changer for CSPs
in developer ecosystems in the future. Having the ability to expose network capabilities,
which enterprise and wholesale customers can access via an API marketplace, can open
up new ways for telcos to monetize network-based services.
Indeed, future 5G services, and in particular network slicing, will rely on the work that has
gone into NaaS, ZTP and intent, combining with software-defined transport networks to
allow CSPs to expose APIs to partners and dynamically provide new on-demand services.
Telco deployments of 5G standalone (5G SA) networks, which support 5G network slicing,
have been patchy so far, but the numbers are creeping up, as are service trials. According
to Counterpoint research, 42 operators had deployed 5G SA commercially worldwide by
the end of 2022.
And that could lead to greater service diversification and revenue streams for operators.
Canadian operator Telus believes its expanded NaaS-based offerings, including rural and
smart city security, retail analytics and network slicing services, will enable it to unlock in
the order of C$1 billion (about US$800 million) in new revenues over the next five years.
It’s the abstraction of the
network and the use of
common Open APIs that is
the real game-changer
for CSPs

9. 9
Work on NaaS has helped Verizon to create an “access-agnostic” network platform based
on common orchestration and an API layer. The platform supports SDN-based services as
well as some edge-based services such as VNS Application Edge, which manages edge
compute, storage and networking resources and provides customers with orchestration
to centrally manage their applications). Its typical enterprise service configurations include
managed SD-WAN, business communications (VoIP) and security services.
More recently, Orange, Telefónica, and Vodafone have exposed a quality of service on
demand (QoD) API to application developers as part of the GSMA Open Gateway initiative.
They say the exposure of advanced 5G functionality through common APIs will enable
operators to better monetize 5G and quickly deliver new services.
George Glass, CTO, TM Forum, stresses the importance of “the industry co-ordinating and
aligning on a clear target architecture and set of standards spanning network, service and
operations and management APIs”. He adds: “We are working closely with our members
and directly as part of CAMARA to prevent duplication of standards and ensure the TM
Forum and CAMARA work evolves in harmony.”
Read our report Naas: where it is and where it’s going, for more information on CSPs’ NaaS
strategies and deployments.
October 2021 | www.tmforum.org
Author: Dana A. Cooperson, Contributing Analyst
Editor: Dawn Bushaus, Managing Editor

10. 10
CHAPTER 3
orchestrating change – towards
the complete service lifecycle
NaaS, and the virtualization that underpins it, represent a sea-change in how telcos have traditionally operated.
As we defined NaaS in chapter 1, it depends on a clear separation of the IT functions that support service
commercialization from the production capabilities of the service, which run independently and are accessed
by standardized APIs. But it also involves moving from a siloed vision of service delivery towards assuring an
end-to-end service lifecycle, based on ZTP and intent.
As our recent TM Forum whitepaper on NaaS explains: “Today a service is managed by organization silos…and
there is not an end-to-end owner for the complete service lifecycle. NaaS is about providing best practices for the
production domain ownership of end-to-end responsibility of the complete service lifecycle.”
But getting there – and beyond to CaaS – is a complex process. Some of the steps telcos need to take to build on
NaaS to truly facilitate CaaS include:
decoupling the network from operational and business support systems (OSS/BSS)
moving to an intent-based customer sales and ordering process
ensuringaccesstodatarequiredforautonomousservicecreation,whichincludesinventory,topology,performance
and policy data
developing cloud-native IT and networks that allow service componentization and composition
enabling customer-centric processes with built-in security and proactive fault response
assuring, charging and billing for on-demand services within a complex partner ecosystem
making it possible for external application developers to create products and services for an industry-standard
NaaS, rather than working with each CSP’s internal complexity.

11. 11
Telcos are already taking several of these steps as part of a broader strategic move to
become platform-based techcos. Nonetheless, as they look towards NaaS and CaaS they
will have to consider from the outset their approach to fundamental building blocks for
new network-based services, namely: service design, orchestration, assurance, charging
and billing, closed loop automation, and service assurance orchestration. A key concern
for enterprise customers is service performance and service level assurance (SLA). They
increasingly expect end-to-end assurance of on-demand services that meet their specific
requirements, as Basma Driss, Senior Partner Manager, Cloud Automation, Deutsche
Telekom,explainedinaninterviewwithTMForum.Andasshedetails,thereisanopportunity
for telcos to give enterprises access to information about network quality.
“Our customers are expecting…more individualized services [and] an experience like a
hyperscaler…where with one click you get your service and…you can also see what you
are getting, what you are paying for and [the]…quality,” said Driss. “We need to have
programming solutions which are secure, and which are fulfilling the SLAs, as that is what
our enterprise customers are expecting. This…becomes even more important when we are
introducing network slicing…or 5G campus networks. Assurance is fundamental and…it
should be by design… [and available] from day one to deliver quality to the customer…and
give them also a dashboard where they can monitor that.”
CSPs could, for example, expose service performance directly to enterprise customers and
provideinformationonfaults,aswellasrecommendationsonhowtheycanmakebetteruse
of the network. However, delivering on SLAs in increasingly complex, automated partner
ecosystems will require multi-layer, end-to-end orchestration to unify all the domains and
orchestrate based on service intent.
Watch our video to find out more
Delivering on SLAs in increasingly
complex, automated partner
ecosystems will require multi-
layer, end-to-end orchestration
Telstra has adopted a composite orchestration architecture for its
NaaS offering.
“Digital leadership enabled by an API-first architecture and the
automation of network services will transform how telcos build,
activate and lifecycle customer and product experiences,” says Mark
Sanders, Chief Architect at Telstra. “In a multi-domain, as-a-service
architecture, being able to compose using composite orchestration
will enable rapid assembly of cross-domain service offerings at greater
speed and lower cost.”

12. 12
A standardized approach
CSPs can only make a business out of
exposing network capabilities if they
are easy for enterprises, developers
and partners to deploy. To this end the
industry is collaborating to develop both
a clear architecture and standards that
span network, service and operations and
management APIs.
TM Forum’s Open Digital Architecture
(ODA) proposes a standardized approach
to automating the lifecycle management of
OSS and BSS, which in turn enables efficient
delivery and lifecycyle automation of NaaS-
based services. ODA exists to help members
build highly complex, flexible solutions by
using sets of loosely coupled components
that expose their business functionality via
a set of Open APIs.
One definition of how ODA can be used to
facilitate NaaS can be found in TM Forum’s
NaaS whitepaper: “Every production
group (e.g., transport, IP, access, media
etc.) expose[s] and manage[s] service
capabilities (i.e. NaaS) in the ODA from the
production function block to other ODA
functional blocks…via the decoupling and
integration function block (API) to allow for
zero-touch automation.”
The diagram right shows the functions a
NaaS layer exposes to other systems to
facilitate end-to-end service management.
Exposing functions for end-to-end service management
NaaS
Service
Catalog
Service
Qualification
Service
Feasibility
Service
Change
Configuration
Service
Inventory
Service
Quality
Service Test
Diagnostics
Service Problem
Reports
Service
Usage
Service
Provisioning
TM Forum, 2023

13. 13
CHAPTER 4
standardizing NaaS delivery
NaaS is one aspect of the fundamental shift to new telco business models. It requires
the traditionally siloed worlds of telco IT and networks to combine and automate the
exposure of their assets so that they are easy for third-party partners and developers
to consume on demand.
This requires a change in working practices, business cultures and skills that is already
underway among many CSPs. It also requires standardization, given that an application’s
success depends on it being able to work on any network of a customer’s choosing.
Software application developers are unlikely to want to know anything much about
networks. Instead, they will look to incorporate functions such as security or a given
latency as quickly and simply as possible into applications, test they work and then sell
them to as big a slice of the global market as possible. Industry-standard APIs mean
developers can integrate network capabilities to address a global market; enterprise
customerswithnotelcoexpertisecanusethoseAPIs;andCSPscanfacilitateapplication-
to-network integration while fulfilling data privacy and regulatory requirements.
BecauseNaaSstraddlestraditionallyseparatenetworkandITworlds,threeorganizations
currently play crucial roles in creating and intertwining the strands of NaaS API
standardization: TM Forum, GSMA and CAMARA.
Announced in February 2022, CAMARA is a joint initiative of GSMA and the Linux
Foundationthatexiststomakeiteasierforend-userdeveloperstoaccessprogrammable
network capabilities.
CAMARA has published and validated its first NaaS API called the Quality on Demand
API, which focuses on access to the network resources needed to deliver 5G quality of
NaaS requires a change in
working practices, business
cultures and skills that is
already underway among
many CSPs

14. 14
service (QoS) on demand (QoD). The API is domain specific and technology dependent
in that it has been created to provide access to 5G mobile network resources.
In March, the CAMARA open-source project took a step further with GSMA’s launch
of Open Gateway. It aims to ensure all operators expose the same interfaces, without
the need for end-user developers to understand telecoms network technology or
terminology. “The industry needs Open Gateway working with the TM Forum’s widely
adoptedOpenAPIsandOpenDigitalArchitecture(ODA),aswellasa fewotherelements
to successfully monetize network-as-a-service and related network capabilities,” says
George Glass, Chief Technology Officer at TM Forum.
TM Forum has a set of NaaS APIs. Initially, they were technology dependent, but at
the request of members they are being modified to abstract the network into a set
of technology-agnostic domains that support intent-based service requests. The idea
is to describe an outcome or characteristics of the service (guaranteed latency, for
example) rather than the specific instructions for the technical resources delivering
the service. This means that QoS can be guaranteed regardless of whether the end
user is accessing the service through 5G, cable broadband, Wi-Fi or some other access
technology.
CSPs say they want the standards to be interoperable and that there should be clear
boundaries around which organizations are responsible for each part. Currently, the
different organizations’ ongoing work is centered on the following areas:
TM Forum leads the definition and development of Operation, Administration and
Management (OAM) APIs, which provide programmable access to capabilities in
OSS, BSS and online charging systems (OCS). More than 70 Open APIs are currently
available and are widely implemented under the Apache 2.0 license.
GSMA focuses on how network capabilities support service APIs and aligns the
service API roadmap with that of network/cloud vendors. Its work includes drafting
recommendations on mapping between CAMARA APIs and technical APIs from
bodies like 3GPP SA2/SA6, IETF, k8s, ETSI NFV and TM Forum.
CAMARA offers a single centralized repository of end-user APIs, making it easier for
developers to access the capabilities of programmable networks without needing to
understand the underlying technology. Thanks to the extensible design of TM Forum

15. 15
Open APIs, they can be tailored to support the goals of CAMARA without creating
additional technical debt or duplication.
To deliver QoD end to end regardless of the type of access, TM Forum’s Open APIs and
CAMARA APIs will need to interoperate. A TM Forum Catalyst project has been set up
to demonstrate this, with a dozen CSPs and vendors sponsoring it (see box below).
CSPs and standards bodies hope that such work will lead to standardized APIs that will
ease the path to NaaS implementations in future.
A new TM Forum Catalyst project sponsored by a dozen large network operators and vendors is showing
how APIs can work together to enable end-to-end quality of service on demand. Nine telcos took part in
the Catalyst: ATT, Axiata, Orange, TIM, Telefonica, Telenor, Telstra, Verizon and Vodafone.
The project sets out to expose different 5G scenarios to enable enterprise customers to control session
data traffic and quality through common APIs. It aims to use CSPs’ standardized APIs – TM Forum,
CAMARA, 3GPP – to automatically boost session data traffic for enterprise customers based on user
policy or via a boost button presented in a partner app user interface.
Industry-standard APIs are vital as CSPs seek to expose network capabilities to developers. Abstraction
from network APIs to service APIs is necessary to hide telco complexity and make APIs easy to consume
for customers with no telco expertise. They’re also needed to fulfil data privacy and regulatory
requirements and to facilitate application-to-network integration.
Watch the video of the Catalyst:

16. 16
ADDITIONAL FEATURE BY ORACLE
NaaS drives operations simplicity
and new revenue opportunity
Oracle Communications views NaaS through two different but interrelated lenses.
First, NaaS is an architectural paradigm that decouples the operations layer from
the network, enabling transformation of operations, independent of the network,
and allowing network abstraction through standards-based open APIs (e.g.:
TMF). Second, NaaS as a business model enabling on-demand consumption of
differentiated network services by enterprises and developer ecosystems through
standardised APIs (e.g.: GSMA Open Gateway and CAMARA). While the former
focusses on achieving high levels of operations efficiency through simplification,
the latter focusses on new revenue generation; the success of both these NaaS
paradigms will depend on an autonomous operations layer enabled by service
lifecycle automation.
CSPs should consider a three-pronged approach to NaaS success.
Operations simplification and rationalisation
Network abstraction and service exposure
Service lifecycle automation and monetization
Operations simplification and rationalisation
CSPs are typically burdened with a plethora of operations application siloes resulting
from a combination of factors including MA, homegrown monolithic apps and
commercially procured apps from vendors. The back-office operations and customer
experience suffer as a direct consequence – for example, the processes required to
support NaaS type on-demand services are created by stitching these fractured
systems through proprietary integrations, resulting in brittle automation, high costs

17. 17
and poor customer experience. Not only is the diverse IT systems estate expensive
to maintain, but it also needs significant lead time for making changes to introduce
new services. By simplifying and rationalizing their operations IT estate, as well as
migrating the network functions and applications to the cloud (e.g.: OCI), CSPs can
achieve better agility and scale.
Read how to modernize your back office.
Learn how Hutchison Drei is driving simplification of its assurance systems.
Network abstraction and service exposure
A simplified operations IT estate paves the way for the decoupling of the operations
layer and the network, creating the basis for a clean network abstraction layer, which
is foundational to achieve the ‘network platform’ architecture. The abstraction layer
enables CSPs to mask the complexity of the underlying network, which consists of
a combination of multiple generations of legacy networks and modern virtual and
software defined networks. The network functions can be wrapped using modern
network modeling techniques such as YANG and/or employ GSMA Open Gateway
based Network APIs, and exposed northbound to the operations layer, which can use
the APIs to create service wrappers and further expose them as Service APIs (e.g.:
CAMARA, TMF) to enterprises and developer ecosystems. In 5G networks, the Network
Exposure Function (NEF) offers another level of service exposure and configurability
including location, device status, quality of service and intelligent charging.
These Service APIs can be called upon for various customer level processes including,
initial negotiation (e.g.: quality, coverage, date / time, and duration), pre-ordering
feasibility checks, ordering and subsequent self-management of the ordered NaaS
services.
This service exposure approach allows CSPs to offer control and flexibility to
enterprises and developer ecosystems enabling them to embed network services in
their applications, with the application-level intent driving service configuration and
ultimately, the network service behavior. Furthermore, from the enterprise perspective,
their business intent can be used to drive network behavior in stressed situations – i.e.,
optimize for throughput vs. optimize for quality or optimize for premium customers
vs. proportionate across all customer types, etc.

18. 18
At Digital Transformation World 2022, Oracle participated in the 5G Flyers catalyst,
where we used TMF Open APIs and ODA to showcase an illustrative drone-based
use case in which an enterprise drone management application embedded such API
calls to automatically control the underlying CSP 5G network without any manual
engagement.
Service lifecycle automation and monetization
At the heart of a CSP’s NaaS operational architecture should be the service lifecycle
automation and monetization layer, which brings together a group of interrelated
technical and process functions to deliver a fully automated on-demand NaaS service
experience. It includes commercial product and technical service design, service order
and delivery, service charging and billing, service observability, service change and
service termination. At a high level,
Service and product design to support both top down (i.e., what network services
the CSP wants to expose externally) as well as bottom up (i.e., support the rapid
incorporation of new network capability within the NaaS offering – e.g., new domain
controller, new application capabilities, etc.).
Service delivery includes the orchestration of service configuration actions based
on the contracted performance and the agreed SLA.
Service charging and billing enables the monetization of NaaS based on various
levers such as the quality of service, API calls etc.
Service observability enables the service assurance management of NaaS services
through anomaly detection and root cause analysis to avoid SLA breaches. It also
uses AI/analytics and automation to enable service lifecycle process improvement,
predictive operations, and automated resolution. Furthermore, service performance
reports can be exposed to enterprise customers with recommendations based on
network behaviour – e.g., in a managed services environment.
Service change and termination involves the self-management of the NaaS and
ultimately service termination and freeing up of all resources involved.

19. 19
The service lifecycle automation and monetization layer bring the Service APIs to life
and truly enables the operationalisation of NaaS. Figure 1 below illustrates the NaaS
operational architecture.
Oracle Communications with Oracle Cloud provides the operational
backbone for NaaS
Oracle’s Unified Operations consists of the three solution pillars to achieve the NaaS
service lifecycle automation. These are: Unified Orchestration, Unified Inventory and
Topology and Unified Assurance. Oracle’s Cloud Scale Monetization includes Cloud
Scale Charging and Cloud Scale Billing that allows CSPs to charge and bill for any
NaaS service based on any unit or metric. Oracle Communications also provides cloud
Figure 1: NaaS operational architecture framework

20. 20
native 5G core control plane network functions to further drive, programmability
and insight based automation to the 5G network. This includes services exposure,
signaling and routing, network slicing, core network analytics and core network
automation. These capabilities are some of the fundamental enablers to monetize 5G
based NaaS. Furthermore, through the Oracle Cloud Marketplace, CSPs can offer their
Service APIs as pre-packaged applications which can either be consumed directly by
the enterprises or used in industry specific applications by the developers. Figure 2
below illustrates Oracle’s solution components in the context of the NaaS operational
architecture framework.
Figure 2: Oracle Communications and Oracle Cloud for NaaS

21. 21
Conclusion
NaaS requires CSPs to simplify and rationalise their operations, which enables them to
abstract network complexity and drive service exposure through standardised network
and service APIs such as GSMA Open Gateway and CAMARA. However, to operationalise
NaaS, CSPs need a standards-based (e.g.: TMF Open APIs and ODA) service lifecycle
automation and monetization layer. Oracle Unified Operations and Cloud Scale
Monetization and Cloud Native 5G core network functions, together with Oracle Cloud
offers the most comprehensive NaaS enablement solution for CSP success.
About Oracle Communications
Oracle Communications provides integrated communications and cloud
solutions for Service Providers and Enterprises to accelerate their digital
transformation journey in a communications-driven world from network
evolution to digital business to customer experience.
www.oracle.com/communications
About Oracle
Oracle offers integrated suites of applications plus secure, autonomous
infrastructure in the Oracle Cloud. For more information about Oracle
(NYSE: ORCL), please visit us at oracle.com.

22. 22
Meet the Research Media team
Author:
Joanne Taaffe
Editor in Chief, Inform
jtaaffe@tmforum.org
Chief Analyst:
Mark Newman
mnewman@tmforum.org
Practice Lead:
Dean Ramsay
dramsay@tmforum.org
Head of Operations:
Ali Groves
agroves@tmforum.org
Commercial Manager:
Tim Edwards
tedwards@tmforum.org
Editor:
Ian Kemp
Managing Editor
ikemp@tmforum.org
Global Account Director:
Carine Vandevelde
cvandevelde@tmforum.org
Marketing Manager:
Ritika Bhateja
rbhateja@tmforum.org
Digital Media Coordinator:
Maureen Adong
madong@tmforum.org
Sponsor Success Manager:
Maryssa Ramsey
mramsey@tmforum.org
Published by:
TM Forum
4 Century Drive,
Parsippany,
NJ 07054
USA
www.tmforum.org
Phone: +1 973-944-5100
Fax: +1 973-944-5110
ISBN: 978-1-955998-50-5
© 2023. The entire contents of this publication are protected by copyright. All rights reserved. The Forum would like to thank
the sponsors and advertisers who have enabled the publication of this fully independently researched report. The views and
opinions expressed by individual authors and contributors in this publication are provided in the writers’ personal capacities
and are their sole responsibility. Their publication does not imply that they represent the views or opinions of TM Forum and
must neither be regarded as constituting advice on any matter whatsoever, nor be interpreted as such. The reproduction of
advertisements and sponsored features in this publication does not in any way imply endorsement by TM Forum of products
or services referred to therein.

23. 23
To find out more about Naas,
CaaS and beyond connectivity
please contact Joann O’Brien