PaperlayerView exact revision on arXiv

Source-linked AI summary

OrchestRAN: Network Automation through Orchestrated Intelligence in the Open RAN

Salvatore D'Oro, Leonardo Bonati, Michele Polese, Tommaso Melodia

arXiv:2201.05632v1cs.NIcs.AI

TL;DR

Open RAN makes network functions and analytics more flexible, but coordinating data-driven control and inference under timing, data, resource, and conflict constraints remains challenging. OrchestRAN automates model selection and placement in O-RAN, and its Colosseum prototype demonstrated application instantiation with reduced E2 control overhead.

  • Problem

    Open RAN intelligence orchestration must select models and locations that satisfy timing, input-data, resource, and control-conflict constraints.

    Source: §I · p. 2

  • Method

    OrchestRAN runs as a non-RT RIC rApp that selects models, determines execution locations, and dispatches O-RAN applications to meet operator intents.

    Source: §I · p. 2

  • Results

    2.6× reduction of control overhead over the O-RAN E2 interface was demonstrated on a network with 7 base stations and 42 users.

    Source: §I · p. 2

  • Takeaways & Limitations

    OrchestRAN demonstrated seamless instantiation of O-RAN applications with diverse timescale requirements at different network components.

    Source: §I · p. 2

Abstract

from arXiv · show

The next generation of cellular networks will be characterized by softwarized, open, and disaggregated architectures exposing analytics and control knobs to enable network intelligence. How to realize this vision, however, is largely an open problem. In this paper, we take a decisive step forward by presenting and prototyping OrchestRAN, a novel orchestration framework that embraces and builds upon the Open RAN paradigm to provide a practical solution to these challenges. OrchestRAN has been designed to execute in the non-real-time RAN Intelligent Controller (RIC) and allows Network Operators (NOs) to specify high-level control/inference objectives (i.e., adapt scheduling, and forecast capacity in near-real-time for a set of base stations in Downtown New York). OrchestRAN automatically computes the optimal set of data-driven algorithms and their execution location to achieve intents specified by the NOs while meeting the desired timing requirements. We show that the problem of orchestrating intelligence in Open RAN is NP-hard, and design low-complexity solutions to support real-world applications. We prototype OrchestRAN and test it at scale on Colosseum. Our experimental results on a network with 7 base stations and 42 users demonstrate that OrchestRAN is able to instantiate data-driven services on demand with minimal control overhead and latency.

I. INTRODUCTION

Open RAN enables flexible deployment and control of network functions, but orchestrating intelligence remains difficult because models must meet timing, data, resource, and conflict constraints. OrchestRAN automates model selection and placement; its Colosseum prototype demonstrates application instantiation with reduced control overhead.

I. INTRODUCTION

  • Orchestration must match model inputs and execution location to timing and resource limits while preventing multiple models from controlling the same parameter or functionality.Required inputs may be difficult to make available at a RIC within the needed time window.Source: §I · pp. 1–2
  • OrchestRAN runs as a non-RT RIC rApp, selecting models, avoiding conflicts, choosing execution locations, and embedding models in dispatched O-RAN applications.Placement accounts for timescales, resources, and data availability.Source: §I · p. 2
  • 2.6× reduction of control overhead over the O-RAN E2 interface was demonstrated in a 7-base-station, 42-user network.The prototype also enabled seamless instantiation of O-RAN applications with diverse timescale requirements.Source: §I · p. 2

II. RELATED WORK

  • Earlier orchestration frameworks targeted RAN resources and functionalities rather than the distinct problem of orchestrating network intelligence.Examples include resource allocation and component placement under latency and performance requirements,,,, [32],.Source: §II · p. 2
  • Prior model orchestration includes automated deployment on 5Growth and network-location selection for cloud-based inference.The latter is not concerned with O-RAN systems.Source: §II · p. 2
  • OrchestRAN focuses on O-RAN and supports both inference and control solutions, with model sharing to reuse network resources across requests.The authors describe it as the first large-scale demonstration tailored to O-RAN architecture and networks.Source: §II · p. 2

