Tag: CI/CD

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

The Telco Cloud Manifesto 2.0

Nearly two years on from our first Telco Cloud Manifesto published in March 2021, we are even more convinced that going through the pain of learning how to orchestrate and manage network workloads in a cloud-native environment is essential for telcos to successfully create new business models, such as Network-as-a-Service in support of edge compute applications.

Since the first Manifesto, hyperscalers have emerged as powerful partners and enablers for telcos’ technology transformation. But telcos that simply outsource to hyperscalers the delivery and management of their telco cloud, and of the multi-vendor, virtualised network functions that run on it, will never realise the true potential of telco cloudification. By contrast, evolving and maintaining an ability to orchestrate and manage multi-vendor, virtualised network functions end-to-end across distributed, multi-domain and multi-vendor infrastructure represents a vital control point that telcos should not surrender to the hyperscalers and vendors. Doing so could relegate telcos to a role as mere physical connectivity and infrastructure providers helping to deliver services developed, marketed and monetised by others.

In short, operators must take on the ‘workload’ of transforming into and acting as cloud-centric organisations before they shift their ‘workloads’ to the hyperscale cloud. In this updated Manifesto, we outline why, and what telcos at different stages of maturity should prioritise.

Two developments have taken place since the publication of our first manifesto that have changed the terms on which telcos are addressing network cloudification:

  • Hyperscale cloud providers have increasingly developed capabilities and commercial offers in the area of telco cloud. To telcos uncertain about the strategy and financial implications of the next phase of their investments, the hyperscalers appear to offer a shortcut to telco cloud: the possibility of avoiding doing all the hard yards of developing the private telco cloud, and of evolving the internal skills and processes for deploying and managing multi-vendor VNFs / CNFs over it. Instead, the hyperscalers offer the prospect of getting telco cloud and VNFs / CNFs on an ‘as-a-Service’ basis – fundamentally like any other cloud service.
  • In April 2021, DISH announced it would build its greenfield 5G network with AWS providing much of the virtual infrastructure layer and all of the physical cloud infrastructure. In June 2021, AT&T sold its private telco cloud platform to Microsoft Azure. In both instances, the telcos involved are now deploying mobile core network functions and, in DISH’s case, all of the software-based functions of its on a hyperscale cloud. These events appear superficially to set an example validating the idea of outsourcing telco cloud to the hyperscalers. After all, AT&T had previously been a champion of the DIY approach to telco cloud but now looked as though it had thrown in the towel and gone all in with outsourcing its cloud from Azure.

Two main questions arise from these developments, which we address in detail in this second Manifesto:

  • Should telcos embarked or embarking on a Pathway 2 strategy outsource their telco cloud infrastructure and procure their critical network functions – in whole or in part – from one or more hyperscalers, on an as-a-Service basis?
  • What is the broader significance of AT&T’s and DISH’s moves? Does it represent the logical culmination of telco cloudification and, if so, what are the technological and business-model characteristics of the ‘infrastructure-independent, cloud-native telco’, as we define this new Pathway 4? Finally, is this a model that all Pathway 3 players – and even all telcos per se – should ultimately seek to emulate?

In this second Manifesto, we also propose an updated version of our pathways describing telco network cloudification strategies for different sizes and types of telco to implement telco cloud. We now have four pathways (we had three in the original Manifesto), as illustrated in the figure below.

The four telco cloud deployment pathways in STL’s Telco Cloud Manifesto 2.0

Source: STL Partners, 2023

Existing subscribers can download the Manifesto at the top of this page. Everyone else, please go here.

If you wish to speak to us about our new Manifesto, please book a call.

Table of contents

  • Executive Summary
    • Recommendations
  • Pathway 1: No way back
    • Two constituencies at operators: Cloud sceptics and cloud advocates
  • Pathway 2: Hyperscalers – friend or foe?
    • Cloud-native network functions are a vital control point telcos must not relinquish
  • Pathway 3: Build own telco cloud competencies before deploying on public cloud
    • AT&T and DISH are important proof points but not applicable to the industry as a whole
    • But telcos will not realise the full benefits of telco cloud unless they, too, become software and cloud businesses
  • Pathway 4: The path to Network-as-a-Service
    • Pathway 4 networks will enable Network-as-a-Service
  • Conclusion: Mastery of cloud-native is key for telcos to create value in the Coordination Age

Related research

Our telco cloud research aligned to this topic includes: