ConceptioArchivearXiv CS
arXiv CSopen access

C-RE-ACT: Causal RE-ACTing Agent for O-RAN Forensic Triage

Unknown · 2026 · arxiv_cs
arXiv CS · Papers · License: Open Access · 2026
Open Source ↗Direct PDF ↓
distributedsystemsprotocols
networking, internet, protocols, distributed systems

This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible.

C-RE-ACT: Causal RE-ACTing Agent for O-RAN Forensic Triage Pau Baguer1 , J. Xavier Salvat Lozano 2,3 , Gines Garcia-Aviles 1 , and Xavier Costa-Pérez 1,2,4 (Senior Member, IEEE) 2

1 i2CAT Foundation, 08034 Barcelona, Spain NEC Laboratories Europe GmbH, 69115 Heidelberg, Germany Universitat Autonoma de Barcelona, 08193 Barcelona, Spain 4 ICREA, 08010 Barcelona, Spain

3

CORRESPONDING AUTHOR: Gines Garcia-Aviles (e-mail: [email protected]).

arXiv:2607.25828v1 [cs.NI] 28 Jul 2026

This work was supported in part by the ORIGAMI Project under Grant 101139270; in part by the CERCA Programme from the Generalitat de Catalunya through the ICREA programme; and in part by the funding received from Department de Recerca I Universitats, Generalitat de Catalunya for this project

ABSTRACT The shift to Open RAN (O-RAN) architectures marks a turning point in cellular security,

where increased openness and modularity directly translate into a broader and more intricate attack surface, as disaggregated components and open interfaces introduce additional vectors for misconfiguration, failure, and exploitation. Among the security threats cataloged by the O-RAN Alliance Working Group 11, performance-degradation attacks constitute the largest class. These attacks induce packet losses and latency spikes that are hard to distinguish from operational events such as misconfigurations, transient congestion, or software regressions. Consequently, upon an adverse incident detection, support engineers must rapidly determine whether to route the corresponding incident ticket to network maintenance or escalate it to security operations. This triage phase represents a critical human-in-the-loop bottleneck in the incident response lifecycle. To address this vulnerability, we introduce C-RE-ACT (Causal REACTing agent), an automated agentic triage framework designed to generate actionable incident reports. C-RE-ACT starts constructing a Weighted Directed Acyclic Graph (WDAG) over O-RAN metrics using the Structural Agnostic Model (SAM). The resulting causal topology is encoded into a continuous soft token via a Graph Isomorphism Network (GIN) aligned with the language space of the Large Language Model (LLM) powering a ReAct agent. Reasoning over this embedded causal graph, the agent outputs structured triage reports to accelerate response times. We evaluate C-RE-ACT on a physical, O-RANcompliant testbed across 140 distinct performance-degradation experiments. Empirical results demonstrate the causal ranking isolates the correct root cause within the top three candidates in 89% of instances. Furthermore, graph soft-prompting improves LLM accuracy on causal-topology queries from 0.22 (textonly baseline) to 0.72. The autonomous agent achieves anomaly classification accuracies of 83% for delay anomalies and 84% for packet-loss anomalies. INDEX TERMS Agentic AI, Causal discovery, Incident Triage, Large Language Models, O-RAN Security

I. INTRODUCTION

The transition of current mobile networks towards the Open Radio Access Network (O-RAN) architecture [1]– [5] promises an open, virtualized, and disaggregated system with greater flexibility and cost efficiency. However, the disaggregation of traditional monolithic network functions into multiple separated components gives rise to a substantially more complex security landscape, with a greater number of

interacting components from (possibly) different providers and an expanded attack surface. This complex picture is compounded by the hierarchical, one-to-many topology of the O-RAN architecture: a single O-CU serves multiple ODUs, each of which in turn serves multiple O-RUs [6], [7]. Attacking interfaces higher in the network’s hierarchy (e.g. the F1-C or F1-U) can degrade service for an entire cluster of cells simultaneously.

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ VOLUME ,

1

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

This broader attack surface has prompted research efforts to secure exposed O-RAN interfaces [8]–[12], develop solutions to detect attacks [13], [14], and incorporate resiliency mechanisms that enable the RAN to recover from platform-level failures and compute contention [15], [16]. Among the different threats faced by O-RAN, performancedegradation attacks against O-RAN interfaces are the most prevalent threat category identified by the O-RAN Alliance Security Work Group (WG11): 60% of the risks catalogued in the WG11 Threat Modeling and Risk Assessment Technical Report involve Denial of Service or performance degradation [17], [18]. Despite their prevalence, investigating performancedegradation attacks is challenging because their observable consequences (e.g., high packet loss, increased latency, or higher connection drops) are indistinguishable from legitimate operational network management anomalies, including misconfigurations, software updates, or transient traffic congestion [16], [18]. While mobile networks incorporate multiple resiliency mechanisms such as redundancy and failover protocols, these defenses may be insufficient against silent compromises. When an attacker operates covertly without triggering conventional alarms, the system’s inherent resilience mechanisms may inadvertently mask the attack, allowing degradation to persist undetected. For instance, the authors in [12] demonstrate a covert manin-the-middle (MITM) attack against the O-RAN fronthaul interface, where an attacker positioned between the O-RU and the O-DU silently degrades the control plane without triggering conventional alarms. This attack vector might be difficult to distinguish from a faulty DU, as the loss of synchronization between the O-RU and O-DU triggers similar UE disconnections [18]. Notably, attacks targeting control and management interfaces (e.g., F1-C, E2, and O1) may be considerably harder to detect. Because these interfaces rely on TCP or SCTP, their inherent retransmission and connection-reset mechanisms can mask early signs of degradation. Furthermore, critical O-RAN control interfaces, such as the A1 interface, are susceptible to vulnerabilities that attackers can exploit to trigger performancedegradation attacks [19]. Such attacks can disrupt the closedloop control mechanisms upon which O-RAN relies for intelligent network optimization. Thus, Mobile Network Operators (MNOs) are increasingly placing greater responsibility on their Network Operations Center (NOC) analysts to triage incidents under uncertainty: determining whether a performance anomaly stems from an operational fault or a potential adversarial action, locating the implicated O-RAN components, and routing the ticket to the appropriate team for deeper investigation. Currently, to detect performance degradation events, MNOs continuously monitor a wide range of Key Performance Indicators (KPIs) (e.g., connection drop rates, cell throughput, handover success rates among others) over several-minute observation windows and typically rely on

2

threshold-based alarms or statistical anomaly detectors [20]– [23] to trigger resiliency mechanisms and open incident investigation tickets when persistent anomalies are observed. These systems flag that a KPI deviates, but they do not answer the key question that determines the incident response workflow: was the degradation caused by an adversary who has compromised the system, by a legitimate operational fluctuation, or by a malfunction?. This distinction is operationally decisive: it determines whether the ticket is escalated to the Security Operations Center (SOC) under the adversarial hypothesis or routed to the maintenance team as an operational fault. In this paper, we present C-RE-ACT, Causal RE-ACTing agent, an agentic system designed to serve as a critical first step in O-RAN incident diagnosis. C-RE-ACT constructs metric-derived causal graphs that capture the complex interdependencies among O-RAN components (O-RU, O-DU, OCU, and Radio Intelligent Controllers (RICs)). By encoding these causal graphs into continuous vector embeddings and leveraging an LLM-powered autonomous agent, CRE-ACT generates structured preliminary diagnostic reports that rapidly narrow the scope of the incident investigation. Rather than requiring NOC analysts to manually correlate disparate system metrics and hypothesize root causes, CRE-ACT automatically identifies the most likely suspect components and their probable failure causes, providing a focused entry point for deeper incident investigation. This initial triage significantly accelerates the incident diagnosis workflow by prioritizing which O-RAN components warrant detailed analysis, allowing analysts and downstream investigators to allocate their expertise and investigative resources efficiently during subsequent in-depth investigation phases. Our contributions are: 1) Agentic triage pipeline for O-RAN: We design CRE-ACT, the first agentic system that supports NOC analysts in deciding how to start investigating an incident ticket in an O-RAN cellular network. C-RE-ACT rapidly produces a structured report that recommends NOC analysts a few starting investigation points and helps them route the ticket. The agentic system uses a ReAct agent which iterates over a cognitive loop of interleaving reasoning and action, querying two specialized tools that turn raw O-RAN telemetry into triageready evidence. 2) Weighted causal graph construction. We adapt the Structural Agnostic Model (SAM) algorithm [24] to construct a weighted causal graph over O-RAN telemetry. Since cellular networks operate under nonstationary conditions driven by UE attachment dynamics, we introduce a confounder-penalized scoring scheme that ranks candidate root causes by their causal proximity to the failure while down-weighting metrics whose variations are explained by routine operational fluctuations. VOLUME ,

3) Graph soft-prompting for LLMs. Inspired by the GraphToken methodology [25], we encode an incident’s causal graph as a continuous soft token aligned with an LLM’s embedding space, allowing a frozen Llama-3.1-8B-Instruct to reason over the causal graph structure without textual serialization. We build the encoder using a Graph Isomorphism Network (GIN) pre-trained on GraphQA [26] and fine-tuned on OCIQA, our O-RAN Causal Inference QA dataset of 840 graph–question–answer triplets. This raises accuracy on causal-topology queries from 0.22 (zero-shot text baseline) to 0.72. 4) Empirical validation on a physical O-RAN testbed. We evaluate C-RE-ACT across 140 controlled experiments spanning four O-RAN interfaces (A1, E2, F1C, F1-U) and two impairment classes (packet loss and delay) at four different strength levels. II. BACKGROUND A. Open RAN architecture

The O-RAN Alliance specifies a disaggregated RAN architecture in which traditional base-station functions are distributed across three principal components. Fig. 4 illustrates the O-RAN architecture and its key interfaces. The O-RAN Radio Unit (O-RU) implements the low-level physical layer (low-PHY) functions. The O-RU connects to the O-RAN Distributed Unit (O-DU) via the Open Fronthaul interface, which carries IQ samples between the low-PHY and highPHY functions according to the O-RAN 7.2x lower-layer split. The O-DU hosts the high-PHY layer functions as well as the Medium Access Control (MAC) and Radio Link Control (RLC) layers. The O-RAN Central Unit (O-CU) supports the higher protocol layers, namely the Packet Data Convergence Protocol (PDCP), the Service Data Adaptation Protocol (SDAP), and the Radio Resource Control (RRC). The O-CU is further split into two logical entities: the OCU Control Plane (O-CU-CP) and the O-CU User Plane (OCU-UP). Beyond the RAN components, O-RAN introduces two Radio Intelligent Controllers (RICs) to enable datadriven, closed-loop optimization of the network. The nonReal-Time RIC (non-RT RIC) operates on timescales greater than one second and hosts rApps, which provide policy guidance, enrichment information, and machine learning (ML) model management. The near-Real-Time RIC (near-RT RIC) operates on timescales between 10 ms and 1 s, hosting xApps that perform fine-grained radio resource management and optimization.

1) O-RAN Interfaces

O-RAN standardizes the different interfaces between the components of the architecture. The interfaces relevant to this paper are the following: • F1 Interface: The F1 interface [27] connects the ODU to the O-CU and is split into two components. VOLUME ,

