arXiv CSopen access

Untangling Co-Drift: Proactive Multi-Intent Failure Prediction and Root-Cause Disambiguation for Self-Driving Networks

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

1

Untangling Co-Drift: Proactive Multi-Intent Failure Prediction and Root-Cause Disambiguation for Self-Driving Networks

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

Md. Kamrul Hossain, Walid Aljoby

Abstract—The vision of self-driving networks that monitor, reason, and act upon themselves with minimal human intervention relies on tightly coupled monitoring, analytics, and actuation functions. In this work, we treat these functions as three operational macro-intents: continuous telemetry (monitoring), real-time analytics (inference and control), and programmatic actuation (rule deployment), and formalize the health of each function as an intent that the network must continuously satisfy. A critical, yet underexplored, challenge stems from the causal coupling among these intents, where a singular fault within one macro-intent propagates as a co-drift and subsequently triggers cascading, symptomatic anomalies across the remaining intents. This ambiguity makes it exceedingly difficult for existing, reactive approaches to distinguish the true root-cause intent from symptomatic victim intents, and their reliance on threshold-crossing detection leaves insufficient time for proactive remediation. We introduce MILD (Multi-Intent Learning and Disambiguation), a novel framework that reformulates intent assurance from reactive drift detection to proactive failure prediction. Grounded in our three-macro-intent formulation of the self-driving control loop, MILD employs a teacher-augmented Mixture-of-Experts architecture with a hybrid objective that jointly optimizes intent failure prediction and root-cause attribution. MILD enables KPI-level diagnostics via SHAP explainability and dynamic intent failure urgency estimation via multi-horizon modeling. Our extensive evaluation of MILD across three environments of increasing realism, from a controlled statistical benchmark, to a microservices application, to an SDN-based edge-to-cloud testbed, demonstrates that MILD achieves high failure detection rates, strong remediation lead times, and accurate intent-level root-cause disambiguation. This positions MILD as a practical enabler of closed-loop assurance in next-generation autonomous networks. Index Terms—Intent-Based Networking (IBN), Intent Drift, Intent Failure, Mixture-of-Experts (MoE), Root-Cause Disambiguation, Self-driving Networks

I. INTRODUCTION

M

ODERN networks are increasingly expected to operate as self-driving networks that continuously monitor, reason about, and act upon themselves in a closed loop, with minimal human intervention [1]–[3]. Realizing this vision in cloud-native enterprise, data-center, and 5G/6G networks has introduced unprecedented operational demands, motivating a shift from imperative configuration to Intent-Based Networking (IBN) [4]–[6]. Following RFC 9315 [7], IBN leverages programmable infrastructures [8], [9] to translate high-level declarative goals into verifiable low-level configurations and (Corresponding author: Walid Aljoby.) Md. Kamrul Hossain is with Information and Computer Science Department, King Fahd University of Petroleum and Minerals, Dhahran 31261, Saudi Arabia. Walid Aljoby is with Information and Computer Science Department, and IRC for Intelligent Secure Systems, King Fahd University of Petroleum and Minerals, Dhahran 31261, Saudi Arabia.

maintain compliance through continuous, closed-loop assurance. A critical component of the IBN paradigm is intent assurance [10], [11], the continuous process of verifying that the network’s operational state complies with its intended goals. When this compliance is broken, an intent failure starts, leading to a service disruption or an SLA violation. Often, these failures are preceded by intent drift [7], a subtle and gradual deviation of the network’s behavior from its intended state that, if unaddressed, culminates in an intent failure. Solving intent drift raises two challenges that existing work has yet to jointly address. First, detection must be proactive: early drift detection is necessary but insufficient, as what autonomous network management demands is prediction with enough lead time to intervene before a service disruption occurs. Second, and more critically, modern IBN environments are multi-intent systems, in which multiple intents coexist, interact, and share infrastructure. As a result, a fault in one intent can propagate to others and generate ambiguous, cascading symptoms. The observed alert may originate from one intent, while the others are merely victims of the same underlying fault. Current methods struggle to disambiguate this cause–victim relation, which limits both attribution and remediation [10], [12]–[14]. The cornerstone of intent drift detection is the real-time analysis of network Key Performance Indicators (KPIs) [10], [15]. Anomalous KPI trends, such as sustained increases in latency, drops in throughput, or unusual fluctuations in resource usage, are often the earliest tangible precursors to intent drift [6], [10], [15]. Yet, current approaches typically treat these KPIs as independent, single-intent signals. They alarm only once a given metric crosses a fixed threshold, well after degradation is already significant [10], [12], [14]. This single-KPI, single-intent view is precisely why multiintent ambiguity remains unresolved. Without a model of how faults propagate across coexisting intents, an observer cannot tell whether an anomalous KPI reflects a root cause or a downstream symptom. This ambiguity is especially consequential when the coexisting intents are not arbitrary tenant services, but the very functions that realize the self-driving loop itself. Indeed, the assurance loop described above is not merely applied to the network, it is realized by network services. A telemetry pipeline that feeds it observations, an analytics engine that performs its reasoning, and an API/actuation layer that carries out its decisions, each of which is itself governed by an intent. A self-driving network is therefore only as reliable as the intents governing its own monitoring, analytics, and actuation functions. Consequently, a KPI-level fault within one of these functions is not merely an application-level issue

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

but a fault inside the assurance loop, one that can silently propagate and compromise the loop’s ability to close. To illustrate this recursive dependency, consider the self-driving loop realized as three co-located microservice intents, an API gateway, a telemetry pipeline, and an analytics service, sharing edge resources [16], [17]. A root-cause CPU fault on the analytics service intent can degrade its throughput and trigger cascading symptoms, such as API latency spikes and telemetry queue backpressure. The resulting KPI traces appear correlated across all intents. This co-drift behavior confounds conventional detectors, making it exceedingly difficult to untangle the true root-cause intent from symptomatic victims or estimate failure urgency. We formalize this recursive structure by casting the selfdriving control loop, spanning monitoring, analytics, and actuation, into three representative macro-intents, and build our problem formulation around this abstraction rather than around any single application. A Telemetry Intent governs a data ingestion pipeline responsible for collecting, buffering, and forwarding monitoring data, where ‘ingestion’ refers to this collection and queuing process (monitored by KPIs like telemetry queue length, indicating potential backpressure). An Analytics Intent governs a data processing service performing computations on the ingested telemetry (monitored by KPIs like analytics throughput). An API Intent governs a requesthandling gateway responsible for serving user or service requests with low latency and high availability (monitored by KPIs like api latency). These intents map directly onto the self-driving loop’s Monitoring, Analytics-and-Control, and Writing-Rules-and-Actions blocks (Sec. III-A), so that any self-driving network can be treated as an instance of the same three-intent structure. They are monitored via a combination of system-level KPIs (e.g., CPU%, Mem%) and applicationspecific KPIs (e.g., api latency, telemetry queue, and analytics throughput as detailed in Table II). This formulation captures both the shared underlying infrastructure and the distinct intent-level behaviors that must be jointly monitored and disambiguated. Building on this three-intent abstraction, we introduce MILD, a framework that reformulates intent assurance from reactive drift detection to proactive intent failure prediction. This predictive objective is the key to advancing the state of the art as it compels the model to learn the subtle, causal patterns within ambiguous KPI signals that precede an ultimate failure event. This approach not only provides earlier warnings of impending failures but also enables intent-level disambiguation to identify the true root-cause intent from symptomatic victim intents. MILD is built around a teacher-augmented Mixture-ofExperts (MoE) architecture [18], where the gating network is explicitly supervised to resolve root-cause ambiguity under codrift. A composite loss function combines lead-time-weighted focal loss, knowledge distillation, gate supervision, and expert decorrelation to jointly optimize prediction and attribution. We summarize the main contributions of this work as follows: • We formulate intent assurance around the three macrointents of a self-driving network—Telemetry, Analytics,

2

and API—and model their causal dependency chain to capture co-drift, where a fault in one intent propagates symptoms to the others. Additionally, we reformulate reactive intent drift detection into a proactive multiintent failure prediction problem. • We develop a holistic framework, MILD, that operationalizes this predictive formulation, using a specialized MoE architecture to achieve multi-intent failure prediction and intent-level disambiguation in co-drift scenarios. • We extend MILD with a suite of operational intelligence techniques, including post-hoc KPI-level disambiguation via SHapley Additive exPlanations (SHAP) [19] to identify root-cause KPIs and multi-horizon modeling for dynamic intent failure urgency estimation. • We validate MILD on three environments: a controlled statistical benchmark, a containerized microservices testbed, and an SDN-based edge-to-cloud testbed. These datasets explicitly model co-drift, non-linear interactions, and causal ambiguity across intents. We release these datasets to facilitate future research in this domain. II. R ELATED W ORK The concept of self-driving networks, as an autonomous system combining query-driven measurement, automated inference, and programmatic control, was articulated in early visionary work [1], [2]. That vision explicitly calls for closing the control loop by coupling real-time telemetry with machine-learning-based inference and SDN-based actuation. We concretize this vision in the IBN context by formalizing the monitoring, analytics/control, and actuation functions of the self-driving loop as operational intents (Itel , Ianl , Iapi ) and by framing proactive intent assurance as the core problem that must be solved for the loop to remain closed under faults. While prior IBN assurance work [10], [12], [15] addresses individual components of this loop, none models the telemetry, analytics, and actuation functions as a causally coupled system with inherent co-drift dynamics. Achieving proactive and precise intent assurance that simultaneously predicts failures and disambiguates root causes remains an open challenge in IBN. The core problem is not just detecting intent drift, but predicting a future failure early enough to prevent service impact. While recent work such as NetIntent [20] has leveraged Large Language Models (LLMs) for intent realization, its dependence on active tests (e.g., iperf, ping) and on comparing flow rules between the configuration and operational datastores [21] of the SDN controller is challenging to scale in complex, large-scale networks. Another common strategy involves forecasting individual KPIs using time-series models (e.g., LSTMs [13], [22]) or classifiers (e.g., SVMs [23]) and flagging violations against static thresholds. However, these single-KPI forecasts lack the multivariate context necessary to resolve multi-intent ambiguity, where a single fault triggers cascading symptoms across multiple interacting services [17], [24]. Recent works [10], [15], [25] have attempted to formalize the concept of intent drift. The work [15] used an unsupervised method by applying the clustering algorithm DBSCAN to

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

SELF-DRIVING-NETWORK INTENTS

FEATURE ENGINEERING

Telemetry Intent (Monitoring)

Multi-Intent KPI Streams

3

MILD CORE

