US-20260129483-A1 - MICROSERVICES FOR CENTRALIZED UNIT USER PLANE (CU-UP) AND CENTRALIZED UNIT CONTROL PLANE (CU-CP) STANDBY PODS IN A CLOUD-NATIVE FIFTH GENERATION (5G) WIRELESS TELECOMMUNICATION NETWORK

Abstract

Example embodiments are directed towards detecting a failure of one or more microservices of a CU-UP pod or a CU-CP pod running on a first cloud compute instance within a node group of a cluster. In response to the detection of a failure of one or more microservices of a CU-UP pod or a CU-CP pod of a node group within a cluster being hosted on a first cloud compute instance, the system automatically switches to run the one or more microservices for which failure was detected on a standby pod running on a second cloud compute instance with user equipment (UE) context corresponding to the one or more microservices for which failure was detected. The standby pods running on the other cloud compute instance are generated with anti-affinity between the CU-CP microservices of the primary CNF instance and CU-CP microservices of the standby pod.

Inventors

• Dhaval Mehta
• Sourabh Gupta
• Gurpreet Sohi

Assignees

• Boost SubscriberCo L.L.C.

Dates

Publication Date

20260507

Application Date

20260102

Claims (9)

1. 1 . A method for failover of centralized unit user plane (CU-UP) and centralized unit control plane (CU-CP) cloud-native microservices in a fifth generation (5G) wireless telecommunication network, the method comprising: detecting a failure of one or more microservices of a CU-UP pod or a CU-CP pod running on a first cloud compute instance within a node group of a cluster; in response to the detection of a failure of one or more microservices of a CU-UP pod or a CU-CP pod of a node group within a cluster being hosted on a first cloud compute instance, automatically switching to run the one or more microservices for which failure was detected on a standby pod running on a second cloud compute instance with user equipment (UE) context corresponding to the one or more microservices for which failure was detected; and avoiding a dropped call by the automatically switching to run the one or more microservices for which failure was detected on the standby pod running the second cloud compute instance.
2. 2 . The method of claim 1 , further comprising: before the detection of the failure of the one or more microservices, generating the standby pod running on the second cloud compute instance with anti-affinity between the one or more microservices and microservices of the standby pod.
3. 3 . The method of claim 2 , wherein generating the standby pod running on the second cloud compute instance includes: generating the standby pod running on the second cloud compute instance within the node group of the cluster.
4. 4 . A system for failover of centralized unit user plane (CU-UP) and centralized unit control plane (CU-CP) cloud-native microservices in a fifth generation (5G) wireless telecommunication network, the system comprising: at least one memory that stores computer executable instructions; and at least one processor that executes the computer executable instructions to cause actions to be performed, the actions including: detecting a failure of one or more microservices of a CU-UP pod or a CU-CP pod running on a first cloud compute instance within a node group of a cluster; in response to the detection of a failure of one or more microservices of a CU-UP pod or a CU-CP pod of a node group within a cluster being hosted on a first cloud compute instance, automatically switching to run the one or more microservices for which failure was detected on a standby pod running on a second cloud compute instance with user equipment (UE) context corresponding to the one or more microservices for which failure was detected; and avoiding a dropped call by the automatically switching to run the one or more microservices for which failure was detected on the standby pod running the second cloud compute instance.
5. 5 . The system of claim 4 , wherein at least one processor executes the computer executable instructions to cause further actions to be performed, the further actions including: before the detection of the failure of the one or more microservices, generating the standby pod running on the second cloud compute instance with anti-affinity between the one or more microservices and microservices of the standby pod.
6. 6 . The system of claim 5 , wherein generating the standby pod running on the second cloud compute instance includes: generating the standby pod running on the second cloud compute instance within the node group of the cluster.
7. 7 . A non-transitory computer-readable storage medium having computer-executable instructions stored thereon that, when executed by at least one processor, cause the at least one processor to cause actions to be performed, the actions including: detecting a failure of one or more microservices of a CU-UP pod or a CU-CP pod running on a first cloud compute instance within a node group of a cluster; in response to the detection of a failure of one or more microservices of a CU-UP pod or a CU-CP pod of a node group within a cluster being hosted on a first cloud compute instance, automatically switching to run the one or more microservices for which failure was detected on a standby pod running on a second cloud compute instance with user equipment (UE) context corresponding to the one or more microservices for which failure was detected; and avoiding a dropped call by the automatically switching to run the one or more microservices for which failure was detected on the standby pod running the second cloud compute instance.
8. 8 . The non-transitory computer-readable storage medium of claim 7 , wherein the computer-executable instructions, when executed by the at least one processor, cause the at least one processor to cause further actions to be performed, the further actions including: before the detection of the failure of the one or more microservices, generating the standby pod running on the second cloud compute instance with anti-affinity between the one or more microservices and microservices of the standby pod.
9. 9 . The non-transitory computer-readable storage medium of claim 8 , wherein generating the standby pod running on the second cloud compute instance includes: generating the standby pod running on the second cloud compute instance within the node group of the cluster.