The F1-C (F1 Control) interface links the O-DU to the O-CU-CP, carrying signaling for RRC connection management, UE context setup and release, and paging. It relies on the F1 Application Protocol (F1AP) over SCTP for reliable signaling transport. The F1-U (F1 User) interface connects the O-DU to the O-CU-UP, transporting user-plane data encapsulated with the GTPU protocol over UDP/IP. The separation of F1-C and F1-U enables independent scaling and placement of control- and user-plane functions. • E2 Interface: The E2 interface [28] connects the nearRT RIC to the RAN nodes, referred to as E2 Nodes (e.g., O-CU-CP, O-CU-UP, O-DU). It enables the nearRT RIC to collect telemetry data from the RAN and to issue control actions in near-real time. The E2 interface is the primary channel through which xApps interact with the RAN to implement closed-loop optimization. • A1 Interface: The A1 interface [29] connects the nonRT RIC to the near-RT RIC. It serves three main functions: policy management, allowing the non-RT RIC to push high-level policies (e.g., QoS objectives, slicing requirements) to the near-RT RIC for enforcement; enrichment information, providing additional context such as analytics or predictions to enhance xApp decisionmaking; and ML model management, enabling the nonRT RIC to deploy and update ML models used by xApps in the near-RT RIC. III. INCIDENT RESPONSE ANALYSIS A. Incident Life-cycle Model

In this section, we describe how incidents are handled in cellular networks and frame the scope of C-RE-ACT. The O-RAN Alliance has not standardized an incident-response model; WG11’s security specifications, which cover threat modeling, security requirements, protocols, and testing [17] are positioned as inputs to operator-specific security operations processes rather than as a specified response workflow. Therefore, we adopt the general-purpose NIST SP 800-61 Rev. 2 [30] incident response model, instantiated for O-RAN cellular operations. The different incident response stages include the following steps: 1) Preparation: The first stage focuses on prevention: ensuring that all components involved in the system are secure before any incident occurs. Operations teams update the different O-RAN components and configure them according to security baselines, ensuring that systems are prepared in case an adverse event occurs. 2) Detection and analysis: The second step is the timely detection and accurate assessment of possible incidents. Determining whether an adverse event has occurred is an active research area in the mobile communications community [20], [23], [31], [32]. First-line anomaly detectors signal possible incidents that might be further investigated. The subsequent analysis proceeds in two stages: 3

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

a) Triage. The incident is classified. Two decisions are taken jointly: (i) severity scoring and (ii) routing to the corresponding team for investigation. C-RE-ACT targets the triage decision—the most consequential human-in-the-loop step of the incident-response lifecycle. b) Investigation and diagnosis. The team to which the ticket was routed performs an in-depth analysis: reproducing the event, identifying the faulty or compromised component, and determining the full downstream impact. 3) Containment, Eradication, Recovery: In this stage, the incident-handling team starts by containing the limits of the event by isolating the affected components if possible. Next, they try to eradicate the root cause from the system. This typically involves actions such as rolling back a recently pushed configuration or policy change, applying a vendor patch, or redeploying a degraded virtual instance from a known-good image. Finally, the handling team recovers the system, restores full service, and verifies that the system has stabilized. 4) Post-Incident Activity: Once service is restored, the team conducts a structured review that converts the incident into organizational knowledge [30]. A lessonslearned meeting consolidates the event timeline, the diagnostic steps taken, and the remediation applied, explicitly identifying what worked, what failed, and which tooling or data sources were missing at each stage. C-RE-ACT supports the triage stage by producing automated hints on where the investigation should start. The deep investigation itself, as well as remediation, remains the responsibility of the corresponding investigation team; the contribution of C-RE-ACT is to narrow the search space the NOC analyst enters, not to replace the analysis performed by downstream investigation teams. B. Adversary Model

The O-RAN Alliance WG11 Threat Modeling and Risk Assessment Technical Report [17] catalogues 56 risks across the seven O-RAN architectural domains, of which 34 are explicitly classified as performance- degradation or denial-ofservice threats. Within this scope, we consider an adversary pursuing two concurrent goals: (i) degrade the Quality of Service experienced by a subset of UEs, a single cell, or an entire cluster of cells served by a common upstream O-CU; and (ii) remain indistinguishable from benign operational faults, so that the incident is routed to the maintenance team rather than escalated to the security team. The second goal is what separates this threat class from overt denial-ofservice: the adversary optimizes for triage ambiguity rather than for maximum disruption, deliberately staying within loss and delay envelopes that are also produced by transient congestion, misconfiguration, or software regressions. A stealthy degradation absorbed into the maintenance queue 4

is operationally more valuable than a short, loud outage escalated within minutes. The adversary operates at two levels, which may be used individually or in combination: • Network-layer: The adversary induces packet loss or adds delay to the signaling and data flows of the A1, E2, F1-C, or F1-U interfaces, using mechanisms such as traffic flooding on shared transport, or queue manipulation on intermediate switches at the transport layer [12], [19]. Attack strength ranges from subtle (10% loss or 10 ms added delay) to complete link failure. The adversary does not hold root access on the RIC platform or on the monitoring infrastructure and cannot decrypt interface payloads. • Component-layer: The adversary controls a legitimate O-RAN component—a compromised or maliciouslyauthored xApp or rApp, a misbehaving O-DU image supplied by a lower-tier vendor, or a subverted CNF running on the O-Cloud—and manipulates the traffic that transits through it (by dropping, delaying, or reordering packets) without requiring access to encrypted payload contents. This level covers a significant fraction of the O-RAN Alliance WG11 high-severity threat identifiers [17] and a subset of the MITRE FiGHT 5G adversarial-technique catalogue [33]. IV. PROBLEM FORMULATION A. The Triage Problem

When a first-line anomaly detector flags a sustained KPI deviation in an O-RAN deployment, the NOC analyst receiving the ticket is not yet in a position to launch a deep investigation: the flagged symptom—a throughput drop, a spike in HARQ failures, a burst of UE disconnections— projects onto the radio layer regardless of where in the stack the underlying cause sits. Before any diagnostic effort is committed, the analyst must answer two coupled questions. Where in the deployment does the investigation start: which interface, which component, and over which sub-window of the flagged observation period? And how should the ticket be routed: to the maintenance team as an operational fault, or to the Security Operations Center (SOC) under the adversarial hypothesis of Sec. B? We call this combined decision the triage problem. Its output is not a diagnosis—the deep investigation remains the investigating team’s responsibility (Sec. A)—but a grounded starting point and a routing recommendation that collectively narrow the search space the engineer enters. The triage problem is hard precisely because the symptom distribution induced by the adversary of Sec. B overlaps with that of a heterogeneous and open set of benign conditions that occur routinely in production O-RAN deployments [18], [20]—misconfiguration of xApp policies or slicing parameters, transient congestion on shared transport, and latent software regressions revealed by upgrades are illustrative but not exhaustive. Each deployment, vendor mix, and release cycle introduces additional failure modes whose KPI VOLUME ,

footprints partially overlap with those of the adversarial ca- (C1) Telemetry volume and heterogeneity. O-RAN generates substantially more telemetry than monolithic RAN pabilities described above. The triage output must therefore — logs from distributed network functions, KPI timeremain well-calibrated in the presence of look-alikes without series, infrastructure metrics, and inter-component independing on a priori enumeration of them. teraction records — exceeding the context window of B. Mathematical Formulation recent LLMs even when serialized aggressively. We now state the triage problem that C-RE-ACT solves. (C2) Non-stationary metrics. The joint distribution of ORAN metrics shifts dynamically as UEs connect, Let the system be observed at discrete time steps idle, and disconnect, so legitimate operational changes t ∈ Z≥0 with sampling period ∆t, and let x[t] = can produce variations indistinguishable from attack(x1 [t], x2 [t], . . . , xd [t])⊤ ∈ Rd denote the multivariate obinduced degradation. servation vector at step t, aggregating d system metrics. Given an incident observation window [ts , te ) ⊂ Z≥0 of (C3) Causal reasoning across disaggregation. Determining whether a degradation originates from a single comlength Tw = te − ts flagged by a first-line anomaly promised component or from cascading failures across detector, C-RE-ACT consumes the windowed observation O-RU, O-DU, O-CU, and the RICs requires explicit W = (x[ts ], x[ts + 1], . . . , x[te − 1]) and produces a triage causal analysis over many fault-propagation paths, not report R. correlation alone. R = ⟨L, C, I, E, A⟩ (1) (C4) Latency and compute budgets. Triage sits on the critical path of the operator’s Mean Time To Recovery where: (MTTR), so prolonged diagnosis allows stealthy attacks • L is a ranked list of the metrics that deviated during to persist; at the same time, operational environments [ts , te ), ordered by causal proximity to the failure; impose strict compute limits that make full LLM fine• C and I are the lists of suspected components and tuning on continuously generated causal graphs prointerfaces, respectively, indicating where the analyst is hibitive. advised to start the investigation; (C5) LLM reasoning brittleness. Even within their context • E is a causal evidence chain — an ordered sequence window, LLMs suffer from positional bias [36], halluciof causally linked metric deviations connecting the nate on unfamiliar domains, and require lengthy prompt observed anomalous metrics to the suspect component engineering [37], [38] that aggravates context pressure. or interface; They also struggle with telecommunications vocabulary • A is the set of recommended diagnostic actions whose and structured modalities such as time series and packet execution helps determine which team should receive captures [39], [40]. the ticket. (C6) Iterative summarization is not a fix. Repeatedly A solution is acceptable when three criteria are jointly summarizing telemetry to fit the context window insatisfied: troduces generative randomness that can drop critical • Localization correctness. The ranked metric list L and signals [35], and large telemetry volumes overwhelm the suspected sets C and I agree with the groundsuch pipelines regardless. truth root-cause metric, component, and interface of the C-RE-ACT addresses these challenges through two design incident, measured through standard top-k accuracy on decisions. First, rather than prompting the LLM with raw the labeled evaluation set. telemetry, we construct a compact causal representation of • Evidence faithfulness. Every element of R must be the failure that surfaces likely root causes within a small grounded either in an observation contained in the context window, addressing C1–C3 and C5–C6 within the lawindowed observation W or in an edge of the causal tency budget of C4. Second, we ground the agent’s reasoning graph constructed from it. The report must contain no through a specialized graph encoder fine-tuned on the graph hallucinated evidence — a requirement that is nonmodality, training only very few parameters compared to the trivial for LLM-based systems [34], [35]. total LLM’s parameters and thereby satisfying the compute • Actionability. The recommended diagnostic actions in side of C4 alongside the brittleness in C5. A must be executable with standard maintenance tools (e.g., terminal commands) and specific enough to name the components from C and interfaces from I they V. C-RE-ACT A. System Model target. C-RE-ACT is designed as a post-detection triage stage C. Challenges and limitations that plugs into the existing observability stack of an ODesigning a triage system for O-RAN raises challenges from RAN operator. It does not replace any first-line anomaly two distinct sources: the operational environment in which detector, nor the in-depth investigation performed by a team the system runs and the constraints imposed by LLMs as the of operations or security engineers; rather, it sits between them and converts a set of persistent incident signals (i.e. underlying reasoning engine. VOLUME ,

5

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

anomalous Key Performance Indicators (KPIs)) into an initial triage report that aids the analyst in deciding where to start investigating and helps in classifying and routing incident tickets. Consistent with the incident model of Sec. A, the passive observability pipeline that supplies C-RE-ACT’s inputs, together with C-RE-ACT itself (its agentic tools and reasoning agent), forms the Trusted Computing Base (TCB); we assume the adversary cannot tamper with TCB outputs. The O-RAN components under analysis — xApps, rApps, O-DU, O-CU, RIC platform services, and their hosting OCloud nodes — lie outside this envelope and may be faulty, misconfigured, or compromised. C-RE-ACT is triggered when an upstream anomaly detector flags a sustained KPI deviation within a bounded observation window [ts , te ]. We assume that commercial mobile networks include resiliency mechanisms that allow the system to recover from many incidents autonomously [15], [16]. Thus, C-RE-ACT uses its agentic tools to process different metric representations during the incident window and produce the report R within the triage-stage latency budget (typically tens of seconds to a few minutes; measured in Sec. VI), providing NOC analysts with a grounded entry point for further investigation.