Teacher Model

OPERATIONAL INTELLIGENCE

EVALUATION ENVIRONMENTS

Failure Prediction Risk Scores

Statistical Benchmark

Shared Encoder Analytics Intent (Inference & Control)

Gating Network Intent Experts

API Intent (Actuation)

• Co-Drift • Root-Cause Ambiguity

Rolling Statistics Mean / Std Trend Features

Prediction Heads

Disambiguation Root-cause, Victim

Microservices Testbed

Explainability SHAP Root-Cause KPIs Multi-Horizon Modeling Failure Urgency Estimation

Edge-to-Cloud SDN Testbed

Hybrid Loss: • Distillation • Gate Supervision • Teacher KL • Decorrelation

Fig. 1. Overview of the proposed framework. KPI streams from the three macro-intents of a self-driving network (Telemetry, Analytics, and API) are transformed into engineered features and processed by a teacher-augmented MoE architecture. The framework jointly performs proactive failure prediction and root-cause disambiguation through a hybrid optimization objective combining distillation, gate supervision, teacher alignment, and expert decorrelation. Operational intelligence is provided through SHAP-based KPI explanations and multi-horizon time-to-failure estimation.

telemetry data to identify anomalous patterns that signify a deviation from normal behavior. While valuable in environments without labeled data, this approach is not trained to recognize the specific multi-variate patterns that are predictive of a future failure and is also prone to false positives from benign network changes. More recent state-of-the-art approaches defined intent drift in terms of KPIs as a deviation from a target state and used LLMs to generate corrective policies [10], [12]. While useful, these methods are inherently reactive. They are designed to detect a drift’s existence but not its urgency, as they provide no estimate of the time-to-failure. This leaves an unquantified and often insufficient window for proactive remediation. As such, neither of these approaches is explicitly designed to learn the subtle precursors to an impending failure within a specific future window, nor do they offer a solution for the critical task of root-cause disambiguation in multi-intent scenarios. Recent work [26] has also explored proactive intent drift prediction at the link level by combining performance forecasting with path similarity, but it remains focused on localized drift detection rather than multi-intent failure disambiguation. Other studies [11], [27] address runtime conflict handling in multi-intent settings, yet they do not model early KPI precursors or root-cause ambiguity under co-drift. Monitoringdriven assurance pipelines for application transitions [28] further show the value of real-time telemetry, but they target application-state changes rather than fixed-horizon failure prediction. Beyond intent drift, approaches specifically targeting rootcause analysis (RCA) in distributed environments primarily rely on statistical graph traversals and LLMs to isolate system faults. For instance, frameworks like MicroRCA [29] and CauseInfer [30] construct dependency and causality graphs to trace anomalies across services, while advanced agentbased systems like MicroRCA-Agent [31] and TAMO [32] orchestrate LLMs to fuse multimodal telemetry into comprehensive diagnostic summaries. Despite their localized effectiveness, these methods share a fundamental limitation: they are strictly reactive, initiating computationally heavy or post-

hoc diagnostic workflows only after an explicit SLA violation or error has already manifested. Consequently, they struggle to provide actionable early warnings and remain vulnerable to ambiguous, cascading co-drift scenarios. We bridge these gaps by reformulating the task from reactive drift detection to proactive, fixed-horizon failure prediction. While this predictive technique has been applied to general network outages [33], [34], its application to the specific challenges of IBN assurance has been underexplored. To the best of our knowledge, MILD is the first framework that jointly addresses fixed-horizon intent failure prediction and root-cause disambiguation in multi-intent co-drift scenarios. MILD is explicitly trained to learn the subtle, causal precursors to an impending failure, which enables it to simultaneously achieve long, proactive lead times and, unlike prior methods, provide precise root-cause disambiguation in complex co-drift scenarios. This manuscript significantly extends our prior work [35], which introduced the core MILD architecture and presented an initial evaluation using a synthetic benchmark. The present manuscript substantially expands that work in several important directions. First, we broaden its scope by recasting MILD as a general framework for self-driving networks, where the original version represents a particular instance of a more general operational macro-intent and multi-intent system model. Second, we reformulate the problem within the broader context of self-driving networks, providing rigorous new mathematical foundations for the problem space by formalizing three operational macro-intents, intent compliance, intent drift, intent failure, and causal dependencies under co-drift events. Alongside this theoretical expansion, we provide a comprehensive architectural exposition of MILD, detailing the teacher-augmented Mixture-of-Experts design, loss formulations, and gate supervision methodology. Third, to enable evaluation under realistic application and network-level dynamics, we designed two new emulation-based testbeds: a containerized microservices application and an SDN-based edge-to-cloud environment. Finally, we conduct extensive cross-dataset evaluations, robustness analyses, ablation studies,

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

Telemetry stream

Analytics Intent (Inference/Control)

Telemetry Intent (Monitor)

Control decisions

API Intent (Actuation)

Rule deployment Programmable Switch

Fig. 2. Closed-loop control architecture for a self-driving network.

and hyperparameter sensitivity analyses, and we have opensourced all datasets and experimental artifacts to support full reproducibility. III. T HE MILD F RAMEWORK A. Motivation: The Three Macro-Intents of a Self-Driving Network The vision of a self-driving network, as articulated in seminal work on autonomous network management [1], [2], centers on a continuous, closed-loop control architecture in which the network monitors itself, reasons about its own state, and takes corrective action with minimal human intervention. In these architectures, the loop is realized through tightly coupled Monitoring, Analytics/Control, and Writing Rules and Actions functions. Building on this architectural view, we cast these functions as three operational macro-intents that the network must continuously satisfy. As depicted in Fig. 2, these intents form the functional backbone of the self-driving control loop. 1) Telemetry Intent (Itel ) — Continuous Monitoring. The network must perpetually collect fine-grained, query-driven measurements from its own data plane. This intent captures the operator’s goal of maintaining an accurate, up-to-date view of system health at all times. It is realized by streaming telemetry pipelines (e.g., in-band network telemetry, Prometheus scraping) and is characterized by KPIs such as ingestion queue length, data-plane throughput, and collection latency. A violation of this intent, for example, a growing telemetry queue that signals backpressure in the data collection pipeline, directly impairs the situational awareness on which all subsequent reasoning depends. 2) Analytics Intent (Ianl ) — Real-Time Inference and Control. The network must continuously process the collected telemetry to infer higher-level properties, detect anomalies, predict failures, and compute corrective actions. This intent corresponds to the Analytics and Control block of the self-driving loop and is realized by distributed inference engines and machine-learning models running over streaming data. It is well characterized by KPIs such as analytics throughput and CPU utilization of the inference infrastructure. A violation of

4

this intent, for example, a CPU bottleneck that degrades the processing rate, starves the control plane of the intelligence it needs to act, even when telemetry data is arriving correctly. 3) API Intent (Iapi ) — Rule Writing and Programmatic Action. The network must expose a reliable, low-latency programmatic interface through which highlevel operator policies and automatically derived rules are translated into concrete data-plane configurations. This intent corresponds to the Writing Rules and Actions block of the self-driving loop and is realized by SDN controllers, orchestrators, and their northbound APIs. It is characterized by KPIs such as end-to-end API request latency and service availability. A violation of this intent prevents corrective actions from being delivered to the network, rendering the control loop open even when the fault has been correctly identified. These three intents are not merely co-existing workloads; they form a causal dependency chain that is the backbone of any self-driving network. The Telemetry Intent feeds raw observations to the Analytics Intent; the Analytics Intent derives decisions that are enacted by the API Intent; and the outcome of those actions is, in turn, observed by the Telemetry Intent, closing the loop. This tight coupling means that a fault in any single intent propagates as cascading, symptomatic anomalies into the other two, creating a phenomenon we term a co-drift: an ambiguous multi-intent degradation pattern whose root cause is a single, primary intent but whose observable signal is spread across the entire trio. Fig. 3 illustrates an example of a canonical co-drift event in which a CPU bottleneck in Ianl (the root cause) causes queue build-up in Itel and latency spikes in Iapi (the symptomatic victims). It is precisely this co-drift ambiguity that makes self-driving network assurance fundamentally harder than single-intent monitoring. Reactive approaches that alarm only when a KPI crosses a threshold cannot distinguish whether a telemetry queue spike is a primary fault or a victim of an analytics bottleneck. The problem, therefore, requires a framework that can (i) proactively predict an impending failure before it becomes critical, and (ii) precisely disambiguate the true root-cause intent from its symptomatic victims. The proposed MILD framework is designed to solve exactly this dual problem. B. Problem Formulation We now formally define the Multi-Intent Failure Prediction and Disambiguation problem for a self-driving network governed by the three macro-intents introduced above. 1) Notation: The key mathematical symbols used throughout our formulation are summarized in Table I, where we describe each symbol explicitly for clarity. 2) System Model: Consider a self-driving network whose closed-loop operation is sustained by a set of K distinct operational intents, I = {I1 , I2 , . . . , IK },

(1)

where, concretely and without loss of generality, K = 3 with I1 ≡ Itel , I2 ≡ Ianl , and I3 ≡ Iapi as defined in

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

5

TABLE I S UMMARY OF K EY N OTATIONS Symbol

Description

System and Intent Model t ∈ Z>0 K ∈ Z>0 I = {1, . . . , K} i∗ ∈ I V ⊂I D ∈ Z>0 kt ∈ R D tfail,i H ∈ Z>0

Discrete time step index (one step = one minute in our setting). Total number of monitored intents (K = 3 in the concrete use case: Telemetry, Analytics, API). Set of intent indices. Index of the true root-cause intent in a co-drift event. Set of victim (symptomatic) intent indices, i∗ ∈ / V. Number of raw KPI signals (input dimensionality before feature engineering). Raw KPI measurement vector at time step t. The future time at which intent i will fail if no corrective action is taken. Prediction horizon, in minutes: the maximum advance warning window.

Feature Engineering D′ ≥ D xt ∈ R D

′

Teacher Model f (T ) (T ) pt ∈ [0, 1]K MILD Model Outputs fθ pt ∈ [0, 1]K gt ∈ ∆K−1

Dimensionality of the engineered feature space (includes rolling statistics). Engineered feature vector at time t: xt = ϕeng ({kt′ }t′ ≤t ). A simpler, pre-trained teacher model used for knowledge distillation. (T ) Vector of per-intent risk scores produced by the teacher model at time t; pt,i is the teacher’s estimated probability that intent i is approaching failure. The parameterized MILD model with trainable parameters θ. Vector of per-intent risk scores at time t; pt,i ∈ [0, 1] is the probability that intent i will fail within the next H minutes. P Root-cause probability distribution at time t, lying on the (K − 1)-simplex ( K i=1 gt,i = 1, gt,i ≥ 0); gt,i is the model’s confidence that intent i is the underlying root cause of any observed co-drift.

