Your guide to building a cloud native infrastructure for 5G
The industry is evolving to the New Radio (NR) and standardized 5G Core (5GC) based on cloud native and a new service-based architecture (SBA). This new 5G SA network will allow service providers to address multiple vertical services for industries and enterprises and to explore new business opportunities.
Service providers also face two big growth challenges in this journey: how to be more efficient and lower the operational and capital expenditure costs in the whole network when data traffic keeps growing, and how to deal with the increasing network complexity in 5G. The complexity growth has two dimensions: firstly, the number of layers and functions in the stacks of hardware, virtualization layers, applications and OSS/BSS. Secondly, the number of potential combinations within and between the layers with products from many vendors’ open source software.
The evolution to the cloud-native 5G Core is a major technology shift for the core network architecture of mobile and eventually fixed networks.
Cloud native transformation
In the telecommunications sector, many operators and vendors are embracing cloud native technologies. Although they’ve has been adopted among public cloud and IT players for some time, there are some different challenges for the telecoms industry. One is that applications must be able to run on different infrastructures as most service providers have bespoke configurations.
The four main areas impacted by its adoption are:
- Application design and development
- Technology and infrastructure
- Processes and ways of working
- Management and orchestration
These four aspects do not exist in isolation. They all influence each other, and so none of them should be overlooked at any point in time. For example, if applications, infrastructure and orchestration all follow cloud-native design patterns, yet the ways of working and organizational setup and model does not take advantage of the cloud-native setup, the full potential will not be reached.
The evolution to a cloud-native infrastructure for 5G builds on NFV
Since 2012 and the start of the virtualization of network functions, the industry has worked hard to get working solutions, and now we see live commercial systems that work well.
Yet many networks have a few virtualized network functions (VNFs) on smaller or node-based NFV Infrastructure (NFVI) platforms. Others are building larger horizontal telecom clouds, which are able to run multiple VNFs from multiple vendors. The traffic running on these VNFs is typically around 30 percent, ranging from 10 to 50 percent depending on type of VNF. The uptake among leaders is increasing quickly.
We have seen management and orchestration (MANO) solutions evolve from the basic VNF manager (VNFM) to more advanced, extended VNFM plus cloud orchestration (NFVO), and we also see early end-to-end service orchestration deployments. Service providers are starting to change their operations organizations. This has created a platform both in terms of technology and learnings to take the next step and evolve telecoms cloud infrastructure to run cloud-native applications.
A system-verified NFVI stack: a key success factor
The stability of telecoms cloud platforms has been a challenge for the industry in past years, but has now reached a good maturity level. This has been achieved by Ericsson customers with our introduction of pre-integrated and system-verified solutions. This could apply for all types of cloud infrastructures regardless if its virtual infrastructure anager (VIM)-based, NFVI or bare metal. What’s notable here is the recurring costs for life cycle management (LCM) of the stack where the open source software is upgraded every quarter. This also enables solution support of the entire cloud infrastructure stack through a single interface.
Fig 1. The NFV infrastructure is the foundation for 5G Core and 5G applications
5G implications in the cloud infrastructure
With 5G, the idea is to build a single infrastructure for all types of IoT and enhanced mobile broadband services, ranging from gaming or highly demanding automated manufacturing, to low traffic sensors. The solution to this is a shared infrastructure with orchestrated network slices to efficiently deploy all the services. This now means that a working telecoms cloud infrastructure is a prerequisite to run many of the new and upcoming 5G services and future innovative applications.
In the 5G context, edge computing has been discussed to provide capabilities like low latency or device offloading for new services or dedicated enterprise networks. We foresee that the same type of telecoms cloud, based on ETSI NFV, will also be used in the evolution to cloud native.
Management and orchestration tools to operate the infrastructure will be more important as we move to cloud native where more frequent updates will be required. Several layers of the CaaS use open source software which will demand at least quarterly upgrades . Automated procedures will be required to cope with this.
Fig 2. Automated and optimized workload placement across distributed data centers in a multi-domain, multi-technology and multi-vendor environment
Deployment options for the cloud-native infrastructure
Option 1: for service providers), with existing NFVI platforms, an easy way to start with cloud-native applications or cloud- native network functions, (CNFs) is to add a container as a service (CaaS) platform on top of the exiting VIM (see Figure 4). This means that Cloud Native Computing Foundation (CNCF)-certified Kubernetes will be deployed in virtual machines over an Openstack-based infrastructure as a service (IaaS). This is an attractive alternative for those with stable working horizontal cloud platforms with many VNFs as it offers an easy evolution to SA 5G core, multi-vendor VNF and CNF with full MANO and security.
Option 2: An alternative deployment option is to deploy CNFs over a bare metal infrastructure to leverage the full benefits of cloud native transformation. This solution has no VIM and instead the Kubernetes-based, CaaS platform runs directly on the underlaying hardware.
We believe this will be the long-term solution, as it simplifies the architecture and uses the underlaying hardware more efficiently, with significant total cost of ownership (TCO) savings. Today, this solution will already be attractive for service providers who seek to move firstly towards a bare metal platform for their cloud-native applications. It may also be an alternative for those that still don’t have a unified virtualized core to expand upon.
The main benefits are: More efficient use of the hardware and a simpler architecture which gives better application performance and is easier to manage.
Fig. 3 Option 1, adding CaaS on top of the VIM to the current NFVI.
Fig 4. Option 2, Run CNFs over CaaS on bare metal.
The cloud-native infrastructure transformation journey
Based on our experience in deploying 5G Core networks with leading service providers around the globe, the most common scenario is a journey starting with a smaller virtualization with few VNFs, which is expanded to a multi-VNF horizontal NFVI with MANO for multi-vendor VNFs. This platform is then expanded with a CaaS layer to support 5GC and other CNFs. Figure 5 is schematic and will also apply for the distributed cloud and edge computing.Fig 5: Cloud native transformation journey and deployment options
Cloud-native applications design
Ericsson has adopted a framework of five principles that should be followed when designing cloud-native telecoms applications:
- Decomposed software
- Application resiliency
- State-optimized design
- Orchestration and automation
Platform agnostic. In the telecommunication industry, a cloud-native application or function (CNA /CNF) needs to be agnostic to the underlying infrastructure. This does not necessarily apply to the traditional cloud native players, like Netflix and Uber, as they control the full stack that they deploy their application on. The CNA /CNF needs to work on any service provider CaaS and should only require “vanilla Kubernetes” with no additional plug-ins. Regulatory emergency services etc. need to be supported.
Decomposed software. A fundamental principle of a cloud-native application is to decompose software into smaller, more manageable pieces, known asaka micro services. Each microservice has a well-bounded scope and can now be individually deployed, scaled and upgraded using a CaaS environment like Kubernetes. In addition, microservices communicate through well-defined and version-controlled network-based interfaces.
A microservice architecture allows independent scaling, based on the need by each microservice. It will scale linearly if the infrastructure provides needed resources like CPU, memory, storage and networking.
Application upgrade becomes the automated and orchestrated upgrade of its microservices.
Application resiliency. Previously, local 1+1 resiliency and geo-redundancy have been sufficient for physical network functions (PNFs) due to the design of hardware. In cloud environments, this is not enough, as one must consider the (much shorter) aggregated MTBF of hardware, virtual machines (VMs) and containers.
Therefore, a CNA/CNF should support any combination of failures at any time, without escalation to full restart and loss of service.
State-optimized design. The best way to manage state or data must be decided based on the type, and the application context within which it is handled. The lifetime of states can vary significantly, from milliseconds to days or even months.
CNA/CNF automation. Cloud-native applications are automated, thereby automating the life cycle of the internal microservices that make up the application through service discovery, load distribution etc. to enable scaling, healing and in-service updates and upgrades.
A CNA/CNF must expose performance and fault management information to an external management system to allow for model-driven configuration management and network-level use cases like a 3GPP network slice.
Continuous ways of working: CI/CD
In the telecom environment, it’s not usual for the software vendor to both develop and operate the application; rather, the vendor delivers software to multiple service providers that operate the application. This means that the telecoms software pipeline needs to support three phases: continuous integration, continuous delivery and continuous deployment (CI/CD/CD) – rather than two (CI/CD).
Automated pipelines have the potential to solve many challenges of the software life cycle. Through staging multi-vendor systems in multiple phases, the increase in network and system complexity can be mitigated and the cost of integration can be managed.
Fig 6. Telecom phasing of software pipelines (CI/CD/CD) and merging multiple vendors
In summary: advanced 5G services + cloud-native infrastructure = TRUE
To conclude, the evolution to 5G standalone will require a cloud-native infrastructure. Since this is a multi-year journey that will require several changes to the network architecture as well as tools for automation and management processes, it’s important to get started sooner than later.
Do you want to know more about cloud-native infrastructure evolution and cloud-native design principles?
Download the guide to deploying a cloud-native platform for 5G:
Download the guide to cloud native design and operations principles:
Want to know more?
This post is part of our guide to building a cloud-native 5G Core blog post series, where we outline six strategic areas that form the foundation to a cloud- native core network capable of unleashing the full potential of 5G. Investing time in these topics will make you better equipped to plan, deploy and manage your new network for business success.
Stay tuned for the coming blog posts which will dive into other key topic areas.
Read the previous articles of the serie:
Read about Network automation
Read more about Core network
Like what you’re reading? Please sign up for email updates on your favorite topics.Subscribe now
At the Ericsson Blog, we provide insight to make complex ideas on technology, innovation and business simple.