# Cloud Native 5G Core

## Summary


5G Core has been standardized as a composition of many Network Functions (NFs) that expose their services via RESTful APIs. This is called Service-Based Architecture (SBA). To implement/deploy such a core, cloud-native is an architectural approach that's becoming increasingly popular. It brings benefits to both vendors and operators. Virtualization, containerization, microservices architecture and Kubernetes are some technologies that facilitate a cloud-native 5G Core. 

SBA addresses primarily the control plane. A cloud-native architecture should also consider the data plane and its performance. A cloud-native 5G Core should interwork with legacy architectures. Some operators may want a dual-mode core in which 4G EPC functions are also implemented in the cloud-native manner. 

Beyond the standardized NFs, a good cloud-native architecture should include provisioning, configuration, CI/CD, observability, scalability, security, and service orchestration.

## Discussion

### What's the cloud-native approach towards implementing 5GC?

The Cloud Native Computing Foundation (CNCF) has defined what cloud native means. Apps have to use the microservices architecture, that is, small independent components with cleanly defined interfaces. Microservices should be stateless whereby data is separated from the business logic. In 5G Core, unstructured data is stored in UDSF while structured data is stored in UDR. 

Via dynamic orchestration, containers can be created or destroyed at will. This leads to resilience and scalability. Immutable infrastructure is another attribute: it's easier to provision/deploy new resources than modify or upgrade existing ones. The system should be observable. To deliver features quickly, DevOps practices and CI/CD pipelines should be followed. 

Cloud-Native Functions (CNFs) are NFs realized using cloud-native principles and components. These are deployed using Kubernetes or any Containers-as-a-Service (CaaS) platform based on Kubernetes. Many CNFs can execute within the same Kubernetes cluster. 


### How does VNF differ from CNF?

Traditionally, costly proprietary hardware were used to build telecom networks. These are called Physical Network Functions (PNFs). With virtualization, network functionality could be deployed as Virtual Network Functions (VNFs) on cheaper commercial-off-the-shelf (COTS) hardware. Different VNFs could run on the same hardware. 

Whereas VNFs run on Virtual Machines (VMs), Cloud-Native Network Functions (CNFs) run inside containers. Containers are more lightweight than VMs. A container includes the application along with dependencies. All containers on a server share the same OS and resources. CNFs give operators more flexibility. Applications can be more easily scaled on demand or ported to different environments (development, staging, production). CNFs bring higher operational efficiency and better use of resources (compute, storage, networking).  

Just moving a legacy application into a container won't help. To realize the benefits of cloud native, applications have to be rearchitected into microservices. The standardization of SBA enables this. 


### How will VNFs coexist with CNFs?

Adoption of CNFs isn't going to be immediate. 5G Core networks are expected to include both VNFs and CNFs for some time to come. The NFV Orchestrator (NVFO) will interact with both Virtual Infrastructure Manager (VIM) and Kubernetes. 

CaaS can be deployed on IaaS (KVM, VMWare, etc). An alternative is to deploy CaaS directly on bare metal. The latter is less secure since it's easier to access host kernel space from host user space. However, the latter approach avoids the virtualization overhead. For better security via isolation, kata containers can be used while keeping the virtualization overhead minimal. 

Multiple CaaS (aka independent Kubernetes clusters) can be deployed over the same IaaS. In this case, CNFs in one cluster are isolated from those in another. This could be an alternative to kata containers on bare metal. 

CaaS themselves have evolved to supported legacy VM-based workloads. Using technologies such as KubeVirt or RancherVM, we can run VMs within a CaaS environment. 


### What are the benefits of going cloud native for the 5GC?

There are benefits for both vendors and operators. With cloud native, features can be developed and deployed faster. This can start small and then quickly scaled up across the network. Efficiency and performance are improved. Resources can be scaled up quickly and automatically to meet peak demands, and vice versa.  Resources can be deployed easily for a 5G feature called network slicing. 

Cloud-native is agnostic of platform or cloud provider. Apps become portable and there's less vendor lock-in. From a business perspective, operators benefit from cost optimization and faster innovation. 

It's insightful to see what characteristics bring these benefits. A cloud-native application is agnostic of the underlying infrastructure, which could be bare metal, IaaS, PaaS, or Kubernetes-based CaaS. Application is decomposed into microservices, each with its own software lifecycle. This bring agility, flexibility and efficiency. Deployment, observability and recovery are automated. Software as a whole is more resilient because non-responsive containers can be quickly replaced. This is because the microservices they contain are stateless. Application logic and state are cleanly separated. 


### What's the role of a service mesh in 5GC?

Since microservices have a dynamic lifecycle, this presents a new set of problems: service discovery, traffic management, security and policy management, and observability. Each application can address these concerns. A better solution is to abstract away such infrastructure logic into a separate component. This is what service mesh offers.  

Service mesh is a dedicated infrastructure layer for service-to-service communication. Each application is accompanied by a sidecar proxy container. Via these proxies, we can collect metrics or implement retries, timeouts, circuit breaking, load balancing, secure tunnelling, and service discovery. Service mesh includes both data plane and control plane. Istio, Linkerd and Consul are examples of service mesh. A service mesh can be part of the Kubernetes platform or embedded within each CNF. 

3GPP hasn't standardized the use of a service mesh. Instead, NF consumers use NRF to discover NF producers. When there millions of active service flows, NRF could get flooded with discovery requests. This can be mitigated by using SCP. NRF and SCP fulfil the role of a service mesh. 


