Telco Cloud

Executive Briefing

NETWORK-AS-A-SERVICE:
APIS, AI AND THE OPEN
CLOUD
NaaS is a major new opportunity enabled by telco cloud. But what is it?
How can it be delivered and monetised? And how might it drive
transformation across the whole industry?

David Martin, Senior Analyst | [email protected] | June 2023

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Executive Summary
NaaS is a major opportunity for telcos and non-telcos alike
We believe that Network-as-a-Service (NaaS) represents a significant potential growth market for the
telecoms industry in the next five to ten years. However, telcos will be able to capture only a much
smaller share of the overall NaaS market than the share of the network-services market that they have
been able to claim historically.

The NaaS market will evolve in two stages, which we have called NaaS 1.0 and NaaS 2.0. NaaS 1.0 is
where the industry is now. It involves API-based access to what is still a rather limited set of
programmable and mostly virtualised network functions. Despite its limitations, the potential for this
mode of API business alone is substantial. In a recent report, we forecast that the revenue opportunity
created by the top 11 mobile network APIs alone will reach over $22 billion by 2028, accounting for
2.3% of total mobile service revenue worldwide.

But API-based NaaS is likely to be superseded – potentially quite rapidly – by a new generation of
NaaS (2.0) that will use AI to simplify and accelerate the development of NaaS propositions. These
new NaaS services will be based on tight and comprehensive integration and inter-dependency
between cloud-native applications and cloud-native network functions (CNFs), along with the AI-driven
integration of software and hardware components across the whole network stack. These “networked
compute” (or “net compute”) applications will support many of the services through which AI will drive
automation of processes, services and aspects of daily life across all sectors of industry and society.
Automated, on-demand and self-optimising network services will play an integral role in this broader
transformation.

NaaS 2.0 will be delivered across an open telco cloud

In this more general sense, NaaS 2.0 represents a significant opportunity for telcos as well as to a
host of other ecosystem players: a significantly greater opportunity than the API-driven mode of NaaS
(1.0). Capturing this opportunity is dependent on the telecoms industry completing the evolution of
networking into a cloud-delivered service.

At the end of this phase of cloudification, the telecoms network will effectively be just another cloud
– albeit with distinct features, tools, and software and hardware optimisations designed to deliver
carrier-grade reliability, security and resilience. But as these elements will also be available via the
hyperscale cloud, the operational distinction between the “private” telco cloud and the “public”
hyperscale cloud will fall away. Together, both clouds will constitute an “open telco cloud” over which
any player – vendors, integrators, hyperscalers, application developers, enterprises, and non-telco
networking providers alongside telcos – will be able to develop, operate and consume networking
capabilities and services on demand: as a service. Accordingly, telcos’ share of the NaaS 2.0 market
will be much less than their share of standard connectivity services today.

Eventually, though, the total size of all AI-driven automation services – across all branches of
technology and all industry verticals – will be far greater than total telecoms services revenue today.

© STL Partners EXECUTIVE BRIEFING 2

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Given the integral role played by tailored, on-demand connectivity (NaaS 2.0) as part of this, operators
have a real opportunity to generate new value, even if they take only a minority share of all NaaS 2.0
revenues. See Figure 1. Much of this is incremental revenue and is additional to revenue from
standard connectivity services, which telcos will continue to provide.

Figure 1: NaaS 2.0 market share, 2023 and 2035, worldwide

NaaS 2.0 market at maturity (2035)

Total connectivity revenues in Telco traditional connectivity

2023 revenue
Telco co-creator

Telco distributor
NaaS 2.0 could double
Telco aggregator
the overall value of
networking & Non-telco traditional connectivity
connectivity services revenue*
Non-telco co-creator

Non-telco distributor
Telco traditional connectivity revenue
Non-telco aggregator
Telco application-specific revenue (incl. NaaS 1.0)
Non-telco revenue

Source: STL Partners

Recommendation: NaaS 2.0 is a long-term but fast-evolving

opportunity and telcos need to pick a strategy
The time window for deciding on which NaaS 2.0 strategy to follow may be short – possibly no longer
than two to five years – as developments around AI gather pace.

Not all telcos will be able to play into this market and tap into its potential value in the same way and
to the same extent. We recommend telcos urgently identify which network cloudification pathway to
pursue bearing in mind the NaaS 2.0 opportunity.

© STL Partners EXECUTIVE BRIEFING 3

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Three NaaS business models: Co-creator, Distributor and

Aggregator
We propose three business models that telcos could adopt to target this broader and larger NaaS 2.0
opportunity.

Co-creator: The operator co-creates application-driven NaaS – and NaaS-dependent apps – together
with a wide range of ecosystem partners across the application and network stack. It is involved in
service creation and delivery at the most financially lucrative levels of the stack: primarily, application
and network-function software design. This approach is an evolution of what we described in our
recent Telco Cloud Manifesto 2.0 as the Pathway 4 approach to telco cloud, where the operator
creates and delivers services over any cloud, and increasingly over cloud and network infrastructure
it does not own. See Figure 2.

Distributor: The telco focuses on operating the physical network equipment and services that deliver
NaaS workloads and services where they are needed, over infrastructure that the telco mostly owns
and/or controls. This is less lucrative than business model 1 but an easier transition from telcos’
traditional business model. The Distributor model is a natural fit with Pathway 1 and 2, where
operators may continue to own telco clouds but offer them as a platform for third-party NaaS creators
as part of the open telco cloud described above. See Figure 2.

Aggregator: More hypothetical than the Co-creator and Distributor roles, the Aggregator role involves
a number of related functions that revolve around providing access to high-quality, secure, multi-
vendor/multi-operator NaaS 2.0 services over cloud and network infrastructure that the telco does not
necessarily own or control. These include:

• Providing third-party NaaS as a managed service (rather like many SD-WAN services today)

• Offering additional orchestration, SDN and assurance services around third-party NaaS offerings

• Acting as a NaaS marketplace platform, providing automated instantiation, activation and

assurance of NaaS apps over any infrastructure, location and device

• Fulfilling a regulatory role to defend against the worst potential impacts of unfettered NaaS 2.0

This is a potentially high-margin option, as the telco’s associated opex and capex would be low but
the revenue opportunity is large, even if it is only a small segment of the overall NaaS 2.0 market.
Operators adopting this approach could also continue to deliver existing, standard connectivity
services, including over their own infrastructure. Accordingly, it is compatible with Pathway 1 and 2,
but also to what could be called Pathway 0 where the telco no longer owns any telco cloud
infrastructure but rather aggregates, orchestrates, manages and distributes third-party services
delivered over the open telco cloud. See Figure 2.

These different business models represent a further development of existing trends and pathways
towards telco cloudification, as described in our recent Telco Cloud Manifesto 2.0. The pathways refer
to strategies and methodologies for telcos to complete the virtualisation and cloudification of their

© STL Partners EXECUTIVE BRIEFING 4

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

network functions and infrastructure – ranging from more siloed, single-vendor, full-stack solutions
at one extreme (Pathway 1) to fully cloud-native network functions (CNF) deployed across any cloud,
at the other extreme (Pathway 4).

Figure 2: The four pathways to telco cloudification

