Virtualized RAN Hot PHY Clones for Disruption-Free Workload Migration

Resolve Bottlenecks,
Find Innovative Solutions
Generate 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

VSEngineering 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

Engineering Contradiction:
Improvehandling server failuresVSAvoidmigration time
Core Design Contradiction:
ReliabilityVSLoss of time

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.

Inventive Principle:
Principle #10Preliminary action

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

Engineering Contradiction:
Improvedynamic reconfiguration capabilityVSAvoidsoftware complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

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.

Inventive Principle:
Principle #24Intermediary (Mediator)

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.

Inventive Principle:
Principle #26Copying

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

Engineering Contradiction:
Improvehigh availabilityVSAvoidmigration implementation complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

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.

Inventive Principle:
Principle #10Preliminary action

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.

Inventive Principle:
Principle #26Copying

Data Source

PatentUS12388748B2Creating elasticity and resiliency in virtualized RANs
Publication Date: 2025.08.12 MICROSOFT TECHNOLOGY LICENSING LLC
  • US12388748B2 patent drawing
  • US12388748B2 patent drawing
  • US12388748B2 patent drawing

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.