B. Agentic design

Generating the triage report R requires three different kinds of reasoning: quantitative ranking of the metrics that are causally closest to the failure; structural reasoning over a causal graph of metrics identifying interfaces, components, and propagation paths; and linguistic synthesis that composes the first two into an auditable report populated with ORAN domain knowledge. C-RE-ACT adopts an agentic architecture [41] that separates the three concerns. A ReActbased autonomous agent, implemented as a LangGraph [42] state machine, provides the linguistic synthesis and the highlevel control flow; two specialized tools, exposed to the agent through LangGraph’s tool-calling interface, provide the quantitative and structural primitives on which the agent reasons. The two tools correspond to the two sources of uncertainty in the triage problem: which metric, among the tens of correlated ones in the incident observation window, is the most proximate cause of the failure (Sec. C); and which interface or component the implicated metrics belong to in the deployment topology (Sec. D). The system prompt, reported in Appendix C, defines its persona as an expert O-RAN Site Reliability Engineer. The agentic workflow follows a three-phase triage protocol. • Identify: The agent uses the ranked_list_causes tool to retrieve a ranked list of metrics causally closest to the failure node F-Node, an artificial node we add to the graph to represent the incident itself. This phase populates R with an initial set of suspect components and interfaces, scoping the search space for downstream severity scoring and ticket routing. 6

• Verify: For each of the top candidates, the agent issues targeted structural queries using the tool query_graph. For instance, the ReAct agent can ask “is the E2 interface affected?” or “how many F1-c KPIs are directly connected to the root incident node (FNode)?” to confirm or refute the incident propagation path implicit in the ranked list. The answers returned by the tool, together with the temporal ordering of onset times on the implicated metrics, populate C and I and anchor the edges of the evidence chain E . • Synthesize: The agent composes a coherent failure chain that connects the root-cause metric in R to the affected interfaces in I and components in C , and emits the structured report R. The synthesis step also derives the recommended diagnostic actions A, each expressed in the operator’s tooling vocabulary (e.g. “inspect PTP offset on O-RU-03 between ts + 12 s and ts + 18 s”), naming components from C , interfaces from I , and subwindows within [ts , te ] so that the outcome of executing A determines the final routing of the ticket. The agent runs a standard call_model–tools loop that terminates when the LLM decides no further tool invocation adds evidence, subject to a maximum-step budget of K = 40 loops. A final generate_structured_response step issues one additional LLM call that emits R in a machine-parseable schema alongside the natural-language rationale, finalizing the overall process. C. Tool #1: Causal Ranked List

The agentic tool ranked_list_causes supplies to our system a quantitative ranking of the metrics that are most closely related to an incident. This tool is used during the Identify Phase. The tool operates on the multivariate observation x[t] introduced in Sec. B, taken over the contextual window CW CW = [ts − Tw , te ),

Tw = te − ts

(2)

which extends Tw seconds before the incident window flagged by a first-line anomaly detector. This symmetric extension exposes both the normal and incident regimes of the system to the causal discovery algorithm (see Sec. 2), allowing it to identify the metrics whose joint behavior changes between the two regimes and so distinguishing genuine causal links from coincidental correlations present in the baseline. Using the contextual window, the tool learns a Weighted Directed Acyclic Graph  GW = V ∪ {F, U}, E ,

E ∈ [0, 1]n×n

(3)

where V is the set of nodes representing each metric variable; F and U are special root nodes encoding the incident signal and UE-population dynamics, called Failure Node and UEs Node (see Sec. 1); and E is the weighted adjacency matrix of the graph, with Eij = 0 encoding the VOLUME ,

Anomaly Ticket

Build Structured Report

Verify

Target Structural Question

Detection Interval: -

0900-0942 CET

Produced Answer for the specific question Q

Report Example RC Indicators: > Indicator 1 – Anomaly Score: 7%

Graph Isomorphism Network

Frozen LLM

Synthesize

> T-2026-01-13-1698C

Tool #2

Ticket ID:

Triage – Perception Agent

Textual Query

Hard prompt tokens

Details

Affected Components: > Com-6874-T via iface-6893-k

Identify

RC Ranked List()

<Indicator 1, Score> <Indicator 2, Score>

Causal Graph

Severity: Major Region: RAN-3248-P

Tool #1

-

Affected Interfaces: > Iface-6893-K, Iface-8369-R, …

Graph embedding

𝑮𝒘

F-Node

KPI-1

KPI-2

Failure Chain: Text

SAM Telemetry

FIGURE 1: C-RE-ACT architecture. Stage 1 constructs a weighted causal graph GW over interface metrics. Stage 2 compresses GW into a continuous soft token aligned with the LLM embedding space to allow the LLM to answer structural queries. Stage 3 is a ReAct-based agent that iteratively queries both tools to produce the triage report R.

absence of an edge from node i to j and Eij > 0 encodes a directed edge from node i to j of causal-strength Eij .

For each node vj ∈ V ∪ {F , U } associated with a time series xj [t], SAM instantiates a conditional generative network fˆj implemented as a H -hidden-layer neural network that reconstructs xj [t] from the other variables as

1) Building the Node Set

The ranked_list_causes tool builds the node set V from the multivariate observation vector x[t] introduced in Sec. B. Each time series xi [t], t ∈ CW becomes a node vi ∈ V . Two additional time series are appended to x[t] and added as nodes of GW : • Failure Node F : a binary indicator time series set to 0 over [ts − Tw , ts ) and 1 over [ts , te ), encoding the incident signal produced by the first-line anomaly detector without any manual labeling at inference time. • UEs Node U : an integer-valued time series counting the registered UEs in the network at each sample over the same window, derived from the access-and-mobility counters exposed by the O-DU.

The graph has n = d+2 nodes: d metric nodes plus F and U . Before learning the causal graph (see Sec. 2), each time series in x[t] (including F and U ) is min–max normalized to [0, 1] over CW to remove unit-of-measurement effects and place all metrics on a comparable scale.

2) Structural Agnostic Model (SAM) Causal Discovery

To uncover the causal structure among the variables in V ∪ {F, U}, we adopt the Structural Agnostic Modeling (SAM) algorithm [24]. Unlike constraint-based discovery methods that rely on pairwise conditional-independence tests [43], [44], SAM formulates causal discovery as a continuous optimization problem and uses Generative Adversarial Networks to model both conditional independencies and distributional asymmetries jointly. This formulation is well suited to mobile networks, where the joint distribution of the metrics is highly non-stationary and where pairwise tests become unreliable as the number of correlated variables grows. VOLUME ,

x̂j [t] = fˆj (x−j [t], aj , θj ) ,

t ∈ CW

(4)

where x−j [t] is the set of all time series except xj [t], θj are the conditional generative network parameters (i.e., all weight matrices and bias vectors), and aj ∈ [0, 1]n is a learned structural gate vector — driven toward {0, 1} by the sparsity penalty introduced below — that acts as the j -th column of the adjacency matrix and decides which variables effectively act as parents of vj . The structural gates of all variables, stacked column-wise, form the gate matrix A = [a1 , . . . , an ]. The gate value Aij = (aj )i has a direct causal interpretation: it is non-zero only when including xi [t] as a predictor for xj [t] genuinely improves the reconstruction; thus, xi [t] is causally related to xj [t]. SAM is trained as a Generative Adversarial Network (GAN) [45]. The per-variable generative networks fˆj act as generators that reconstruct each metric from its candidate parents, while a single neural discriminator with parameters ω is trained to tell apart the real samples drawn from x[t] from the synthetic samples the generators produce. Generators and discriminator are trained against each other. The generators learn to fool the discriminator while the discriminator learns to spot them. The gate matrix A, the network weights θ = {θj }nj=1 and the discriminator weights ω are learned jointly by minimizing n   X X X tr(Ak ) , L = min max Lfit +λS ai,j +λF ∥θj ∥F +λD k! A,θ

ω

i,j

j

k=1

(5) where the min–max structure reflects the adversarial game between the generators (parameterized by A and θ) and the discriminator (parameterized by ω ). The first term, Lfit , is the adversarial fitting loss that drives each generator fˆj to produce reconstructions of x̂j [t] that the discriminator 7

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

dU(Ri)

s(Ri)

0.75

0.75

δ(vi , vj ) = 1 − Eij .

0.50

The lower the distance, the stronger the causal link: an edge with Eij = 1 has δ = 0 (a fully-supported direct causal link), while an edge with Eij → 0 has δ → 1 (a weakly-supported link). For each candidate vj ∈ VF , the causal proximity to F is the distance of the direct edge (F , vj ):

0.50 0.25

0.25 0.00

(a) Ordered by dF(Ri)

R1 R2 R4 R3 R5 R7 R6 R9 R8 R10

Distance

1.00

0.00

(b) Ordered by s(Ri)

FIGURE 2: Confounder penalty effect on ten candidate root causes, ordered by (a) dF alone and (b) the final score s. Lower is better.

cannot distinguish from the true data, given its currently active parents set by matrix A. The second term penalizes the ℓ1 norm of A and enforces the sparsity prior that a metric depends on a small number of direct causes rather than on all the others [46]. The third term regularizes the Frobenius norm of the generator weights, controlling the functional complexity of each fˆj and avoiding overfitting on the small contextual window. The fourth term measures the weight of directed cycles of every length k in A and is zero only for acyclic matrices; minimizing it enforces the absence of cycles in A. The hyperparameters λS , λF , and λD control the trade-off between fit, parsimony, regularization, and acyclicity; their values are reported in Appendix D. Nodes F and U act as exogenous drivers of the system rather than consequences of it. We enforce this by masking the columns of A corresponding to F and U throughout training, fixing ai,F = ai,U = 0 for all i and so placing both nodes as roots in the recovered DAG. To reduce the variance of a single SAM run, we further execute M instances in parallel with distinct random seeds their learned gate matrices into Ā = PMand average 1 (m) A . The resulting object is the Weighted DAG m=1 M GW where E = Ā.

3) Confounder-Penalized Ranking

The ranked_list_causes tool derives a ranked list L of the metrics most likely to be the root cause of the incident, ordered by their direct causal proximity to F . We define the candidate set as the direct children of F in GW :  VF = vj ∈ V : EF ,vj > 0 , (6) i.e., the metric nodes connected to F by a single directed edge in the recovered DAG. Restricting candidates to direct children focuses the ranking on metrics that SAM has identified as immediate consequences of the failure signal, rather than on metrics implicated only through long propagation chains whose causal evidence is diluted by multiple intermediate links. Each directed edge (vi , vj ) in E carries a causal-strength weight Eij ∈ [0, 1], where larger values indicate stronger 8