### What are the challenges in making 5G Core cloud native?

Each vendor offers more than just the application logic of NFs. While an operator may aim for a multi-vendor solution, in-house integration is a challenge. At least for some NFs, the operator may adopt pre-integrated solutions. 

Cloud-native technologies were developed for the web/mobile services that expose REST APIs. They're not yet mature enough for telco-grade requirements of bandwidth, latency, availability and security. Telecom networks typical demand 99.999% availability. The twelve factors that characterize microservices-based web apps can't directly be applied to telecom. 

Adopting the cloud native approach requires change of mindset. Applications are no longer vertically integrated. Common functionality will be horizontally integrated at the platform layer. Neither vendors nor operators should feel they're losing control. Instead they should see the benefits of embracing cloud native. 

For the data plane, performance (throughput, latency, jitter) is a challenge. DPDK and VPP are solutions that bypass the kernel space and process data directly in the user space. Another approach called SR-IOV bypasses the hypervisor and gives multiple VNFs direct access to the same physical NIC. 


### Who has implemented cloud-native 5G Core?

Huawei's Telco Converged Cloud (TCC) is a cloud-native architecture. It's based on OpenStack and Kubernetes. It allows VMs and containers (within VMs or on bare metal) to coexist. For better resource utilization, it offers the Unified Resource Management layer. 

Ericsson offers a layer called Generic Services that includes load balancing, databases, observability, and FCAPS. For business logic, it offers Packet Core Controller and Packet Core Gateway.  It offers end-to-end management from deep edge sites to central sites. 

Samsung's 5G Core aims to be FAST: fast, agile, scale and tunable. With closed-loop automation they claim to achieve high operational efficiency. Orchestration, operations and analytics are centralized. Samsung identifies three types of microservices: NF-specific, common (eg. database, event), and OAM (eg. logging, tracing). It's competitive advantage comes from multi-interface, pod-based load balancer, geo-redundancy, inline upgrade, UPF packet acceleration (SR-IOV, OVS-DPDK) and open tracing. 

Among the open source offerings, there's some work happening to port Open5GS on Kubernetes and Free5GC on Kubernetes. As a cloud-native service platform, Kube5G offers CI/CD and operator workflows. Its alternative is 5G-Kube. 

## Milestones

Oct  
2012

At the SDN and OpenFlow World Conference, an introductory white paper titled *Network Functions Virtualization* is published. This triggers interest towards virtualization of telecom infrastructure. NFV enables Software Defined Networking (SDN). SDN advocates the separation of control and data planes. By now, some vendors are already offering virtualized versions of their proprietary software. However challenges remain in terms of interoperability, orchestration, performance, and stability. 

2013

**Docker** is released to build and manage containerized applications. It uses Linux kernel features to isolate processes. But for an app composed of dozens of containers, it quickly becomes clear that some sort of orchestration tool is needed. 

Dec  
2014

ETSI releases v1.1.1 of **NFV Management and Orchestration (NFV-MANO)**. 

2015

**Kubernetes 1.0** is released as a tool for container orchestration. At the same time, the **Cloud Native Computing Foundation (CNCF)** is formed with Kubernetes as its first project. 

Nov  
2017

5G PPP's 5G-MoNArch project publishes the document *5G Mobile Network Architecture*. This talks about a "cloud-enabled protocol stack" that's based on virtualization and orchestration. The term **telco cloud** is used although there's no mention of the term "cloud native". 

Jul  
2018

5G PPP publishes a white paper titled *From Webscale to Telco, the Cloud Native Journey*. It notes that future 5G networks can't ignore the cloud-native paradigm, which it summarizes as "the shift from the cloud ready to cloud native, from VM to container, from MANO to Kubernetes". They identify six features needed for telecom: multi-network interfaces, service function chaining, data plane acceleration, enhanced platform awareness, environment aware scheduling and multi-site support. 

May  
2019

The CNCF creates the **Telecom User Group (TUG)**. Under this group, telecom vendors and operators can collaborate for faster adoption of cloud-native. Some operators are deploying containers within VMs, which isn't the right way to containerize apps. There are also networking challenges that projects such as MULTUS, DANM and NSM are addressing. 

Dec  
2019

Early adoption of VNFs are disappointing because applications are not stateless or platform agnostic. Where CNFs are adopted, they run inside VMs. However, stakeholders realize Kubernetes on bare metal is the future. One trial shows that NF deploy time drops from 220 seconds under OpenStack to less than 30 seconds under Kubernetes. 

2020

Samsung offers a cloud-native 5G Core platform where both VNFs and CNFs can coexist. This enables seamless migration from VNFs to CNFs. It's working towards a multi-cloud solution. For example, core can be split between on-prime private cloud and remote public cloud. With a purely public cloud approach, user plane runs on AWS Outpost for performance reasons while the control plane runs centrally. MEC applications can be more easily deployed on public clouds. 

2022

While adoption of Kubernetes and CNFs is growing, it's expected that **VNFs and CNFs will coexist** for some time. Platforms are likely to support both. Huawei's Telco Converged Cloud (TCC) is an example, available since 2020. It supports both OpenStack-based VMs and Kubernetes-based containers. It also supports containers that can run within VMs or directly on bare metal. 

Nov  
2023

The Linux Foundation announces its intention to merge telecom-specific activities of the CNCF to those of the Linux Foundation's Networking group. Certification and test suites related to CNFs will be handled by the Linux Foundation.