Pathway 1 Pathway 2 Pathway 3 Pathway 4

Single-vendor/full-stack Vendor-supported best-of-breed DIY best-of-breed Infrastructure-independent
cloud-native

Operators deploy siloed vertical solutions using Operators leverage COTS hardware with the Operators build and integrate their own
Agile CNF development, deployment and
vendor one-stop-shop for hardware, platforms support of a vendor/systems integrator to run platforms and VNFs/CNFs using components
operation over cloud-agnostic infrastructure
and applications and it is semi-open with enabling platforms and VNFs from a from multiple vendors and hybrid cloud
and in a multi-vendor environment
vertical integration collection of vendors infrastructure

Stack 1 Stack n
MANO MANO MANO
MANO MANO
VNFs VNFs CNFs VNFs CNFs CNFs CNFs CNFs CNFs
VNFs VNFs

Virtualisation layer (containers)/container Virtualisation layer (containers)/container

Virtualisation layer (VMs/containers)
Virtualisation Virtualisation orchestration orchestration
layer (VMs) layer (VMs)
Private cloud Private cloud Public cloud Infrastructure- and cloud-agnostic

Proprietary Proprietary
hardware hardware COTS hardware COTS hardware
COTS hardware

Source: STL Partners

The Co-creator model is a natural fit with the Pathway 4 approach and, to a lesser extent, Pathway 3.
Pathway 1 and 2 players may decide that the Distributor model is a more logical and less risky
evolution of where they are now. Similarly, the Aggregator model is a better fit for Pathway 1 and 2
telcos, as well as for Pathway 0: a new breed of players with no cloud or network infrastructure of their
own.

© STL Partners EXECUTIVE BRIEFING 5

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Table of Contents
Executive Summary ......................................................................................................................................... 2
NaaS is a major opportunity for telcos and non-telcos alike .................................................................. 2
NaaS 2.0 will be delivered across an open telco cloud ............................................................................ 2
Recommendation: NaaS 2.0 is a long-term but fast-evolving opportunity and telcos need to pick a
strategy .......................................................................................................................................................... 3
Three NaaS business models: Co-creator, Distributor and Aggregator................................................. 4

NaaS is a cloud-native opportunity ................................................................................................................ 8

NaaS is also an opportunity for non-telcos................................................................................................. 10

AI-driven automation and cloud-native software could bypass telco APIs ............................................ 14
Cloud-native and AI are made for each other ......................................................................................... 14
AI-based NaaS will enable a new breed of automation-enabling, edge compute applications ........ 15
NaaS 2.0 threatens a “Wild West” of networking .................................................................................... 16
NaaS will drive a restructuring of the telecoms industry as a whole: How should telcos play? ....... 18

Three NaaS 2.0 business models for the telco: Co-creator, distributor and aggregator ....................... 20
Business model 1: Enabler and co-creator of NaaS 2.0 services ......................................................... 21
Business model 2: Physical distributor of NaaS 2.0 services ............................................................... 23
Business model 3: NaaS aggregator ........................................................................................................ 25

Conclusion: NaaS is a significant opportunity — but not just for telcos.................................................. 28

Index ................................................................................................................................................................ 30

© STL Partners EXECUTIVE BRIEFING 6

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Table of Figures
Figure 1: NaaS 2.0 market share, 2023 and 2035, worldwide .................................................................... 3

Figure 2: The four pathways to telco cloudification ..................................................................................... 5

Figure 3: Mobile network API revenue opportunity, 2022-2028, worldwide .............................................. 9

Figure 4: Extended APIs in the disaggregated network stack .................................................................. 11

Figure 5: NaaS service creation and enablement via extended APIs....................................................... 12

Figure 6: NaaS – from telco walled garden to networking Wild West ..................................................... 17

Figure 7: Telcos can increase revenues by widening their remit from connectivity-only to a share of AI-
driven automation services........................................................................................................................... 19

Figure 8: The four telco cloud pathways ..................................................................................................... 20

Figure 9: The NaaS creator model open to Pathway 3 and 4 telcos........................................................ 21

Figure 10: The NaaS distributor model open to Pathway 1 and 2 telcos ................................................ 23

Figure 11: The NaaS aggregator model for Pathway 0, 1 and 2 telcos ................................................... 25

© STL Partners EXECUTIVE BRIEFING 7

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

NaaS is a cloud-native opportunity

Network virtualisation and disaggregation are creating opportunities that are broadly categorised as
Network as a Service (NaaS). This concept has been around since the early 2010s, when the project
to virtualise telecoms networks began. In other words, it is an idea that is native to telco cloud and a
natural by-product of virtualising network functions. Some of the goals of Functions Virtualisation
(NFV) implied NaaS. These were to enable networking capabilities to be:

• Spun up and activated whenever required to meet user demand

• Scaled up and out dynamically to provide greater capacity, bandwidth and reliability, along with
lower latencies, whenever and wherever required

• Programmable and instructible by operators, third parties such as application developers, and
customers, including via APIs (see below)

• Defined and managed centrally, through software, independently of the underlying network
technologies and domains (for example, through software-defined networking [SDN], typically in
SD-WAN platforms)

• Made able – in the 5G era – to support multiple, parallel virtual networks running over the same
physical core and access networks, for example in network slicing

The role of network slicing relates to a distinction between the NaaS discussion at the present time
and previous iterations of the idea in the earlier phases of the telco industry’s cloud evolution.
Previously, NaaS referred to services that depended either on the enhanced scalability enabled by
virtualised network functions or on SDN control over traffic flows. Earlier NaaS services included:

• On-demand activation, or scaling up or down, of dedicated Ethernet links or broadband access

• Flexible, rapid deployment of enterprise network services using Virtualised Network Functions
(VNFs) hosted on vendor-neutral customer premises equipment (uCPE)

• SD-WAN, involving on-demand creation and centralised, SDN-based management of WAN

services, via a software overlay, across multiple physical network types and domains

Current thinking around NaaS is directed towards the opportunities resulting from enabling the largely
virtualised functions of the telco network to be programmed and customised around the requirements
of applications of different types, typically via APIs. This is an opportunity linked to other technology
trends such as edge computing, IoT and the emergence of cloud-native networks and functions. Here,
it is not just the standard attributes of rigid VNFs that can be scaled or controlled via the service, but
the fundamental building blocks of the network – from core to access – that can be re-programmed,
modified or swapped out altogether. The ultimate logic of this is to allow an almost indefinite number
of virtual networks to be created and run across a single cloud-managed, physical network.

© STL Partners EXECUTIVE BRIEFING 8

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Many of the commercial and technological challenges and opportunities from network APIs were
discussed in our recent report, Network APIs: Driving new revenue streams for telcos. Our research
shows that APIs represent a substantial opportunity for telcos, with the revenue opportunity created
by the top 11 mobile network APIs forecast to reach over $22 billion by 2028 (see Figure 33).

Figure 3: Mobile network API revenue opportunity, 2022-2028, worldwide

$25
11 Application instance management

10 Edge node discovery

$20
09 Device onboarding and
authentication
08 Non real-time device status
$15
US$ billions

07 Real-time device status

06 Non-GPS enabled sensor location

$10
05 Hyper precise location

04 Background data transfer