Ground-Truth Labels bin yt,i ∈ {0, 1}

Binary failure label for intent i at time t: equals 1 iff t falls within the prediction window preceding a failure, i.e., tfail,i − H ≤ t < tfail,i . ttf yt,i ≥0 Continuous time-to-failure label for intent i at time t: the remaining minutes until failure, zeroed outside the prediction window. Used to weight the loss function so that samples closer to failure are penalized more heavily. cause yt,i ∈ {0, 1} Root-cause indicator label for intent i at time t: equals 1 iff intent i is the annotated root cause and t falls within the prediction window. Used exclusively to supervise the gating network. Loss Function and Optimization Ltotal Total composite training loss, minimized end-to-end. Lhead,i Per-head loss for intent i, combining focal and distillation terms. Lgate Gate loss that trains the gating network for root-cause disambiguation. Ldecorr Decorrelation regularization loss that enforces expert diversity. α ∈ [0, 1] Mixing coefficient between focal loss and distillation loss in Lhead,i . λgate , λdecorr Scalar weights controlling the relative contribution of Lgate and Ldecorr in Ltotal . w c , w T , λs Hyperparameters of Lgate : weight on the ground-truth cause term, weight on the teacher-alignment term, and sparsity regularization coefficient, respectively. Alerting p̃t,i EWMA-smoothed risk score for intent i at time t. τi ∈ [0, 1] Alert threshold for intent i: an alert is issued when p̃t,i > τi . Γmax ≥ 0 Maximum tolerated false positive rate (alerts per day), used as a constraint during threshold tuning.

Sec.III-III-A. The health of these intents is jointly observed through a multivariate time series of D raw Key Performance D Indicators (KPIs), {kt }∞ is the vector of t=1 , where kt ∈ R all KPI measurements collected at discrete time step t (e.g., one sample per minute). Each KPI kt,d may carry information relevant to one or more intents simultaneously, and this shared observability is both what makes co-drift diagnostics possible and what makes them ambiguous. a) Intent Compliance and Drift.: Each intent Ii is associated with a compliance region Ri ⊂ RD defined over the KPI space: the network is compliant with intent i at time t if and only if kt ∈ Ri . An intent drift for intent i is a sustained, progressive deviation of the observed KPIs away from Ri , i.e., a trajectory {kt } that is moving toward the boundary of Ri and, if left unaddressed, will cross it at some future time tfail,i , constituting an intent failure. Formally, Failure of Ii at tfail,i :

ktfail,i ∈ / Ri ,

kt ∈ Ri ∀ t < tfail,i . (2)

CPU bottleneck (root fault)

Analytics Intent backpressure Analytics build Throughput Slows (analytics_tput)

Telemetry Intent Queue Grows (telemetry_queue)

request stall

API Intent Latency Increases (api_latency)

Fig. 3. Example of a canonical co-drift cascade. A CPU bottleneck in Ianl (root cause, red) propagates via causal dependency edges (dashed) to Itel and Iapi (symptomatic victims, orange), creating ambiguous, simultaneous KPI anomalies across all three intents.

b) Causal Dependency and Co-Drift.: The three macrointents are not independent. Let D ⊆ I × I denote the set of

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

directed causal dependency edges, where (i, j) ∈ D means that a failure of intent i can induce a symptomatic drift in intent j (e.g., (Ianl , Itel ) and (Ianl , Iapi ) in the cascade illustrated in Fig. 3). A co-drift event occurs when a single primary fault in the root-cause intent i∗ ∈ I propagates along the dependency edges in D, causing one or more victim intents V ⊂ I \ {i∗ } to simultaneously exhibit anomalous KPI trajectories. In such a scenario, the KPI signal is confounded: each victim intent j ∈ V will show drifting metrics not because of an intrinsic fault of its own, but as a downstream consequence of i∗ ’s degradation. This confounding is the defining challenge of multi-intent assurance. Crucially, the structural topology of D is neither assumed to be known a priori nor provided as an explicit input to our model. Instead, MILD implicitly learns to disentangle these latent cause-victim dependencies purely from data, leveraging historical event logs where codrift instances are labeled with their true root-cause intents. 3) Problem Setting: Multi-Intent Failure Prediction and Disambiguation: Given the system model above, we formally state the problem that MILD is designed to solve. Problem (Multi-Intent Failure Prediction and Disambiguation). Let I = {1, . . . , K} be the set of operational intents of a self-driving network, jointly observed through the multivariate KPI time series {kt }. The Multi-Intent Failure Prediction and Disambiguation problem requires learning a function fθ that, at each time step t and given the history of KPI observations up to t, simultaneously solves the following two sub-problems: a) Sub-Problem 1: Proactive Multi-Intent Failure Prediction: For each intent i ∈ I, produce a scalar risk score pt,i ∈ [0, 1] that remains near 0 during nominal operation (t ≪ tf ail,i ) but increases monotonically to cross an alert threshold τi at least H minutes before failure. The prediction must minimize false positives by distinguishing genuine prefailure drifts from benign transient anomalies. b) Sub-Problem 2: Root-Cause Disambiguation: Concurrently, at any time t during a pre-failure drift event, produce a decisive probability distribution gt ∈ ∆K−1 over the intent set I. The mass of gt must concentrate on the true root-cause intent i∗ even when symptomatic victims V dominate the observable KPI signals, providing clear attribution at the exact moment of the first alert (pt,i∗ first exceeds τi∗ ). a) Joint Objective: The two sub-problems must be solved simultaneously by a single model, because the disambiguation of i∗ is inherently coupled to the prediction of risk scores. Understanding which intent is the root cause directly informs how strongly each intent should be alarmed, and vice versa. A unified architecture that jointly reasons about prediction and attribution is therefore fundamentally necessary. b) Operational Intelligence.: Beyond the core dual objective, an operationally useful solution must additionally: (a) Provide KPI-level explanations for each alert, identifying which specific metrics drove the risk score, to guide human investigation. (b) Offer dynamic intent failure urgency estimation that enables operators to gauge the urgency of an impending failure as it approaches.

6

(c) Operate within a false positive budget Γmax , ensuring that the alerting system remains trustworthy in production. The MILD framework, presented in full in the remainder of this section, is the first, to the best of our knowledge, to holistically address this joint problem in the context of IntentBased Networking. 4) Fixed-Horizon Labeling Strategy: To supervise fθ , we leverage historical event logs to generate three complementary labels at each time step t for each intent i ∈ I: bin • Binary Failure Label (yt,i ∈ {0, 1}): Targets failure prediction within a horizon H:  bin yt,i = 1 tfail,i − H ≤ t < tfail,i . (3) •

ttf Time-to-Failure (TTF) Label (yt,i ≥ 0): Weights the loss function to prioritize early failure precursors: ttf bin yt,i = (tfail,i − t) · yt,i .

•

(4)

cause Root-Cause Label (yt,i ∈ {0, 1}): Supervises the gating network specifically for root-cause disambiguation:  cause bin (5) yt,i = 1 i = i∗ · yt,i .

Importantly, in a co-drift event caused by intent i∗ , we assign cause yt,i = 1. For all symptomatic victim intents j ∈ V, ∗ cause bin yt,j = 0 despite their binary labels yt,j being active. 5) Predictive Learning Formulation: To solve the joint problem stated in Sec.III-B-III-B3, we reformulate it as a supervised learning task. The raw KPI vector kt is first enriched by a feature engineering function ϕeng that computes rolling-window statistics (mean and standard deviation over windows of 5 and 15 minutes) across all base KPIs, yielding ′ the enriched feature vector xt = ϕeng ({kt′ }t′ ≤t ) ∈ RD with D′ ≫ D. This enrichment is critical since the rolling statistics encode the trend and volatility of each KPI that are more diagnostic of pre-failure drift than instantaneous values alone. A pre-trained teacher model f (T ) , which is a simpler, independently trained classifier operating on the same features, produces its own per-intent risk score vector (T ) pt = f (T ) (xt ) ∈ [0, 1]K . These teacher predictions serve two roles: (i) as a soft distillation target for the prediction heads, providing a smooth, calibrated training signal; and (ii) as an auxiliary input to the gating network, supplying a coarse first hypothesis about which intents are at risk, which the gate can then refine. The MILD model fθ is then defined as the parameterized function:
(T )
fθ : x t , p t 7−→ pt , gt , (6) where: K K is the vector of per-intent risk • pt = {pt,i }i=1 ∈ [0, 1] scores that addresses Sub-Problem 1 (Proactive Prediction). Each element pt,i is the probability, as estimated by the model, that intent i will fail within the next H minutes. K K−1 • gt = {gt,i }i=1 ∈ ∆ is the root-cause probability distribution that addresses Sub-Problem 2 (Disambiguation). The element gt,i represents the model’s confidence that

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

7

Risk- Based Alerting

Architecture of MILD Experts Network Expert 1

Expert 2

Prediction Heads

Expert K

Per- Intent Risk Scores

Proactive Alert

Head 1

...

Feature Engineering

EWMA Smoothing and Tuned Threshold

Feature Vector Head 2

Operational Intelligence Rolling- window statistics (mean, std)

Shared Encoder Teacher Prediction

SHAP analysis identifies root- cause KPIs Gating Network Head K

Raw Time- Series KPIs

Input

Root- Cause Distribution

Teacher Model

Output Fig. 4. MILD: teacher-augmented MoE with risk prediction, root-cause disambiguation, and per-alert intelligence.

henc,t = ϕenc (xt ) ∈ Rdh .

(7)

This shared representation encodes the global system state, where dh is the dimensionality of the shared latent vector, and serves as the common input to both the gating and expert sub-networks, ensuring that all intent-specific branches operate from a consistent, jointly learned view of the network.

(T )

Per-Alert Explainability

Fig. 4 shows MILD’s flow from KPI features and teacher priors to per-intent risks, root-cause gating, and EWMAthreshold alerting with SHAP explanations. The system ingests raw time-series KPIs, which are first transformed into an enriched feature vector xt by the Feature Engineering module. This vector is then processed in parallel by the pre-trained Teacher Model f (T ) and the core MILD model fθ . The MILD model itself is a teacher-augmented MoE architecture. A Shared Encoder generates a latent system representation henc,t , which is fed to both a Gating Network and K specialized Expert networks. The Gating Network, conditioned (T ) on both henc,t and the teacher’s predictions pt , produces the final Root-Cause Distribution (gt ). It also generates perexpert modulation weights (gt,i ) that scale each expert’s output before it is passed to a corresponding prediction Head. The Heads produce the final Per-Intent Risk Scores (pt ). These two outputs are then consumed by the operational layers for real-time alerting and root-cause intelligence, as detailed in Subsec. III-E and Subsec. III-F. MILD realizes the mapping fθ in Eq. (6) through the following components: • Shared Encoder (ϕenc ). A stack of dense layers maps the full engineered feature vector xt to a shared latent representation:

Gating Network (ϕgate ). This network produces the rootcause distribution gt by conditioning on both the shared latent state and the teacher’s coarse predictions. The (T ) concatenation [henc,t ; pt ] is the input, and a softmax output layer guarantees a valid probability distribution:   (T )
gt = softmax ϕgate [henc,t ; pt ] . (8)

Including pt in the gate’s input is the key teacher augmentation: the teacher’s simpler per-intent risk estimates provide an initial soft prior over which intents are at risk, which the gate can confirm or override based on the richer latent representation henc,t . This allows the gating network to leverage complementary information from two abstraction levels simultaneously, improving disambiguation accuracy especially in the early, ambiguous stages of a co-drift. • Experts Network and Prediction Heads (ϕexp,i , ϕhead,i ). Each of the K intent-specific experts ϕexp,i refines the shared latent representation henc,t into a specialized embedding of dimension de that captures the failure precursor patterns unique to intent i: Root- Cause Disambiguation

C. MILD Model Architecture

•

...

intent i is the underlying primary PKcause of any ongoing system-wide degradation, with i=1 gt,i = 1. The architecture of fθ that realizes this joint mapping is the teacher-augmented MoE model described in the following section.

hexp,t,i = ϕexp,i (henc,t ) ∈ Rde .

(9)

The gate score gt,i ∈ [0, 1] then modulates this embedding before it is passed to the i-th prediction head ϕhead,i , which maps it to a scalar risk score via a sigmoid activation: 
 pt,i = σ ϕhead,i gt,i · hexp,t,i ∈ [0, 1]. (10) This multiplicative modulation introduces a form of soft intent selection: if the gating network assigns low confidence to intent i as the root cause (gt,i ≈ 0), its expert’s embedding is suppressed, reducing its risk score; if intent i is strongly suspected as the root cause (gt,i ≈ 1), its expert’s signal is amplified. This coupling between gt and pt is what allows the model to jointly reason about prediction and attribution in a single forward pass.

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

8

D. Hybrid Optimization Framework The model is optimized end-to-end by minimizing a composite loss function that combines four distinct objectives, each addressing a specific facet of the joint problem. 1) Per-Head Loss: Lead-Time-Weighted Focal Loss and Distillation: Each prediction head i is trained by minimizing a weighted combination of two terms: Lhead,i = α Lfocal,i + (1 − α) Ldistill,i ,

(11)

where α ∈ [0, 1] controls the balance between the two terms. Lfocal,i is an early-precursor weighted focal loss [36]. The standard focal loss modulates binary cross-entropy by a focusing factor (1 − pt,i )γ , where γ ≥ 0 is a tunable focusing parameter. It down-weights easy (confidently predicted) examples and concentrates learning on hard, ambiguous samples near the decision boundary. To emphasize proactive prediction, this is further multiplied by a temporal weighting factor ltf ttf wt,i ∝ (yt,i /H), which assigns the highest penalty to samples at the beginning of the prediction window and smoothly decays to a non-zero minimum weight as t → tfail,i . This explicit temporal bias prevents the model from lazily relying on latestage, obvious failure symptoms, forcing it instead to learn the subtle, early-stage drifts that maximize operational lead time. Additionally, a static class-balancing weight is applied to the active failure windows to compensate for the rarity of failure events relative to nominal network operation. Ldistill,i is a Kullback–Leibler (KL) divergence term [37] that penalizes the difference between the model’s output distribution and (T ) (T ) the teacher’s softened predictions. Let ℓt,i = logit(pt,i ) and ℓt,i = logit(pt,i ) denote the teacher and student logits, respectively. Then: 

 (T ) Ldistill,i = KL σ ℓt,i /T σ ℓt,i /T , (12) where T > 1 is the distillation temperature, and σ(·) denotes the sigmoid activation function. Following standard knowledge distillation practice, temperature scaling is applied to the teacher and student logits before the sigmoid transformation, producing softened Bernoulli distributions for KL matching. This distillation guides the student model to match the teacher’s generalization behavior, reducing overfitting to the hard binary labels and improving robustness to unseen drift patterns. 2) Gate (Disambiguation) Loss: The gating network is trained specifically for root-cause disambiguation via three complementary objectives:

(T ) Lgate = wc KL ytcause ∥ gt + wT KL dt ∥ gt + λs

K X

gt,i (1 − gt,i ),

(13)

i=1 cause K where ytcause = {yt,i }i=1 is the vector of root-cause labels (T ) and dt denotes the teacher distribution obtained by applying temperature-scaled softmax to the teacher logits. For the KL divergence computation, ytcause is L1 -normalized to form a valid probability distribution. To prevent arbitrary routing during nominal operation, the ground-truth cause alignment term, KL(ytcause ||gt ), is explicitly masked (computed as

zero) unless an active root-cause label is present in the prediction window. Conversely, the teacher alignment term, (T ) KL(dt ||gt ), remains unmasked at all times. This design choice allows the teacher’s distribution to act as a continuous regularizer during nominal operation, gently guiding the gating network toward a stable, uncommitted state when no faults are present. We empirically found that this mechanism improves overall disambiguation performance and prevents premature overconfidence in the gating network. The three terms serve distinct roles: (i) the first term aligns gt with the groundtruth root-cause labels ytcause , directly supervising the disambiguation objective; (ii) the second term aligns gt with the (T ) teacher-derived intent distribution dt , allowing the teacher’s simpler analysis to regularize the gate’s behavior and improve generalization; (iii) the third term is a sparsity regularizer that penalizes high-entropy, non-decisive gate outputs—it is minimized when gt,i ∈ {0, 1}, encouraging the gate to make confident, single-intent attributions rather than spreading probability mass across all intents ambiguously. 3) Head Decorrelation Loss: To promote functional diversity among the K experts and prevent them from collapsing to a single, shared representation (which would negate the MoE design philosophy), we apply a DeCov regularization term [38] that penalizes the off-diagonal elements of the b ∈ RKdhead ×Kdhead of the empirical covariance matrix Σ concatenated head feature vectors across a training batch, where dhead is the hidden dimensionality of each prediction head: b − diag(Σ) b 2. (14) Ldecorr = Σ F Minimizing this term drives each expert’s learned representation to be uncorrelated with the others, ensuring that each head captures intent-specific failure precursor patterns that are orthogonal to those captured by its peers. 4) Total Training Objective: The four components are combined into a single composite loss function: Ltotal =

K X

Lhead,i + λgate Lgate + λdecorr Ldecorr ,

(15)

i=1

where the hyperparameters λgate ≥ 0 and λdecorr ≥ 0 govern the relative importance of the gate and decorrelation objectives with respect to the primary prediction objective. The full set of hyperparameters {α, λgate , λdecorr , wc , wT , λs , T } is tuned on a held-out validation set. E. Failure Prediction and Alerting The learned per-intent risk scores pt,i are translated into operational alerts through a two-stage policy. First, the raw score is smoothed using an Exponential Moving Average (EWMA) [39] with span Wi to suppress high-frequency noise and stabilize predictions: p̃t,i = EWMA(pt,i ; Wi ).

(16)

An alert for intent i is then issued at time t if the smoothed score exceeds the tuned threshold: Alert for Ii at t ⇐⇒ p̃t,i > τi .

(17)

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

9

The EWMA span Wi and threshold τi are tuned jointly via grid search on the validation set to maximize expected lead time subject to a false positive budget:   (18) max E LeadTime(τi , Wi ) τi , Wi   s.t. E FalsePositivesPerDay(τi , Wi ) ≤ Γmax . (19) This constrained formulation ensures that the alerting policy is operationally viable. Maximizing warning time is meaningful only if the false alarm rate is controlled below the operator’s tolerance Γmax . F. Disambiguation and Operational Intelligence 1) Intent-Level Disambiguation: At the time of an alert for any intent i, the gating network’s output gt immediately provides the root-cause attribution required by Sub-Problem 2. Because the gate has been explicitly trained against the y cause labels via Lgate , its output is a calibrated probability distribution over the intents that reflects the model’s causal understanding of the system, not merely a correlation-based ranking. The most likely root-cause intent is identified as: i∗ = arg max gt,i . i∈I

(20)

′

pt,i∗ ≈ µ +

ϕj (xt,j ),

(21)

j=1

where µ is a baseline expected value and ϕj is thePShapley value of feature j, satisfying the efficiency axiom j ϕj = pt,i∗ − µ. Features with large positive ϕj are the KPIs most responsible for the elevated risk score, providing immediate diagnostic guidance: the operator knows not only which intent is the root cause, but which specific metrics within that intent are driving the impending failure. 3) Dynamic Failure Urgency Estimation via MultiHorizon Models: To address operational intelligence objective (b), MILD enables deployment as an ensemble {fH1 , fH2 , . . . , fHN }, where each model fHn is trained with a different prediction horizon Hn . At inference time, the combination of alert states across models provides a dynamically tightening bound on the true TTF. Concretely, for a three-model ensemble {fHlong , fHmid , fHshort }, if fHlong alerts but fHshort does not, the estimated TTF is bounded as TTF ∈ (Hshort , Hlong ], giving operators a concrete window of urgency for scheduling remediation. As the failure approaches and shorter-horizon models begin to alert, this bound narrows,

Only H=120 Active Early Warning Stage

Prepare

Plan Action

Only H=120 and H =60 Active Risk Increasing

Mitigate

H=120, H =60, and H=30 Active Failure Imminent

H=60

H=120

>120 min

60–120 min

H=30

30–60 min

< 30 min

Failure

Fig. 5. Multi-horizon MILD deployment. Multiple models trained at different prediction horizons (e.g., H = 120, H = 60, and H = 30 minutes) provide progressively refined estimates of failure urgency. TABLE II BASE KPI S U SED F OR DATASET P REPARATION KPI Name

Description

Category

CPU Mem

CPU utilization percentage Memory utilization percentage Disk utilization percentage

System Resource System Resource

Composite network health score Composite service reliability score Length of the data ingestion queue Throughput of the data processing service Latency for API requests

