PaperlayerView exact revision on arXiv

Source-linked AI summary

ORION: Intent-Aware Orchestration in Open RAN for SLA-Driven Network Management

Gabriela da Silva Machado, Gustavo Z. Bruno, Alexandre Huff, Jose Marcos Camara Brito, Cristiano B. Both

arXiv:2603.03667v1cs.NI

TL;DR

O-RAN intent management lacks an integrated path from high-level goals to assured, enforceable policies. ORION uses LLM-assisted MCP services, a CAMARA schema, and O-RAN control functions to orchestrate intent translation and enforcement. Policy-generation success reaches 100% for several evaluated models, while the conclusion reports a cost-optimized model with 97% success.

  • Problem

    Existing intent-based approaches lack an integrated O-RAN lifecycle spanning clarification, validation, deployment, and continuous adaptation with SLA-preservation guarantees.

    Source: §I · p. 1

  • Method

    ORION combines LLM-assisted intent handling through MCP, CAMARA’s NetworkSliceBooking schema, and O-RAN SMO/Non-RT and Near-RT RIC functions for policy generation and enforcement.

    Source: §I · p. 1

  • Results

    100% policy-creation success was achieved by Claude Opus 4.5, Gemini 3 Pro, and GPT-5; GPT-5 Nano achieved 97%.

    Source: 3) Policy Creation Success · p. 9

  • Takeaways & Limitations

    The conclusion reports that GPT-5 Nano offers a cost-optimized alternative at 97% success and that semantic processing latency is confined to the SMO layer.

    Source: §VII · p. 12

Abstract

from arXiv · show

The disaggregation of the Radio Access Network (RAN) introduces unprecedented flexibility but significant operational complexity, necessitating automated management frameworks. However, current Open RAN (O-RAN) orchestration relies on fragmented manual policies, lacking end-to-end intent assurance from high-level requirements to low-level configurations. In this paper, we propose ORION, an O-RAN compliant intent orchestration framework that integrates Large Language Models (LLMs) via the Model Context Protocol (MCP) to translate natural language intents into enforceable network policies. ORION leverages a hierarchical agent architecture, combining an MCP-based Service Management and Orchestration (SMO) layer for semantic translation with a Non-Real-Time RIC rApp and Near-Real-Time RIC xApp for closed-loop enforcement. Extensive evaluations using GPT-5, Gemini 3 Pro, and Claude Opus demonstrate a 100% policy generation success rate for high-capacity models, highlighting significant trade-offs in reasoning efficiency. We show that ORION reduces provisioning complexity by automating the complete intent lifecycle, from ingestion to E2-level enforcement, paving the way for autonomous 6G networks.

I. INTRODUCTION

O-RAN openness increases operational coordination demands, while existing intent-based approaches lack an integrated O-RAN lifecycle with end-to-end assurance. ORION aligns LLM-assisted intent handling with O-RAN roles and interfaces, and the paper evaluates its prototype and intent-translation pipeline.

I. INTRODUCTION

  • Disaggregation and openness increase operator coordination demands across rApps, xApps, SLAs, SLOs, and end-to-end observability.Source: §I · p. 1
  • Existing intent efforts lack an integrated O-RAN lifecycle spanning clarification, validation, deployment, and adaptation with strong SLA-preservation guarantees.The paper asks how intent-enabled O-RAN management can preserve network quality and SLA compliance.Source: §I · p. 1
  • ORION structures slice requests with CAMARA’s NetworkSliceBooking schema and aligns intent capture with the SMO, Non-RT RIC, and Near-RT RIC.The architecture combines LLM-assisted intent capture with validation and policy composition before A1/E2 enforcement.Source: §I · p. 1
  • The prototype combines MCP services and O-RAN-compliant control functions to operationalize provisioning and activation.Source: §I · p. 1
  • The paper provides 100 natural-language intents mapped to eMBB, URLLC, and mMTC slice types and QoS parameters for translation-fidelity benchmarking.Source: §I · p. 1
  • The evaluation examines LLM cost-performance trade-offs, policy-creation success, tool-use reliability, resource overhead, latency, translation fidelity, and generated-policy correctness.Source: §I · pp. 1–2