$5
03 Slice configuration

02 Quality of Service (on-demand)

$-
2022 2023 2024 2025 2026 2027 2028 01 Network performance
(information only)

Source: STL Partners, TELUS

These APIs comprise network information APIs providing real-time information about the network
(such as performance, hyper-precise location and device status) and network configuration APIs,
which instruct the network (for example, quality-of-service on-demand, slice configuration and device
onboarding).

© STL Partners EXECUTIVE BRIEFING 9

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

NaaS is also an opportunity for non-telcos

Our forecast in Figure 3 is, however, beset by a great deal of uncertainty. Firstly, this is because the
business model for these sorts of network API is still highly unclear. For example, how much
application developers will actually be prepared to pay for network access via this route. This depends
on operators being able to establish a clear value proposition for their APIs, i.e. that they give access
to capabilities that clearly enhance the functionality of applications or indeed are essential to their
performance. And secondly, operators would need to assert themselves as the primary, even
exclusive, providers of access to these capabilities.

It is unclear if operators collectively will be able to exercise such a monopolistic stranglehold over the
API market, let alone over NaaS more broadly. This is because the capabilities of the current crop of
APIs that the industry is developing are relatively limited, and because there are many alternative
suppliers not only of the APIs themselves, but of the networking capabilities they give access to, such
as hyperscalers and vendors, alongside API standard-setting industry bodies supported by operators,
such as GSMA or TM Forum. So whereas some of these APIs will boost wholesale and retail telco
businesses, others will bypass the telco altogether.

The reason there are many other potential suppliers of NaaS – whether API-driven or not – is because
network disaggregation, alongside virtualisation, enables practically every layer of the application and
network stack, and every network domain (from access to core), to be provided (in theory) by non-
telco or alternative networking providers, in addition to telcos. Another challenge to the API-driven
approach is that application developers are unconvinced by their value. Rather, they tend to treat the
network simply as a problem: a dumb, unreliable resource that they need to minimise the cost of and
engineer around. This may, however, be addressed by a more extended set of APIs and by an AI-driven
approach, which is discussed below.

Figure 4 shows the disaggregated network stack and the potential role for more extended APIs in
connecting up the different layers.

© STL Partners EXECUTIVE BRIEFING 10

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Figure 4: Extended APIs in the disaggregated network stack

Provider 3

Provider 2

providers
Multiple

Multiple
Apps Apps Apps providers

API API API

NFs NFs NFs

API
Provider 4 Provider 5

API API

BSS/OSS
MANO
SDN
Virtualisation layer
Provider 6
(containers)/container orchestration

API

API
Private and/or public clouds Provider 7

Hardware Provider 8

API Northbound API API Southbound API

Source: STL Partners

The APIs we have discussed so far are so-called “northbound” APIs, which connect the application
layer to the predominantly virtualised and/or cloud-native network functions of the telco. Connections
between the SDN controller and higher-level functions such as the cross-domain Management and
Orchestration (MANO) layer and the BSS/OSS are also northbound. Connections down through the
network layers, such as from the SDN through to the data plane functions and switching software and
hardware, or from VNFs down to lower cloud infrastructure layers, are described as “southbound”.

These more extended northbound and southbound connections can be made programmable via APIs,
as shown in Figure 4. This is because APIs are merely software abstractions designed to simplify the
job of programming an external application (like a network function) and integrating it with another
application such as an IoT or mobile edge computing (MEC) app.

Telcos, vendors and standards bodies could decide to develop APIs of these types, as shown in Figure
5. Also, operators could make them available to application developer customers and partners, if they
chose to expose them, which only a handful of wholesale-focused operators have shown any interest
in doing to date. Operators would be able to charge a premium for them, assuming the more granular
and comprehensive control over network capabilities they enabled for application developers and
others was a sufficient value-add for the applications and use cases concerned.

But the more access is granted to networking capabilities and assets in this way, the more it becomes
possible for third parties purchasing that access to create and manage their own on-demand, virtual

© STL Partners EXECUTIVE BRIEFING 11

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

networks (NaaS), whether for their own consumption or for their customers (see Figure 5). In the
B2B2x model shown, customers or partners of the telco are enabled to develop their own use case-
or enterprise-specific NaaS.

Figure 5: NaaS service creation and enablement via extended APIs

Network elements
Customers and partners Business models Monetisation models
accessible via APIs

NFs NFs • Application developers

• B2B
Virtual. layer • Basic set of NFs and • Third-party networking • Usage-based billing
• Wholesale
Telco cloud NF configuration providers • Subscription
Hardware
• Enterprises • MVNO/Es

• Premium billing for

• B2B2x
NFs NFs • More granular set of extended API access
• Vendors • Manually
Virtual. layer NFs and NF and on-demand
• System integrators programmable NaaP*
Telco cloud configuration capabilities
Hardware • Hyperscalers • Partnership co-
(typically, CNFs) • Partnership revenue
development
sharing

• Edge compute • Additional premium

NFs NFs
• Virtualisation layer developers billing for NaaS
Virtual. layer • Zero-touch/full
• Telco cloud • Service providers platform provision
Telco cloud automated NaaP*
Hardware • Hardware with bespoke 5G (and and management
6G) requirements (SLA-backed QoS)

*network-as-a-platform

KEY NaaS 1.0: Telco walled garden

Source: STL Partners

Figure 5 demonstrates how the opening up of deeper layers of the network and – almost as
importantly – IT management platforms such as BSS/OSS, via APIs, is potentially transformative of
the whole telco business model. The present crop of APIs, shown in the first row of Figure 5, could be
described as a walled garden approach: access to a limited set of network functions, defined and
controlled by the telco. This is only a slightly more customisable version of standard connectivity
services, billed in the classic way on a usage-based or subscription basis.

As access is opened up to deeper layers of network design, configuration and management, this
creates opportunities for other types of player both to consume telco NaaS (B2B) and to use the telco
network as a platform to design and offer their own NaaS services (B2B2x). The value in this for the
telco is that it expands and augments the telco’s revenue, partnership and business development
opportunities. This includes:

• Premium billing for enhanced API access

• Opportunities to partner with application developers, vendors, system integrators and

hyperscalers on the development of new connectivity-dependent applications and use cases

• Enhanced, premium-billed role as the guarantor of network resilience and service quality for the
multiple types of service provider delivering NaaS over the telco’s network

© STL Partners EXECUTIVE BRIEFING 12

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Telcos generally remain unconvinced that this represents a substantial untapped opportunity for
them. Instead, they believe it will erode their control point and their ability to monetise the network.
This mindset is a barrier to creating value in ecosystem business models, despite the fact that telcos
have seen how successful hyperscalers have been with this model. Note that the concept and basis
of “the network” itself changes with cloudification; and accordingly, so does the basis for value
creation through the network. The network becomes a software artifact at the service of
applications and application-driven outcomes in the real world. If telcos overlook the opportunities,
then application developers and other software and IT players may simply bypass them.

The ability to fully develop and exploit these sorts of opportunity is dependent on the telco network
ultimately being transformed into a sort of open telco cloud that is based on standardised software
platforms and programming languages, and – initially, at least – on widely adopted, standardised
APIs. See discussion below in the section, AI-driven automation and cloud-native software could
bypass telco APIs.