Network Health

Disk snet

This mechanism correctly handles both simple single-drift scenarios where one gt,i is naturally dominant, and the harder co-drift scenarios, where the gate must assign high mass to i∗ despite the victims V exhibiting the most visually conspicuous KPI anomalies. 2) KPI-Level Disambiguation via SHAP: To provide operators with the granular, KPI-level explanation required by operational intelligence objective (a), each alert on the identified root-cause intent i∗ is accompanied by a SHAP analysis. For the alert at time t, SHAP computes the contribution ϕj of each input feature xt,j to the final risk score pt,i∗ : D X

No Horizon Active Low Risk

sri telemetry queue analytics tput api latency

System Resource

Network Health Intent-Specific Intent-Specific Intent-Specific

providing a continuously updated countdown of urgency. This is illustrated in Fig. 5 where each model answers a different question. For example, the long-horizon model (trained with H=120 min) predicts whether a failure is likely within the next two hours; the medium-horizon model (H=60 min) predicts whether a failure is likely within the next hour; and the short-horizon model (H=30 min) predicts whether a failure is likely within the next thirty minutes. IV. DATASET G ENERATION In this section, we describe how we designed three datasets for the evaluation of MILD. Our datasets not only follow the behavior of real-world network KPIs but also contain precisely labeled, complex failure scenarios that are difficult to isolate in operational data. Such complexity arises frequently in modern distributed systems like cloud-native applications and microservices [16], [17]. Each dataset begins with the 8 base KPI features shown in Table II, representing our raw input dimension D = 8. While the system resource and intent-specific KPIs are standard metrics, the network-level KPIs (snet and sri) are bounded composite scores (0–100) whose generation methodology reflects the specific evaluation environment. In the microservices testbed, they are generated using seasonal drift with stochastic variation and injected fault penalties. Conversely, in the SDNbased testbed, they are derived from active network measurements where snet summarizes actual packet loss, excess delay,

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

and jitter from active ICMP probes, while sri combines the rolling HTTP request success ratio with excess latency and packet loss to characterize end-to-end service reliability. Within the machine learning pipeline, these base KPIs (raw time-series data) are augmented by computing rollingwindow statistics (mean and standard deviation) over 5 and 15-minute windows. In addition, two more features are added, CPU delta and sri delta, which are computed as the firstorder temporal difference with respect to the features CPU and sri, respectively. Together, these rolling statistics and temporal differences expand the raw measurements into the enriched input feature space (dimension D′ ). Finally, target features (labels) are generated from the annotated events based on the fixed-horizon labeling strategy detailed in Sec. III-B-III-B4. For each intent, this creates the three distinct labels required for MILD’s hybrid loss function: a binary label (y bin ), a continuous TTF label (y ttf ), and the root-cause label (y cause ).

A. Controlled Statistical Benchmark To establish a rigorous baseline for MILD, we developed a Python-based algorithmic data generator that produces a highly controlled, multivariate time-series benchmark. Unlike operational data where failure conditions are often obscured, this controlled algorithmic environment allows us to inject precise, mathematically defined failure signatures. The baseline KPIs are modeled to reflect realistic operational patterns, incorporating seasonality for day/night cycles and Gaussian noise for natural system fluctuations. Progressive metric degradation during failure events is modeled via localized random walks. To test model robustness against false positives, the benchmark is heavily injected with unlabeled “benign mimics” (i.e., transient anomalies that resolve independently) and random high-load periods. This reflects the challenge of distinguishing true failures in complex systems [16]. The primary feature of this benchmark is the injection of three distinct categories of labeled failure events reflecting known difficulties in real-world network operations [16], [17]: Simple Independent Drifts: Standard single-intent failures where one KPI degrades. • Non-Linear Failures: Complex single-intent failures where the drift is triggered by subtle, non-linear interactions between multiple KPIs (e.g., XOR-style dependencies). These scenarios represent situations where simple thresholding or linear models often fail because individual metrics might appear normal [16]. • Multi-Intent Co-Drifts: Scenarios where a single underlying fault creates ambiguous, cascading symptoms across multiple intents, mirroring the challenges of rootcause analysis in distributed microservice systems where failure propagation is common [16], [17]. One intent is explicitly labeled as the root cause and another as a symptomatic victim.

•

The final benchmark consists of 200,000 minutes of perminute KPI data, weighted heavily towards complex scenarios to rigorously test the model with 60% non-linear failures, 20% multi-intent co-drifts, and 20% simple independent drifts.

10

Load Generator (Host Process)

API (:8000)

ANALYTICS (:8000)

TELEMETRY (:8000)

Export Metrics (/metrics)

PROMETHEUS CENTRAL COLLECTOR (:9090)

Export Host/Container Metrics

cAdvisor (:8080)

Query for Metrics

NET (:8003, snet/sri)

Collector Script

Fig. 6. Containerized microservices emulation testbed for KPI generation and monitoring. TABLE III C OMPONENTS AND T RAFFIC P ROFILES OF THE M ICROSERVICES E MULATION T ESTBED Component / Traffic

Nature / Example

System Components Load generator API service (8000)

Host process Container service

Function / Purpose

Simulates user requests Processes requests, reports latency Analytics service Container service Processes jobs, reports (8001) throughput Telemetry service Container service Ingests events, reports (8002) queue size Network KPI service Container service Provides network-level KPIs Prometheus Monitoring server Scrapes metrics from services cAdvisor Monitoring exporter Reports host/container usage Data collection module Data collector Queries metrics, builds dataset Traffic Types API request Analytics job submission Telemetry event ingestion Metrics scraping Host/container monitoring

GET /work POST /submit

Simulate user requests Simulate analytics jobs

POST /ingest

Simulate event ingestion

GET /metrics cAdvisor metrics

Collect service KPIs Collect system KPIs

B. Emulation-Based Datasets While the statistical benchmark enables controlled evaluation of complex failure patterns, it does not fully capture the dynamics of real-world systems. To complement this, we design two emulation-based testbeds that generate realistic KPI time series data under varying conditions. These environments enable the modeling of multi-intent interactions, network impairments, and service-level dependencies, which are essential for evaluating MILD in practical scenarios. We use the same KPIs as mentioned in Table II. 1) Microservices Emulation Testbed: To capture application-level dynamics, we built a containerized microservices testbed (Fig. 6). Three representative services (API, Analytics, and Telemetry) map to latency, throughput, and queue-based intents. A load generator simulates user

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

11

V. E XPERIMENTAL R ESULTS

Control Plane Ryu SDN Controller

G /w ET or k

Data Plane

Load Generator

Experiment Logic

s1: LAN edge OVS switch

s2: WAN core OVS switch

s3: Cloud edge OVS switch

Latency / loss injection

POST /submit ST st PO nge /i

Prometheus

KPI time series

metrics (latency, throughput, queue)

Client/Monitor

API service (latency intent) Analytics service (throughput intent) Telemetry service (queue intent)

To ground our experiments, we use the tangible, real-world scenario introduced in Sec.I. Our model is designed to assure the performance of a distributed, cloud-native application by monitoring three representative intents: the API Intent, Telemetry Intent, and Analytics Intent. The health of these intents is monitored using a set of fundamental system-level and application-specific KPIs summarized in Table II. A. Experimental Setup

Fig. 7. SDN-based edge-to-cloud emulation testbed. TABLE IV C OMPONENTS AND T RAFFIC P ROFILES OF THE SDN- BASED E MULATION T ESTBED Component / Traffic

Nature / Example

Function / Purpose

System Components Client/monitor host

Host node

API service host Analytics service host Telemetry service host LAN edge switch

Virtual host/server Virtual host/server Virtual host/server OVS switch

WAN core switch

OVS switch

Cloud edge switch

OVS switch

SDN controller (Ryu) Prometheus

Control plane comp. Monitoring server

Experiment logic

Controller script

Runs load generator, Prometheus, experiment logic Runs API service Runs analytics service Runs telemetry service Connects client to network edge Represents core network segment Connects services at cloud edge Controls switch forwarding via OpenFlow Scrapes metrics from services Injects faults, collects metrics, writes dataset

Traffic Types API workload Analytics workload Telemetry workload

GET /work POST /submit POST /ingest

Ping probes HTTP probes Prometheus scrapes OpenFlow control messages

ICMP ping HTTP requests GET /metrics Control traffic

Simulate user requests Simulate analytics jobs Simulate telemetry/event ingestion Measure delay/loss Measure reachability Collect KPIs Install/learn forwarding behavior

requests while Prometheus and cAdvisor continuously collect application and system-level KPIs (Table III), yielding multi-variate traces that reflect service behavior and resource contention. 2) SDN-based Edge-to-Cloud Emulation Testbed: To evaluate network-induced impairments, we implemented a Ryucontrolled SDN testbed (Fig. 7) spanning LAN edge, WAN core, and cloud edge segments via Open vSwitch. Application traffic traverses this topology while we inject controlled latency and packet loss into the WAN core (Table IV). These network impairments directly impact service-level KPIs, generating complex, fast-propagating co-drift cascades across multiple intents.

In this section, we describe the experimental setup used for evaluating MILD across all datasets. Across all experiments, MILD was trained using the Adam optimizer with a learning rate of 1 × 10−3 . A blocked cross-validation strategy was employed to prevent temporal leakage, ensuring that each model was trained exclusively on historical data preceding the test block. Training data was further partitioned into an 80/20 split for training and validation. Early stopping was applied with a patience of 8 epochs, monitoring the validation loss. The core MILD architecture remained identical across all datasets. However, several operational hyperparameters were selected independently for each dataset through validation-based sensitivity analysis to account for differences in temporal scale, failure dynamics, and alerting requirements. These hyperparameters include the prediction horizon H, false-positive budget, distillation coefficient (α), gate cause-supervision weight (wc ), gate teacher-alignment weight (wT ), gate sparsity coefficient (λs ), batch size, and number of training epochs. The distillation temperature was fixed at T = 2.0 for all experiments. The statistical benchmark employed a longer prediction horizon (H = 120 min), a stricter false-positive budget of 1 alert/day, 10-fold blocked cross-validation (leveraging its extensive data volume), a batch size of 512, and 30 training epochs. The selected MILD hyperparameters were α = 0.9, wc = 0.7, wT = 0.7, and λs = 0.005. The microservices emulation testbed dataset employed a shorter prediction horizon (H = 50 min), a false-positive budget of 3 alerts/day, and 3-fold blocked crossvalidation. This adjustment in folds compared to the statistical benchmark was made to ensure sufficient temporal samples remained within each block given the smaller total volume of emulation data. The selected hyperparameters were α = 0.6, wc = 0.6, wT = 0.3, and λs = 0.005, with a batch size of 128 and 20 training epochs. The SDN-based edge-to-cloud emulation testbed dataset also used a false-positive budget of 3 alerts/day and 3-fold blocked cross-validation (for the same data-scarcity considerations), but with a shorter prediction horizon (H = 15 min) that reflects the faster dynamics of network-induced failures. The selected hyperparameters were α = 0.7, wc = 0.6, wT = 0.3, and λs = 0.002, with a batch size of 256 and 20 training epochs. B. Baselines We compare MILD against five representative baselines trained and evaluated under identical conditions: WKPITuned, a heuristic computing risk scores via pre-trained

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