evidence that vj is causally driven by vi . We define the distance of the edge (vi , vj ) as

1.00

R1 R2 R3 R4 R5 R6 R7 R8 R9 R10

Distance

dF(Ri)

dF (vj ) = δ(F, vj ) = 1 − EF ,vj ∈ [0, 1].

(7)

(8)

A small dF (vj ) indicates that vj is connected to F by a strong causal link and is therefore a strong candidate root cause of the incident. Ranking metrics by dF alone would conflate genuine root causes with metrics that merely co-vary with the incident through the operational non-stationarity of the network: legitimate UE attachments, idle transitions, and detachments shift the joint distribution of many metrics throughout the contextual window, and SAM accordingly learns spurious links from F to UE-sensitive metrics. We treat U as a confounder of these F-rooted causal effects and analogously define the candidate’s distance to U as the distance of the direct edge (U , vj ), when such an edge exists: ( 1 − EU ,vj if EU ,vj > 0, dU (vj ) = dU (vj ) ∈ [0, 1]. 1 otherwise, (9) The convention dU (vj ) = 1 for candidates with no direct edge from U keeps the distance bounded and ensures that such candidates receive no UE-confounder penalty in the score below. A small dU (vj ) identifies a metric whose dynamics are strongly explained by UE-driven non-stationarity rather than by the incident itself. The final ranking score, which we call the causality distance of candidate vj , combines the two distances by penalizing candidates that are simultaneously close to F and to U : h i s(vj ) = dF (vj ) 1 + λ · 1 − dU (vj ) , (10) where λ ∈ R≥0 controls the penalization strength and is tuned on the validation split (Sec. VI). Because dU (vj ) ∈ [0, 1], the factor (1 − dU (vj )) ∈ [0, 1] is close to 1 for candidates tightly coupled to U (small dU ) and close to 0 for candidates weakly coupled to or disconnected from U (dU → 1). The penalty therefore acts most strongly on metrics that are simultaneously close to F and to U — precisely the candidates whose apparent F-rooted causality is most likely an artifact of UE-driven non-stationarity. Sorting VF in ascending order of s(vj ) yields the ranked list L that the agent retrieves through the ranked_list_causes tool call (Phase 1 of the diagnostic protocol, Sec. B). Figure 2 illustrates the effect of the confounder penalty on a representative incident. Plot (a) orders ten candidate metrics by dF alone, placing R2 second despite its nearzero dU (its dynamics are largely explained by background VOLUME ,

Tokenizer

Graph or F-Node Embeddings

Text Embedding Model

LLM

Node Embeddings

interface is affected because [LLM output]

affected? is the impairment deliberate or operational?

Node Features

LLM input

Answer: Yes, the E2

Question: is the E2 interface

GIN Graph Encoder

Frozen Model Projection

F-Node

Trained Model Readout

𝑮𝒘

Laplacian Pos. Enc.

Causal Graph

Causal Reasoning

FIGURE 3: Graph Soft-Prompting architecture. By updating only the GIN encoder weights while keeping the LLM completely frozen, it compresses causal graphs into continuous soft tokens with minimal computational overhead.

UE activity). Plot (b) re-orders the same candidates by s: the penalty in Eq. 10 demotes R2 , while candidates with small dF but large dU rise toward the top.

expose GW to the LLM, so that the graph enters the LLM’s attention layers as a first-class continuous token rather than as text in the prompt. Fig. 3 shows the four-stage pipeline of C-RE-ACT’s graph encoder architecture.

4) Causal Evidence Chain

Constructing the evidence chain E requires its own procedure. For the top-ranked candidate r, we extract the weighted shortest path π = (r = v0 , v1 , . . . , vk = F − N ode) in GW . Each vi is annotated with the O-RAN interface to which the underlying KPI belongs, producing the set of implicated interfaces exposed to the NOC analyst. For each consecutive pair (vi , vi+1 ) in π , the agent also checks the onset timestamps τ (vi ), τ (vi+1 ) (the first second at which each variable deviates from its normal distribution by more than 2σ ) and flags the edge as temporally suspect if τ (vi ) > τ (vi+1 ). Temporally consistent edges are kept while temporally inconsistent ones trigger an extra structural query to the graph-grounded LLM asking for an alternative path. This two-step validation turns the statistical ranking into a temporally grounded narrative that the engineer can audit. D. Tool #2: Causal Reasoning via Graph Soft-Prompting

In the Verify phase of C-RE-ACT’s agentic design, the agent reasons about the structure of the causal graph GW computed by Tool #1 (ranked_list_causes, see Sec. C), to decide which O-RAN interfaces or components were the first to deviate from normal operation, and whether any unexpected behavior propagated to other components or interfaces. The output of this reasoning step populates the suspect sets C and I in the triage report R. The agentic tool query_graph provides this structural-reasoning primitive. Given a natural-language query Q about GW generated by the agent (e.g. “Is the F1-c interface affected?”, “Which F1u Key Performance Metrics (KPIs) are directly connected to F ?”, “Is packet losses at A1 a metric on a propagation chain rooted at F ?”), the tool encodes GW as a single continuous soft token aligned with the embedding space of a frozen large language model (LLM), prepends that token to Q, and returns the LLM’s textual answer to the agent. We adopt a soft-prompting methodology similar to GraphToken [25] to VOLUME ,

1) Graph Encoding

To encode the GW into a soft-token suited to an LLM, we begin representing its nodes as 4-dimensional vectors using a Laplacian Positional Encoding (LPE) [47]. We compute the normalized Laplacian matrix of GW as L = I − D−1/2 AD−1/2 , where I is the identity matrix, A is its weighted adjacency matrix (i.e. E computed in Sec. C) and D its degree matrix. We then compute the spectral decomposition of L and retain the four eigenvectors whose corresponding eigenvalues are the lowest strictly positive ones. Concatenating these eigenvectors column-wise yields a matrix of size (d + 2) × 4 where d is the total number of observed metrics, in which each row encodes a node of GW as a 4-dimensional spatial vector. Following the LPE coordinate assignment, the node features of GW are projected into a continuous latent space using a Graph Isomorphism Network (GIN) [48]. GINs are a class of Graph Neural Networks (GNNs) theoretically proven to maximize structural distinguishability, ensuring that nonisomorphic local structures map to distinct representations. The resulting embeddings capture both the global spatial coordinates of a node within GW and its specific local causal topology. We employ a stack of three GIN layers with a latent dimension of 128. Each layer executes one iteration of message passing: a node updates its state by aggregating the representations of its in-neighbors —scaled by the causal-strength weights from the adjacency matrix E—and combining this aggregate with its own prior state. Stacking L layers expands the receptive field symmetrically; after L rounds, a node has absorbed structural information from its L-hop causal neighborhood. By setting L = 3, the 128 final embedding hL for node i acts as a compressed i ∈R structural fingerprint of the subgraph reaching i via up to three causal links. Stacking the per-node embeddings row by row yields the encoded graph as a matrix H L ∈ R(d+2)×128 9

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

• Graph-level queries (e.g., “Is the F1-c interface affected?”) require a complete representation of the graph, since the agent must reason about propagation paths and cascading effects that may impact interfaces not directly adjacent to F . • Node-level queries (e.g., “Which metrics are causally related to packet losses on F1-c?”) interrogate the immediate topological neighborhood of F .

A single one-size-fits-all aggregation discards information that one query type needs but another can ignore; we therefore use two different readout strategies, dispatched by query type. For graph-level queries, we apply mean pooling across all node embeddings to synthesize a global graph vector: N

hL G =

1 X L h , N i=1 i

(11)

(12)

where gϕ (h) is the projected graph embedding, t(Q) is the standard token embedding sequence of the natural-language query Q, and ∥ denotes the concatenation operator. 10

Non-RT RIC xApp …

Traffic Generator

xApp

Network Probes

A1 Near-RT RIC xApp xApp … xApp User Plane E2

NTP Sync Degradation

NG-c

E1 Centralized Unit (CU) Control Plane F1-u

NG-u

F1-c Distributed Unit Radio Interface Radio Unit (RU)

User Equipment (UE)

USRP B210

Quectel RM520N

FIGURE 4: Experimental testbed used for the evaluation.

2) Soft-Token Encoding Training

Tool #2 must be trained so that the GIN learns to encode causal graphs into soft tokens that steer the frozen LLM toward correct answers. Each training example is a triplet (GW , Q, y) where y is the ground-truth answer derived from the labeled incidents generated in our O-RAN testbed (Sec. VI). After concatenating the graph soft token with the tokenized query and passing the result to the frozen LLM, the model emits a probability distribution over its output vocabulary. The training signal is the negative log-likelihood of the correct answer: L(ϕ, θGIN ) = −

where N = d + 2 is the total number of nodes in GW . This collapses the N × 128 embedding matrix H L into a single 128-dimensional vector via element-wise arithmetic averaging. For node-level queries, we extract the F-Node embedding hL F directly. Because the GIN encodes each node with L = 3 hops, this single vector encapsulates the localized topology and causal dynamics within a 3-hop radius of F , providing the LLM with a concentrated structural fingerprint of the fault’s immediate vicinity. While both readout strategies share the GIN architecture, they are optimized as distinct model checkpoints. At inference time, the agent’s natural-language query is classified into one of the two categories by a lightweight rule-based classifier on the query template, and the tool dispatches the forward pass through the corresponding checkpoint. The selected readout vector, denoted generically as h ∈ R128 , is transformed by a linear projection layer gϕ : R128 → R4096 into a continuous soft token aligned with the native embedding space of a Llama-3.1-8B-Instruct model [49]. The final input prompt sequence P is constructed via concatenation: P = gϕ (h) ∥ t(Q),

xApp

5G core

in which each row encodes a node of GW in the GIN latent space. To convert H L into a single soft token for LLM consumption, we execute a readout step that aggregates the rows of H L into one fixed-size vector. The choice of aggregation strategy is critical: distinct categories of structural queries depend on different topological features of the graph. The natural-language queries submitted to Tool #2 fall into two structural categories:

n X

log pϕ,θGIN (yi | Pi ) ,

(13)

i=1

where ϕ and θGIN encapsulate the learnable parameters of the linear projection layer and the GIN encoder respectively, n is the batch size, Pi is the input prompt sequence of Eq. 12 for instance i, and pϕ,θGIN (yi | Pi ) is the LLM’s predicted probability of emitting the ground-truth answer yi given Pi . Since the LLM weights remain frozen, gradients update only ϕ and θGIN , refining the soft tokens to concentrate the LLM’s probability mass on the correct text output. To train the soft-token encoding, we built the O-RAN Causal Inference Questions and Answers (O-CIQA) dataset: 840 graph–question–answer triplets spanning three query categories — interface impact (e.g., “Is the F1-c interface affected?”), component impact (e.g., “Is the O-DU affected?”), and KPI structure (e.g., “How many latency KPIs are connected to F ?”). For each of the 35 unique causal graphs produced from our experimental deployment (Sec. VI), we generated 24 question–answer pairs. O-CIQA alone is too small to teach the GIN encoder general graph-reasoning primitives such as node counting and adjacency detection. We therefore pre-train on the GraphQA benchmark [26], which provides 1,000 examples over Erdős–Rényi, Barabási–Albert, and stochastic-blockmodel graphs with node-count, degree, and connectedcomponent queries, and then fine-tune on O-CIQA. Across both stages, backpropagation updates only the GIN and projection-layer weights while the LLM remains frozen. VOLUME ,

