Telco Cloud Deployment Tracker: Open RAN deep dive

Telco Cloud: Open RAN is a work in progress

This report accompanies the latest release and quarterly update of STL Partners ‘Telco Cloud Deployment Tracker’ database. This contains data on deployments of VNFs (Virtual Network Functions), CNFs (cloud-native network functions) and SDN (Software Defined Networking) in the networks of the leading telcos worldwide. In this update we have added some additional categories to the database to reflect the different types of virtualised / open RAN:

  1. Open RAN / O-RAN: Fully open, disaggregated, virtualised / cloud-native, with CU / DU split
  2. vRAN: Virtualised CU/DU, with open interfaces but implemented as an integrated, single-vendor platform
  3. Cloud RAN: Single-vendor, virtualised / centralised BU, or CU only, with proprietary / closed interfaces

Cloud RAN is the most limited form of virtualised RAN: It is based on porting part or all of the functionality of the legacy, appliance-based BU into a Virtual Machine. vRAN and open RAN are much more significant, in both technology and business-model terms, breaking open all parts of the RAN to more competition and opportunities for innovation.

Accordingly, the report presents data on only open RAN and vRAN deployments however a granular analysis of each category of RAN deployment can be carried out using the Telco Cloud Tracker tool.

Access our online Telco Cloud Deployment Tracker tool here

Download the additional file for the full dataset of Telco Cloud deployments

Enter your details below to request an extract of the report

Open RAN and vRAN deployments, 2018 – 2022

Open-RAN-Deployments-Apr-2021-STL-Partners

Source: STL Partners

Open RAN and vRAN

Both Open RAN and vRAN are virtualised (with the exception of NTT DoCoMo as outlined in the report), but ‘open RAN’ implies full disaggregation of the different parts of the RAN (hardware, software and radio), and open interfaces between them. By contrast, vRAN incorporates the open interfaces but is generally deployed as a pre-integrated, single-vendor solution: hardware, software and radio supplied by the same vendor.

To date, there have been significantly more open RAN than vRAN deployments. But vRAN is emerging as a potentially competitive alternative to pure open RAN: offering the same operational benefits and – in theory – multi-vendor openness, but without the overhead of integrating components from multiple vendors, and a ‘single neck to choke’ if things go wrong. Deployments in 2020 were mostly small-scale and / or 4G, including trials which continued to carry live traffic after the trial period came to an end.

The stark contrast between 2021 and 2022 reflects a slight hiatus in commercial deployments as work intensified around integration and operational models, trials, performance optimisation, and cost economics. However, major deployments are expected in 2022, including greenfield networks 1&1 Drillisch (Germany) and DISH (US), Verizon, Vodafone UK, and MTN (Africa and ME).

Scope and content of the Tracker

The data in the latest update of our interactive tool and database covers the period up to March 2022, although reference is made in the report to events and deployments after that date. The data is drawn predominantly from public-domain information contained in news releases from operators and vendors, along with reputable industry media.

We apply the term ‘deployment’ to refer to the total set of VNFs, CNFs or SDN technology, and their associated management software and infrastructure, deployed at an operator – or at one or more of an operator’s opcos or natcos – in order to achieve a defined objective or support particular services (in the spreadsheet, we designate these as the ‘primary purpose’ of the deployment). For example, this could be:

  • to deploy a 5G standalone core
  • to launch a software-defined WAN (SD-WAN) service
  • or to construct a ‘telco cloud’ or NFV infrastructure (NFVi): a cloud infrastructure platform on which virtualised network services can be introduced and operated.

The Tracker is provided as an interactive tool containing line-by-line analysis of over 900 individual deployments of VNFs, CNFs or SDN technology, which can be used to drill down by:

  • Region where deployed
  • Operator
  • Technology vendor
  • Primary purpose
  • Type of telco cloud function deployed
  • …and more filters

Telco Cloud Trial Deployment Tracker

Take a look at the trial of our interactive tool with live, commercial deployments of VNFs, CNFs and SDN technologies worldwide

Previous telco cloud tracker releases

Each new release of the tracker is global, but is accompanied by an analytical report which focusses on trends in given regions from time to time:

 

Enter your details below to request an extract of the report

VNFs on public cloud: Opportunity, not threat

VNF deployments on the hyperscale cloud are just beginning

Numerous collaboration agreements between hyperscalers and leading telcos, but few live VNF deployments to date

The past three years have seen many major telcos concluding collaboration agreements with the leading hyperscalers. These have involved one or more of five business models for the telco-hyperscaler relationship that we discussed in a previous report, and which are illustrated below:

Five business models for telco-hyperscaler partnerships

Source: STL Partners

