Cloud Native 5G Core

Cloud-native 5G Core architecture. Source: Strategy Analytics et al. 2020, fig. 11.
Cloud-native 5G Core architecture. Source: Strategy Analytics et al. 2020, fig. 11.

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?
    VMs versus containers for telecom. Source: Ericsson 2018, slide 17.
    VMs versus containers for telecom. Source: Ericsson 2018, slide 17.

    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?
    Evolution from PNFs to VNFs to CNFs. Source: Red Hat 2022.
    Evolution from PNFs to VNFs to CNFs. Source: Red Hat 2022.

    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?
    CaaS with VMs, containers and kata containers. Source: Ericsson 2018, slide 21.
    CaaS with VMs, containers and kata containers. Source: Ericsson 2018, slide 21.

    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?
    SCP mediates communication between NF producer and NF consumer. Source: Strategy Analytics 2021, fig. 4.
    SCP mediates communication between NF producer and NF consumer. Source: Strategy Analytics 2021, fig. 4.

    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?
    Cloud native needs a change of mindset. Source: Strategy Analytics et al. 2020, fig. 3.
    Cloud native needs a change of mindset. Source: Strategy Analytics et al. 2020, fig. 3.

    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?
    Samsung's cloud-native 5G core architecture. Source: Samsung 2020a, fig. 4-3.
    Samsung's cloud-native 5G core architecture. Source: Samsung 2020a, fig. 4-3.

    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
Vision for NFV. Source: ETSI 2012, fig. 1.
Vision for NFV. Source: ETSI 2012, fig. 1.

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
Developments leading to the formation of CNCF and cloud native stacks. Source: 5G Americas 2019, fig. 2.1.
Developments leading to the formation of CNCF and cloud native stacks. Source: 5G Americas 2019, fig. 2.1.

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
Evolution to cloud native in telecom. Source: 5G Americas 2019, fig. 4.3.
Evolution to cloud native in telecom. Source: 5G Americas 2019, fig. 4.3.

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's proposal of 5G Core multi-cloud deployments. Source: Samsung 2020b, fig. 2-6.
Samsung's proposal of 5G Core multi-cloud deployments. Source: Samsung 2020b, fig. 2-6.

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
Huawei's Telco Converged Cloud architecture supports both VNFs and CNFs. Source: Huawei 2020.
Huawei's Telco Converged Cloud architecture supports both VNFs and CNFs. Source: Huawei 2020.

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.