E2

F1-c

1.00

1.0

0.75

0.8

0.50 0.25 0.00

3 top-k

5

1

3

5

top-k

FIGURE 5: Accuracy of the ranked_list_causes tool across packet-loss and packet-delay experiments

VI. EVALUATION A. Experimental Setup

To evaluate C-RE-ACT, we built the experimental O-RAN testbed shown in Fig. 4. We decided to physically distribute the testbed components across three dedicated host machines interconnected via a high-speed LAN, keeping all hosts’ clocks synchronized. The primary host (AMD Ryzen R9 7950X, 64GB RAM, Ubuntu 22.04 LTS) allocates the ORAN components O-RU, O-DU, and O-CU, the O-RAN RICs, and 5G Core. To satisfy the hard real-time requirements of the O-DU and prevent noisy-neighbor interference during long-running experiments, all O-RAN components are containerized using Docker and assigned dedicated CPU cores. A second host (Intel i9-13900H, 32GB RAM) manages the user equipment (UE), and the third host is dedicated to the observability stack. The software stack relies on open-source solutions fully aligned with 3GPP and O-RAN Alliance standards: the O-RAN Software Community [50] (for the Non-RT and near-RT RICs), srsRAN [51] (for the O-RU, O-DU, and O-CU), and Open5GS [52] (for the Core Network). The physical radio link is established using an Ettus USRP B210 Software-Defined Radio (SDR) acting as the O-RU radio head and two Quectel RM520N-GL serving as standard-compliant UEs. We deploy C-RE-ACT’s agentic system on an off-the-shelf server equipped with an Intel Xeon Silver 4314 CPU (using 4 assigned cores), an Nvidia A5000 GPU (24GB), and 22GB of RAM, using Gemma 4 31B [53], [54] and processing the data generated during the testbed trace replays.

1) Data Observability

To capture a comprehensive and highly granular view of the system’s state, we continuously retrieve interface metrics at each O-RAN component across its different O-RAN interfaces. We extract interface metrics such as the number of packets sent/received, the number of bytes sent/received, and the percentage of lost packets, among other interface metrics. Simultaneously, we use Telegraf to stream these metrics alongside platform-level data, container logs, and srsRAN radio KPIs—such as Block Error Rate (BLER) and VOLUME ,

0.4

Llama-3.1

↑)

Llama-3.1-Instruct

RMSE (

6 5 4 3 2 1 0 Zero-shot

↓)

5.22

0.77 0.79 0.73

0.84 0.78

0.67

0.6 0.2

1

Node Query

Accuracy (

Packet Delay

Accuracy

Accuracy

Graph Query

F1-u

0.57

0.57

0.29 0.22 0.09

0.13

0.0 Zero-shot

GIN FS

GIN FT

RMSE

A1 Packet Loss

2.00 1.71

1.66

0.42 0.40 0.27 0.20 0.19 0.28 0.11 0.00

GIN FS

GIN FT

FIGURE 6: Graph soft-prompting evaluation.

Modulation and Coding Scheme (MCS) per UE—into an InfluxDB time-series database.

2) Traffic Generation and Adversarial Emulation

To move beyond synthetic traffic patterns and establish a realistic mobile network baseline, the testbed replays actual mobile traffic traces captured from a live commercial deployment in a European country1 using the FALCON tool [55]. To emulate the adversarial capabilities described in Sec. B, where an attacker silently degrades O-RAN interfaces, we inject different levels of packet losses and packet delay into F1-U, F1-C, A1, and E2 interfaces. This effectively reproduces the operational footprint of a performance-degradation attack. B. C-RE-ACT’s Tool #1 Evaluation

This section evaluates the ranked_list_causes tool introduced in Sec. C, which is designed to rank the metrics most causally related to a given incident. Figure 5 reports the tool’s accuracy in identifying these metrics across multiple performance degradation events that include packet-loss and packet-delay experiments. The y-axis reports the percentage of incidents in which the ground-truth root-cause metric appears within the tool’s Top-1 (k = 1), Top-3, or Top-5 candidates. The accuracy results are grouped by the attacked interface and the emulated adversarial effect (i.e., packet loss or packet delay). Tool #1 achieves perfect accuracy on the A1 interface for both packet-loss and packet-delay adversarial events, confirming that SLA-metric projections on the A1 signaling plane are sufficiently discriminative for unambiguous causal metric identification. On F1-c, packet-loss events are also identified perfectly at all tiers, but delay-induced ones reduce Top-1 and Top-3 accuracy to ∼ 60%. Nonetheless, the true most causally related metric always appears within the Top 5. This pattern suggests that performance-degradation events via high packet delays in F1-C spread the evidence across multiple candidates rather than concentrating on a single metric. In the case of the E2 interface, Top-3 and Top-5 accuracy for packet-loss events reach 100%, whereas Top-1 1 Hidden due to double-blind review policy

11

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

Accuracy Score

Performance-degradation type

1.0

0.85 0.94

0.70

0.89

Performance-degradation location

0.93 0.90

0.82

0.94

0.5 0.0

A1

E2

F1-c

F1-u

FIGURE 7: Classification Accuracy

accuracy is only 50%. This gap reflects the usage of SCTP as a transport layer in this interface, a connection-oriented protocol. When a packet loss occurs, it triggers SCTP retransmissions, which inflate E2AP-level latency KPIs and cause the causal graph to assign non-zero edge weights to both loss-adjacent and latency-adjacent metrics simultaneously, thereby introducing ambiguity that the ranking tool captures. These misclassification errors are further studied in Sec. 2. For packet-delay degradation incidents on E2, accuracy drops to ∼ 60% across all tiers, consistent with the broader causal signature of delay degradation incidents on connection-oriented interfaces. Finally, F1-U shows complementary behavior in terms of accuracy: delay events are identified perfectly at all tiers, whereas packet-loss events achieve ∼ 75% Top-1 accuracy. The connectionless transport used by F1-U does not generate retransmissions, and hence, its causal signature is less prominent in the SLA metric space relative to the delay signature. C. C-RE-ACT’s Tool #2 Evaluation

Next, we evaluate the verification phase of C-RE-ACT, during which the agent issues targeted structural queries over the causal graph for each top-ranked metric candidate to confirm or refute its involvement in the incident and determine whether the corresponding component or interface warrants further investigation. This structural reasoning serves as the basis for the agent to recommend which suspected components a NOC analyst should prioritize. We compare two tool configurations against a zero-shot text baseline, which prompts the LLM with the graph encoded as textual node and edge lists: (i) GIN FS, where the GIN is trained from scratch on O-CIQA; and (ii) GIN FT, which pre-trains the GIN on GraphQA before fine-tuning it on OCIQA (Sec. 2). For each GIN configuration, we evaluate both the base Llama-3.1-8B model and its instruction-tuned Instruct variant as the frozen LLM. Figure 6 presents the evaluation results for the three tool configurations (zero-shot, GIN FS, and GIN FT) across graph-level and node-level reasoning tasks. Performance is measured by accuracy for categorical questions (e.g. “What other metrics are causally related to F1-U packet losses?”) and Root Mean Square Error (RMSE) for numerical predictions (e.g., “How many F1-c KPIs are connected to F ”). The experiments show that the zero-shot baseline fails to reliably extract structural information, yielding low accuracy 12

(≤ 0.29) and high error rates (up to 5.22 RMSE). Conversely, both graph soft-prompting configurations (GIN FS and GIN FT) significantly improve structural reasoning, elevating accuracy above 0.70 for most tasks and compressing RMSE to near-zero values. The instruction-tuned Llama-3.1-Instruct variant consistently outperforms the base model when paired with the GIN encoders, peaking at 0.82 accuracy on nodelevel tasks under the GIN FT configuration. Pre-training on GraphQA (GIN FT) provides a robust weight initialization, raising the base model’s graph-task accuracy from 0.67 (GIN FS) to 0.79 (GIN FT), without any measurable effect on node-task accuracy. Using the Instruct variant further improves node-task accuracy from 0.77 (GIN FS) to 0.82 (GIN FT), driven by better formatting compliance on list-valued and integer-valued responses. In terms of RMSE, the results are similar to those obtained for GIN FS, yielding near-perfect values for both task types. D. C-RE-ACT Performance

This section evaluates the complete agentic pipeline, characterizing its ability to correctly identify the type and location (interface and component) of performance-degradation incidents across the four tested O-RAN interfaces (A1, F1C, F1-U, and E2). To systematically evaluate the text-based final reports (R), an external LLM node processes each report to extract a structured response. The target fields for this extraction—degradation type and incident location—are strictly constrained to a predefined set of values matching the ground-truth parameters established during the experimental incident generation. Figure 7 reports the aggregate classification accuracy of C-RE-ACT across all adversarial perturbations, broken down by interface and prediction objective. The system consistently achieves an accuracy of 85% or higher across most categories. A notable exception is performance-degradation type identification on the E2 interface, which drops to 70%. This performance gap is structurally consistent with SCTP retransmission mechanics: packet-loss events trigger retransmissions that produce E2AP-level latency signatures indistinguishable from genuine delay, and the agent inherits the structural ambiguity already present in the ranked candidate set. Despite this protocol-specific limitation, the overall results confirm that C-RE-ACT provides highly reliable automated triage across the O-RAN architecture.

1) C-RE-ACT’s Accuracy

Figure 8 disaggregates the accuracy of C-RE-ACT across two primary prediction objectives: identifying the performance-degradation type and pinpointing its location. Within each objective, the x-axis represents the strength of the degradation event. For packet-loss anomalies, “Low” corresponds to 10–30% loss, “Medium” to 40–60%, “High” to 70–90%, and “Link Down” indicates a complete interface failure. For packet-delay anomalies, “Low” corresponds to a VOLUME ,

A1 1.00

F1-c

F1-u

A1

Packet Delay

0.75 0.50 0.25 0.00

Low

Medium

High Link Down

Performance-degradation strength

Low

Medium

High

E2

F1-c

F1-u

Packet Loss

1.00

Accuracy

Accuracy

E2

Packet Loss

Packet Delay

0.75 0.50 0.25 0.00

Performance-degradation strength

Low

Medium

High Link Down

Low

Performance-degradation strength

(a) Performance-degradation type identification task.

Medium

High

Performance-degradation strength

(b) Performance-degradation location identification task

FIGURE 8: Perception Agent triage results as a function of anomaly strength.

VOLUME ,

at 60% for low-strength delay before stabilizing at 100% for higher strengths. Because the F1-U interface utilizes connectionless UDP transport, it avoids retransmission ambiguity; however, its delay footprints can overlap heavily with legitimate radio-layer congestion, occasionally decreasing classifier certainty.

0.94

0.00

0.03

0.03

E2

0.00

0.89

0.04

0.07

F1-c

0.00

0.00

0.90

0.10

F1-u

0.00

0.00

0.06

0.94

A1

E2 F1-c Predicted label

F1-u

True label

A1

Delay

Loss

0.86

0.14

0.16

0.84

Perf. deg. Type - E2 True label

Perf. deg. Type - A1 Performance-degradation Location

Delay Loss Predicted label

Loss

0.80

0.20

0.00

1.00

Delay Loss Predicted label

Loss

0.88

0.12

0.37

0.63

Perf. deg. Type - F1-u True label