Crucially, though, this is not something that telcos individually or the telecoms industry as a whole can
achieve on their own as a “telecoms network/industry exclusive”. As the telecoms network becomes
a form of cloud, it increasingly becomes inescapable for telcos to partner and converge with the
broader cloud community: the hyperscalers, of course, but also the full range of potential ecosystem
partners, customers and competitors referred to in Figure 5. All of these players are involved, to a
greater or lesser extent, in the creation and delivery of connectivity-enabled or -dependent applications
and services, via the cloud. If telcos do not open up their own network clouds to these players, they
will eventually be bypassed by other cloud and networking providers that will.

© STL Partners EXECUTIVE BRIEFING 13

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

AI-driven automation and cloud-native

software could bypass telco APIs
AI is an additional factor that will put pressure on telcos to open up their network clouds to third-party
creators of NaaS. This is because, over time, AI will make the job of assembling, on demand, the
disaggregated and virtualised components of bespoke network services much simpler, quicker and
more automated. AI has the potential to truly realise the promise of CNFs that are continuously
developed, upgraded and (self-)optimised, and orchestrated around the requirements of the
application they serve (i.e. intent-based).

As mentioned, APIs are merely software abstractions designed to make the job of programming an
external application like a network function or set of network functions, simpler. However, they also
serve to limit the scope of the programmability, as they give access only to particular functions,
functional subsets and network layers. (This bounding of network access – the walled garden
approach – clearly serves a security purpose as well as defending the telco’s control over the network
and ability to parcel up and monetise access to parts of it via the APIs.)

AI has the potential to supersede APIs in this role of simplifying the programming of network
functions, for operators themselves in the first instance, as well as for third parties. In so doing, AI
offers the prospect of overcoming some of the biggest challenges faced by cloud-native networking
and helping to realise some of its core goals:

• Continuous optimisation of the performance of CNFs based on the overall service intent they are
designed to realise, in conjunction with the other CNFs with which they interoperate.

• Accelerating and automating the orchestration of CNFs, as part of this continuous upgrading
process, via Continuous Integration/Continuous Deployment) (CI/CD) pipelines. The CI/CD
process and tools themselves will become steadily more optimised and speedier as AI machine
learning is able to eliminate coding inconsistencies and flow through the steps in a more zero-
touch way.

• Integrating the evolving CNFs with the other layers of the network stack (e.g. the virtualisation
platform and the compute hardware) in an ever more comprehensive, effective and automated
way. This will progressively eliminate the need for secondary, manual integration tasks and
processes to join the disaggregated components together, as the AI takes charge of the whole
lifecycle management process, end to end.

Cloud-native and AI are made for each other

This type of automated, continuous upgrading and integration of the disparate elements of the
disaggregated network may well seem like nirvana to some, and a nightmare to others. But it is not
fanciful. In fact, the automated optimisation of CNFs is something that is built into their logical
architecture, whereby containerised applications automatically seek the most optimal way (including
through re-coding, as required) to deliver a service intent that is specified to them via so-called

© STL Partners EXECUTIVE BRIEFING 14

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

“declarative APIs”. These are APIs that tell applications, in something that approximates more to
natural language, what they want the application to achieve, without specifying how they should
achieve it.

And this is how AI is meant to work, too: users tell the AI, in natural language, what logical construct
they wish to produce, and the AI assembles it from a vast set of available data, delivering it in the most
concise and comprehensive form possible at that time. The re-engineering of network function code,
and the vast set of complex dependencies it forms part of within a network platform, represent an
orders-of-magnitude greater challenge to AI than the production of a Word-based report or
PowerPoint presentation on a straightforward topic. But the core principles are the same.

AI-based NaaS will enable a new breed of automation-

enabling, edge compute applications
In this way, AI raises the prospect of eventually being able to rapidly create and deliver software- and
cloud-based networks that are both on-demand and highly customised around the needs of
applications. But just how much will applications need this type of bespoke network service, rather
than relying on the best-efforts connectivity that is readily available, now and in the near future, on
telco networks in the physical locations served? After all, advances in both wireline and wireless
technologies, and the distribution of network functions to the edge, already enable ultrafast bandwidth
and low latencies.

This is a reasonable question. But if you asked many application developers whether access to
network capabilities that could reliably deliver, in any location, over any transmission technology, and
over any device, all of the network capabilities required to realise the full potential of their applications,
easily and on demand, they would be extremely interested. Capabilities such as this are not obviously
demanded by applications today. But if those capabilities become available, then they will enable a
new breed of applications that will benefit from them.

These applications are those where AI has the potential to drive optimisation and automation of
compute-directed processes across industries and society as a whole. There is much discussion at
present about how extensive the impact of AI will be in automating many processes and aspects of
our lives. But what is required in practice to deliver this AI-based automation is networks that are
capable of distributing and processing the critical compute-intensive workloads involved, on
demand, and wherever and however is needed.1

This broader, AI-driven push towards automation represents a potentially substantial opportunity for
telcos. It is based on a growing interdependence of cloud-native networks and the use cases they
serve, where AI continuously optimises, in combination, both the application software and the
operational technology (OT) driving the physical processes that are being automated, and the network

1 The kind of AI described here is based on deep learning algorithms that can analyse billions of network events, identify root causes for
sub-optimal performance and faults, and suggest or take remedial action, including ultimately redesigning parts or all of network functions,
orchestrations and integrations throughout the stack. In this sense, it is a form of generative AI. This contrasts with more basic machine
learning (which merely mimics what humans do) or still more basic rules-based automation, which is what characterises standards-based
APIs.

© STL Partners EXECUTIVE BRIEFING 15

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

software and platform they depend on. The AI will operate in a full-system, agnostic manner, across
both the application layer and the different layers of the network. That is its power 2: to integrate and
coordinate, in an ever-more effective manner, the disparate and disaggregated elements of a network-
enabled, compute-driven process – or what we have previously described as “net compute”3.

NaaS 2.0 threatens a “Wild West” of networking

AI-driven NaaS (or net compute) could be termed NaaS 2.0. This is in contrast to the walled garden,
API-driven mode of NaaS described above, or NaaS 1.0. Telcos are far from being able to deliver NaaS
2.0 as a telecoms industry-led and telco-coordinated project in the manner that they are seeking to
steer NaaS 1.0. This is because NaaS 2.0 is something that serves a more far-ranging technological
and societal trend – AI-driven automation. By definition, this involves inputs from and outputs into
different branches of technology (the cloudified telco network being one of them), as well as inputs
from and outcomes in the physical world. To realise the economic opportunities and broader,
potential, societal benefits of AI, the telco network has to become an open telco cloud, with
disaggregated network-function, platform, physical-transmission, and compute-hardware
components that lend themselves to being continuously optimised and adapted around AI-driven
applications and their desired outcomes.

In a worst-case scenario, this could mean the evolution of a chaotic Wild West of networking, where
the open telco cloud – in combination with the hyperscale, public cloud – becomes the platform for a
rampant, AI-driven, networking free-for-all, as shown in Figure 6.

