Could NaaS transform telecoms’ market revenue share?

NaaS APIs — Image by bestforbest | Bigstockphoto

NaaS (network-as-a-service) 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?

NaaS is a cloud-native opportunity

Network virtualisation and disaggregation create opportunities broadly categorised as Network as a Service (NaaS). This concept has existed since the early 2010s when the project to virtualise telecoms networks began. In other words, it is an idea native to the 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.

The role of 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 opportunity is 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 is to allow an almost indefinite number of virtual networks to be created and run across a single cloud-managed, physical network.

Opportunities from network APIs

Many commercial and technological challenges and opportunities from network APIs were discussed in a recent STL report, Network APIs: Driving new revenue streams for telcos. The 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

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

STL’s forecast is, however, beset by a great deal of uncertainty. This is because the business model for these network APIs is still highly unclear. For example, how much will application developers be prepared to pay for network access via this route? This depends on operators establishing a clear value proposition for their APIs, i.e., giving 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.