II. BACKGROUND

This section establishes the O-RAN control structure, distinguishes desired outcomes from enforcement rules, and describes an auditable intent lifecycle with closed-loop assurance.

A. O-RAN Architectural Elements

  • O-RAN separates long-horizon Non-RT RIC optimization from Near-RT control, with A1 carrying guidance and E2 carrying telemetry and fine-grained actions.The SMO hosts rApps, while the Near-RT RIC hosts xApps; coordination across interfaces and heterogeneous data models remains challenging.Source: A. O-RAN Architectural Elements · p. 2

B. Policies vs. Intents

  • Intents declare desired outcomes while policies encode reactive “if/when → do” actions; translation maps KPI goals into policies and monitoring queries.Frameworks must address feasibility, conflicts, measurability, and drift while maintaining consistent policy sets.Source: B. Policies vs. Intents · p. 2

C. Intent Lifecycle

  • The lifecycle moves through Create, Activate, Monitor/Assure, Modify, Suspend, and Terminate, with auditable transitions and corrective CLA feedback loops.When monitored KPIs deviate, CLA can trigger policy re-translation or operator notification; modifications can prompt re-translation or rollback.Source: C. Intent Lifecycle · pp. 2–3, Figure 1 · p. 2

D. Roles in Intent-Driven RAN

The section outlines intent ownership and execution roles, introduces MCP’s client-server tool access, and surveys standards and research approaches to intent-driven RAN management. It identifies an O-RAN-native end-to-end pipeline with long-term assurance as an area not yet fully instantiated by the prototype.

D. Roles in Intent-Driven RAN

  • The RMIO owns intent goals and lifecycle decisions, while the RMIH interprets submissions, coordinates fulfillment, and performs assurance.The RMIH’s dependency graph supports targeted updates when a KPI threshold changes, rather than recomputing the entire intent mapping.Source: D. Roles in Intent-Driven RAN · p. 3

E. Model Context Protocol

  • MCP connects AI assistants to external tools and data through a host, client, and server that discovers and executes requested operations.Source: E. Model Context Protocol · p. 3

III. RELATED WORK

  • Standards define intent semantics and lifecycle roles, while research spans natural-language, template, and standards-based representations and several translation approaches.The surveyed literature converges on declarative goals, repository-backed translation, and mult timescale control, but no work provides the complete O-RAN-native ingestion-to-CLA pipeline described in the review; ORION’s prototype covers ingestion to E2 enforcement, with long-term CLA left for future work.Source: §III · pp. 3–5
  • Prior work varies in O-RAN alignment and slicing scope, and many prototypes emphasize initial fulfillment over long-horizon assurance, conflict reconciliation, and rollback.Source: §III · p. 4

IV. PROPOSED ARCHITECTURE: ORION

ORION bridges natural-language intents and deployable RAN policies by pairing an LLM-assisted MCP client/server with O-RAN control functions and a canonical slice-intent schema.

IV. PROPOSED ARCHITECTURE: ORION

  • ORION couples an LLM-assisted MCP client/server with Non-RT/SMO and Near-RT RIC control functions, using CAMARA’s NetworkSliceBooking schema to structure slice intents.Source: §IV · p. 5

A. Design Objectives

ORION targets SLA-aware, modular, O-RAN-compliant intent orchestration, with roles distributed across the SMO and RICs. Its workflow validates structured intents, composes policies, deploys them through A1 and E2, and monitors for adaptation.

A. Design Objectives

  • ORION’s five objectives are SLA-aware automation, modularity, SMO/RIC role alignment, strict O-RAN compliance, and extensibility beyond slicing.Examples of additional use cases include energy saving; the design aims to preserve latency, throughput, and reliability KPIs.Source: A. Design Objectives · p. 5