Delay

Delay

Delay Loss Predicted label

Perf. deg. Type - F1-c True label

True label

10–100 ms delay, “Medium” to 0.1–1 s, and “High” to a 1–5 s delay. Results are further grouped by the affected interface. A1 Interface. Performance-degradation type identification maintains high accuracy (≥ 75%) for both packet loss and delay across most strength levels, though it experiences a notable drop to 40% for high-strength packet loss. High packet losses have negative consequences on more network components, which might start retransmitting packets and increase the overall delay experienced, making the type identification harder. Conversely, incident location identification remains consistently robust (≥ 80%) and frequently reaches 100%, indicating that A1 performance degradation events are spatially well-localized within the causal graph regardless of the degradation severity. E2 Interface. Performance-degradation type identification struggles significantly with low-strength packet loss, plummeting to 20% accuracy, though it recovers to 75–80% at higher loss strengths. Under packet-delay degradation, both type and location identification perform perfectly (100%) at low and medium strengths but degrade sharply to 50% under high-strength delay. As noted previously, this degradation occurs because extreme delay causes SCTP connection timeouts, producing KPI relations that confound the classification logic. F1-C Interface. The system achieves flawless 100% accuracy for both type and location identification during packet loss experiments across all strengths. However, delay degradation events present an abrupt contrast: while mediumstrength delay achieves perfect accuracy, low-strength delay shows reduced performance (60% type, 40% location), and high-strength delay completely degrades both objectives to 0%. Extreme delay on the F1-C SCTP transport triggers severe control-plane timeouts and massive variance across all radio metrics, entirely obscuring the root location of the performance-degradation incident. F1-U Interface. For packet-loss incidents, location accuracy is a perfect 100% across all strengths. Type accuracy is equally perfect for low through high strengths, dropping to 50% only during a complete link failure (Link Down). Under packet-delay impairments, type accuracy fluctuates (100% low, 60% medium, 75% high), while location accuracy starts

Delay

Loss

0.79

0.21

0.16

0.84

Delay Loss Predicted label

FIGURE 9: Confusion matrices for performance-degradation location (left) and performance-degradation type per interface (right).

2) C-RE-ACT’s Misclassifications

To further analyze the performance of C-RE-ACT, we decompose the misclassification structure to identify where the metric space is incomplete and under what conditions triage routing decisions might be unreliable. Figure 9 depicts the confusion matrices for performance-degradation location and type identification across all attacked interfaces. The performance degradation location matrix (left) shows diagonal values between 0.89 and 0.94. The off-diagonal mass leaks consistently toward F1-U — A1, E2, and F1-C each redirect 3 − 10% of their probability there, while the reverse leakage is negligible. We attribute this to F1-U’s role as the user-plane data-bearing interface: any control-plane degradation eventually manifests in the user-plane. The four performance-degradation type matrices (right) reveal three structurally distinct misclassification patterns: E2 (SCTP retransmission confound). 37% of packet-loss degradation are classified as delay. SCTP’s reliable-delivery 13

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

E2

F1-c

F1-u

Exec Time (s)

A1

Score

0.6 0.4 0.2 0.0

1000 500

FIGURE 11: PerFIGURE 10: Lexical and semantic fi- ception Agent execution time. delity of C-RE-ACT’s final reports. BLEU

METEOR

ROUGE-R

BERT-R

mechanism converts dropped packets into retransmissions, whose latency surfaces in the same E2AP-level KPIs that genuine delay would perturb. The ranked candidate list contains both loss- and latency-adjacent metrics with comparable causal weight, biasing the agent toward the delay hypothesis. F1-C (low-strength delay misclassified as loss). Packet loss is perfectly classified, but 20% of delay events are reported as losses. The pattern concentrates at low-strength delay regimes (Sec. 1), where the added delay does not exceed SCTP retransmission timeouts and so leaves no observable footprints. F1-U (secondary loss from delay-induced congestion). 21% of delay events are reported as losses. F1-U operates at high throughput; injected delay overflows transport buffers, and the agent misses the main cause of degradation. On the F1-U interface (GTP-U/UDP), retransmissions do not occur, and loss classification accuracy is near-perfect. This asymmetry between E2 and F1-U confirms that the misclassification is a property of the O-RAN transport architecture, not of the agent’s reasoning capability. E. Final Report Quality

We evaluate C-RE-ACT’s reports along lexical (BLEU [56], METEOR [57], ROUGE-R [58]) and semantic (BERTR [59]) axes. Both are necessary because O-RAN diagnostics admit multiple correct surface forms — interface aliases, vendor-specific naming — that lexical metrics penalize even when the diagnostic content is preserved. Figure 10 summarizes the results. BLEU scores are uniformly low (median ∼ 0.15 − 0.25) because BLEU’s precision-based formulation requires exact n-gram matches: A1 policy-guidance traffic “is correct relative to a ground-truth A1 interface traffic” but registers as a mismatch. METEOR and ROUGE-R, which incorporate recall and partial-match credit, recover to a middle range (∼ 0.35 − 0.45). BERT-R is the highest by median (∼ 0.40−0.45), confirming that diagnostic content is preserved at the semantic level even when token-level fidelity is imperfect. The wide low-tail variance — particularly on F1-U — traces to occasional template non-compliance in the agent’s free-form generation, an artifact addressable through stricter schema validation. Figure 11 reports the end-to-end execution time of CRE-ACT’s full pipeline across all 140 experiments. In a 14

prototyping testbed with locally-hosted LLMs and nonperformance-optimized tools, the median runtime of 678s sits within the post-detection triage latency budget identified in Sec. C (Challenge C4), confirming that C-RE-ACT can produce a triage report well within the operator’s MTTR budget. VII. Conclusion

In this paper, we presented C-RE-ACT, an agentic system that automates triage and diagnosis for O-RAN incidents. Operationally, C-RE-ACT targets the repetitive, judgmentbound triage tasks of standard performance-degradation incidents. By converting raw KPI-deviation alerts into grounded incident reports, the pipeline replaces manual overhead with auditable inference, preserving the critical human-in-the-loop boundary required for network reconfiguration. The system models performance-degradation incidents as weighted causal graphs, compresses them into continuous soft tokens for a frozen LLM, and drives an autonomous loop to produce structured incident triage reports. We evaluated C-RE-ACT on a physical O-RAN deployment. Our solution correctly places the root causes within the top three candidates in 91% of cases. Furthermore, it improves LLM graph-reasoning accuracy from 22% to 72% and classifies delay-related performance degradation with 98% accuracy. The generated report, R, functions as a verifiable diagnostic artifact. Each claim in the evidence chain is grounded in either window observation measurements or an edge within GW , enabling operators to validate or reject any reasoning step. ACKNOWLEDGMENT

This work was supported in part by the ORIGAMI Project under Grant 101139270; in part by the CERCA Programme from the Generalitat de Catalunya through the ICREA programme; and in part by the funding received from Departament de Recerca I Universitats, Generalitat de Catalunya for this project REFERENCES [1] Fujitsu, “Fujitsu, KDDI successfully turns on the world’s first 5G standalone open RAN site powered by vRAN in Japan,” News Release, 2022. [Online]. Available: https://www.fujitsu.com/global/about/resources/news/pressreleases/2022/0218-01.html [2] NTT DOCOMO, “NTT DOCOMO offers open RAN product set to other telcos,” Fierce Network, News Release, 2023. [Online]. Available: https://www.fierce-network.com/tech/ntt-docomooffers-open-ran-product-set-other-telcos [3] AT&T, “AT&T to accelerate open and interoperable radio access networks (RAN) in the United States through new collaboration with Ericsson,” News Release, 2023. [Online]. Available: https://about.att.com/story/2023/commercialscale-open-radio-access-network.html [4] GSMA, “Major European operators sign open RAN MoU,” News Release, 2021. [Online]. Available: https://www.gsma.com/futurenetworks/digest/major-europeanoperators-sign-open-ran-mou/ [5] Light Reading, “Amarisoft powered Orange 5G at Olympics in best open RAN example yet,” Light Reading, 2024. [Online]. Available: https://www.lightreading.com/open-ran/amarisoft-poweredorange-5g-at-olympics-in-best-open-ran-example-yet

VOLUME ,

[6] O-RAN Alliance, “O-ran control, user and synchronization plane specification 20.0,” O-RAN Alliance, Technical Specification ORAN.WG4.TS.CUS.0-R005-v20.00, 2026. [7] O-RAN Alliance, “O-ran nr c-plane profile 17.0,” O-RAN Alliance, Technical Specification O-RAN.WG5.TS.C.1-R005-v17.00, 2026. [8] S. R. Hussain, M. Echeverria, I. Karim, O. Chowdhury, and E. Bertino, “5greasoner: A property-directed security and privacy analysis framework for 5g cellular network protocol,” in Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2019, pp. 669–684. [9] J. Groen, B. Kim, and K. Chowdhury, “The cost of securing o-ran,” in ICC 2023-IEEE International Conference on Communications. IEEE, 2023, pp. 5444–5449. [10] J. Groen, S. D’Oro, U. Demir, L. Bonati, D. Villa, M. Polese, T. Melodia, and K. Chowdhury, “Securing o-ran open interfaces,” IEEE Transactions on Mobile Computing, vol. 23, no. 12, pp. 11 265–11 277, 2024. [11] J. Xing, S. Yoo, X. Foukas, D. Kim, and M. K. Reiter, “On the criticality of integrity protection in 5g fronthaul networks,” in 33rd USENIX Security Symposium (USENIX Security 24), 2024, pp. 4463– 4479. [12] W. Lin, Z. Li, B. Chen, J. Liu, R.-G. Cheng, and F. Zhang, “5gmuffler: Covert dos attacks over open fronthaul interface of o-ran 5g network,” in IEEE INFOCOM 2025-IEEE Conference on Computer Communications. IEEE, 2025, pp. 1–10. [13] A. Scalingi, S. D’Oro, F. Restuccia, T. Melodia, and D. Giustiniano, “Det-ran: Data-driven cross-layer real-time attack detection in 5g open rans,” in IEEE INFOCOM 2024-IEEE Conference on Computer Communications. IEEE, 2024, pp. 41–50. [14] H. Wen, P. A. Porras, V. Yegneswaran, A. Gehani, and Z. Lin, “5gspector: An o-ran compliant layer-3 cellular attack detection service.” in NDSS, 2024. [15] G. Garcia-Aviles, A. Garcia-Saavedra, M. Gramaglia, X. Costa-Perez, P. Serrano, and A. Banchs, “Nuberu: Reliable ran virtualization in shared platforms,” in Proceedings of the 27th Annual International Conference on Mobile Computing and Networking, 2021, pp. 749– 761. [16] J. Xing, J. Gong, X. Foukas, A. Kalia, D. Kim, and M. Kotaru, “Enabling resilience in virtualized rans with atlas,” in Proceedings of the 29th Annual International Conference on Mobile Computing and Networking, 2023, pp. 1–15. [17] O-RAN Alliance, “Security threat modeling and risk assessment 8.0,” O-RAN Alliance, Technical Report O-RAN.WG11.TR.ThreatModeling-R005-v08.00, 2026, work Group 11 (Security). Available at https://www.o-ran.org/specifications. [18] P. Baguer, G. M. Yilma, E. Municio, G. Garcia-Aviles, A. GarciaSaavedra, M. Liebsch, and X. Costa-Pérez, “Attacking O-RAN interfaces: Threat modeling, analysis and practical experimentation,” IEEE Open J. Commun. Soc., 2024. [19] K. Thimmaraju, A. Shaik, S. Flück, P. J. F. Mora, C. Werling, and J.-P. Seifert, “Security testing the o-ran near-real time ric & a1 interface,” in Proceedings of the 17th ACM Conference on Security and Privacy in Wireless and Mobile Networks, 2024, pp. 277–287. [20] A. P. Iyer, L. E. Li, and I. Stoica, “Automating diagnosis of cellular radio access network problems,” in Proceedings of the 23rd annual international conference on mobile computing and networking, 2017, pp. 79–87. [21] T. Sundqvist, M. Bhuyan, and E. Elmroth, “Robust procedural learning for anomaly detection and observability in 5g ran,” IEEE Transactions on Network and Service Management, vol. 21, no. 2, pp. 1432–1445, 2023. [22] A. Chawla, P. Jacob, S. Feghhi, D. Rughwani, S. van der Meer, and S. Fallon, “Interpretable unsupervised anomaly detection for ran cell trace analysis,” in 2020 16th International Conference on Network and Service Management (CNSM). IEEE, 2020, pp. 1–5. [23] C. Sun, U. Pawar, M. Khoja, X. Foukas, M. K. Marina, and B. Radunovic, “Spotlight: Accurate, explainable and efficient anomaly detection for open ran,” in Proceedings of the 30th Annual International Conference on Mobile Computing and Networking, 2024, pp. 923–937. [24] D. Kalainathan, O. Goudet, I. Guyon, D. Lopez-Paz, and M. Sebag, “Structural agnostic modeling: Adversarial learning of causal graphs,” Journal of Machine Learning Research, vol. 23, no. 219, pp. 1–62, 2022.