In this report, we focus more narrowly on the deployment, delivery and operation by and to telcos of virtualised and cloud-native network functions (VNFs / CNFs) over the hyperscale public cloud. To date, there have been few instances of telcos delivering live, commercial services on the public network via VNFs hosted on the public cloud. STL Partners’ Telco Cloud Deployment Tracker contains eight examples of this, as illustrated below:

Major telcos deploying VNFs in the public cloud

Source: STL Partners

Enter your details below to request an extract of the report

 

Telcos are looking to generate returns from their telco cloud investments and maintain control over their ‘core business’

The telcos in the above table are all of comparable stature and ambition to the likes of AT&T and DISH in the realm of telco cloud but have a diametrically opposite stance when it comes to VNF deployment on public cloud. They have decided against large-scale public cloud deployments for a variety of reasons, including:

  • They have invested a considerable amount of money, time and human resources on their private clouddeployments, and they want and need to utilise the asset and generate the RoI.
  • Related to this, they have generated a large amount of intellectual property (IP) as a result of their DIY cloud– and VNF-development work. Clearly, they wish to realise the business benefits they sought to achieve through these efforts, such as cost and resource efficiencies, automation gains, enhanced flexibility and agility, and opportunities for both connectivityand edge compute service innovation. Apart from the opportunity cost of not realising these gains, it is demoralising for some CTO departments to contemplate surrendering the fruit of this effort in favour of a hyperscaler’s comparable cloud infrastructure, orchestration and management tools.
  • In addition, telcos have an opportunity to monetise that IP by marketing it to other telcos. The Rakuten Communications Platform (RCP) marketed by Rakuten Symphony is an example of this: effectively, a telco providing a telco cloud platform on an NFaaS basis to third-party operators or enterprises – in competition to similar offerings that might be developed by hyperscalers. Accordingly, RCP will be hosted over private cloud facilities, not public cloud. But in theory, there is no reason why RCP could not in future be delivered over public cloud. In this case, Rakuten would be acting like any other vendor adapting its solutions to the hyperscale cloud.
  • In theory also, telcos could also offer their private telcoclouds as a platform, or wholesale or on-demand service, for third parties to source and run their own network functions (i.e. these would be hosted on the wholesale provider’s facilities, in contrast to the RCP, which is hosted on the client telco’s facilities). This would be a logical fit for telcos such as BT or Deutsche Telekom, which still operate as their respective countries’ communications backbone provider and primary wholesale provider

BT and Deutsche Telekom have also been among the telcos that have been most visibly hostile to the idea of running NFs powering their own public, mass-market services on the public and hyperscale cloud. And for most operators, this is the main concern making them cautious about deploying VNFs on the public cloud, let alone sourcing them from the cloud on an NFaaS basis: that this would be making the ‘core’ telco business and asset – the network – dependent on the technology roadmaps, operational competence and business priorities of the hyperscalers.

Table of contents

  • Executive Summary
  • Introduction: VNF deployments on the hyperscale cloud are just beginning
    • Numerous collaboration agreements between hyperscalers and leading telcos, but few live VNF deployments to date
    • DISH and AT&T: AWS vs Azure; vendor-supported vs DIY; NaaCP vs net compute
  • Other DIY or vendor-supported best-of-breed players are not hosting VNFs on public cloud
    • Telcos are looking to generate returns from their telco cloud investments and maintain control over their ‘core business’
    • The reluctance to deploy VNFs on the cloud reflects a persistent, legacy concept of the telco
  • But NaaCP will drive more VNF deployments on public cloud, and opportunities for telcos
    • Multiple models for NaaCP present prospects for greater integration of cloud-native networks and public cloud
  • Conclusion: Convergence of network and cloud is inevitable – but not telcos’ defeat
  • Appendix

Related Research

 

Enter your details below to request an extract of the report

 

Telco Cloud Deployment Tracker: 5G standalone and RAN

Telco cloud 2.0, fuelled by 5G standalone and RAN, is on the starting grid

This report accompanies the latest release and update of STL Partners ‘Telco Cloud Deployment Tracker’ database. This contains data on deployments of VNFs (Virtual Network Functions), CNFs (cloud-native network functions) and SDN (Software Defined Networking) in the networks of the leading telcos worldwide. It builds on an extensive body of analysis by STL Partners over the past nine years on NFV and SDN strategies, technology and market developments.

Access our Telco Cloud Tracker here

Download the additional file for the full dataset of Telco Cloud deployments

Scope and content of the Tracker

The data in the latest update of our interactive tool and database covers the period up to September 2021, although reference is made in the report to events and deployments after that date. The data is drawn predominantly from public-domain information contained in news releases from operators and vendors, along with reputable industry media.

