Building an adaptable 5G Core on an open source container platform

In this post:

• We’ll explain the role of 5G and common challenges services providers face when building the 5G core.
• Walk through the components of a 5G solution stack.

5G aims to enable the delivery of highly immersive experiences for people and ultra reliable, low latency communication between devices. At the heart of each 5G network lies the 5G Core (5GC), with service providers needing to make several key decisions when building the 5G Core. 

Their platform should be able to support a wide range of use cases without adding operational complexities and cost. The proposed architecture conceives 5G Core as a set of disaggregated, cloud native applications that communicate internally and externally over well defined standard interfaces. 

Each 5GC component is implemented as a container-based application and is referred to as cloud-native network function (CNF). This requires the container platform to support functionalities and operational features like automated deployment, intelligent workload placement, dynamic scaling, hitless upgrades, and self healing. 

This post covers how to architect an open 5G Core solution with cloud-native technologies, focusing on an on-premise, stand-alone deployment approach. 

Role of 5G

5G is an evolution in wireless technologies that, in addition to supporting high broadband immersive services for consumers, enables high speed reliable communication between devices. 

These advanced services are made possible through enhancements to the radio access technologies and with the deployment of 5G Core, part of the 4G system as defined by the 3rd Generation Partnership Project (3GPP)—an umbrella term for a number of standards organizations which develop protocols for mobile telecommunications.

Note: 3GPP defines specs for radio access, core network and service capabilities. For this article we’re focusing on Rel. 15 Phase 1 of the spec, which is the first full set of 5G standards  covering a stand-alone 5G and a new radio system complemented by a next-generation core network.

Service providers face several challenges when building the 5G Core, with the platform of choice needing to support a variety of requirements, among them:

• Ease of deployment and operation: To reduce the complexities of deployment and operation, service providers need the solution to be cloud-native, support disaggregation and be highly automatable. 

• Cost effectiveness: In order for the core to be cost effective at scale, it needs to adopt best operational practices like GitOps framework and lend itself well to analytics and closed-loop automation.

• Security consciousness: The platform should include built-in security or integrated security tools. 

• Regulatory compliance: Telco remains a highly regulated industry, so the solution needs to comply with local regulatory requirements.

• Use case adaptability: In order to support a wide range of use cases, the network needs to satisfy varying requirements, e.g., creating end-to-end virtual networks each with its own custom latency, performance and bandwidth requirements on top of a shared infrastructure (network slicing).

The network slicing is a cornerstone of enabling a range of 5G services network operators are envisioning for the future. Each network slice operates as a virtual network over the shared infrastructure. 

When a network slice gets created, resources will be allocated at each layer of the stack to isolate and secure the slice and to deliver the performance, latency and other characteristics required for that slice. A network slice dedicated to one customer ideally will also have self-service capabilities for the customer to manage it. 

For telco service providers, the infrastructure needs to be flexible and scalable to meet the end customer requirements. The virtualized or containerized platform is necessary as it allows partitioning of common resources and dynamic instantiation of components. Providers also need a unified way of orchestrating, operating and monitoring the network at each layer of abstraction.

5G Core platform

5G Core is conceived as a set of disaggregated, cloud-native applications that communicate internally and externally over a set of well-defined standard interfaces. This means the associated life cycle events will follow standard continuous integration/continuous delivery (CI/CD) and GitOps patterns. This requires the platform to support functionality like automated deployment, intelligent workload placement, dynamic scaling, seamless upgrades and self healing.

5G Core architecture

Each component in the diagrams is implemented as a cloud-native application and is a CNF. Each CNF can be composed of multiple pods or microservices. Each component needs to comply with standards that allow interoperability between CNFs from different vendors, allowing service providers to mix and match solutions, and support the API calls that are necessary for interactions with the underlying platform components.

Adherence to cloud-native principles is crucial, enabling components to scale independently of each other, and their placement is determined dynamically by demands on the service and availability of resources.

Security can be implemented using Role Based Access Control (RBAC) mechanisms to manage user access and by applying pod security policies using Security Context Constraints (SCC) without the need for privileged containers, or requiring clusterwide admin access.

Proper life-cycle management can be achieved in a non-disruptive automated manner using common container orchestration tools like those built into Red Hat OpenShift. 

Logical solution view

Conceptually, the 5G solution stack can be categorized into: 

• Individual cluster components comprising platform-related cloud native components, 5G Core functions, 5G supplementary functions and 5G management functions.

• Shared cluster platform services.

• External services.

• External network infrastructure.

• Management and orchestration.

Note: Elements presented are the common architectural elements to provide conceptual guidance. 