III. O-RAN: A PRIMER

O-RAN distributes functions across network nodes and uses RICs for control and model deployment at different timescales. OrchestRAN accepts operator intents, selects and dispatches applications, and represents infrastructure as a hierarchical network with node resources and reachability.

III. O-RAN: A PRIMER

  • O-RAN splits functions across CUs, DUs, and RUs; near-RT RIC xApps perform 10 ms–1 s operations, while non-RT RIC rApps act above 1 s.The non-RT RIC trains models and deploys models and policies to the near-RT RIC; OrchestRAN also supports RT applications on CUs and DUs.Source: §III · p. 3

IV. ORCHESTRAN

  • Operators specify desired functionalities, execution locations, and time constraints; OrchestRAN then selects models and placement, creates O-RAN application containers, and dispatches them.The Request Collector feeds requests to the Orchestration Engine, which consults the catalog and infrastructure abstraction.Source: §IV · p. 3, Figure 2 · p. 3

A. The Infrastructure Abstraction Module

  • The infrastructure abstraction groups nodes as non-RT RICs, near-RT RICs, CUs, DUs, and RUs, with reachability and resources represented on a tree.The non-RT RIC is the tree root and edge nodes are leaves; each non-RT RIC's domain includes only its controlled nodes.Source: A. The Infrastructure Abstraction Module · p. 3

B. The ML/AI Catalog

The ML/AI Catalog records models, their offered functionalities, input types, resource needs, suitability, performance, and instance limits. Network-operator requests specify desired functionalities and locations, performance and timing requirements, and data sources.

B. The ML/AI Catalog

  • Models in the catalog provide control or inference functionalities, including scheduling, beamforming, capacity forecasting, and handover prediction.Source: B. The ML/AI Catalog · p. 4
  • The catalog represents each model by the functionalities it offers, its required input type and resources, suitability and performance scores, and an instance limit per node.Suitability captures how well a model fits a functionality at a location; performance scores can use accuracy, mean squared error, or false-alarm probability.Source: B. The ML/AI Catalog · p. 4

C. Request Collector

  • Each request identifies required functionalities and nodes, minimum performance, maximum tolerated latency, and the nodes whose data must be used.Source: C. Request Collector · p. 4

D. The Orchestration Engine

The Orchestration Engine selects models and execution locations, then packages and dispatches applications to the selected network nodes. Connectors gather the specified input data and send control commands.

D. The Orchestration Engine

  • The engine selects suitable catalog models and execution locations, then converts the orchestration policy into applications dispatched to designated nodes.The process proceeds from model and location selection through container creation and dispatch to execution with RAN data.Source: D. The Orchestration Engine · p. 4
  • Each container combines a model with an application-specific connector that interfaces with its host node, collects specified data, and sends control commands.Source: D. The Orchestration Engine · p. 4
  • xApps subscribe to input data from specified nodes and use custom Service Models to interact with them over the E2 interface.Source: D. The Orchestration Engine · p. 5

V. THE ORCHESTRATION PROBLEM

The orchestration problem allows functionality outsourcing and model sharing, while selecting policies that accommodate requests subject to conflict and performance constraints.

V. THE ORCHESTRATION PROBLEM

  • Functionality can be outsourced to another node when it has the required data and resources and meets the request’s performance and timing requirements.Source: §V · p. 5
  • Sharing one model instance across requests with common functionality can reduce deployments; the example uses three models instead of four.Source: §V · p. 5

A. Formulating the Orchestration Problem

1) Quality of models:

  • The quality constraint enforces each request’s specified minimum or maximum model-performance level, depending on the request’s goal.Source: 1) Quality of models · p. 5

2) Control-loop time-scales:

The formulation constrains data collection and execution latency, available node resources, and request accommodation. It can also disable sharing when operators have privacy or business concerns.

2) Control-loop time-scales:

  • The policy must keep data collection and model execution within each request’s maximum latency constraint.Collection time depends on input size, link data rate, and propagation delay; execution time is also included in the combined latency constraint.Source: 2) Control-loop time-scales · p. 5
  • Applications’ resource consumption at each node cannot exceed the available resources of each type.Source: 2) Control-loop time-scales · p. 5
  • OrchestRAN maximizes the total value of accommodated requests by choosing which requests to satisfy, which models to instantiate, and where to run them.When all request values are one, the objective is to maximize the number of satisfied requests.Source: 2) Control-loop time-scales · p. 6
  • Operators can disable model sharing for privacy or business reasons by requiring each model instance to serve only one request.Source: 2) Control-loop time-scales · p. 6

B. NP-hardness of the Orchestration Problem

The orchestration problem is a Binary Integer Linear Programming problem and is NP-hard, as shown by a polynomial-time reduction from 3-SAT.

B. NP-hardness of the Orchestration Problem

VI. SOLVING THE ORCHESTRATION PROBLEM

The orchestration problem can become difficult to solve at scale because it has many optimization variables. Variable reduction removes variables that are always inactive, lowering complexity while preserving solution optimality.

VI. SOLVING THE ORCHESTRATION PROBLEM

  • A deployment with D = 20, M = 13, I = 10, F = 7, and Cmax = 3 involves approximately 10^6 optimization variables.The variable count grows primarily with |x|, which is O(IFD^2MCmax).Source: §VI · p. 6

A. Combating Dimensionality via Variable Reduction

  • Function-aware pruning removes variables when a request does not require a function or a model does not provide it.These variables are inactive and can be excluded from optimization.Source: A. Combating Dimensionality via… · p. 6
  • Architecture-aware pruning removes model-placement variables for nodes that cannot receive input from the relevant data source.Such nodes are disconnected, so the placement cannot be activated.Source: A. Combating Dimensionality via… · p. 6
  • After inactive variables are removed, the reduced optimization problem still guarantees an optimal solution.The new variable set excludes the function-aware and architecture-aware inactive variables.Source: A. Combating Dimensionality via… · p. 6

B. Graph Tree Branching

The proposed scalable solution partitions the infrastructure into smaller cluster subtrees and solves an orchestration subproblem for each cluster. Each subproblem uses only requests and nodes belonging to that cluster.

B. Graph Tree Branching

  • The orchestration problem has O(IFD^2MCmax) variables, so its variable count grows quadratically with the number of nodes.RUs, DUs, and CUs are identified as the major sources of complexity.Source: B. Graph Tree Branching · p. 6
  • The algorithm splits the infrastructure tree into cluster subtrees and creates a smaller orchestration instance for each subtree.Each instance considers only requests and nodes associated with its cluster.Source: B. Graph Tree Branching · p. 6
  • Each cluster subproblem includes requests involving only nodes in that cluster and is solved using Branch-and-Bound.A request accommodated in only some clusters is partially satisfied and violates Constraint 1.Source: B. Graph Tree Branching · p. 7

VII. NUMERICAL EVALUATION

Numerical evaluation shows that preprocessing and branching scale orchestration to larger networks, while model sharing improves resource use and request acceptance. Placement also shifts toward CUs, DUs, and RUs under tighter timing requirements.

Simulation setup

  • The simulations submit 20 randomly generated requests across a single-domain infrastructure with 1 non-RT RIC, 4 near-RT RICs, 10 CUs, 30 DUs, and 90 RUs.The six evaluated cases cover combinations of node types and timing requirements.Source: §VII · p. 7
  • The simulated catalog contains 13 models offering 7 functionalities; 10 take RAN metrics as input and 3 use RU IQ samples.The evaluation averages results over 100 independent simulation runs.Source: §VII · p. 7

