Network-as-a-service: APIs, AI and the open cloud

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 network functions virtualisation 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-WANplatforms)
  • 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

Enter your details below to download an extract of the report

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.

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 graphic below).

Mobile network API revenue opportunity, 2022-2028, worldwide

Mobile-network-API-revenue-opportunity-2022-2028-worldwide-stl-partners

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).

NaaS is also an opportunity for non-telcos

Our forecast 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.

Table of contents

  • Executive Summary
    • NaaS is a major opportunity for telcos and non-telcos alike
    • NaaS 2.0 will be delivered across an open telco cloud
    • Recommendation: NaaS 2.0 is a long-term but fast-evolving opportunity and telcos need to pick a strategy
    • Three NaaS business models: Co-creator, Distributor and Aggregator
  • NaaS is a cloud-native opportunity
  • NaaS is also an opportunity for non-telcos
  • AI-driven automation and cloud-native software could bypass telco APIs
    • Cloud-native and AI are made for each other
    • AI-based NaaS will enable a new breed of automation-enabling, edge compute applications
    • NaaS 2.0 threatens a “Wild West” of networking
    • NaaS will drive a restructuring of the telecoms industry as a whole: How should telcos play?
  • Three NaaS 2.0 business models for the telco: Co-creator, distributor and aggregator
    • Business model 1: Enabler and co-creator of NaaS 2.0 services
    • Business model 2: Physical distributor of NaaS 2.0 services
    • Business model 3: NaaS aggregator
  • Conclusion: NaaS is a significant opportunity — but not just for telcos

Related Research

Enter your details below to download an extract of the report

Network APIs: Driving new revenue streams for telcos

Network APIs promise new revenues for telcos

Since 2020 there has been a resurgent interest in applications interfacing with the network they run over. The exponential increase in the number of connected devices and complex traffic, particularly video, is exerting pressure on network resources. Applications must become more aware of network and edge compute resource availability to meet increasingly stringent customer requirements as well as energy efficiency targets – for example, by prioritising critical applications. MEC allows data to be collected and processed closer to the customer (more information on edge computing is available on our Edge hub).

STL Partners forecasts the revenue opportunity created by mobile network APIs to reach over $20 billion by 2028 (the full version of this report provides a breakdown of the opportunity for the top 11 network APIs), as well as enabling powerful new applications that leverage programmable, cloud-native networks.

Increased network programmability will enable developers to build applications that require guaranteed connection speed and bandwidth, giving users/providers the option to pay a premium for network resource when and where they need it. The network APIs fuelling this market fall into two broad categories:

  • Network information APIs: Basic network APIs that provide real-time information about the network will reach extremely high volumes over the next decade. These will gradually be consolidated into the core network offering as a hygiene factor for all operators. Examples include network performance (information only), hyper-precise location, real-time device status, etc.
  • Network configuration APIs: APIs that instruct the network will not reach the same volume of usage, instead offering a premium service to a smaller pool of users wanting to define their network environment. Examples of these APIs include quality-of-service on-demand, slice configuration and device onboarding. These APIs offer a longer-term monetisation opportunity for operators, although there is little visibility around what developers and enterprise will pay for these services (e.g., pay per use vs. monthly subscription, etc.).

In this report, we explore the work that is currently happening to develop network APIs from a technical and commercial point of view, surveying the telecoms industry consortia that are proactively building the technical and commercial tools to make network-as-a-service a revenue-driving success.

Enter your details below to download an extract of the report

Two API domains: The macro network and MEC

MEC APIs control both the compute and networking elements at the edge. In the instance that a telco is operating and managing the edge site, these APIs come under their remit. In some instances, however, the MEC APIs could be defining edge or cloud compute not operated by the telco. Therefore, we do not consider all MEC APIs to come under the umbrella of network APIs (See figure below).

MEC APIs vs. Network APIs

Source: STL Partners

A MEC API is a set of programming interfaces that allow developers to access and utilize the resources of mobile edge computing platforms. These resources include computing power, storage, and network connectivity, and can be used to run applications, services, and tasks at the edge of the network, closer to the end users. MEC APIs can provide a way to offload workloads from the cloud to the edge, reducing latency and improving the performance of applications and services. CSPs must make a strategic decision on where to focus their development: general network APIs (quality-on-demand, location, etc.) or MEC APIs (edge node discovery, intent-based workload placement, etc.).

Need for reliable, real-time connectivity across a wide area will drive demand

Based on our interviews with application developers, we developed a framework to assess the types of use cases network APIs are best suited to enable. This framework sets out the network API opportunity across two dimensions:

  • The geographic nature of the use case: Local area vs. wide-area use cases. This influences the type of edge that is likely to be used, with local-area use cases leveraging the on-premiseedge and wide-area use cases better suited to the network edge.
  • Need for real-time vs. non-real time insight and response: This depends on the mission criticality of the use case or the need from the application point of view to be dynamic (i.e., adapt to changing circumstances to maintain a consistent or enhanced customer experience).

As network operators, telcos’ primary value-add is the ability to provide quality connectivity. Application developers leverage awareness of the network throughout their development process, and the ability to define the network environment enables use cases which require constant, ultra-reliable connectivity (see figure below).

Importance of connectivity features for developers

Source: STL Partners Survey (December 2022), n=101

Table of Contents

  • Executive Summary
  • Network APIs promise new revenues for telcos
    • Two API domains: The macro network and MEC
    • Need for reliable, real-time connectivity across a wide area will drive demand
    • Layers of API needed to translate network complexity into valuable network functions
    • Cross-telco collaboration and engagement of developers
    • Each industry fora focuses on specific layers of the API value chain
  • Operators must leverage multiple distribution channels for network APIs
    • Failure to standardise quickly allows other distribution channels to achieve greater scale
    • Operators must engage the developer community to play an aggregator role
  • Challenges and barriers: What needs to change
  • Conclusion
  • Appendix
    • Understanding the fundamentals of APIs
    • What are network APIs and what has changed?

Related research

Enter your details below to download an extract of the report