VOLUME ,

[25] B. Perozzi, B. Fatemi, D. Zelle, A. Tsitsulin, M. Kazemi, R. Al-Rfou, and J. Halcrow, “Let your graph do the talking: Encoding structured data for LLMs,” arXiv preprint arXiv:2402.05862, 2024. [26] B. Fatemi, J. Halcrow, and B. Perozzi, “Talk like a graph: Encoding graphs for large language models,” arXiv preprint arXiv:2310.04560, 2023. [27] O-RAN Alliance, “NR C-plane profile 17.0,” O-RAN Alliance, Technical Specification O-RAN.WG5.TS.C.1-R005-v17.00, 2026, work Group 5 (Open F1/W1/E1/X2/Xn Interface). Available at https://www.o-ran.org/specifications. [28] O-RAN Alliance, “O-ran E2 general aspects and principles (e2gap) 8.0,” O-RAN Alliance, Technical Specification ORAN.WG3.TS.E2GAP-R004-v08.00, 2025, work Group 3 (NearReal-Time RIC and E2 Interface). Available at https://www.oran.org/specifications. [29] O-RAN Alliance, “A1 interface: General aspects and principles (A1GAP) 5.03,” O-RAN Alliance, Technical Specification ORAN.WG2.TS.A1GAP-R005-v05.03, 2026, work Group 2 (NonReal-Time RIC and A1 Interface). Available at https://www.oran.org/specifications. [30] P. Cichonski, T. Millar, T. Grance, and K. Scarfone, “Computer Security Incident Handling Guide,” National Institute of Standards and Technology, Gaithersburg, MD, NIST Special Publication (SP) 800-61 Rev. 2, 2012. [31] A. Padmanabha Iyer, L. Erran Li, M. Chowdhury, and I. Stoica, “Mitigating the latency-accuracy trade-off in mobile data analytics systems,” in Proceedings of the 24th annual international conference on mobile computing and networking, 2018, pp. 513–528. [32] M. Kotaru, “Adapting foundation models for operator data analytics,” in Proceedings of the 22nd ACM Workshop on Hot Topics in Networks, 2023, pp. 172–179. [33] MITRE Corporation, “FiGHT: 5G Hierarchy of Global Adversary Threats,” 2026, accessed: April 18, 2026. [Online]. Available: https://fight.mitre.org/ [34] C. Pei, Z. Wang, F. Liu, Z. Li, Y. Liu, X. He, R. Kang, T. Zhang, J. Chen, J. Li et al., “Flow-of-action: Sop enhanced llm-based multiagent system for root cause analysis,” in Companion Proceedings of the ACM on Web Conference 2025, 2025, pp. 422–431. [35] Z. Wang, J. Li, M. Ma, Z. Li, Y. Kang, C. Zhang, C. Bansal, M. Chintalapati, S. Rajmohan, Q. Lin et al., “Large language models can provide accurate and interpretable incident triage,” in 2024 IEEE 35th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 2024, pp. 523–534. [36] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, and P. Liang, “Lost in the middle: How language models use long contexts,” Trans. ACL, vol. 12, pp. 157–173, 2024. [37] J. Wei, X. Wang, D. Schuurmans, M. Bosma, F. Xia, E. Chi, Q. V. Le, D. Zhou et al., “Chain-of-thought prompting elicits reasoning in large language models,” Advances in neural information processing systems, vol. 35, pp. 24 824–24 837, 2022. [38] Y. Zhang, Y. Yuan, and A. C.-C. Yao, “Meta prompting for ai systems,” arXiv preprint arXiv:2311.11482, 2023. [39] J. Liu, C. Zhang, J. Qian, M. Ma, S. Qin, C. Bansal, Q. Lin, S. Rajmohan, and D. Zhang, “Large language models can deliver accurate and interpretable time series anomaly detection,” no. arXiv:2405.15370, May 2024, arXiv:2405.15370 [cs]. [Online]. Available: http://arxiv.org/abs/2405.15370 [40] D. Wu, X. Wang, Y. Qiao, Z. Wang, J. Jiang, S. Cui, and F. Wang, “Netllm: Adapting large language models for networking,” in Proceedings of the ACM SIGCOMM 2024 Conference. Sydney NSW Australia: ACM, Aug. 2024, p. 661–678. [Online]. Available: https://dl.acm.org/doi/10.1145/3651890.3672268 [41] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing reasoning and acting in language models,” in Proc. ICLR, 2023. [42] LangChain. (2024) Langgraph. [Online]. Available: https://www.langchain.com/langgraph [43] P. Spirtes, C. N. Glymour, and R. Scheines, Causation, prediction, and search. MIT press, 2000. [44] A. Ikram, S. Chakraborty, S. Mitra, S. Saini, S. Bagchi, and M. Kocaoglu, “Root cause analysis of failures in microservices through causal discovery,” Advances in Neural Information Processing Systems, vol. 35, pp. 31 158–31 170, 2022.

15

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

[45] I. J. Goodfellow, J. Pouget-Abadie, M. Mirza, B. Xu, D. Warde-Farley, S. Ozair, A. Courville, and Y. Bengio, “Generative adversarial nets,” Advances in neural information processing systems, vol. 27, 2014. [46] T. Hastie, R. Tibshirani, and M. Wainwright, “Statistical learning with sparsity,” Monographs on statistics and applied probability, vol. 143, no. 143, p. 8, 2015. [47] V. P. Dwivedi, C. K. Joshi, A. T. Luu, T. Laurent, Y. Bengio, and X. Bresson, “Benchmarking graph neural networks,” J. Mach. Learn. Res., vol. 24, no. 43, pp. 1–48, 2023.

F-node

UEs f1_u_latency_mean_ul_ms e2_du_latency_p90_ul_ms f1_u_latency_p90_ul_ms

e2_du_latency_mean_ul_ms

f1_u_throughput_dl_kbps f1_u_throughput_ul_kbps

[48] K. Xu, W. Hu, J. Leskovec, and S. Jegelka, “How powerful are graph neural networks?” arXiv preprint arXiv:1810.00826, 2018.

f1_u_latency_mean_dl_ms

[49] A. Grattafiori et al., “The Llama 3 herd of models,” arXiv preprint arXiv:2407.21783, 2024.

f1_u_latency_p90_dl_ms

[50] O-RAN Software Community. (2026) O-ran software community. [Online]. Available: https://o-ran-sc.org/ [51] Software Radio Systems. (2026) srsran. [Online]. Available: https://www.srslte.com/

FIGURE 12: Causal Graph for E2 under low delay impairment experiment.

[52] Open5GS. (2026) Open5gs. [Online]. Available: https://open5gs.org/ [53] Google DeepMind. (2026) Gemma 4. [Online]. https://deepmind.google/models/gemma/gemma-4/

Available:

TABLE 1: Top-10 Ordered Root Causes KPI Metric

[54] G. Team, T. Mesnard, C. Hardin, R. Dadashi, S. Bhupatiraju, S. Pathak, L. Sifre, M. Rivière, M. S. Kale, J. Love et al., “Gemma: Open models based on gemini research and technology,” arXiv preprint arXiv:2403.08295, 2024. [55] R. Falkenberg and C. Wietfeld, “FALCON: An accurate realtime monitor for client-based mobile network data analytics,” in 2019 IEEE Global Communications Conference (GLOBECOM). Waikoloa, Hawaii, USA: IEEE, Dec. 2019. [Online]. Available: https://arxiv.org/abs/1907.10110 [56] K. Papineni, S. Roukos, T. Ward, and W.-J. Zhu, “Bleu: a method for automatic evaluation of machine translation,” in Proceedings of the 40th annual meeting of the Association for Computational Linguistics, 2002, pp. 311–318. [57] S. Banerjee and A. Lavie, “Meteor: An automatic metric for mt evaluation with improved correlation with human judgments,” in Proceedings of the acl workshop on intrinsic and extrinsic evaluation measures for machine translation and/or summarization, 2005, pp. 65–72. [58] C.-Y. Lin, “Rouge: A package for automatic evaluation of summaries,” in Text summarization branches out, 2004, pp. 74–81. [59] T. Zhang, V. Kishore, F. Wu, K. Q. Weinberger, and Y. Artzi, “Bertscore: Evaluating text generation with bert,” arXiv preprint arXiv:1904.09675, 2019.

APPENDIX ILLUSTRATIVE PIPELINE ARTIFACTS A. Causal Graph and Root-Cause Ranking

Figure 12 shows a representative causal graph produced by the SAM-based discovery pipeline for a packet-delay impairment on the E2 interface. Nodes correspond to SLAderived KPIs, the F-Node and UEs-Node special nodes. Table 1 reports the corresponding output of the tool, listing all KPI candidates in ascending order of their distance to the F-Node. 16

Anomaly Score

e2 du latency p90 ul ms e2 du latency mean ul ms e2 du throughput ul kbps f1 u latency mean ul ms f1 u throughput ul kbps

0.1156 0.3797 0.7722 0.8054 0.8534

f1 u latency p90 ul ms f1 u throughput dl kbps f1 u latency p90 dl ms a1 throughput dl kbps f1 c throughput ul kbps

0.8788 0.9239 0.9363 0.9390 0.9395

B. Causal Reasoning: Query and Response