We apply the term ‘deployment’ to refer to the total set of VNFs, CNFs or SDN technology, and their associated management software and infrastructure, deployed at an operator – or at one or more of an operator’s opcos or natcos – in order to achieve a defined objective or support particular services (in the spreadsheet, we designate these as the ‘primary purpose’ of the deployment). For example, this could be:

  • to deploy a 5G standalone core
  • to launch a software-defined WAN (SD-WAN) service
  • or to construct a ‘telco cloud’ or NFV infrastructure (NFVi): a cloud infrastructure platform on which virtualised network services can be introduced and operated.

The Tracker is provided as an interactive tool containing line-by-line analysis of over 900 individual deployments of VNFs, CNFs or SDN technology, which can be used to drill down by:

  • Region where deployed
  • Operator
  • Technology vendor
  • Primary purpose
  • Category of NFV/SDN technology deployed
  • …and more filters

Enter your details below to request an extract of the report

5G standalone (SA) will hit an inflection point in 2022

5G standalone (SA) core is beginning to take off, with 19 deployments so far expected to be completed in 2022. The eventual total will be higher still, as will that of NSA core, as NSA 5G networks continue to be launched. As non-standalone (NSA) cores are replaced by SA, this will result in another massive wave of core deployments – probably from 2023/4 onwards.

Standalone 5G vs non-standalone 5G core deployments

STL-5G-standalone-core-cloud-tracker-2021

Source: STL Partners

 

Previous telco cloud tracker releases

Each new release of the tracker is global, but is accompanied by an analytical report which focusses on trends in given regions from time to time:

Enter your details below to request an extract of the report

End-to-end network automation: Why and how to do it?

Automation, analytics and AI: A3 unlocks value for operators

STL Partners has been writing about automation, artificial intelligence (AI) and data analytics for several years. While the three have overlapping capabilities and often a single use case will rely upon a combination, they are also distinct in their technical outcomes.

Distinctions between the three As

Source: STL Partners

Operators have been heavily investing in A3 use cases for several years and are making significant progress. Efforts can be broadly broken down into five different domains: sales and marketing, customer experience, network planning and operations, service innovation and other operations. Some of these domains, such as sales and marketing and customer experience, are more mature, with significant numbers of use cases moving beyond R&D and PoCs into live, scaled deployments. In comparison, other domains, like service innovation, are typically less mature, despite the potential new revenue opportunities attached to them.

Five A3 use case domains

Source: STL Partners

Use cases often overlap across domains. For example, a Western European operator has implemented an advanced analytics platform that monitors network performance, and outputs a unique KPI that, at a per subscriber level, indicates the customer experience of the network. This can be used to trigger an automated marketing campaign to customers who are experiencing issues with their network performance (e.g. an offer for free mobile hotspot until issues are sorted). In this way, it spans both customer experience and network operations. For the purpose of this paper, however, we will primarily focus on automation use cases in the network domain.  We have modelled the financial value of A3 for telcos: Mapping the financial value.

Request a report extract

The time is ripe for network automation now

Network automation is not new. In fact, it’s been a core part of operator’s network capabilities since Almon Strowger invented the Strowger switch (in 1889), automating the process of the telephone exchange. Anecdotally, Strowger (an undertaker by profession) came up with this invention because the wife of a rival funeral parlour owner, working at the local community switchboard, was redirecting customers calling for Strowger to her own husband’s business.

Early advertising called the Strowger switch the “girl-less, cuss-less, out-of-order-less, wait-less telephone” or, in other words, free from human error and faster than the manual switchboard system. While this example is more than 100 years old, many of the benefits of automation that it achieved are still true today; automation can provide operators with the ability to deliver services on-demand, without the wait, and free from human error (or worse still, malevolent intent).