Description

TECHNICAL FIELD The present disclosure relates generally to telecommunication networks, more particularly, to microservices for CU-UP and CU-CP standby pods in a cloud-native 5G wireless telecommunication network. BRIEF SUMMARY It is advantageous to provide Fifth Generation (5G) wireless technology in a highly available, flexible manner that avoids or reduces network outages and dropped calls experienced by ends users. It is with respect to these and other considerations that the embodiments described herein have been made. 5G provides a broad range of wireless services delivered to the end user across multiple access platforms and multi-layer networks. 5G is a dynamic, coherent and flexible framework of multiple advanced technologies supporting a variety of applications. 5G utilizes an intelligent architecture, with Radio Access Networks (RANs) not constrained by base station proximity or complex infrastructure. 5G enables a disaggregated, flexible and virtualized RAN with interfaces creating additional data access points. 5G network functions may be completely software-based and designed as cloud-native, meaning that they're agnostic to the underlying cloud infrastructure, allowing higher deployment, agility and flexibility. With the advent of 5G, industry experts defined how the 5G core (5GC) network should evolve to support the needs of 5G New Radio (NR) and the advanced use cases enabled by it. The 3rd Generation Partnership Project (3GPP) develops protocols and standards for telecommunication technologies including RAN, core transport networks and service capabilities. 3GPP has provided complete system specifications for 5G network architecture which is much more service oriented than previous generations. Multi-Access Edge Computing (MEC) is an important element of 5G architecture. MEC is an evolution in cloud computing that brings the applications from centralized data centers to the network edge, and therefore closer to the end users and their devices. This essentially creates a shortcut in content delivery between the user and host, and the long network path that once separated them. This MEC technology is not exclusive to 5G but is certainly important to its efficiency. Characteristics of the MEC include the low latency, high bandwidth and real time access to RAN information that distinguishes 5G architecture from its predecessors. This convergence of the RAN and core networks enables operators to leverage new approaches to network testing and validation. 5G networks based on the 3GPP 5G specifications provide an environment for MEC deployment. The 5G specifications define the enablers for edge computing, allowing MEC and 5G to collaboratively route traffic. In addition to the latency and bandwidth benefits of the MEC architecture, the distribution of computing power is better enables the high volume of connected devices inherent to 5G deployment and the rise of IoT. The 3rd Generation Partnership Project (3GPP) develops protocols for mobile telecommunications and has developed a standard for 5G. The 5G architecture is based on what is called a Service-Based Architecture (SBA), which implements IT network principles and a cloud-native design approach. In this architecture, each network function (NF) offers one or more services to other NFs via Application Programming Interfaces (API). Network function virtualization (NFV) decouples software from hardware by replacing various network functions such as firewalls, load balancers and routers with virtualized instances running as software. This eliminates the need to invest in many expensive hardware elements and can also accelerate installation times, thereby providing revenue generating services to the customer faster. NFV enables the 5G infrastructure by virtualizing appliances within the 5G network. This includes the network slicing technology that enables multiple virtual networks to run simultaneously. NFV may address other 5G challenges through virtualized computing, storage, and network resources that are customized based on the applications and customer segments. The concept of NFV extends to the RAN through, for example, network disaggregation promoted by alliances such as O-RAN. This enables flexibility, provides open interfaces and open source development, ultimately to ease the deployment of new features and technology with scale. The O-RAN ALLIANCE objective is to allow multi-vendor deployment with off-the shelf hardware for the purposes of easier and faster inter-operability. Network disaggregation also allows components of the network to be virtualized, providing a means to scale and improve user experience as capacity grows. The benefits of virtualizing components of the RAN provide a means to be more cost effective from a hardware and software viewpoint especially for IoT applications where the number of devices is in the millions. The 5G New Radio (5G NR) RAN comprises of a set of radio base stations (each known as Next Generation N