This section illustrates the iterative exchange between C-REACT and the query_graph_tool during the verification stage of the ReAct loop. Each row shows a targeted naturallanguage question formulated by the agent to confirm or refute the implication of the top-ranked candidate, together with the structured response. • Question: How many E2 interface KPIs are affected by the anomaly? • Answer: 7 Of the 13 edges in G, 7 are E2 interface KPIs. • Question: Is the O-DU component affected by the anomaly? • Answer: 1. The O-DU is affected by the anomaly. The (e2 du rtx ul count, e2 du throughput ul kbps) edge means that the O-DU is affected by the anomaly. • Question: List the F1-u interface KPI nodes that are directly connected to the F-node, in alphabetical order. • Answer: 1. f1 u latency mean ul ms, f1 u latency p90 ul ms, f1 u throughput ul kbps. VOLUME ,

C. C-RE-ACT Prompt and Triage Report

LLM Prompt 2: C-RE-ACT prompt.

The following Markdown illustration reproduces the full system prompt supplied to C-RE-ACT at inference time, defining the O-RAN component hierarchy, the five-step investigative strategy, and the strict report schema the agent must follow (green background illustration). Then, the subsequent figure (yellow background) shows the complete triage report generated, illustrating how the agent translates the causal evidence collected during the ReAct loop into a structured diagnostic document comprising a failure chain, affected interface list, root cause statement, and actionable remediation steps.

4. Isolate Root Cause: Filter out symptomatic noise and confounding variables to identify the true origin point. Do not blindly trust the ranked list, as statistical anomalies can be noisy due to normal network dynamics (e.g., users connecting/disconnecting, load balancing, or routine policy executions). Apply the following strict heuristics: – Metric Severity Prioritization: Hard errors carry more diagnostic weight than volume fluctuations. Always prioritize severe degradation metrics (e.g., packet_loss, retransmissions, error_rates) over milder volumetric symptoms (e.g., throughput_kbps), even if the volumetric metrics have a worse anomaly score or higher ranking. – Causal Precedence: Use the graph tool to determine the direction of the failure. If a severe error on one interface logically precedes a volume drop on another, the severe error is the root cause. – Exclude Normal Noise: Recognize that isolated throughput drops without accompanying hard errors may simply be confounding variables (like user mobility), not the root cause of a network-wide failure. 5. Synthesize: Construct the failure chain based ONLY on verified edges and resolved data. ### AVAILABLE TOOLS

LLM Prompt 1: C-RE-ACT prompt. You are an expert O-RAN Perception Agent responsible for diagnosing network failures with high precision. ### SYSTEM CONTEXT The O-RAN network is a 5G Radio Access Network composed of the following hierarchy: 1. Components: – O-DU (Distributed Unit) – O-CU (Centralized Unit) – Near-RT RIC (Near Real-Time RAN Intelligent Controller) – Non-RT RIC (Non-RT RAN Intelligent Controller) 2. Interfaces: – F1-c / F1-u: Connects O-CU and O-DU (Control/User plane). – E2: Connects Near-RT RIC to O-DU/O-CU. – A1: Connects Non-RT RIC to Near-RT RIC. ### YOUR MISSION The network has been detected in a failure state. Your task is to diagnose the root cause and map the failure propagation. Do not guess, hallucinate, or jump to premature conclusions. Adopt a rigorous, iterative, investigative strategy: 1. Identify Candidates: First, query_root_cause_ranked_list to most likely anomaly source (lowest distance).

find

use the

2. Verify Topology: Use query_graph_tool to confirm which interfaces and downstream components are actually affected by those candidates.

– query_graph_tool: Queries the causal graph via natural language. Use this iteratively to check status, verify connections, and contrast conflicting data (e.g., ‘Is the F1-u interface affected?’, ‘What does node X affect?’, ‘Does anomaly A cause anomaly B?’). – query_root_cause_ranked_list: Returns the top root cause candidates ranked by probability (distance to F-node). ### REPORT FORMAT Produce a report in the following strict format: # Failure Analysis Root Cause Indicators (Directly Connected to F-node): List the top KPIs from the ranked list (include their rank/score). Diagnostic Reasoning & Disambiguation: Briefly explain your investigative steps. If multiple interfaces or contradictions were found, explain how you cross-referenced the graph to resolve them. Affected Interfaces: List interfaces confirmed to be affected (verify status before listing). Affected O-RAN Components: List components confirmed to be affected based on the interface status. Failure Chain: A logical explanation of how the failure propagated (e.g., Root KPI → Interface → Component). Root Cause: The single most probable technical cause of the failure. Recommendation: Actionable steps to resolve the specific root cause.

3. Cross-Reference & Disambiguate: This is critical. If tool outputs contradict each other, or if anomalies span multiple interfaces (e.g., both F1-c and E2 show issues), you MUST ask further questions using query_graph_tool to contrast the information.

VOLUME ,

17

Author et al.: Preparation of Papers for IEEE OPEN JOURNALS

LLM Output 1: Example of Perception Agent Final Report on Low Packet Delay anomaly in the E2 interface. # Failure Analysis Root Cause Indicators (Directly Connected to F-node): – e2_du_latency_p90_ul_ms (Rank: 1, Score: 0.1237) – e2_du_latency_mean_ul_ms (Rank: 2, Score: 0.4188) – e2_du_throughput_ul_kbps (Rank: 3, Score: 0.8651) Diagnostic Reasoning & Disambiguation: The investigation began with the root cause ranked list, which strongly indicated a failure originating at the E2 interface, specifically with high uplink latency (e2_du_latency_p90_ul_ms). Cross-referencing with the causal graph revealed a slight contradiction: while a general query suggested the F1-c interface was not affected, a specific query on hard errors confirmed that f1_c_retransmissions_dl_count is directly connected to the F-node. This confirms that F1-c is indeed affected by the anomaly, likely as a downstream symptom. The A1 interface was confirmed to be unaffected, which allows us to exclude the NonRT RIC from the failure chain, despite inconsistent tool feedback regarding that component. Following the Metric Severity Prioritization heuristic, while hard errors (retransmissions on F1-c) were present, the extremely low anomaly score of the E2 latency KPIs (0.12) identifies the E2 interface as the primary origin. The failure propagates from the control/management plane (E2) to the transport/control planes (F1c/F1-u). Affected Interfaces: – E2: Confirmed affected (High latency/throughput drops). – F1-u: Confirmed affected (Latency issues). – F1-c: Confirmed affected (Retransmission increase). Affected O-RAN Components: – Near-RT RIC: Affected via the E2 interface. – O-DU: Affected via the E2, F1-c, and F1-u interfaces. – O-CU: Affected via the E2, F1-c, and F1-u interfaces. Failure Chain: e2_du_latency_p90_ul_ms (Root Cause) → E2 Interface → Degradation of Near-RT RIC to O-DU/O-CU coordination → Propagation to F1-c/F1-u Interfaces → Impact on O-DU and OCU performance. Root Cause: Severe latency degradation on the E2 interface uplink, impairing the Near-RT RIC’s ability to manage the Distributed Unit (O-DU) and Centralized Unit (O-CU).

HYPERPARAMETERS AND TRAINING DETAILS D. SAM Configurations

To determine the optimal architecture and training dynamics for the SAM utilized in the causal discovery phase, we conducted an automated hyperparameter search over 110 runs using the Optuna framework2 . Table 2 details the specific hyperparameter search space explored during the optimization trials, alongside the bestperforming values adopted for the final model deployment. Consistent with the objective function formulation presented in Sec. 2, lambda1 corresponds to the structural sparsity penalty (λS ), and lambda2 corresponds to the functional complexity penalty (λF ). E. Graph Soft-Prompting Encoder Training

The causal reasoning within the verification phase relies on encoding the graph topological structure into continuous soft tokens that align with the embedding space of a frozen Large Language Model. Based on our configuration, the underlying LLM employed is the meta-llama/Llama-3.1-8B-Instruct architecture. To train the GIN and the linear projection layer, we utilized the Adam optimizer coupled with a linear learning rate warmup schedule. The specific hyperparameter configuration for the graph encoder training is summarized in Table 3. TABLE 3: Hyperparameter Configuration for Graph SoftPrompting Encoder Parameter

Description

Value

lr epochs warmup_epochs es_patience

Peak learning rate (Adam) Maximum training epochs Epochs for lr warmup Patience for early stopping

10−4 50 3 10

latent_dim num_gte_layers gte_pos_enc_size num_soft_tokens readout

GIN hidden dimension size Graph encoder layers LPE size Number of soft tokens Readout agg. strategy

128 3 4 1 Graph / Node

Recommendation: 1. Inspect the transport network between the Near-RT RIC and the O-DU/O-CU for congestion or hardware faults. 2. Verify the E2 agent configuration on the O-DU/O-CU to ensure there are no processing bottlenecks causing uplink latency. 3. Restart the E2 service on the affected components to clear potential stale sessions or buffer overflows.

During data preprocessing, we compute the normalized Laplacian matrix for each graph to extract the first 4 strictly positive eigenvectors, which map directly to the gte_pos_enc_size parameter. The generated soft token is then concatenated with the tokenized natural language question, while the LLM weights remain strictly frozen. The graph encoder updates its parameters through backpropagation by minimizing the training loss generated from the textual answers across the validation and training dataset splits.

2 https://optuna.org/

18

VOLUME ,

TABLE 2: Optuna Search Space and Optimal Hyperparameters for SAM Parameter

Description

lambda1 (λS ) lambda2 (λF ) lr dlr nh dnh

Sparsity penalty weight Functional complexity penalty Generator learning rate Discriminator learning rate Generator hidden units Discriminator hidden units

hlayers (H) dhlayers dagstart dagpenalization_increase

Generator hidden layers Discriminator hidden layers Epoch ratio to begin DAG penalty Acyclicity penalty increase step

Search Space

Optimal Value

[1.0, 50.0] (log) [0.001, 1.0] (log) [10−4 , 5 · 10−2 ] (log) [10−4 , 10−2 ] (log) {10, 20, 50, 100} {100, 200, 350, 500}

5.159 0.046 0.0185 0.0037 20 200

[1, 3] [1, 3] [0.4, 0.7] [0.001, 0.05] (log)

2 1 0.417 0.041

Pau Baguer completed a double engineering degree in aerospace systems and networking from the Polytechnic University of Catalonia (Barcelona) in 2023. He joined the AI-driven Systems group of i2CAT in June 2022 and became a junior researcher in 2023.

Josep Xavier Salvat Lozano received his PhD from the Technical University of Kaiserslautern in 2022 and he currently works as a senior research scientist in the 6G Network group at NEC Laboratories Europe, Heidelberg. He worked as a reviewer for several international scientific conferences and journals, including IEEE Transactions on Mobile Computing, IEEE ICC, and Computer Communications Journal and has actively participated in several EU-founded projects, including H2020 5Growth, H2020 Daemon and SNS-JU BeGREEN. His research interests lie in the application of AI to real-world wireless communication systems, including resource allocation and energyefficiency problems.

Gines Garcia-Aviles received his PhD degree in Telematics Engineering from the University Carlos III of Madrid at the IMDEA Networks Institute. Since January 2021, he has been with i2CAT, where he is currently a research scientist in the AI-driven Systems group.

Xavier Costa-Pérez is an ICREA Research Professor, Scientific Director at the i2CAT Research Center, and Head of 6G R&D at NEC Laboratories Europe. He has served on the Organizing Committees of several conferences, published papers of high impact, and holds more than 80 granted patents. He received his PhD degree in telecommunications from the Polytechnic University of Catalonia, Barcelona, and was the recipient of a national award for his PhD thesis.

VOLUME ,

19

Record · ID 410988 · SHA-256 c3a8413b717a56e9
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.