Virtualized RAN Hot PHY Clones for Disruption-Free Workload Migration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current virtualized RAN deployments face challenges in dynamically reconfiguring RU-to-server mappings due to stringent real-time latency requirements and high software complexity, leading to user-visible disruptions during events like server failures or software upgrades.
Innovation Solution
Dynamically re-route layer traffic between servers using message transformations such as duplication and filtering, maintaining low-overhead 'hot, inactive' PHY clones to seamlessly migrate PHY workloads without modifying the vRAN software stack, and utilize external state stores for minimal inter-slot state migration.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If virtual machine migration is used to migrate PHY processing, then server failures can be handled, but the migration takes tens of milliseconds to seconds which causes severe user-visible disruptions
Solution Approach 1:
The patent pre-creates inactive PHY clones on standby servers before migration is needed. These clones are prepared in advance with the necessary configuration and state information, so when migration is triggered by a server failure, the clone can immediately become active without requiring time-consuming migration operations. This resolves the contradiction by performing the migration preparation work beforehand, reducing the actual migration time to meet strict TTI requirements.
2Adaptability or versatility
If custom migration logic is implemented in production-grade vRAN software stacks, then dynamic reconfiguration capability is achieved, but the complex and proprietary software becomes difficult or impossible to modify
Solution Approach 1:
The patent introduces an intermediary component called a message controller that sits between the L2 and PHY layers. This message controller handles the migration logic and message transformations, acting as a mediator that enables dynamic reconfiguration without requiring modifications to the complex proprietary vRAN software stack. The message controller translates and routes messages appropriately, allowing the system to achieve adaptability while keeping the core software unchanged.
Solution Approach 2:
The patent creates copies of the PHY layer (inactive PHY clones) that can be activated during migration. Instead of modifying the existing PHY implementation to add migration capabilities, the system creates duplicate PHY instances with the necessary state information. This copying approach enables dynamic reconfiguration while avoiding the need to modify the complex proprietary software, as the clones can be independently managed and activated.
3Reliability
If PHY processing is migrated between servers, then high availability is improved, but the stringent tail latency requirements of 500 μs TTIs make existing migration approaches inapplicable
Solution Approach 1:
The patent pre-creates inactive PHY clones on standby servers before migration is needed. These clones are prepared in advance with the necessary configuration and state information, so when migration is triggered by a server failure, the clone can immediately become active without requiring time-consuming migration operations. This resolves the contradiction by performing the migration preparation work beforehand, reducing the actual migration time to meet strict TTI requirements.
Solution Approach 2:
The patent creates copies of the PHY layer (inactive PHY clones) that can be activated during migration. Instead of modifying the existing PHY implementation to add migration capabilities, the system creates duplicate PHY instances with the necessary state information. This copying approach enables dynamic reconfiguration while avoiding the need to modify the complex proprietary software, as the clones can be independently managed and activated.
Data Source
AI summary
Methods and systems for dynamically re-routing layer traffic between different servers with little user-visible disruption and without modifications to the vRAN software stack are provided. For instance, transformations on messages between the L2 and PHY, such as duplication and filtering, enable the system to maintain one or more low-overhead “hot, inactive” PHY clones. A hot, inactive PHY clone may be a duplicate of an operational PHY, where the PHY clone is primed to process a PHY workload of the operational PHY (e.g., “hot”) but is not currently responsible for processing the PHY workload (e.g., low-overhead, inactive). In this way, a PHY workload may be automatically and seamlessly migrated to the hot PHY clone in response to planned downtime (e.g., scheduled maintenance, software upgrades) or unexpected events (e.g., server failures) within the strict transmission time intervals (TTIs) required for processing the PHY workload.