Computational complexity

  • 0.1 s for 200 nodes and 2 s for 500 nodes yield optimal solutions with FP and AP preprocessing; branching takes under 0.1 s at 2,000 nodes but may partially satisfy requests.Preprocessing reduces optimization variables while preserving optimality; branching trades full satisfaction for faster computation.Source: Figure 5 · p. 7, §VII · p. 7

Acceptance ratio

  • ≈99% of requests are partially satisfied on at least one subtree with branching, allowing portions of otherwise rejected requests to be accommodated.The reported outcome is the probability of partial acceptance when using branching.Source: Figure 6 · p. 7, §VII · p. 8

Advantages of model sharing

  • 2× less resource use accompanies model sharing, which accommodates at least 90% of requests versus ≈70% without sharing.The comparison is between model sharing enabled and disabled.Source: Figure 7 · p. 8, §VII · p. 8

Model instantiation

  • ≈45% of models are allocated in RICs under delay-tolerant requirements, while ≈70% are instantiated at CUs, DUs, and RUs under low- or ultra-low-latency requirements.The distribution is reported for the ER case.Source: §VII · p. 8

VIII. PROTOTYPE AND EXPERIMENTAL EVALUATION

The Colosseum prototype demonstrates on-demand orchestration across the near-RT RIC and DUs. Experiments show reduced E2 traffic with DU execution and seamless application instantiation alongside differing slice-level outcomes.

Prototype

  • OrchestRAN runs in an LXC and dispatches models to near-RT RIC xApps or DU dApps; new control requests are generated every 4 minutes.The orchestration engine computes the policy and embeds models in the applications dispatched to execution nodes.Source: Figure 10 · p. 8, §VIII · p. 8

Experimental setup

  • The Colosseum setup uses 7 base stations and 42 UEs, with traffic distributed across eMBB, MTC, and URLLC slices.Users are randomly deployed; the base stations use a 10 MHz channel with 50 PRBs.Source: §VIII · p. 8

Prototype

  • The prototype's catalog includes four trained models for throughput and buffer forecasting and for network control; training-procedure details are omitted.The paper focuses on orchestrating pretrained models rather than their training procedures.Source: §VIII · pp. 8–9

Experimental results

  • Up to 2.6× less E2 traffic is reported when models run as DU dApps rather than only as near-RT RIC xApps.≈40% of E2 traffic carries payload information, with the remaining 60% consisting of overhead data.Source: Figure 11 · p. 9, §VIII · p. 9
  • ≈25% of models execute at the near-RT RIC when DUs can run dApps, while all models execute there in the RIC-only configuration.The remaining 75% execute as DU dApps in the configurations that allow them.Source: Figure 11 · p. 9, §VIII · p. 9
  • ≈10% higher slice-0 throughput and ≈2× more slice-1 transmitted packets occur with M4 than M3; on slice 2, M3 has higher buffer size while M4 lowers buffer size as its PRB ratio decreases.M4 can also control network slicing, unlike M3; the reported policy change does not interrupt service.Source: Figure 12 · p. 9, §VIII · p. 9

IX. CONCLUSIONS

OrchestRAN automates deployment of data-driven inference and control solutions across O-RAN nodes and timescales, with a Colosseum prototype demonstrating seamless instantiation and up to 2.6× lower E2 message overhead at the network edge.

Conclusion

  • OrchestRAN uses O-RAN specifications, RIC applications, and open interfaces to automate deployment of data-driven inference and control solutions with diverse timing requirements.Its orchestration algorithms offer different optimality and complexity trade-offs for non-RT, near-RT, and RT applications.Source: §IX · p. 9
  • On Colosseum, a 7-base-station, 42-UE prototype demonstrated seamless application instantiation across network nodes and timescales, with up to 2.6× lower E2 message overhead for edge intelligence.Source: §IX · p. 9

Related papers

Loading 2201.05632v1…