B. High-Level Architecture Overview

  • The MCP Client uses domain tools from an MCP Server to structure operator intents with CAMARA’s NetworkSliceBooking schema before policy creation.The rApp derives SLA targets and composes policy parameters; the xApp translates resource needs into PRB quotas using real-time cell capacity and enforces control through E2.Source: B. High-Level Architecture Overview · p. 5, Figure 2 · p. 5

C. Component Details

  • The MCP Server checks intent completeness, consistency, and feasibility against CAMARA’s API, while ambiguities prompt clarification before policy composition.The client maintains conversation state and guardrails; the server’s translator returns structured results and separates API logic and credentials from the model prompt.Source: C. Component Details · pp. 5–6

D. End-to-End Intent Workflow

  • ORION’s lifecycle proceeds through ingestion, CAMARA-schema translation, validation, rApp composition, A1 deployment and E2 enforcement, then KPI-triggered recomputation, updates, or rollback.The xApp monitors key performance metrics and can request recomputation or rollback when deviations are detected.Source: D. End-to-End Intent Workflow · p. 6, C. Component Details · p. 6

E. Extensibility and Standards Alignment

ORION maps operator and service roles to O-RAN management roles and can generalize its workflow by swapping schemas and policy templates. The prototype implements the intent interface and supporting services as containerized components.

E. Extensibility and Standards Alignment

  • ORION assigns the operator or service the RMIO role and the MCP Client and rApp the RMIH role, aligning intent management with SMO/Non-RT and A1/E2 control.The workflow can extend to energy saving or load balancing by swapping tools and policy templates without changing its core.Source: E. Extensibility and Standards Alignment · p. 6

V. IMPLEMENTATION AND PROTOTYPE

  • The proof of concept implements the creation and activation phases, validating translation from natural-language intent into enforceable policies.The prototype integrates a generative-AI orchestration agent with O-RAN components in containerized microservices.Source: §V · p. 6

A. Frontend (Streamlit)

  • A Streamlit interface accepts natural-language intents, preserves conversation state across sessions, and sends requests asynchronously to the MCP Client’s /intent endpoint.The interface renders user interaction as distinct conversation bubbles.Source: A. Frontend (Streamlit) · p. 6

B. Service Management and Orchestration

  • The FastAPI MCP Client integrates multiple LLM providers and uses server-sent events to execute tools exposed by the Python MCP Server.The server’s create_session tool forwards Pydantic-validated arguments to the Slice API.Source: B. Service Management and Orchestration · p. 6

C. Large Language Model

  • The LLM first selects a tool from the natural-language intent, then classifies traffic such as eMBB or URLLC from session parameters.A strict system prompt prohibits using minimum values unless specified.Source: C. Large Language Model · p. 6

D. CAMARA Mock API

  • The CAMARA mock API’s POST /sessions endpoint accepts Network Slice Booking requests conforming to OpenAPI 3.0.3 schemas.In-memory admission control rejects requests with HTTP 429 when active sessions exceed a predefined threshold.Source: D. CAMARA Mock API · pp. 6–7
  • Figure 3 is identified as the Non-RT RIC intent execution flow.The provided caption does not specify the flow’s steps.Source: Figure 3 · p. 7

E. Orion rApp (Non-RT RIC)

The Non-RT RIC rApp converts structured intent into SLA objectives and A1 policy payloads, while the Near-RT xApp translates those objectives into resource allocations. The described SMO workflow passes a CAMARA-validated intent to the rApp for policy generation.

E. Orion rApp (Non-RT RIC)

  • The rApp derives target QoS metrics, including throughput, latency budgets, and packet error rates, and emits an A1 policy containing slice scope and SLO objectives.The policy’s slice_type tag lets the xApp select a scheduling discipline, such as Earliest Deadline First for URLLC or Proportional Fair for eMBB.Source: E. Orion rApp (Non-RT RIC) · p. 7

