By Ajay Thakur with Alan J Weissberger

Abstract:

In this article, we endeavor to clarify some of the critical issues and questions related to implementing a cloud native 5G SA core network and how it differs from the traditional core network composed of hardware devices and software solutions. It’s important to note that NONE of the 3GPP defined 5G features can be realized without a 5G SA core. Those include: Network Automation, Network Function Virtualization, 5G Security, Network Slicing, Multi-Access Edge Computing (MEC), Policy Control, Network Data Analytics, etc.

Communication Service Providers (CSPs) will need to do things differently (than 4G) in order to implement and use a 5G cloud native SA core. Various cloud native 5G SA core aspects include network planning, deployment, software upgrades, network monitoring, hardware and platform upgrades.

These will be examined and contrasted with traditional implementations, such as the 4G Evolved Packet Core (EPC).

Introduction:

3GPP introduced 5G SA core network architecture in release 15. Since then numerous new features (work items) have been introduced to specifications. 3GPP’s 5G SA’s specifications use virtualization and cloud native principles as the foundation. A few key 3GPP Technical Specifications (TSs) for 5G system are the following:

• TS 22.261, “Service requirements for the 5G system”.
• TS 23.501, “System architecture for the 5G System (5GS)”
• TS 23.502 “Procedures for the 5G System (5GS)
• TS 32.240 “Charging management; Charging architecture and principles”.
• TS 24.501 “Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3”
• TS 38.300 “NR; NR and NG-RAN Overall description; Stage-2”
• TS 23.527 “5G System; Restoration procedures Stage-2”

5G SA tries to resolve the challenges faced by network operators in the EPC deployments and how those challenges can be mitigated with new design.

Several important changes in the 5G SA core are support for a Service Based Architecture and Cloud Native implementation of 5G SA core. That will enable new 5G features and functions like Network Slicing, 5G Security, and MEC, among others.

To reap the benefits of Cloud Native SA, CSPs are required to adapt to new cloud native principles of network deployment, operation and monitoring. We shall examine various aspects of Life Cycle Management of 5G SA software and also ask some open ended questions on each aspect.

SBA architecture Diagram with multiple Interfaces:

• The Network diagram above shows the SBI interfaces in case of roaming. Each of the individual NF may be composed of one more micro-services. Each NF may come from different vendor. Since these NFs are available in containerized format, they may or may not share the same container orchestration platform.

Network Dimensioning:

• 5G SA solves the network expansion problem since the network can be scaled up/down by adding/removing commercial off the shelf hardware.
• Once we have all the NFs software releases available, operators can gather the compute, memory & network requirements for deployment.
• Operators would rely on auto scaling functionality provided by the 5G NF vendors to avoid over provisioning at the start. This is relatively much simpler compared to adding dedicated hardware for NF in case of EPC.

Deployment Options Selection/Planning

• Operators need to decide the type of deployment for the network like the 5G SA deployment on public cloud or on private cloud.
• Along with Public vs Private cloud decisions, the Operator also needs to decide on a Container orchestration engine. Container orchestration can be managed service or operator managed service. Popular container orchestration engine is Kubernetes (K8s).
• Next step would be to finalize or select one of the CI/CD tools which works for all the vendors and integrate that with the container orchestration platform.
• Also placement of the NFs needs to be decided, e.g. User Plane Function (UPF) could be on-prem close to RAN. It’s possible that the operator may place some of the RAN virtualized components in the cloud.
• These all are important decisions to be made before getting into the real deployment of the software.
• Some of the aspects here are due to Cloud Native 5G SA and were not applicable for EPC.

CI/CD:

