F1 Demux Rolling Upgrade for Seamless 5G Traffic Handover
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing load balancers for F1-APP protocol in 5G networks are inefficient, requiring excessive CPU/RAM resources and adding latency, and there is a lack of seamless software upgrade solutions for microservices in dynamic cloud environments.
Innovation Solution
Implement a method for rolling upgrades of F1 demux instances within the CU-CP cluster, using Service Management and Orchestration (SMO) to create a new instance, redirect traffic, and establish Transport Network Layer (TNL) associations, ensuring minimal downtime and efficient load balancing across multiple backend pods.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If existing load balancers are used for F1-APP protocol in 5G networks, then traffic routing is provided, but CPU/RAM resources are excessively consumed and latency is added
Solution Approach 1:
The patent introduces an intermediary component (SMO-based traffic redirection mechanism) that mediates between the DU and the F1 demux instances. This intermediary manages the traffic routing and instance coordination without requiring heavy load balancer infrastructure, thus reducing CPU/RAM consumption while maintaining reliable traffic routing.
Solution Approach 2:
The patent uses multiple copies of the F1 demux microservice instance running in parallel within the same namespace. Traffic can be routed to different instances, providing load distribution without traditional load balancers. This copying approach reduces the need for resource-intensive load balancing hardware while maintaining system reliability.
2Adaptability or versatility
If traditional software upgrade methods are used for microservices, then version updates are achieved, but downtime occurs and service continuity is interrupted
Solution Approach 1:
The patent implements preliminary action by pre-deploying new versions of F1 demux instances alongside existing instances before traffic migration. The SMO coordinates the gradual transition, allowing the system to prepare for upgrades without interrupting service. This ensures software adaptability while minimizing downtime.
Solution Approach 2:
The patent maintains continuity of useful action by ensuring that at least one F1 demux instance (either old or new version) remains active and handling traffic throughout the upgrade process. The SMO manages traffic redirection to ensure continuous service operation, eliminating gaps in functionality during version transitions.
3Reliability
If traffic is redirected from old F1 demux to new F1 demux instance, then seamless upgrade is enabled, but traffic routing complexity increases
Solution Approach 1:
The patent implements self-service by enabling the SMO to automatically manage traffic redirection between old and new F1 demux instances without manual intervention. The system self-coordinates the upgrade process, dynamically adjusting traffic routing based on instance availability and health status. This automation reduces the perceived complexity while maintaining reliable seamless upgrades.
4Productivity
If multiple F1 demux instances run in parallel, then load balancing is improved, but resource management complexity increases
Solution Approach 1:
The patent applies universality by having multiple F1 demux instances perform the same function within the same namespace. Each instance is identical in capability and can handle traffic independently. The SMO manages these universal instances through standardized procedures, simplifying resource management despite the presence of multiple instances. This multi-functionality approach improves load balancing while keeping management complexity manageable.
Data Source
AI summary
A method is disclosed for providing a telecom microservice rolling upgrade, the method comprising: providing, by a Service Management and Orchestration (SMO), a new instance of F1 demux in a same cluster and namespace; advertising the new instance of the F1 demux to all PODs and micro services; informing, by the SMO, an old F1 demux to start a version upgrade to a new instance; sending, by the old F1 demux, a trigger to start a reconcile procedure to a new F1 demux; advertising that the old instance of the F1 demux is not available to take up new calls from internal PODs and micro-service, and is accepting traffic via the new F1 demux only; routing, by the old F1 demux, all incoming F1 traffic from a Distributed Unit (DU) to the new F1 demux; and instructing the DU, by the old F1 demux, to add a Transport Network Layer (TNL) association of the new F1 demux.