2 There is arguably more work yet to be done to ensure that AI can deliver the five 9s reliability required of telco networks. However, in
contrast to the use of AI in customer care contexts (where getting things wrong 5% of the time, for instance, is not disastrous), the very
basis on which AI would be deployed in telco networks would be to improve on what is already achieved using legacy processes, both
manual and automated.
3 See Why and how to go telco cloud native: AT&T, DISH and Rakuten.

© STL Partners EXECUTIVE BRIEFING 16

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Figure 6: NaaS – from telco walled garden to networking Wild West

NaaS 1.0: NaaS 2.0:
Telco walled garden Networking Wild West
Services Services App developers, Services Any player can create,
edge compute consume or deliver on-
providers, demand/as-a-service
APIs enterprises, etc. can any part(s) of the
access the telco’s stack, and offer it/them
existing deployed directly to customers
PNFs VNFs / CNFs NFs and cloud CNFs (B2x) or to other
platform to deliver players in the value
network services chain (B2B2x)
APIs customised around
needs of the
Virtualised application
Physical
infrastructure infrastructure Cloud
(NFVi)

Pre-virtualisation Current 2030+

legacy telco network Private telco cloud Open multi-cloud

Source: STL Partners

Figure 6 shows, in simplified form, the evolution of the telco network, first via virtualisation and then
via cloudification and disaggregation, into a platform that supports the two generations of NaaS. To
capitalise fully on the opportunities of AI-driven NaaS 2.0, the telco network will need to complete its
evolution into a disaggregated, cloud-native platform that ultimately any player can access to create,
consume or deliver any or all parts of the NaaS/net compute service and value chain – compute,
application software, network-function software, virtualisation platform layer, and compute and
transmission hardware.

In addition, the telco cloud would need to effectively merge with the public, hyperscale cloud. This is
because the AI and the application software needs to run in a network-agnostic way, over any
supporting infrastructure, and over standardised software and platform elements, in order to deliver
the ubiquitous compute that powers the automation services involved. In addition, the hyperscale
cloud provides burstable, on-demand compute capacity necessary to support AI-driven services in a
way the private telco cloud will never be able to match. The telco can continue to operate its own
network cloud; but operationally and practically, this will need to seamlessly interoperate with the
cloud more broadly. This is analogous to the Internet, which is in reality composed of many networks
owned and operated by different operators and non-telcos, but which functions as an integrated,
unified platform built on common standards and architecture.

Ultimately, the telco network evolves into just one part of a larger, global, open cloud platform
supporting more or less on-demand networks-as-a-service that are developed and operated mainly by
non-telcos. This is potentially the networking Wild West – third parties effectively let loose across
what was once a telco-controlled and -exclusive domain.

© STL Partners EXECUTIVE BRIEFING 17

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Less dramatically, this could be described simply as a situation in which networking has now evolved
into a software and cloud business, for which telcos provide much of the infrastructure but are only
relative bit-part players in creating the value, which lies in compute, application and network software,
and AI.

NaaS will drive a restructuring of the telecoms industry as a

whole: How should telcos play?
The Wild West of networking described above represents a worst-case scenario where different
elements come together to squeeze telcos out of the more valuable networking opportunities. This
scenario is based on extrapolating from these key trends:

• Cloud-native networking

• The convergence of telco cloud and the hyperscale cloud

• The rise of AI

• The substantial market potential for NaaS as targeted via the present breed of APIs (NaaS 1.0)

The emergence of the new mode of NaaS (2.0) is hypothetical. Things could play out in this way, but
they may turn out differently. However, the technological and societal drivers – particularly AI-driven
automation – are already a reality. Telcos still control their destiny, but they will have to contend with
a networking landscape that may change even more rapidly and fundamentally than it already has
through the cloudification of networks that has taken place over the last decade. Nobody really knows
for sure how AI-driven automation will play out, across society in general and the telecoms industry in
particular. But it will have at least two fundamental effects, both of which underscore the importance
of NaaS business models in the future.

It will drive a fragmentation, diversification and verticalisation of the networking business.

Connectivity services will increasingly be designed around the varying requirements of real-world
use cases and vertical-specific processes, rather than being generic as previously. This is already
happening with private networks. AI will be deeply involved in developing and optimising the
software and hardware components of networking services, which could be provided by different
telco and non-telco ecosystem players focusing on specific network and application layers, and
different network domains. In short, telcos will not command the end-to-end networking space as
once they did or presumed to. But there will be valuable roles they can play as part of the new breed
of application- and AI-driven services.

The bespoke/on-demand networking services supporting AI-driven automation across society

and industry (NaaS 2.0) are a significant growth opportunity. In fact, they are probably the biggest
growth driver for telecoms over the foreseeable future. Telcos will have a smaller share of this new
market, but it will grow to be a larger potential source of revenue than that of simple connectivity
services alone. See Figure 7.

© STL Partners EXECUTIVE BRIEFING 18

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Figure 7: Telcos can increase revenues by widening their remit from connectivity-only
to a share of AI-driven automation services

NaaS 2.0 market at maturity (2035)

Total connectivity revenues in Telco traditional connectivity

2023 revenue
Telco co-creator

Telco distributor
NaaS 2.0 could double
Telco aggregator
the overall value of
networking and Non-telco traditional connectivity
connectivity services revenue*
Non-telco co-creator

Non-telco distributor
Telco traditional connectivity revenue
Non-telco aggregator
Telco application-specific revenue (incl. NaaS 1.0)
Non-telco revenue

* Includes services such as legacy WAN/LAN provided by IT services providers or systems integrators, Wi-Fi services, neutral host networks, etc.

Source: STL Partners

The revenue shares and comparative market sizes in Figure 7 are illustrative rather than precise
estimates. The potential value of NaaS 2.0 services – bespoke, on-demand, application-driven and -
enabling network services – is considerably larger than the total network services market in the
present; although whether this is more or less than double the size is impossible to model at present,
as it is a rapidly evolving technology landscape.

The distinct roles that telcos could play in this much expanded, but diversified, networking landscape
are outlined below.

© STL Partners EXECUTIVE BRIEFING 19

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Three NaaS 2.0 business models for the telco:

Co-creator, distributor and aggregator
As part of this fragmentation and diversification of the networking landscape we have identified three
main business models that telcos could pursue to target the value of the NaaS 2.0 market. These
represent a natural fit and evolution path for telcos from where they are now. In different ways, they
also involve the telco in exercising a controlling and limiting influence over what could otherwise be
an unfettered open season for AI-driven, cloud-based networking, which could be against the public
interest and pose a threat to security.

Figure 8 shows how we relate the business models to the four telco cloud pathways set out in our
recent Telco Cloud Manifesto 2.0. These represent the different strategies and trajectories that telcos
have been following to virtualise and cloudify their networks. For a more detailed explanation, see the
Manifesto itself.

Figure 8: The four telco cloud pathways

Pathway 1 Pathway 2 Pathway 3 Pathway 4

Single-vendor/full-stack Vendor-supported best-of-breed DIY best-of-breed Infrastructure-independent
cloud-native