References

  1. 5G Americas. 2019. "5G and the Cloud." White paper, 5G Americas, December. Accessed 2023-12-15.
  2. 5G PPP. 2018. "From Webscale to Telco, the Cloud Native Journey." White paper, v1.0, 5G PPP, July 4. Accessed 2023-12-29.
  3. AWS. 2023. "What is Cloud Native?" AWS. Accessed 2023-12-29.
  4. Arouk, O., and N. Nikaein. 2020. "Kube5G: A Cloud-Native 5G Service Platform." GLOBECOM 2020, IEEE Global Communications Conference, aipei, Taiwan. pp.1-6, December. doi: 10.1109/GLOBECOM42002.2020.9348073ff. Accessed 2023-12-18.
  5. BasuMallick, C. 2022. "What Is a Cloud Native Network Function (CNF)? Meaning, Architecture, and Examples." Spiceworks, December 7. Accessed 2023-12-18.
  6. Crippa, M. R (ed). 2017. "5G Mobile Network Architecture." Deliverable D2.1, 5G-MoNArch project, 5G PPP, November 6. Accessed 2023-12-29.
  7. ETSI. 2012. "Network Functions Virtualisation." White paper, SDN and OpenFlow World Congress, October 22-24. Accessed 2023-12-29.
  8. ETSI. 2014. "GS NFV-MAN 001: Network Functions Virtualisation (NFV); Management and Orchestration." V1.1.1, December. Accessed 2023-12-29.
  9. Ericsson. 2018. "Cloud Native Tutorial." Slides, Ericsson. Accessed 2023-12-18.
  10. Ericsson. 2018a. "Cloud Infrastructure for 5G." Ericsson, July 30. Updated 2022-12-02. Accessed 2023-12-15.
  11. Ericsson. 2021. "Telstra’s journey to a cloud-native 5G Core." Ericsson, September 10. Updated 2022-09-23. Accessed 2023-12-15.
  12. Gangwal, G. and K. Gray. 2023. "The 5G Core Network Demystified." Blog, Dell Technologies, August 18. Accessed 2023-12-18.
  13. Huawei. 2020. "Next-Generation Telco Cloud Based on Cloud Native." Huawei, August 4. Accessed 2023-12-18.
  14. Hung, C. and D. Kohn. 2019. "CNCF Telecom Users Group (TUG)." Slides, CNCF. Accessed 2023-12-29.
  15. Kundattil, F. and I. Meirick. 2022. "Istio Usage in 5G Core CNFs." Presentation, IstioCon, April 25-29. Accessed 2023-12-29.
  16. Meyer, D. 2023. "Linux Foundation wants to defragment telecom CNF efforts." SDxCentral, November 16. Accessed 2023-12-29.
  17. NGMN Alliance. 2021. "Cloud Native Enabling Future Telco Platforms." v5.2, NGMN Alliance, May 17. Accessed 2023-12-18.
  18. RCR Wireless News. 2022. "Telcos are moving increasing to cloud-native functions." RCR Wireless News, August 3. Accessed 2023-12-29.
  19. Red Hat. 2019. "What is NFV?" Red Hat, August 16. Accessed 2023-12-28.
  20. Red Hat. 2022. "VNF and CNF, what’s the difference?" Red Hat, July 28. Accessed 2023-12-18.
  21. Samsung. 2020a. "5G Core Vision: Samsung 5G Core Vol.1." Technical Report, Samsung. Accessed 2023-12-18.
  22. Samsung. 2020b. "Cloud Native 5G Core: Samsung 5G Core Vol.2." Technical Report, Samsung. Accessed 2023-12-18.
  23. Scotece, D., A. Noor, L. Foschini, and A. Corradi. 2023. "5G-Kube: Complex Telco Core Infrastructure Deployment Made Low-Cost." IEEE Communications Magazine, vol. 61, no. 7, pp. 26-30, July. doi: 10.1109/MCOM.006.2200693. Accessed 2023-12-18.
  24. Strategy Analytics. 2021. "5G Signaling and Control Plane Traffic Depends on Service Communications Proxy (SCP)." White paper, Strategy Analytics. Accessed 2023-12-29.
  25. Strategy Analytics, Inc., HPE, and Intel. 2020. "5G Integration, Operations In A Multivendor, Container-based Architecture." White paper, Strategy Analytics, HPE, and Intel. Accessed 2023-12-15.
  26. Susnjara, S. 2023. "The history of Kubernetes." Blog, IBM, November 2. Accessed 2023-12-29.
  27. TelecomTV. 2022. "The evolution of network functions from VNF to CNF." TelecomTV, on YouTube, September 21. Accessed 2023-12-28.

Further Reading

  1. 5G Americas. 2019. "5G and the Cloud." White paper, 5G Americas, December. Accessed 2023-12-15.
  2. 5G PPP. 2021. "View on 5G Architecture." White paper, v4.0, 5G PPP, August 2. Accessed 2023-12-18.
  3. NGMN Alliance. 2021. "Cloud Native Enabling Future Telco Platforms." v5.2, NGMN Alliance, May 17. Accessed 2023-12-18.
  4. AWS. 2020. "5G Network Evolution with AWS." White paper, AWS, July. Accessed 2023-12-15.
  5. Sugiyama, H. 2019. "Kubernetes Native Infrastructure and Operator Framework for 5G Edge Cloud Computing." Presentation, Open Source Summit, Tokyo, Japan, July 17-19. Accessed 2023-12-15.
  6. Apostolakis, N., M. Gramaglia, and P. Serrano. 2022. "Design and Validation of an Open Source Cloud Native Mobile Network." IEEE Communications Magazine, vol. 60, no. 11, pp. 66-72, November. doi: 10.1109/MCOM.003.2200195. Accessed 2023-12-18.

Article Stats

Author-wise Stats for Article Edits

Author
No. of Edits
No. of Chats
DevCoins
Avatar of user arvindpdmn arvindpdmn
2
0
1426
DevCoins due to articles, chats, their likes and article hits are included.
1999
Words
1
Authors
2
Edits
0
Chats
3
Likes
1301
Hits

Cite As

Devopedia. 2023. "Cloud Native 5G Core." Version 2, December 30. Accessed 2024-06-25. https://devopedia.org/cloud-native-5g-core
Contributed by
1 author

Last updated on
2023-12-30 05:37:03