F. SMO/Non-RT RIC Workflow

  • The SMO workflow sends natural-language intent through the MCP Client and CAMARA booking tool, then returns confirmed session parameters for LLM-generated JSON and rApp policy generation.The CAMARA API performs admission control and allocates resources before returning a Session ID and confirmed QoS parameters.Source: F. SMO/Non-RT RIC Workflow · p. 7

G. Orion xApp

  • The Near-RT xApp dynamically translates received Non-RT policies’ SLA objectives into resource allocations.It retrieves target E2-node configuration, including bandwidth, numerology, and MIMO layers, to determine maximum cell capacity; its control messages enforce slice boundaries at the scheduler.Source: G. Orion xApp · pp. 7–8

H. E2 Simulator (E2Sim) (e2sim-rc)

The e2sim-rc prototype emulates a gNB that accepts slice-level PRB quota control and checks allocations against cell capacity. The Near-RT workflow encodes xApp control messages for E2 nodes and reports operation status to the Non-RT RIC.

H. E2 Simulator (E2Sim) (e2sim-rc)

  • The e2sim-rc extends OSC E2Sim to emulate a gNB with E2SM-RC resource control and rejects requests that exceed total cell PRB capacity.It advertises Control Style 2 and Action ID 6 for slice-level PRB quota during E2 Setup.Source: H. E2 Simulator (E2Sim) (e2sim-rc) · p. 8

I. Near-RT RIC Workflow

  • The xApp converts SLA parameters into E2SM-RC control messages, sends them to an E2 node, and reports operation status to the Non-RT RIC via an A1 Policy Response.The workflow includes node inventory lookup, capacity validation, scheduler update, and an acknowledgement on successful configuration.Source: §I · p. 8

VI. EVALUATION

  • The evaluation examines LLM policy-generation reliability, model cost-performance trade-offs, slice-type classification accuracy, and orchestration latency and resource overhead.It also evaluates translation fidelity and correctness of generated policies for representative slicing scenarios.Source: §VI · p. 8

A. Experimental Setup

ORION is evaluated on a 100-intent workload spanning three 3GPP slice types, using six LLMs to translate intents into A1 policies. Token use varies across providers, with Gemini producing substantially more output tokens than Anthropic and OpenAI models.

A. Experimental Setup

  • The 100-intent dataset contains 20 eMBB, 20 URLLC, and 60 mMTC scenarios, pairing operator prompts with structured slice-type and QoS ground truth.The workload is weighted toward mMTC to represent heterogeneous, large-scale IoT endpoints.Source: A. Experimental Setup · p. 9

B. LLM Cost-Performance Analysis

  • Six models from Anthropic, Google, and OpenAI processed identical eMBB, URLLC, and mMTC intents through the SMO for A1 policy translation.The testbed ran the SMO, Non-RT and Near-RT RICs, and RAN simulation components on a Kubernetes cluster with 12 vCPUs and 23 GiB RAM.Source: B. LLM Cost-Performance Analysis · p. 9, A. Experimental Setup · p. 9

1) Token Consumption Patterns:

  • 15,090 input tokens (Gemini 3 Flash) to 27,306 (GPT-5) span a 1.8× difference; Gemini models produce 2,394–2,418 output tokens versus 154–775 for Anthropic and OpenAI models.Gemini’s higher output consumption is attributed to verbose chain-of-thought responses.Source: 1) Token Consumption Patterns · p. 9, Figure 5 · p. 9

2) Reasoning Token Allocation:

Models differ in reasoning-token allocation, policy-creation success, and API cost. Several achieve near-perfect policy-generation success, while the cost comparison shows that price does not track success rate.

2) Reasoning Token Allocation:

  • 21–23% of total tokens are explicit reasoning tokens for Gemini models, compared with 2.4–4.9% for GPT-5 variants; Anthropic reasoning tokens are not exposed by its API.The unavailable Anthropic metric prevents direct comparison of its internal deliberation overhead.Source: 2) Reasoning Token Allocation · p. 9, Figure 6 · p. 9