Operators deploy siloed vertical solutions using Operators leverage COTS hardware with the Operators build and integrate their own
Agile CNF development, deployment and
vendor one-stop-shop for hardware, platforms support of a vendor/systems integrator to run platforms and VNFs/CNFs using components
operation over cloud-agnostic infrastructure
and applications and it is semi-open with enabling platforms and VNFs from a from multiple vendors and hybrid cloud
and in a multi-vendor environment
vertical integration collection of vendors infrastructure

Stack 1 Stack n
MANO MANO MANO
MANO MANO
VNFs VNFs CNFs VNFs CNFs CNFs CNFs CNFs CNFs
VNFs VNFs

Virtualisation layer (containers)/container Virtualisation layer (containers)/container

Virtualisation layer (VMs/containers)
Virtualisation Virtualisation orchestration orchestration
layer (VMs) layer (VMs)
Private cloud Private cloud Public cloud Infrastructure- and cloud-agnostic

Proprietary Proprietary
hardware hardware COTS hardware COTS hardware
COTS hardware

Source: STL Partners

© STL Partners EXECUTIVE BRIEFING 20

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Business model 1: Enabler and co-creator of NaaS 2.0 services

This business model is a logical target for Pathway 3 and particularly Pathway 4 telcos, which have
transformed their operations, organisations and infrastructure around cloud- and software-centric
networking. See Figure 9.

Figure 9: The NaaS creator model open to Pathway 3 and 4 telcos

Apps Apps Apps

NFs NFs NFs

BSS/OSS
MANO
SDN
Virtualisation layer
(containers)/container orchestration
Private and/or public clouds

Hardware

Telco remit

Source: STL Partners

Under this business model, the telco would partner with application developers to create, manage and
possibly operate the cloud-native software layers delivering the NaaS service. These comprise the
application layer and the CNFs, but also potentially any of the other parts of the network stack. By
creating these layers, we mean developing new software components (e.g. containerised,
microservices-based application software), alongside adapting and upgrading existing software
components (such as CNFs originally developed by a vendor). These are then integrated with one
another and with the underlying virtual and physical cloud platform components, and orchestrated
into a bespoke, application-driven network service (NaaS 2.0).

Telcos would naturally be expected to focus on the network-function software, while application
developer partners would look after the application software. However, in this concept of NaaS, the
two software layers are profoundly interdependent and interact dynamically with each other. In
addition, solution integration and optimisation across all layers of the stack would be increasingly
assisted and managed by AI, operating continuously across the stack to modify and upgrade
components and code in order to deliver the desired outcomes of the application ever more holistically
and efficiently. This sort of role for AI has been described in a recent blog post by the Chairman of the
O-RAN Alliance as a “GoalSimOps” approach to network automation, replacing the current DevOps

© STL Partners EXECUTIVE BRIEFING 21

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

and DevSecOps paradigms: intent-driven networking, with AI-prompted modifications first being
automatically test-simulated before being rolled out operationally.4

In this context, there is no reason theoretically why telcos would not also get involved in developing
the application software for some application-specific NaaS services they co-create in this way. These
services would in any case typically be the product of the joint effort of a whole ecosystem of
technology and service partners, including IT and network software and hardware vendors, systems
integrators, hyperscalers, and third-party networking service and infrastructure providers. The basis
of value creation in these services would be primarily the design and delivery of the software, along
with the compute function directing the end application – rather than in operating the physical network
infrastructure that distributes the functionality and enables the application data to be processed in
geographical locations near where it is consumed.

In this sense, the telco would not need to either own or exercise operational control over any of the
physical infrastructure over which the service is delivered. The telco would have evolved from physical
network operator to “application-network software creator”. That is why we are assigning this
business model to our Pathway 4 operator type, “infrastructure-independent cloud-native”.5

However, in cases where the operator does retain ownership and control over more of the
infrastructure over which the services are delivered, this business model is also a natural fit for the
Pathway 3 operator type, “DIY best-of-breed”. This latter category comprises operators that are taking
responsibility for the design, integration and operation of their cloud-native network functions and are
also getting involved in MEC and IoT platform development and service design, leveraging the private
telco cloud infrastructure and competencies they have built up. Examples include Deutsche Telekom,
SK Telecom, Verizon and Vodafone.

As stated above, in each of the business models described here, the operator has the potential to
exercise a brake on unfettered NaaS, the networking Wild West. As NaaS 2.0 co-creator, the telco
could help direct, restrain and co-ordinate the AI function, ensuring that the network automation and
optimisation role that AI plays does not get out of control, and that it continues to generate genuine
customer and societal value at a realistic and sustainable pace of development and upgrade rollouts.
More particularly, building on their networking heritage, operators could be tasked to ensure that
innovation and network evolution in different domains or application-centric areas of networking did
not adversely affect or place too great a strain on networking capabilities and services in other
domains and parts of a country’s overall networking infrastructure. This sort of role could also be
exercised in different ways as part of the other two NaaS business models we describe here.

4 https://www.linkedin.com/posts/alex-jinsung-choi-48a8b61_revolutionizing-network-services-auto-chatgpt-activity-
7058123972747390976-0nPh/?utm_source=share&utm_medium=member_ios
5 Our analysis in the Telco Cloud Manifesto 2.0, identifies AT&T and DISH Networks as the only clear and current examples of the still-

emerging Pathway 4 model.

© STL Partners EXECUTIVE BRIEFING 22

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Business model 2: Physical distributor of NaaS 2.0 services

This business model is a logical target for Pathway 1 or 2 telcos that have begun the process of
cloudifying their networks and operations but are more reliant on vendor and system integrator
partners and have continuing focus on their own physical networking assets and services. See Figure
10.

Figure 10: The NaaS distributor model open to Pathway 1 and 2 telcos

Apps Apps Apps

NFs NFs NFs

BSS/OSS
MANO
SDN
Virtualisation layer
(containers)/container orchestration
Private cloud

Hardware

Telco remit
Source: STL Partners

This business model is more closely aligned with the traditional role of the telco as operator of physical
network equipment and services. As part of a NaaS 2.0 ecosystem, this involves the operator focusing
on physical distribution of NaaS workloads across infrastructure it owns and/or has operational
control over. In other words, this is providing the connectivity assets and services that deliver and
process NaaS workloads in the geographical locations and physical environments where they are
needed to fulfil the service intent.

Accordingly, this NaaS business model involves a reduction in the degree to which the telcos
concerned get involved with the cloud layers of the NaaS stack. This is compared even with the extent
to which they have been involved up to now in virtualising and cloudifying their networks around the
delivery of pure connectivity services via a Pathway 1 or 2 approach. In the context of NaaS
specifically, the telco offers its network facilities, data centres, edge and aggregation sites as a
physical platform for third parties and NaaS 2.0 ecosystems to build out, customise and manage the
application, network-function, cloud-platform and hardware layers required for their services.

The role of the NaaS distributor is then limited to ensuring that the NaaS 2.0 workloads get to and
from their destination reliably and on time. This involves an emphasis on traditional, physical network
operational layers and tasks: Layers 1 to 4 of the OSI network stack – physical transmission (radio,
optics), Ethernet, IP and transport.

© STL Partners EXECUTIVE BRIEFING 23

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