Despite automation not being a new phenomenon, STL Partners has identified six key reasons why network automation is something operators should prioritise now:

  • Only with automation can operators deliver the degree of agility that customers will demand. Customers today expect the kind of speed, accuracy and flexibility of service that can only be achieved in a cost-effective manner with high degrees of network automation. This can be both consumer customers (e.g. for next generation network services like VR/AR applications, gaming, high-definition video streaming etc.) or enterprise customers (e.g. for creating a network slice that is spun up for a weekend for a specific big event). With networks becoming increasingly customised, operators must automate their systems (across both OSS and BSS) to ensure that they can deliver these services without a drastic increase in their operating costs.
    One  wholesale operator exemplified this shift in expectations when describing their customers, which included several of the big technology companies including Amazon and Google: “They have a pace in their business that is really high and for us to keep up with their requirements and at the same time beat all our competitors we just need to be more automated”. They stated that while other customers may be more flexible and understand that instantiating a new service takes time, the “Big 5” expect services in hours rather than days and weeks.
  • Automation can enable operators to do more, such as play higher up the value chain. External partners have an expectation that telcos are highly skilled at handling data and are highly automated, particularly within the network domain. It is only through investing in internal automation efforts that operators will be able to position themselves as respected partners for services above and beyond pure connectivity. An example of success here would be the Finnish operator Elisa. They invested in automation capabilities for their own network – but subsequently have been able to monetise this externally in the form of Elisa Automate.
    A further example would be STL Partners’ vision of the Coordination Age. There is a role for telcos to play further up the value chain in coordinating across ecosystems – which will ultimately enable them to unlock new verticals and new revenue growth. The telecoms industry already connects some organisations and ecosystems together, so it’s in a strong position to play this coordinating role. But, if they wish to be trusted as ecosystem coordinators, they must first prove their pedigree in these core skills. Or, in other words, if you can’t automate your own systems, customers won’t trust you to be key partners in trying to automate theirs.
  • Automation can free up resource for service innovation. If operators are going to do more, and play a role beyond connectivity, they need to invest more in service innovation. Equally, they must also learn to innovate at a much lower cost, embracing automation alongside principles like agile development and fast fail mentalities. To invest more in service innovation, operators need to reallocate resources from other areas of their business – as most telcos are no longer rapidly growing, resource must be freed up from elsewhere.
    Reducing operating costs is a key way that operators can enable increased investment in innovation – and automation is a key way to achieve this.

A3 can drive savings to redistribute to service innovation

Source: Telecoms operator accounts, STL Partners estimates and analysis

  • 5G won’t fulfil its potential without automation. 5G standards mean that automation is built into the design from the bottom up. Most operators believe that 5G will essentially not be possible without being highly automated, particularly when considering next generation network services such as dynamic network slicing. On top of this, there will be a ranging need for automation outside of the standards – like for efficient cell-site deployment, or more sophisticated optimisation efforts for energy efficiency. Therefore, the capex investment in 5G is a major trigger to invest in automation solutions.
  • Intent-based network automation is a maturing domain. Newer technologies, like artificial intelligence and machine learning, are increasing the capabilities of automation. Traditional automation (such as robotic process automation or RPA) can be used to perform the same tasks as previously were done manually (such as inputting information for VPN provisioning) but in an automated fashion. To achieve this, rules-based scripts are used – where a human inputs exactly what it is they want the machine to do. In comparison, intent-based automation enables engineers to define a particular task (e.g. connectivity between two end-points with particular latency, bandwidth and security requirements) and software converts this request into lower level instructions for the service bearing infrastructure. You can then monitor the success of achieving the original intent.
    Use of AI and ML in conjunction with intent-based automation, can enable operators to move from automation ‘to do what humans can do but faster and more accurately’, to automation to achieve outcomes that could not be achieved in a manual way. ML and AI has a particular role to play in anomaly detection, event clustering and predictive analytics for network operations teams.
    While you can automate without AI and ML, and in fact for many telcos this is still the focus, this new technology is increasing the possibilities of what automation can achieve. 40% of our interviewees had network automation use cases that made some use of AI or ML.
  • Network virtualisation is increasing automation possibilities. As networks are increasingly virtualised, and network functions become software, operators will be afforded a greater ability than ever before to automate management, maintenance and orchestration of network services. Once networks are running on common computing hardware, making changes to the network is, in theory, purely a software change. It is easy to see how, for example, SDN will allow automation of previously human-intensive maintenance tasks. A number of operators have shared that their teams and/or organisations as a whole are thinking of virtualisation, orchestration and automation as coming hand-in-hand.

This report focuses on the opportunities and challenges in network automation. In the future, STL Partners will also look to more deeply evaluate the implications of network automation for governments and regulators, a key stakeholder within this ecosystem.

Table of Contents

  • Executive Summary
    • End-to-end network automation
    • A key opportunity: 6 reasons to focus on network automation now
    • Key recommendations for operators to drive their network automation journey
    • There are challenges operators need to overcome
    • This paper explores a range of network automation use cases
    • STL Partners: Next steps
  • Automation, analytics and AI: A3 unlocks value for operators
    • The time is ripe for network automation now
  • Looking to the future: Operators’ strategy and ambitions
    • Defining end-to-end automation
    • Defining ambitions
  • State of the industry: Network automation today
    • Which networks and what use cases: the breadth of network automation today
    • Removing the human? There is a continuum within automation use cases
    • Strategic challenges: How to effectively prioritise (network) automation efforts
    • Challenges to network automation– people and culture are key to success
  • Conclusions
    • Recommendations for vendors (and others in the ecosystem)
    • Recommendations for operators

Request STL research insights overview pack