3) Policy Creation Success:

4) Cost-Performance Tradeoff:

  • 156× separates Gemini 3 Flash at 0.19 cents/intent from Claude Opus 4.5 at 29.68 cents/intent, and cost does not correlate with success rate.GPT-5 Nano costs 0.49 cents/intent and achieves 97% success, compared with Gemini 3 Flash at 0.19 cents/intent and 85.7% success.Source: 4) Cost-Performance Tradeoff · p. 10, Figure 8 · p. 10

5) Slice-Type Classification Accuracy:

Slice-type classification and schema-aware tool-use scoring assess different aspects of intent translation. The results show high classification accuracy among models that reliably produce predictions, but tool-use quality also depends on schema adherence and serialization.

5) Slice-Type Classification Accuracy:

  • 99% slice-type accuracy for Claude Opus 4.5 and 96% for GPT-5 lead the reported results; among models with ≥97% prediction rates, accuracy spans 90–99%.Gemini 3 Flash is 100% correct on its 66 predictions, but its 66% prediction rate limits overall accuracy.Source: 5) Slice-Type Classification Accuracy · p. 10, Figure 9 · p. 10

6) MCP Tool-Use Quality Assessment:

  • MCPUseMetric scores 600 test cases on tool selection, argument structure, and value fidelity, using a judge model rather than an expected-output comparison.The evaluation uses the system prompt, user intent, and MCP server tool schema; its judge is Claude Opus 4.5 at temperature 0.Source: 6) MCP Tool-Use Quality Assessment · pp. 10–11
  • 0.85 for Claude Opus 4.5 and 0.82 for GPT-5 Nano are the highest mean MCPUseMetric scores; GPT-5 averages 0.75, while Gemini 3 Pro and Flash score 0.36 and 0.28.GPT-5 is penalized for populating an unspecified upstream delay field; Gemini models score poorly amid redundant calls and truncated arguments, while Sonnet often refuses optional fields.Source: 6) MCP Tool-Use Quality Assessment · p. 11, Figure 10 · p. 11

C. Resource Consumption Analysis

ORION’s custom intent applications use little CPU and memory relative to the RIC platforms, while processing latency is concentrated in SMO-side LLM work. The conclusion reports high policy-generation success for selected models and leaves local LLM evaluation and full closed-loop assurance for future work.

C. Resource Consumption Analysis

  • The system draws approximately 141 millicores and 8.5 GiB RAM; Orion rApp and xApp consume 1.5 ± 0.3 m and 0.4 ± 0.0 m CPU, respectively, with memory under 40 MiB.The Non-RT RIC averages 76.4 ± 3.4 m CPU and approximately 7.1 GiB memory; the Near-RT RIC averages 37.1 ± 4.6 m CPU and 1.1 GiB memory.Source: C. Resource Consumption Analysis · p. 11, Figure 11 · p. 12

D. End-to-End Latency Analysis

  • SMO intent-to-policy translation and MCP tool execution contribute most of the end-to-end delay, while Near-RT RIC and E2 Node processing remains low-variance and deterministic.The reported xApp and E2 control operations execute within sub-second/millisecond ranges required for RAN optimization.Source: D. End-to-End Latency Analysis · pp. 11–12, Figure 12 · p. 12

VII. CONCLUSION

  • GPT-5 Nano delivers 97% policy-generation success at a fraction of inference cost, while ORION imposes negligible RIC resource overhead and keeps semantic processing latency in the SMO.The conclusion also reports that Near-RT control loops remain deterministic.Source: §VII · p. 12
  • Local LLM deployments and fully instrumented closed-loop assurance are future work, including telemetry-triggered intent modification and rollback.The planned local-model evaluation will assess inference latency, privacy compliance, and reasoning capability against cloud-hosted models.Source: §VII · p. 12

Related papers

Loading 2603.03667v1…