While representing a subordinate and less lucrative role for the telco in NaaS, compared with business
model 1, this is nonetheless a substantial opportunity. This is for the reason articulated above: that AI-
driven and automation-enabling NaaS 2.0 represents a potentially large overall market. Accordingly,
the network services that deliver NaaS to the physical locations where it is consumed represent a vital
part of the value chain and a potential growth driver. In addition, there is much work to be done to
build out new or re-fit existing edge infrastructure to support this ubiquitous compute capacity.
Arguably, telcos are the ones that are in the strongest position to do this.

The telcos opting for this business model would be those that decide strategically that they will not
be able to transition into cloud- and software-centric businesses. They will have decided that this
approach is too difficult and costly, and they will be unlikely to achieve anything like the scale and
competency of the larger telcos in these areas, let alone those of the broader ecosystem and the
hyperscalers in particular. This model involves the smallest degree of change to existing operating
and financial models, as telcos remain fixed asset-based infrastructure operators. However there will
be a need for more operational agility and flexibility to ensure that right-sized and tailored hardware
and software assets are deployed in the right locations at the right time.

As stated above, one of the roles that telcos adopting any of the three business models could play is
that of helping rein in some of the potentially more harmful impacts of unfettered, AI-driven NaaS. The
telco as NaaS distributor could exercise this role by protecting and guaranteeing the performance,
reliability and security of NaaS infrastructure. This would ensure that the dynamically and
continuously evolving capabilities of NaaS services did not lead to an overall degradation of network
performance and integrity, or the emergence of advanced security threats that could not be defended
against owing to a lack of contingency measures or the ability to physically isolate and segregate the
parts of the infrastructure that might be targeted. Again, this is a role that is a natural fit with some of
the existing roles and responsibilities of telcos as providers of secure, vital, national infrastructure, and
as guardians of data privacy and security.

© STL Partners EXECUTIVE BRIEFING 24

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Business model 3: NaaS aggregator

This business model is also a more suitable target for Pathway 1 or 2 players, along with Pathway 0
service providers (those without any of their own cloud or even physical network infrastructure). It
involves no direct role in NaaS creation or operation, but rather the marketing, orchestration and
regulatory monitoring of third-party NaaS. See Figure 11.

Figure 11: The NaaS aggregator model for Pathway 0, 1 and 2 telcos

Apps Apps Apps

NFs NFs NFs

BSS/OSS
MANO
SDN
Virtualisation layer
(containers)/container orchestration
Private cloud

Hardware

Telco remit
Source: STL Partners

In business model 3, the telco does not or need not directly develop, provide or operate any of the
software layers or networking components involved in NaaS services. In addition, the telco may not
own or operate any of the physical infrastructure that is used. In the case where the telco does own
some of the physical infrastructure, this business model could be adopted in tandem with business
model 2.

Instead, business model 3 involves the telco acting as an aggregator of NaaS services developed and
operated by others. This role could include some or all of the following components. These are
hypothetical, to a greater or lesser degree, and depend on how the impact of AI on networking plays
out in practice:

1. Marketing, billing and reselling NaaS provided by a large number of third-party NaaS creators
and operators. This leverages the telco’s technology assets and skills in BSS, billing and
charging, and customer service/CRM. The reseller role is an extension and generalisation of a
role telcos already play in many SD-WAN and SASE services; for example, where they effectively
resell the services of SD-WAN vendors, particularly those with their own WAN and cloud
infrastructure. The telcos could place such services within a managed services “wrap” under
which they offer things such as SLAs, guaranteed delivery times, security services, maintenance
and repair, and support to the customer in seeking a NaaS partner to develop and operate its
bespoke network services, and in managing the relationship with that partner. This role is also
not dissimilar to that of MVNOs or PSTN voice resellers in the past. It offers a route into the
NaaS 2.0 market for new entrants, which do not need to build their own network.

© STL Partners EXECUTIVE BRIEFING 25

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

2. Cross-domain, multi-operator and multi-cloud MANO and SDN services. This is a more
operationally hands-on role, but one which still does not require the telco to directly own or
operate any of the application and network software and hardware components involved in the
NaaS solution. Several multi-cloud orchestration platforms and tools already exist, which telcos
could exploit to fulfil the MANO role (for example, Google’s Anthos for Telecom). And SDN itself
is a technology that is designed to manage and optimise data flows across data centre/cloud
infrastructure, in order to prioritise specific application workloads and meet customer SLAs. The
ability to offer MANO and SDN managed services would enable the telco to back up the NaaS
reselling services described above with operational capabilities that enabled it to meet its SLAs
and support-services obligations more reliably, under its own control.

3. Looser NaaS aggregator role, similar to the content and app aggregator role played by the
likes of Google or Apple. Customers could go to a telco portal and order a download of a
network-enabled app (or NaaS 2.0 service). AI could then be used to determine the cloud and
network infrastructure required to:

• deliver the service, together with the associated network parameters (such as latency,
bandwidth, reliability), to the user’s device and location

• automate the deployment, instantiation and orchestration of all the networking components
involved in a flow-through, zero-touch way

• install and deliver closed-loop service assurance and security functions

This role probably requires the telcos or non-telcos providing the service to operate globally, and telcos
would be likely to face competition from hyperscalers and others. But there are specific network-
operational aspects to this role (as described above) that may not fit with the hyperscalers’ business
model. Telcos currently owning global or multinational infrastructure would have an advantage in
building this sort of scale. But as this model does not require telcos to deliver the service across
infrastructure they themselves own or control, this would not be imperative.

4. Regulatory responsibility for managing and co-ordinating multi-vendor/multi-operator NaaS

services across a national infrastructure. This is a more speculative, prospective role that the
aggregator could take on. As aggregators of NaaS delivered across their own and third-party
infrastructure, telcos could also act as guardians of the national and public interest in relation to
AI-driven NaaS, helping to counteract and mitigate the threats to service levels and security they
could otherwise pose. Operationally, this would involve an extended application of the tools and
capabilities required for numbers 2 and 3 above. As this would be a regulatory function, the
telcos involved would need formal authorisation to access third-party network and service
performance and security-related data; so there would need to be regulatory safeguards in place
to prevent telcos using this privileged access to secure a competitive advantage. This function is
a continuation and extension of the role traditionally played by national incumbents as
protectors and guarantors of critical national communications infrastructure. It also leverages
telcos’ strengths and assets in BSS/OSS, MANO, security and physical networking.

© STL Partners EXECUTIVE BRIEFING 26

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Whether fulfilled by telcos or not, the need for a regulatory function such as this is almost certain to
emerge in order to defend against the potentially harmful impacts of AI-driven NaaS 2.0. National
security, data sovereignty and data protection concerns are already acting as an inhibitor to telcos
deploying network functions on the public cloud and to deepening collaboration with hyperscalers. So
the creation of this new, enhanced regulatory role could play a vital part in fostering the growth of
NaaS 2.0 and in promoting its positive contribution to AI-driven automation across industry and
society more broadly.

We have assigned this business model to operators following the Pathway 1 or 2 approaches to telco
cloud or, by contrast, Pathway 0. This latter term expresses the idea that the NaaS aggregator, as a
standalone role, is no longer a network operator, in either the traditional sense (operator of physical
network equipment and services) or the cloudified sense (creator and enabler of network services,
and network-dependent applications, over virtualised infrastructure).