TABLE V P ERFORMANCE OF MILD ON THE S TATISTICAL B ENCHMARK

12

TABLE VII P ERFORMANCE OF MILD ON THE M ICROSERVICES E MULATION T ESTBED

Metric

Details

Value (mean ± std)

Metric

Details

Value (mean ± std)

Failure Detection Rate (%)

Analytics API Telemetry

96.67 ± 10.00 100.00 ± 0.00 100.00 ± 0.00

Failure Detection Rate (%)

Analytics API Telemetry

82.34 ± 1.03 99.10 ± 0.62 92.51 ± 0.34

Avg. Lead Time (min)

Analytics API Telemetry

91.53 ± 7.73 97.63 ± 12.04 111.10 ± 10.07

Avg. Lead Time (min)

Analytics API Telemetry

29.73 ± 0.72 34.30 ± 1.77 31.25 ± 0.58

FP Rate per Day

Overall

4.97 ± 6.03

FP Rate per Day

Overall

8.17 ± 0.67

Disambiguation Accuracy (%)

Root Cause Acc.

89.67 ± 10.04

Disambiguation Accuracy (%)

Root Cause Acc.

66.80 ± 0.13

TABLE VI C OMPARISON WITH BASELINES ON THE S TATISTICAL B ENCHMARK Model MILD MLP LSTM WKPI-Tuned Dist-Target LR-OvR

TABLE VIII C OMPARISON WITH BASELINES ON THE M ICROSERVICES E MULATION T ESTBED

Detection (%) Lead Time (min) FP/Day Disamb. Acc. (%) 98.89 99.44 97.11 99.07 78.39 99.44

100.09 92.77 88.13 78.42 57.95 82.67

4.97 5.05 5.35 15.73 9.40 6.23

89.67 81.03 80.60 66.68 60.82 79.02

Logistic Regression coefficients; Dist-Target [10], a targetbased method measuring Euclidean distance between current KPIs and a ‘healthy’ target vector; LR-OvR [40], [41], independent One-vs-Rest Logistic Regression classifiers per intent; and MLP & LSTM, standard supervised neural networks (a multi-layer perceptron and a sequential LSTM) featuring shared encoders and per-intent sigmoid heads. All baseline outputs are EWMA-smoothed and converted into alerts via thresholding. To ensure a fair and rigorous comparison, all baselines were trained and evaluated under an identical experimental environment as MILD. For reproducibility, all random processes (including data generation, model initialization, and data splitting) were controlled with a global random seed of 42. For compact comparison, detection rates and lead times are reported as macro-averages across intents for all three datasets. We provide the complete implementation of MILD as well as the datasets publicly on GitHub [42]. C. Results on the Statistical Benchmark Evaluated via 10-fold blocked cross-validation, MILD’s performance on the Statistical Benchmark (Table V) demonstrates high reliability, achieving a 98.89% average Failure Detection Rate. Critically, these predictions provide substantial lead times (averaging 100.09 minutes), offering a substantial operational window for proactive remediation while maintaining a low False Positive Rate (4.97 alerts/day). Furthermore, MILD successfully resolves multi-intent ambiguity by correctly identifying the true root cause in 89.67% of both co-drift and single-intent failures. Compared to representative baselines (Table VI), MILD achieves the most balanced profile. While models like MLP and LR-OvR achieve comparable detection rates, they suffer from significantly shorter lead times and weaker root-cause identification (e.g., MLP: 81.03%). MILD uniquely combines high detection performance, the longest warning horizon, and superior causal attribution.

Model MILD MLP LSTM WKPI-Tuned Dist-Target LR-OvR

Detection (%) Lead Time (min) FP/Day Disamb. Acc. (%) 91.32 79.77 86.85 0.13 11.77 9.14

31.76 24.00 29.41 6.50 7.54 9.15

8.17 4.41 19.54 3.80 11.99 61.07

66.80 41.22 59.23 0.13 5.55 7.07

D. Results on the Microservices Emulation Testbed Under realistic application-level dynamics (Table VII), MILD maintains strong predictive performance, achieving high detection rates for the API (99.10%) and Telemetry (92.51%) intents. As expected in noisier environments, the average lead time decreases to 31.76 minutes while remaining sufficient for proactive intervention. Despite complex, non-linear failure interactions, MILD achieves a Root Cause Disambiguation Accuracy of 66.80% with a controlled false positive rate of 8.17 alerts/day. Against baselines (Table VIII), MILD achieves the highest overall detection rate (91.32%). More importantly, it consistently outperforms the best baseline (LSTM) in disambiguation accuracy by over 7.6 percentage points while more than doubling the performance of the MLP baseline. Baselines that achieve lower false positive rates (e.g., WKPI-Tuned) do so at the cost of severely degraded root-cause attribution, highlighting MILD’s superior balance between detection performance, operational reliability, and causal attribution. E. Results on the SDN-based Emulation Testbed Under network-level dynamics and impairments (Table IX), MILD achieves perfect detection for the Analytics and API intents and 76.18% detection for the more challenging Telemetry intent. The tighter prediction horizon and fast failure propagation that is natural to network-driven scenarios result in an average lead time of 8.62 minutes. Despite these challenging network impairments, MILD retains a high Root Cause Accuracy of 88.97% and a stable false positive rate of 8.30 alerts/day. Comparison with representative baselines (Table X) confirms MILD’s robustness under network variability. MILD achieves the highest overall detection rate (92.06%) and substantially outperforms all competing methods in root-cause

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

TABLE IX P ERFORMANCE OF MILD ON THE SDN- BASED E MULATION T ESTBED Metric

Details

Value (mean ± std)

Failure Detection Rate (%)

Analytics API Telemetry

100.00 ± 0.00 100.00 ± 0.00 76.18 ± 10.29

Avg. Lead Time (min)

Analytics API Telemetry

10.63 ± 0.23 7.76 ± 0.64 7.48 ± 1.02

FP Rate per Day

Overall

8.30 ± 0.34

Disambiguation Accuracy (%)

Root Cause Acc.

88.97 ± 0.26

13

TABLE XI C ROSS -DATASET P ERFORMANCE S UMMARY OF MILD Dataset Statistical Microservices SDN-based

Detection (%) Lead Time (min) FP/Day Disamb. Acc. (%) 98.89 91.32 92.06

100.09 31.76 8.62

4.97 8.17 8.30

89.67 66.80 88.97

TABLE X C OMPARISON WITH BASELINES ON THE SDN- BASED E MULATION T ESTBED Model MILD MLP LSTM WKPI-Tuned Dist-Target LR-OvR

Detection (%) Lead Time (min) FP/Day Disamb. Acc. (%) 92.06 55.52 35.91 4.34 5.26 10.56

8.62 8.62 5.97 1.26 2.12 1.15

8.30 5.09 14.73 7.20 5.14 4.70

88.97 51.79 40.77 0.51 1.54 10.26

disambiguation (88.97% versus 51.79% for the strongest neural baseline). Competing methods either lose detection capability or fail to provide reliable causal attribution, positioning MILD as a robust framework for dynamic network conditions. F. Cross-Dataset Robustness Analysis Table XI summarizes MILD’s performance across all evaluation environments. For compact comparison, the false positive rates and disambiguation accuracy are reported at the overall level. The results demonstrate that MILD generalizes effectively across datasets with varying levels of realism and complexity. On the statistical benchmark, MILD achieves the highest lead times due to the longer prediction horizon and controlled environment. In contrast, the microservices and SDN-based testbeds introduce realistic noise, service interactions, and network impairments. While this naturally reduces operational lead times, MILD preserves strong early warning capabilities appropriate to each environment, demonstrating its robustness to both application-level and network-level variability. G. Operational Intelligence and Interpretability 1) Intent-Level Disambiguation: Fig. 8 illustrates MILD’s disambiguation behavior during a co-drift event in which an API failure acts as the root cause while a Telemetry failure appears as a propagated victim. Because both intents experience correlated degradation during the failure propagation window, their smoothed risk scores increase concurrently and both exceed their respective alarm thresholds. Such situations are difficult for conventional failure predictors, which can identify that multiple intents are at risk but cannot determine which intent initiated the failure. MILD resolves this ambiguity through its gating network. Although both intents exhibit high risk scores, the gating probability assigned to the API

Fig. 8. Example of root-cause disambiguation under a co-drift event, showing the evolution of intent risk scores and gating probabilities.

intent increases steadily throughout the drift window, reaching approximately 0.7 before failure, while the Telemetry gating probability decreases toward 0.3. This indicates that the model attributes the majority of the observed degradation to the API intent and treats the Telemetry degradation as a secondary consequence. The resulting separation between risk estimation and causal attribution enables MILD to identify the most likely root cause even when multiple intents simultaneously exhibit elevated risk. This provides operators with a more actionable diagnosis than risk prediction alone. 2) KPI-Level Explanation via SHAP: To provide KPI-level operational insight, every alert from MILD is accompanied by a SHAP explanation that identifies how individual KPIs contribute to the predicted risk score. Fig. 9 shows the explanation for an analytics intent failure alert generated on the SDN-based edge-to-cloud testbed. The predicted raw risk score reaches 0.896 and its smoothed score exceeds the tuned decision threshold. The prediction is driven primarily by the current analytics throughput (analytics tput), while current memory utilization (Mem) and disk utilization (Disk) provide additional positive evidence. In contrast, the 5-minute rolling mean of analytics throughput (analytics tput mean 5) contributes negatively, indicating that the model contrasts the current workload with its recent historical behavior rather than reacting to a single instantaneous KPI measurement. Additional contributions from other engineered temporal features further refine the prediction. Overall, the explanation suggests

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

14