5G Core technology stack

Dedicated cluster

The purpose of the dedicated cluster is to provide resources to the applications and the tools for the service provider to manage these applications. 

Containerized 5GC applications can be deployed by the service providers on-premise in their own datacenters on a horizontal cloud platform. Red Hat OpenShift Container Platform is well-suited for this purpose, supporting multiple applications from different vendors on the same infrastructure. 

It can be deployed on bare metal on top of certified hardware with a network underlay of the operator’s choosing. It also offers several options for integrated overlay networks, including Open vSwitch-based software-defined network (SDN) and third-party SDNs using Container Network Interface (CNI). Red Hat OpenShift also provides access to shared storage with Red Hat OpenShift Data Foundation or, alternatively, through supported third-party enterprise storage solutions that can be plugged in using Container Storage Interface (CSI). 

Cloud native components

Each OpenShift-based cluster provides components that are used by the applications or the service provider teams for Day 0, Day 1, and Day 2 operational tasks. They include:

• Kubernetes operators for life-cycle management of the platform and platform services. Application vendors may also provide operators for managing their application products.  

• Service assurance tools for logging and monitoring, which can be integrated with existing operations systems to provide visibility into the functioning of the platform and applications. 

• OpenShift Service Mesh for service discovery and exposure, and as a mechanism for specialized network handling, certificate management, etc.

• Integrated networking and storage interfaces providing access to the corresponding resources.

• Cluster console to provide visibility into an individual cluster configuration and status and the details of its workloads.

Additionally, each cluster includes built-in features for performance optimization, security, resiliency, etc., readily enabled through the use of Kubernetes operators and Kubernetes APIs.

5G Core functions

5G Core follows the control and user plane separation (CUPS) strategy that was introduced in 3GPP Release 14. CUPS decouples control and user plane functions, enabling data forwarding components to be decentralized.

• User Plane Function (UPF) is responsible for packet processing and traffic aggregation of user traffic. Since this functionality is decoupled from the control component, it can be placed closer to the network edge near the end user or device, increasing bandwidth efficiencies and resulting in higher data rates and lower latencies.

• Access and Mobility Management Function (AMF) and Session Management Function (SMF) are part of the control plane. AMF is responsible for handling connections and mobility management tasks while SMF handles session management. AMF receives connection and session-related info from the end devices, passing the session info to SMF, which establishes sessions by using UPF.

• Policy Control Function (PCF) provides a framework for creating policies to be consumed by the other control plane network functions. Examples include policies for QoS, network slicing management, and subscribers, applications, and network resources management. 

• Authentication Server Function (AUSF) provides authentication and Unified Data Management (UDM) ensuring user identification, authorization and subscription management.

5G supplementary functions

• Network Repository Function (NRF) is used by AMF to select the correct SMF out of the available pool.

• NRF and Network Slice Selection Function (NSSF) work together to support network slicing capabilities. 

• Network Exposure Function (NEF) exposes 5G services and resources so third-party apps can more securely access 5G services.

• Application Function (AF) exposes an application layer for interacting with 5G network resources, retrieving resource info from PCF and exposing them. 

5G management function

Most complex telco applications, such as 5GC, include their own management component responsible for the application’s life cycle: provisioning, configuration, scaling, updates, etc. This component would be application-specific, and depending on the vendor implementation, would interact with the platform and the application over open or proprietary API interfaces. This component is optional and its functionality might be rolled into the Orchestrator or implemented using Operators.  

Shared services

Common cluster-external services can be shared across multiple clusters and are not application-specific. They provide such things as shared storage, underlay networking, container image repositories for platform and application images, DevOps or GitOps pipelines, and automation tools. 

External services

Common datacenter services applicable to network applications running on cloud platforms would include Domain Name Service (DNS), identity management, and Network Time Protocol (NTP).

External network infrastructure

This component of the solution stack includes key network infrastructure capabilities such as security, load balancing and datacenter fabric.

Management and application orchestration

Management and orchestration allows dynamic scaling of end-to-end 5G solution, across multiple clusters with automation.

What’s next?

As described, this post provided an overview of the common generic elements that make up the 5G Core architecture blueprint. Future posts could take a more detailed look at interaction between various 5G Core solution components that allow service providers to adapt and distribute or place them to meet business requirements as well as to scale the 5G Core on-demand. 

Learn more about Red Hat OpenShift, the enterprise Kubernetes application platform trusted by more than 2,000 organizations.

Check out Red Hat Portfolio Architecture Center for an entire catalog of solutions that are all built off of successful customer deployments for telecommunications, media, and entertainment (TME) service providers.