A reality check on cloud-native networks: what are the barriers to progress and what needs to be done?

5G was conceived as a cloud-native network featuring decomposed, microservices-based functions on open, automated infrastructure. However, the development of such networks remains slow as the initial phase of 5G investment concludes. Analysys Mason’s benchmarking studies¹ show that a strong interest in cloud-native, open networks and operations remains, but barriers related to operations, ecosystems and standards hinder their implementation across the core, RAN and edge. This article examines these obstacles and proposes solutions.

Operators have made progress with cloud-native networks but claims of major developments are often overly optimistic

Many operators have launched their first cloud-native networks featuring cloud-native network functions (CNFs) and Kubernetes (K8s)-based container-as-a-service (CaaS) platforms. However, these are primarily small-scale implementations in the mobile core (such as 5G standalone); there have been far fewer deployments in the RAN (vRAN/Open RAN). Even in the mobile core, no operator meets all of the essential criteria of a cloud-native network (Figure 1), yet they have (unrealistic) expectations of doing so within the next 3 years.

Figure 1: Operators’ plans to adopt the properties of cloud-native technology in the mobile core, 2H 2023²

Source: Analysys Mason

Major Tier 1 operators aim to have disaggregated, network functions and/or domain-neutral, horizontal, cloud-native architecture and lifecycle automation platforms across 5G domains. However, only a few (12% according to our Open Network Index (ONI) study³) have made significant progress in this regard. Many still operate with vendor-/domain-/service-specific approaches and have not transitioned from vertically integrated network cloud stacks. Furthermore, our data⁴ shows that the divide between vertically integrated vendor-/domain-specific silos and disaggregated network cloud models has remained largely unchanged since 2022, despite initial interest in disaggregated 5G networks. For instance, AT&T opted for a vertically integrated stack from Ericsson for its Open RAN, which is surprising given its advocacy for openness and the inherently disaggregated nature of Open RAN.

These siloed network clouds lack many important characteristics of cloud-native systems and inevitably lead to suboptimal, snowflake automations that are unable to take full advantage of cloud-native principles and methodologies. As a result, the level of automation in operators’ cloud-based networks remains disappointing (operators reported that only 25–30% of Day 0, 1 and 2 processes are automated, on average).

Overall, operators are grappling with the large-scale operationalisation of cloud-native networks. A blame game is taking place between operators and vendors, with each side asserting that the other is responsible for the lacklustre progress. We believe that both parties share responsibility and that there are concrete steps that the industry must take to resolve this deadlock.

Network functions often stand in the way of achieving cloud-native networks

The goal of cloud-native network transformation is to achieve high levels of operational efficiency and agility with automation and programmability. Cloud-native technologies support a new network operating model whereby components from any vendor using any technology can be managed as cloud-native objects using open, industry-standard tools and principles such as GitOps and immutability. Operators have made the most progress in the cloud infrastructure layers (CaaS and COTS hardware) due to commonality with cloud-native IT tools and best practices. However, progress with network functions (NFs) lags behind; NFs are not yet fully manageable as software objects in an open and common way.

Operators often feel that NF vendors are slow to develop CNFs, and that many vendor-specific dependencies are still present across the stack (management, PaaS and hardware), particularly with incumbent vendors’ NFs. This complicates disaggregation and horizontalisation. NF vendors’ reluctance to guarantee performance and support for the disaggregated, best-of-breed infrastructure chosen by an operator is a common issue. Consequently, testing, validation, integration and ongoing support for such infrastructure is complex and resource-intensive, thereby reducing operators’ commitment to disaggregation. This raises the question of whether operators are pushing NF vendors hard enough to make a change, or if they are simply accepting it because they feel stuck.

The number of NF vendors remains small, and a few major players dominate the market. Cloud-native technologies were expected to increase vendor diversity, but expectations have not been met. Casa Systems went bankrupt, Microsoft discontinued Affirmed and Metaswitch and other challenger vendors have not gained enough traction or financial stability. Additionally, Chinese vendors’ solutions are excluded from many countries outside of China. This reduced competition at the NF layer stifles innovation and weakens operators’ influence over how NFs should evolve.

The convergence of IT and networks across operator organisations, industry standards and initiatives is the key to cloud-native NFs

The industry must collectively take steps to advance cloud-native networks. This starts with operators bridging the divide between their IT and networks teams. IT departments are familiar with cloud-native technologies, including concepts such as containerisation, microservices, CI/CD and GitOps, but lack in-depth knowledge about telecoms network requirements. Conversely, networks teams have deep expertise in telecoms networks, but are not yet fully familiar with cloud-native technologies. Converging these units is essential and long overdue. Without it, operators cannot fully understand cloud-native NF requirements, select the right vendors and steer them in the right direction, or eliminate internal organisational and political barriers.

Secondly, telecoms standards and cloud-native ecosystems need to be aligned far more closely. 3GPP standards consider the cloudification of the 5G core and RAN, but these are high-level, non-prescriptive specifications that were defined predominantly by traditional telecoms vendors. Many of the technology components of a cloud-native network originate from the IT and cloud vendors and open-source communities that drive cloud-native innovation but currently make very limited contributions to 3GPP standards. As a result, these technologies need to be retrofitted rather than natively supported. There is a strong need for increased collaboration and synchronisation between these two worlds to help vendors to build solutions that address the requirements of cloud-native networks.

Finally, operators need to take cloud-native, open-source industry initiatives as seriously as traditional ones such as 3GPP and TM Forum. Our research reveals that many operators are not actively involved in, nor do they contribute to, such initiatives. This is a crucial step in creating a more unified front against the small group of vendors that currently control the market. Operators should work within the ecosystem to reach a general consensus on the definition and features of cloud-native networks, such as those identified in NGMN’s Cloud Native Manifesto. Operators should then drive industry-wide testing and conformance programmes, such as the Cloud Native Telecom Initiative (CNTI), and consistently require vendors to comply with these standards.

¹ For more information, see Analysys Mason’s Cloud Transformation Benchmark 2023: results and key findings, Open Network Index: evaluating operators’ progress and attitudes to ‘openness’ across core, RAN and edge and Cloud-native mobile core networks: operator maturity index.

² Question: “When are you planning to adopt the following properties of cloud-native technology for the mobile core domain?”; n=75.

³ For more information, see Analysys Mason’s Open Network Index: evaluating operators’ progress and attitudes to ‘openness’ across core, RAN and edge.

⁴ For more information, see Analysys Mason’s 5G network cloud deployment tracker.