TABLE XII A BLATION ON THE S TATISTICAL B ENCHMARK (10- FOLD BLOCKED CV). B OLD = BEST PER COLUMN ; RED = W ORST P ER C OLUMN . Variant MILD (full, proposed) w/o Distillation (α=1) w/o Gate Cause Sup. (wc =0) w/o Teacher Aug. in Gate w/o Teacher KL in Gate w/o Decorrelation (λdecorr =0)

FDR (%)

LT (min)

FP/day

DA (%)

98.89 96.11 98.89 100.0 91.11 100.0

100.09 100.47 100.31 98.27 93.83 100.04

4.97 5.13 6.49 4.13 4.78 5.77

89.67 87.04 87.61 89.71 79.22 88.67

TABLE XIII A BLATION ON THE M ICROSERVICES E MULATION T ESTBED (3- FOLD BLOCKED CV). B OLD = BEST PER COLUMN ; RED = W ORST P ER C OLUMN . Variant

Fig. 9. SHAP explanation for an analytics intent failure alert on the SDNbased edge-to-cloud testbed.

an emerging analytics workload imbalance accompanied by increasing resource utilization, providing operators with a concise rationale for the alert and clear guidance for root-cause investigation. 3) Dynamic Failure Urgency Estimation with MultiHorizon Models: The practical deployment of the multihorizon framework, conceptually illustrated earlier in Fig. 5, provides progressively refined estimates of failure urgency. To validate this operational intelligence, we evaluated an ensemble of three models trained with prediction horizons of 120, 60, and 20 minutes on the statistical benchmark. During deployment, their first alerts for the failure of the Telemetry intent occurred approximately 128, 97, and 42 minutes before the observed failure, respectively. These values represent the empirical lead times achieved in practice, rather than the nominal training horizons. As additional horizonspecific models become active, the estimated failure window becomes narrower, enabling operators to transition from early planning to increasingly urgent mitigation actions. H. Ablation Study and Hyperparameter Sensitivity Analysis To rigorously validate the contribution of each component of MILD’s hybrid loss and teacher-augmented architecture, we conduct a systematic ablation study and hyperparameter sensitivity analysis across all three evaluation environments: the statistical benchmark, the microservices emulation testbed, and the SDN-based edge-to-cloud testbed. Five ablated variants are evaluated, each obtained by disabling exactly one component while holding all other hyperparameters at their chosen values. For sensitivity analysis, α and wc , the two most influential scalar hyperparameters, are swept independently across five values while all other settings remain fixed. The four evaluation metrics are: average Failure Detection Rate (FDR, %), average Lead Time (LT, min), False Positives per Day (FP), and Root-Cause Disambiguation Accuracy (DA, %). The full MILD model appears in every table as the reference row. 1) Ablation Result Analysis: Tables XII–XIV report the ablation results. No single ablated variant dominates across

MILD (full, proposed) w/o Distillation (α=1) w/o Gate Cause Sup. (wc =0) w/o Teacher Aug. in Gate w/o Teacher KL in Gate w/o Decorrelation (λdecorr =0)

FDR (%)

LT (min)

FP/day

DA (%)

91.32 91.57 91.50 91.65 90.57 90.87

31.76 32.84 32.65 32.37 30.6 31.66

8.17 11.96 19.39 8.72 7.52 7.95

66.80 67.35 20.65 69.34 65.93 65.76

TABLE XIV A BLATION ON THE SDN- BASED E DGE - TO -C LOUD T ESTBED (3- FOLD BLOCKED CV). B OLD = BEST PER COLUMN ; RED = W ORST P ER C OLUMN . Variant MILD (full, proposed) w/o Distillation (α=1) w/o Gate Cause Sup. (wc =0) w/o Teacher Aug. in Gate w/o Teacher KL in Gate w/o Decorrelation (λdecorr =0)

FDR (%)

LT (min)

FP/day

DA (%)

92.06 80.20 95.64 76.34 59.21 90.78

8.62 8.51 8.52 7.67 7.19 8.23

8.30 8.74 8.88 7.68 6.34 8.06

88.97 87.18 87.95 81.28 67.44 88.72

all datasets; however, the full MILD model is the only configuration that avoids catastrophic failure on any single metric across all three environments, which is a critical requirement for real-world deployment. a) Gate Cause Supervision & Teacher Guidance: Gate cause supervision (wc ) is the most critical component for rootcause disambiguation. Removing it (wc = 0) collapses DA from 66.80% to 20.65% on the microservices testbed while more than doubling the false-positive rate, as the gate degenerates into an unguided correlation router. Similarly, removing the teacher KL term severely impairs both detection and attribution under noisy conditions, reducing the FDR to 59.21% on the SDN-based edge-to-cloud testbed. While removing teacher augmentation slightly improves some metrics on the statistical benchmark, it severely degrades both detection and disambiguation under severe network impairments. b) Distillation & Decorrelation: Removing knowledge distillation (α = 1) has mixed effects in cleaner environments but causes a 12.15 percentage-point FDR drop on the SDNbased edge-to-cloud testbed that highlights its role as a robustness mechanism. Finally, head decorrelation (Ldecorr ) acts as a lightweight stabilizer. Although its removal does not cause catastrophic degradation, it consistently reduces DA across all datasets, supporting expert diversity.

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

15

TABLE XV H YPERPARAMETER SENSITIVITY ON THE S TATISTICAL B ENCHMARK . B OLD = CHOSEN CONFIGURATION . Param

Value

FDR (%)

LT (min)

FP/day

DA (%)

α

0.3 0.5 0.7 0.9 1.0 (no distill.)

99.44 98.33 98.33 98.89 96.11

92.60 94.31 96.06 100.09 100.47

7.68 6.65 6.92 4.97 5.13

89.67 89.67 89.71 89.67 87.04

wc

0.0 (no Gate Sup.) 0.3 0.5 0.7 0.9

98.89 98.89 98.89 98.89 98.33

100.31 100.49 100.36 100.09 101.00

6.49 6.11 6.18 4.97 6.24

87.61 89.09 92.05 89.67 91.38

TABLE XVI H YPERPARAMETER SENSITIVITY ON THE M ICROSERVICES T ESTBED . B OLD = CHOSEN CONFIGURATION . Param

Value

FDR (%)

LT (min)

FP/day

DA (%)

α

0.3 0.5 0.6 0.7 0.9 1.0 (no distill.)

75.98 90.21 91.32 91.83 91.43 91.57

25.69 29.43 31.76 32.82 32.94 32.84

7.25 6.79 8.17 10.32 12.47 11.96

56.66 66.74 66.80 68.31 65.10 67.35

wc

0.0 (no Gate Sup.) 0.3 0.5 0.6 0.7 0.9

91.50 91.57 90.58 91.32 90.4 91.07

32.65 32.00 31.63 31.76 31.48 31.82

19.39 10.89 7.01 8.17 9.33 9.70

20.65 64.27 65.95 66.80 64.34 68.18

TABLE XVII H YPERPARAMETER SENSITIVITY ON THE SDN- BASED T ESTBED . B OLD = CHOSEN CONFIGURATION . Param

Value

FDR (%)

LT (min)

FP/day

DA (%)

α

0.3 0.5 0.6 0.7 0.9 1.0 (no distill.)

90.46 89.64 92.35 92.06 93.73 80.20

7.56 8.11 8.38 8.62 9.37 8.51

8.54 7.97 8.59 8.30 10.08 8.74

85.64 87.18 88.72 88.97 89.49 87.18

wc

0.0 (no Gate Sup.) 0.3 0.5 0.6 0.7 0.9

95.64 93.34 91.63 92.06 90.39 90.78

8.52 8.37 8.27 8.62 8.19 8.13

8.88 8.35 8.35 8.30 8.30 8.11

87.95 87.95 88.21 88.97 87.69 89.23

2) Hyperparameter Sensitivity Result Analysis: Tables XV– XVII report the model’s sensitivity to the distillation mixing coefficient (α) and the gate cause supervision weight (wc ). Because no single configuration is uniformly optimal across all environments, the chosen operating points (bolded) reflect the best dataset-specific compromise between detection sensitivity, attribution accuracy, and false-positive control. a) Distillation Coefficient (α): Balancing focal loss and teacher KL divergence, moderate-to-high α values generally yield the best performance. While α=1.0 (no distillation)

slightly extends lead times on the statistical benchmark, it increases FP/day and reduces Disambiguation Accuracy (DA) in more challenging environments. We selected α=0.9 for the controlled benchmark, and more conservative values of α=0.6 and α=0.7 for the microservices and SDN-based edge-to-cloud testbeds, respectively, reflecting their different noise characteristics and preventing FP inflation (e.g., α=0.7 increases FP/day by approximately 26% on the microservices testbed). b) Gate Cause Supervision (wc ): This parameter dictates the strength of the causal alignment term KL(ytcause ∥gt ). Setting wc =0 triggers a catastrophic DA collapse on the microservices testbed and degrades the overall operating profile on the SDN testbed, confirming the necessity of explicit causal supervision. However, larger supervision weights (wc ≥ 0.9) provide only marginal gains in DA without consistently improving the overall multi-metric profile. Consequently, moderate values (wc ∈ [0.6, 0.7]) are selected to maintain a balanced trade-off between detection performance, attribution quality, and false-positive control. VI. D ISCUSSION Real-World Deployment Pathway: Deploying MILD in production requires a phased, human-in-the-loop strategy [1], [2]. Initial pre-training on statistical benchmarks captures fundamental co-drift patterns, drastically reducing the annotation burden for subsequent fine-tuning on a small “golden dataset” of operational telemetry. Post-deployment, uncertain alerts (where maxi gt,i is below a confidence threshold) are surfaced for operator verification, driving continuous, incremental retraining. Generalizability Beyond the Three-Intent Use Case: while evaluated on three macro-intents, MILD’s architecture scales naturally. Accommodating additional intents requires only appending expert-head pairs and expanding the gate’s output dimension, making the framework readily adaptable to broader IBN environments, such as full-stack 5G slice assurance or enterprise networks. Limitations of MILD: Despite its strong performance, MILD’s supervised nature relies on post-mortem expert annotation of failure events. Furthermore, the model currently assumes a static root-cause intent per failure window. Extending this to track dynamic, cascading root causes during prolonged incidents remains an open challenge. VII. C ONCLUSION This paper introduced MILD, a framework that reformulates intent assurance from reactive drift detection to proactive intent failure prediction. By modeling the self-driving network control loop as a causally linked multi-intent system, we demonstrated how single faults trigger ambiguous co-drift anomalies. MILD resolves this through a teacher-augmented Mixture-of-Experts architecture optimized for joint failure prediction and root-cause attribution. MILD enables both intent-level root-cause disambiguation and KPI-level diagnostic explanations, as well as multi-horizon modeling for failure urgency estimation. Validated across the statistical benchmark, microservices, and SDN-based edge-to-cloud emulation