However, it is mainly operators currently engaged in either Pathway 1 or 2 for which the aggregator
role may represent an attractive strategic option. It would be a way for such operators to tap into the
NaaS 2.0 opportunity without necessarily developing their own NaaS 2.0 services. This still requires a
certain level of cloud competency and further evolution of the MANO and SDN skillset and assets
developed during the Pathway 1 and 2 phases they have already gone through. But operators adopting
this strategy would not need to go through the full transformation into a cloud-native telco that is
required for business model 1. They could continue to provide commodity connectivity services over
their own cloud and network infrastructure as their core business. But their engagement in NaaS 2.0
would be that of a reseller and managed services provider.

Accordingly, business model 3 requires comparatively little direct capex or opex, but would still have
substantial revenue-generation potential, as it involves taking a low-percentage slice out of the large
NaaS 2.0 pie. The risk would be that enterprises would be unwilling to source their NaaS 2.0 services
from a mere aggregator rather than direct from the creators of those services. The aggregator offer
would probably, therefore, be more relevant for larger enterprises and organisations, as this would
enable them to deal with a single provider and a single point of accountability if SLAs are not delivered,
rather than having to contract with a multitude of providers, some of which would be relative
unknowns without a clear record of providing carrier-grade reliability.

© STL Partners EXECUTIVE BRIEFING 27

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Conclusion: NaaS is a significant opportunity —

but not just for telcos
NaaS represents a large potential growth market for the telecoms industry in the next five to ten years.
However, telcos will be able to capture only a much smaller share of the overall NaaS market than the
share of the network services market that they have been able to claim historically (see Figure 7).

The NaaS market will evolve in two stages – NaaS 1.0 and NaaS 2.0. NaaS 1.0 is where the industry
is now. It involves API-based access to what is still a limited set of programmable and mostly
virtualised network functions. Despite its limitations, the potential for this mode of API business alone
is substantial. In a recent report, we forecast that the revenue opportunity created by the top 11 mobile
network APIs alone will reach over $22 billion by 2028.

This market could see further growth if the industry succeeds in developing and commercialising a
more extensive set of APIs giving access to deeper layers of the network and to OSS/BSS and
management layers. But as the telco network is opened up in this way, more opportunities are also
created for third parties (such as vendors, integrators and other networking providers) to create and
provide their own NaaS services.

While they are a significant opportunity, APIs also represent an attempt to limit the degree of access
to the telco network that is provided to third parties, and to monetise that access by restricting its
supply. But telcos will not be able to achieve this in the longer term, as there are other potential
suppliers of APIs, and other cloud and networking providers over which API-driven NaaS could be
offered.

In addition, API-based NaaS is likely to be superseded – potentially quite rapidly – by a new generation
of NaaS (2.0) that will use AI to simplify and accelerate the development of NaaS propositions. These
new NaaS services will be based on tight and comprehensive integration and inter-dependency
between cloud-native applications and cloud-native network functions, along with AI-driven integration
of software and hardware components across the whole network stack. These “networked compute”
(or ”net compute”) applications represent the different ways in which AI will drive automation of
processes, services and aspects of daily life across all sectors of industry and society. Automated, on-
demand and self-optimising network services will play an integral role in this broader transformation.

In this broader sense, NaaS 2.0 represents a large opportunity for telcos and a host of other ecosystem
players. This is a significantly greater opportunity than the API-driven mode of NaaS (1.0). But not all
telcos will be able to play into this market and tap into its potential value in the same way and to the
same extent.

NaaS 1.0 should be viewed as a stepping stone to the broader NaaS 2.0 opportunity. However, telcos
must consider now how or whether they aim to play into NaaS 2.0.

• Investing time and money into the more restrictive forms of API-driven NaaS could be a waste of
effort. The monetisation models are still not completely clear, and this form of NaaS is likely to

© STL Partners EXECUTIVE BRIEFING 28

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

be superseded by AI-driven NaaS in any case, possibly much faster than expected as
applications for AI across all sectors gather pace.

• The timeframe for successfully targeting the most lucrative NaaS 2.0 business model (model 1
below) may therefore be short – five years at most.

The three business models that telcos could adopt to target this broader and larger NaaS 2.0
opportunity:

1. Co-creator: The operator co-creates application-driven NaaS – and NaaS-dependent apps –

together with a wide range of ecosystem partners across the application and network stack. It is
involved in service creation and delivery at the most financially lucrative levels of the stack,
primarily, application and network-function software design.

2. Distributor: The telco focuses on operating the physical network equipment and services that
deliver NaaS workloads and services where they are needed, over infrastructure that the telco in
large measure owns and/or controls. This is less lucrative than business model 1 but an easier
transition from telcos’ traditional business model.

3. Aggregator: More speculative than the other two roles, the aggregator involves a number of
related functions that revolve around providing access to high-quality, secure, third-party, multi-
vendor/multi-operator NaaS 2.0 services over cloud and network infrastructure that the telco
does not necessarily own or control. These include:

• providing third-party NaaS as a managed service (rather like many SD-WAN services)

• offering additional orchestration, SDN and assurance services around third-party NaaS offerings

• acting as a NaaS marketplace platform, providing automated instantiation, activation and

assurance of NaaS apps over any infrastructure, location and device

• fulfilling a regulatory role to defend against the worst potential impacts of unfettered NaaS 2.0

These different business models represent a further development of existing trends and pathways
towards telco cloudification, as described in our Telco Cloud Manifesto 2.0. However, the rather
short timeframe for deciding on which NaaS strategy to follow makes the imperative to identify
which network cloudification pathway the telco aims to pursue even more urgent.

© STL Partners EXECUTIVE BRIEFING 29

 NETWORK-AS-A-SERVICE: APIS, AI AND THE OPEN CLOUD | JUNE 2023

Index

aggregator, 20, 25, 27, 29 NaaS, 8, 10, 12, 14, 15, 16, 17, 18, 20, 21, 22, 23,
AI, 10, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 24, 24, 25, 26, 27, 28, 29
26, 28, 29 NaaS 1.0, 16, 18, 28
APIs, 8, 9, 10, 11, 12, 13, 14, 15, 18, 28 NaaS 2.0, 16, 17, 18, 20, 21, 22, 23, 24, 27, 28,
application developers, 8, 10, 11, 12, 13, 15, 21 29
B2B2x, 12 northbound, 11
BSS/OSS, 11, 12, 26 Pathway 0, 25, 27
business model 1, 21, 24, 27 Pathway 1, 23, 27
business model 2, 23 Pathway 2, 23, 27
business model 3, 25, 27 Pathway 4, 22
business models, 13, 18, 20, 22, 24, 29 SDN, 8, 11, 26, 27
CI/CD, 14 SD-WAN, 8, 25
CNFs, 14, 21, 28 southbound, 11
co-creator, 20, 29 system integrators, 12
distributor, 20, 23, 24, 29 TM Forum, 10
GSMA, 10 uCPE, 8
hyperscalers, 10, 12, 13, 22, 24 VNFs, 8, 11
MANO, 11, 26, 27 walled garden, 12, 14, 16, 17

© STL Partners EXECUTIVE BRIEFING 30

Research Consulting Events

www.stlpartners.com