• CI/CD landscape (https://landscape.cncf.io/) from CNCF shown in below Figure

• It can be seen from the CNCF project that there are many projects which are available for CI/CD
• Irrespective of Public or Private cloud, operators need to follow cloud native CI/CD principles for deploying the Core Network in the Cloud environment. CI/CD involves taking the software release from the vendor and running it against existing network functions and carrying out some minimum tests and once operator is satisfied with evaluation of the release then rollout the release in the network.
• Operators can decide to have a separate staging environments where new releases can soak for a certain period of time while few subscribers use the new release.
• CI/CD gives the option of rolling back the release if the operator is not happy with the performance of the new release.
• Now the challenge here would be, will the operator have single CI/CD tools used for deploying all the vendors’ solution OR would the operator use its own CI/CD tooling and integrate NFs from vendor it in its own environment. This is the decision the operator needs to take.
• Having Automated CI/CD infrastructure which takes the software releases from the vendors and passes it through multiple environments and all the way to the production environment is key.
• Without having an appropriate CI/CD environment it would be very difficult to manage all micro-services and their deployments.
• Public Cloud may come with inbuilt CI/CD solutions and would be easy for operators to start with.
• AWS offers multiple services around CI/CD and those are listed here – https://docs.aws.amazon.com/whitepapers/latest/cicd_for_5g_networks_on_aws/cicd-on-aws.html
• Azure offering can be found here https://learn.microsoft.com/en-us/azure/devops/pipelines/apps/cd/azure/cicd-data-overview?view=azure-devops
• Google Cloud CI/CD services can be found here – https://cloud.google.com/solutions/continuous-integration

Software Upgrade:

• Cloud Native 5G SA allows operator to upgrade some of the components easily instead of complete 5G Core update in one go. CI/CD framework would help in the software upgrades with minimal human intervention.
• Note that with Cloud Native principles the operator would get multiple patch/minor releases and may be some major releases throughout the life cycle of the software. So the traditional approach of pulling down complete hardware & upgrading it with new software is not required for microservice based solutions. But this really works as long as all microservices are truly built stateless and supports live upgrade.
• As an operator, it would be required to know the impact of each upgrade package and prepare for rollback in case something goes wrong during the upgrade cycle.

Network Monitoring:

• Traditionally, operators developed their own Network Monitoring solutions to monitor the health of EPC since there was no standard mechanism to get the metrics, statistics from the NFs,
• 5G SA follows Cloud Native principles; it is easy to get the logs, statistics, alerts, alarms from all microservices in a consistent manner. There are common tooling used by most of the cloud native applications and CNCF has multiple projects in these categories.
• CNCF supported Monitoring projects are shown below figure

• • Tracing is important aspect to find out the bottleneck in the performance.

 

• Logging has been a traditional approach for debugging network issues. Below are the projects offered by CNCF in the logging area

• Public Cloud providers can extend the monitoring easily by generating Texts or email alerts as per CSPs needs.
• Operators can define their policies to retain the network performance monitoring output for a long time and can take backup of this easily through use of Public Cloud Providers data backup services.
• In the case of EPC these mechanisms were product dependent.
• Challenge in case of 5G SA would be each NF vendor may end up in using different tool and operators would have some challenges to converge all NF vendors to the common tooling.

Hardware & platform upgrade:

• In the traditional approach, providing hardware with updated operating systems and platforms was the responsibility of the equipment vendor. Now this responsibility has gone into either operator’s hand or sometimes in Public Cloud Provider’s hand. It depends on if the 5G SA is deployed on on-prem or on public cloud. Operators need to carefully plan for these upgrades without causing any downtime and of course follow the rolling upgrade patterns to avoid updating multiple entities at a time.
• If managed container orchestration is used, then these upgrades are seamlessly handled by Public Cloud Providers.

Vendor Lock In:

• In the case of EPC, vendor lock in was specific to NF & Radio Vendors. The 3GPP EPC specification allows the operators to swap NFs from one vendor with another and as long as NF supports the required Services. Point to note that this is less costly replacement compared to replacing one vendor with another vendor when NF had associated hardware.
• But with cloud native SA there is a chance that the operator may end up in building the tooling (CI/CD, monitoring etc.) over the period of time and this may lead to cloud provider lock in.

Conclusions:

The 5G SA core network provides a lot of flexibility and automation via cloud native deployments. However, the 3GPP 5G core specs contain a lot of implementation options, which network operators and their vendors must select to properly deploy a 5G core network. Making those decisions will likely require solid experience with operating applications on a cloud native platform. And that may be a reason that 5G SA core network rollouts have been so slow.

In the U.S. AT&T and Verizon have taken a very cautious approach to deploying their long ago promised 5G SA core networks. During the Brooklyn 6G Summit in November 2023, Chris Sambar, EVP for technology at AT&T said, ““I would say we are not moving as quickly as some of the other operators on the 5G standalone core, but we see the use cases that are coming, we understand when they’re coming, so we’re being very purposeful about getting there when we need to get there.” That’s despite AT&T outsourcing its 5G SA core network deployment to Microsoft Azure in June 2021. Yet Microsoft is the world’s second biggest cloud services provider with tons of experience running cloud native applications.

Summing up, Dave Bolan, Research Director at Dell’Oro Group wrote, “The buildout of 5G SA networks is going slower than anticipated which is restraining growth in the marketplace. To date, we count fifty 5G SA eMBB (enhanced Mobile BroadBand) networks that have been commercially deployed worldwide by Mobile Network Operators (MNOs). We counted 18 new 5G SA networks in 2022, but only 12 were launched in 2023. On a positive note, we believe a lot of work has been done in the background, preparing for 5G SA launches by Mobile Network Operators (MNOs) and we expect 2024 to have more launches than 2022.”

 

Ajay Lotan Thakur,  Cloud Software Architect at Intel and IEEE Techblog Editorial Team member

 

 

 

 

 

 

References:

Global 5G Market Snapshot; Dell’Oro and GSA Updates on 5G SA networks and devices

Ericsson Mobility Report touts “5G SA opportunities”

Analysys Mason: 40 operational 5G SA networks worldwide; Sub-Sahara Africa dominates new launches

Samsung and VMware Collaborate to Advance 5G SA Core & Telco Cloud

5G SA networks (real 5G) remain conspicuous by their absence

GSM 5G-Market Snapshot Highlights – July 2023 (includes 5G SA status)