JOURNAL OF LATEX CLASS FILES, VOL. 18, NO. 9, SEPTEMBER 2020

testbeds, MILD consistently delivered high detection rates, substantial operational lead times, and root-cause attribution, remaining robust even under severe network impairments in the SDN-based testbed. Future work will focus on dataefficient semi-supervised and active learning, validation on production telemetry, and dynamic causal modeling to track shifting root causes in complex, multi-stage incidents. R EFERENCES [1] N. Feamster and J. Rexford, “Why (and how) networks should run themselves,” arXiv preprint arXiv:1710.11583, 2017. [2] Feamster and Rexford, “Workshop on self-driving networks — workshop report,” https://www.cs.princeton.edu/∼jrex/papers/ self-driving-networks18.pdf, 2018, [Accessed 07-06-2026]. [3] F. S. Ardestani, N. Saha, N. Limam, and R. Boutaba, “Towards nwdaf-enabled analytics and closed-loop automation in 5g networks,” 2025. [Online]. Available: https://arxiv.org/abs/2505.06789 [4] A. Kaushik, R. Singh, S. Dayarathna, R. Senanayake, M. Di Renzo, M. Dajer, H. Ji, Y. Kim, V. Sciancalepore, A. Zappone, and W. Shin, “Toward integrated sensing and communications for 6g: Key enabling technologies, standardization, and challenges,” IEEE Communications Standards Magazine, vol. 8, no. 2, pp. 52–59, 2024. [5] Y. Ouyang, C. Li, J. Zhang, X. Zhao, and C. Yang, “Intent-driven 6g end-to-end network orchestration,” in Proc. IEEE INFOCOM Workshop, 2024, pp. 1–2. [6] A. Leivadeas and M. Falkner, “A survey on intent-based networking,” IEEE Communications Surveys & Tutorials, vol. 25, no. 1, pp. 625–655, 2023. [7] A. Clemm, L. Ciavaglia, L. Z. Granville, and J. Tantsura, “Intent-Based Networking - Concepts and Definitions,” RFC 9315, Oct. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9315 [8] S. D’Oro, L. Bonati, M. Polese, and T. Melodia, “Orchestran: Orchestrating network intelligence in the open ran,” IEEE Transactions on Mobile Computing, vol. 23, no. 7, pp. 7952–7968, 2023. [9] A. Sharma, S. Tokekar, and S. Varma, “A comprehensive survey on network resource management in sdn enabled data centre network,” 6G Enabled Fog Computing in IoT: Applications and Opportunities, pp. 333–353, 2023. [10] K. Dzeparoska, A. Tizghadam, and A. Leon-Garcia, “Intent assurance using llms guided by intent drift,” in Proc. IEEE/IFIP NOMS, 2024, pp. 1–7. [11] M. Gharbaoui, F. Sciarrone, M. Fontana, P. Castoldi, and B. Martini, “Assurance and conflict detection in intent-based networking: A comprehensive survey and insights on standards and open-source tools,” IEEE Transactions on Network and Service Management, vol. 23, pp. 1891– 1912, 2026. [12] K. Dzeparoska and A. Leon-Garcia, “Kpi assurance and llms for intentbased management,” in Proc. IEEE/IFIP NOMS, 2025, pp. 1–9. [13] X. Zheng and A. Leivadeas, “Network assurance in intent-based networking data centers with machine learning techniques,” in Proc. IEEE CNSM, 2021, pp. 14–20. [14] S. K. Perepu, J. P. Martins, R. S. S, and K. Dey, “Intent-based multiagent reinforcement learning for service assurance in cellular networks,” in Proc. IEEE GLOBECOM, 2022, pp. 2879–2884. [15] C. Muonagor, M. Bensalem, and A. Jukan, “Performance analysis of learning-based intent drift detection algorithms in next generation networks,” in Proc. IEEE LATINCOM, 2024, pp. 1–6. [16] J. Soldani and A. Brogi, “Anomaly detection and failure root cause analysis in (micro) service-based cloud applications: A survey,” ACM Comput. Surv., vol. 55, no. 3, Feb. 2022. [Online]. Available: https://doi.org/10.1145/3501297 [17] L. Wang, C. Zhang, R. Ding, Y. Xu, Q. Chen, W. Zou, Q. Chen, M. Zhang, X. Gao, H. Fan, S. Rajmohan, Q. Lin, and D. Zhang, “Root cause analysis for microservice systems via hierarchical reinforcement learning from human feedback,” in Proc. ACM SIGKDD, ser. KDD ’23. New York, NY, USA: Association for Computing Machinery, 2023, p. 5116–5125. [Online]. Available: https://doi.org/10.1145/3580305.3599934 [18] Z. Chen, Y. Deng, Y. Wu, Q. Gu, and Y. Li, “Towards understanding the mixture-of-experts layer in deep learning,” Advances in neural information processing systems, vol. 35, pp. 23 049–23 062, 2022. [19] S. M. Lundberg and S.-I. Lee, “A unified approach to interpreting model predictions,” in Proc. NIPS, ser. NIPS’17. Red Hook, NY, USA: Curran Associates Inc., 2017, p. 4768–4777.

16

[20] M. K. Hossain and W. Aljoby, “Netintent: Leveraging large language models for end-to-end intent-based sdn automation,” IEEE Open Journal of the Communications Society, vol. 6, pp. 10 512–10 541, 2025. [21] O. Project, “Opendaylight: A linux foundation collaborative project,” 2015, accessed: 2025-01-15. [Online]. Available: https://www.opendaylight.org/ [22] J. Arellano-Uson, E. Magaña, D. Morató, and M. Izal, “Interactivity anomaly detection in remote work scenarios using lstm,” IEEE Access, vol. 12, pp. 34 402–34 416, 2024. [23] M. Gharbaoui, B. Martini, D. Berardi, and P. Castoldi, “Towards intent assurance: A traffic prediction model for software-defined networks,” in Proc. IEEE ICIN, 2025, pp. 135–139. [24] T. Zanouda, M. Masoudi, F. G. Gebre, and M. Dohler, “Telecom foundation models: Applications, challenges, and future trends,” Aug. 2024. [Online]. Available: http://dx.doi.org/10.36227/techrxiv. 172296173.35282215/v1 [25] M. K. Hossain and W. Aljoby, “Lead-drift: Real-time and explainable intent drift detection by learning a data-driven risk score,” 2026. [Online]. Available: https://arxiv.org/abs/2602.13672 [26] H. Liu, H. Li, and Y. Ai, “Refined link-level intent drift forecasting through advanced link performance prediction and path similarity approaches,” Computer Networks, vol. 275, p. 111857, 2026. [27] E. Dehghan Biyar, M. D’Angelo, J. C. Cisneros, A. Nascimento, M. Orlic, A. Likhyani, A. Zahemszky, A. C. Baktir, D. A. Temesgene, and D. Roeland, “Autonomous conflict handling in intent-based management,” Computer Networks, vol. 271, p. 111561, 2025. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S1389128625005286 [28] J. Violos, F. Voutsas, C. Diou, and A. Leivadeas, “Detecting application transitions and identifying application types for intentbased network assurance: A machine learning perspective,” Computer Networks, vol. 274, p. 111872, 2026. [Online]. Available: https: //www.sciencedirect.com/science/article/pii/S1389128625008382 [29] L. Wu, J. Tordsson, E. Elmroth, and O. Kao, “Microrca: Root cause localization of performance issues in microservices,” in Proc. IEEE/IFIP NOMS, 2020, pp. 1–9. [30] P. Chen, Y. Qi, and D. Hou, “Causeinfer: Automated end-to-end performance diagnosis with hierarchical causality graph in cloud environment,” IEEE Transactions on Services Computing, vol. 12, no. 2, pp. 214–230, 2019. [31] P. Tang, S. Tang, H. Pu, Z. Miao, and Z. Wang, “Microrca-agent: Microservice root cause analysis method based on large language model agents,” 2025. [Online]. Available: https://arxiv.org/abs/2509.15635 [32] X. Zhang, Q. Wang, M. Li, Y. Yuan, M. Xiao, F. Zhuang, and D. Yu, “Tamo:fine-grained root cause analysis via tool-assisted llm agent with multi-modality observation data in cloud-native systems,” IEEE Transactions on Services Computing, vol. 18, no. 6, pp. 4221–4233, 2025. [33] E. Basikolo and T. Basikolo, “Towards zero downtime: Using machine learning to predict network failure in 5g and beyond,” ITU Journal on Future and Evolving Technologies, vol. 4, no. 3, pp. 434–446, 2023. [34] M. Züfle, J. Agne, J. Grohmann, I. Dörtoluk, and S. Kounev, “A predictive maintenance methodology: Predicting the time-to-failure of machines in industry 4.0,” in Proc. IEEE INDIN, 2021, pp. 1–8. [35] M. K. Hossain and W. Aljoby, “Mild: Multi-intent learning and disambiguation for proactive failure prediction in intent-based networking,” 2026. [Online]. Available: https://arxiv.org/abs/2602.14283 [36] T.-Y. Lin, P. Goyal, R. Girshick, K. He, and P. Dollár, “Focal loss for dense object detection,” in Proc. ICCV, 2017, pp. 2980–2988. [37] G. Hinton, O. Vinyals, and J. Dean, “Distilling the knowledge in a neural network,” arXiv preprint arXiv:1503.02531, 2015. [38] M. Cogswell, F. Ahmed, R. Girshick, C. L. Zitnick, and D. Batra, “Reducing overfitting in deep networks by decorrelating representations,” in 4th International Conference on Learning Representations (ICLR 2016), San Juan, Puerto Rico, May 2016. [39] R. J. Hyndman and G. Athanasopoulos, Forecasting: Principles and practice, 3rd ed. OTexts, 2021. [40] A. N. Tarekegn, M. Ullah, and F. A. Cheikh, “Deep learning for multi-label learning: A comprehensive survey,” 2024. [Online]. Available: https://arxiv.org/abs/2401.16549 [41] N. Jalodia, M. Taneja, and A. Davy, “A deep neural network-based multilabel classifier for sla violation prediction in a latency sensitive nfv application,” IEEE Open Journal of the Communications Society, vol. 2, pp. 2469–2493, 2021. [42] M. K. Hossain and W. Aljoby, “Mild: Multi-intent learning and disambiguation for proactive failure prediction in intent-based networking.” [Online]. Available: https://github.com/Muhammadkamrul/ Extended MILD