Paper deep dive
AI-driven Intent-Based Networking Approach for Self-configuration of Next Generation Networks
Md. Kamrul Hossain, Walid Aljoby
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 91%
Last extracted: 3/26/2026, 2:11:30 AM
Summary
This paper proposes an end-to-end closed-loop Intent-Based Networking (IBN) pipeline that integrates Large Language Models (LLMs) for natural language to policy translation, conflict-aware activation, and proactive multi-intent failure prediction with root-cause disambiguation to improve network automation dependability.
Entities (5)
Relation Signals (3)
Proactive Failure Prediction → improves → Intent Assurance
confidence 95% · reformulates assurance as proactive multi-intent failure prediction with root-cause disambiguation
Large Language Models → enables → Intent-Based Networking
confidence 90% · This paper proposes an end-to-end closed-loop IBN pipeline that uses large language models
Intent-Based Networking → utilizes → Software-Defined Networking
confidence 85% · SDN decouples control and forwarding to enable centralized programmability and is a key enabler for automating modern networks.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Intent-Based Networking (IBN) aims to simplify operating heterogeneous infrastructures by translating high-level intents into enforceable policies and assuring compliance. However, dependable automation remains difficult because (i) realizing intents from ambiguous natural language into controller-ready policies is brittle and prone to conflicts and unintended side effects, and (ii) assurance is often reactive and struggles in multi-intent settings where faults create cascading symptoms and ambiguous telemetry. This paper proposes an end-to-end closed-loop IBN pipeline that uses large language models with structured validation for natural language to policy realization and conflict-aware activation, and reformulates assurance as proactive multi-intent failure prediction with root-cause disambiguation. The expected outcome is operator-trustworthy automation that provides actionable early warnings, interpretable explanations, and measurable lead time for remediation.
Tags
Links
- Source: https://arxiv.org/abs/2603.23772v1
- Canonical: https://arxiv.org/abs/2603.23772v1
Trouble viewing inline? Open PDF directly →
Full Text
25,835 characters extracted from source content.
Expand or collapse full text
AI-driven Intent-Based Networking Approach for Self-configuration of Next Generation Networks Md. Kamrul Hossain ∗ , Walid Aljoby † ∗† Information and Computer Science Department, King Fahd University of Petroleum and Minerals, Dhahran 31261, Saudi Arabia † IRC for Intelligent Secure Systems, King Fahd University of Petroleum and Minerals, Dhahran 31261, Saudi Arabia (e-mail: g202215400@kfupm.edu.sa, waleed.gobi@kfupm.edu.sa) Abstract—Intent-Based Networking (IBN) aims to simplify operating heterogeneous infrastructures by translating high- level intents into enforceable policies and assuring compliance. However, dependable automation remains difficult because (i) re- alizing intents from ambiguous natural language into controller- ready policies is brittle and prone to conflicts and unintended side effects, and (i) assurance is often reactive and struggles in multi-intent settings where faults create cascading symptoms and ambiguous telemetry. This paper proposes an end-to-end closed- loop IBN pipeline that uses large language models with structured validation for natural language to policy realization and conflict- aware activation, and reformulates assurance as proactive multi- intent failure prediction with root-cause disambiguation. The expected outcome is operator-trustworthy automation that pro- vides actionable early warnings, interpretable explanations, and measurable lead time for remediation. Index Terms—Intent-Based Networking, Closed-Loop Automa- tion, Intent Assurance, Proactive Failure Prediction, Root-Cause Disambiguation I. INTRODUCTION AND MOTIVATION Software-Defined Networking (SDN) decouples control and forwarding to enable centralized programmability and is a key enabler for automating modern networks. Large-scale deployments such as Google’s B4 and Microsoft’s SWAN demonstrate its practicality and scalability [1]. Yet, operators still must translate business goals into low-level controller rules and configurations, which is a time-consuming and error- prone process. Even with mature controller ecosystems and tooling, translation and validation remain largely manual. As networks evolve toward 6G and cloud-native infrastructures, they must meet strict service requirements while also sup- porting microservices-based east–west traffic, multi-tenancy, and zero-trust segmentation. As a result, configuring each device individually is becoming increasingly complex and impractical [2], [3]. Intent-Based Networking (IBN) bridges the gap between what operators want and how the network is configured [4], with growing industry adoption. Following RFC 9315 [5], an intent is a declarative statement of goals and expected outcomes, independent of realization mechanisms. Realizing intents requires compiling them into policy artifacts and en- forcing them via controllers and orchestrators, including SDN fabrics and Open RAN SMO/RIC-based stacks [6]. Although IBN aims to automate translation, activation, and closed-loop validation, many systems still require structured intent formats (e.g., JSON/XML/YAML/NSD) [4] and bind them to specific data models and controller semantics, limiting usability and increasing misconfiguration risk in heterogeneous ecosystems. A second barrier is intent assurance which is continuously verifying that operational state satisfies intended goals [7]. Assurance is central to closed-loop automation in 5G/6G, reflected by the 3GPP NWDAF analytics function [8]. Intent violations are often preceded by intent drift [5] which is first visible as weak but persistent KPI changes [4], [7]. Many solutions remain reactive [7], [9], and the problem is harder in multi-intent settings where interacting intents produce cas- cading symptoms and ambiguous co-drifting KPIs [7], [9], [10]. For example, in cloud-native edge applications, resource contention affecting one service can degrade KPIs elsewhere, creating symptomatic victims that are hard to distinguish from the root-cause intent [11], [12]. This research targets dependable end-to-end IBN via two complementary thrusts. First, we investigate how large lan- guage models (LLMs) can enable natural language to pol- icy realization with bounded failure modes, using schema- constrained policy intermediate representation (IR) generation, context examples, and conflict-aware activation across het- erogeneous controllers. While recent efforts explore LLMs for networking/IBN [13], most emphasize translation and do not systematically address conflict detection, activation robustness, and closed-loop assurance across realistic con- troller stacks [14]–[18]. Second, we reformulate assurance as proactive failure prediction under multi-intent ambiguity. This includes learning early KPI precursors, disambiguating root- cause intents from co-drift victims, and providing operator- facing outputs such as attribution and lead-time (early warn- ing) estimates via multi-horizon modeling. Collectively, the goal is an operationally viable closed-loop IBN pipeline that (i) translates natural-language intents into verifiable, controller-ready policy artifacts, (i) activates them safely through conflict-aware deployment, and (i) assures compliance proactively in multi-intent environments with in- terpretable, actionable outputs. I. RELATED WORK IBN automates network operation through an intent lifecycle that includes translation, activation, and assurance [4]. While substantial progress has been made in individual stages, de- © 2026 IEEE. Accepted for presentation in IEEE/IFIP NOMS 2026. arXiv:2603.23772v1 [cs.NI] 24 Mar 2026 pendable end-to-end automation remains difficult in practice, particularly under heterogeneous controller ecosystems and multi-intent operational dynamics. Translation and realization: Earlier systems used rule- based NLP and programmatic logic to parse intents and generate configurations [4], [19], but natural-language vari- ability and context dependence limit their robustness. Recent work leverages LLMs for intent translation and configuration generation [9], [14]–[16], [20]. For example, NetConfEval benchmarks LLMs for mapping specifications to structured rules [16]. However, the studies rely mostly on closed-source models, evaluate limited model/dataset combinations, and of- ten stop at abstract outputs rather than controller-ready arti- facts, leaving open questions about robustness across practical controller schemas. Activation and conflict handling: Deploying intents safely requires preventing conflicts among overlapping policies. Prior SDN/IBN work categorizes conflicts and provides detection methods, supported by verification and analysis tools such as VeriFlow, NetPlumber, and Batfish [21]. Additional ap- proaches use logical evaluation, graph reasoning, and transac- tional mechanisms [4], [22]. Yet, these systems often provide limited actionable guidance on why conflicts occur and how to resolve them, and LLM-based conflict handling has so far been narrow in scope [16]. Controller-aware activation that is both verifiable and operationally actionable remains underexplored. Assurance and drift: Intent assurance verifies that op- erational behavior continues to satisfy intents [7]. Beyond static checks and flow-level invariants [4], [21], [23], many approaches monitor KPIs and detect violations after degrada- tion becomes visible. Predictive approaches forecast individual KPIs (e.g., LSTM-based forecasting with thresholding) [10] or classify near-term events (e.g., congestion prediction). Be- sides, unsupervised drift detection can help when labels are scarce [24], but may be prone to false alarms and is not optimized to learn subtle failure precursors. Recent methods treat drift as KPI deviation from targets and use LLMs to generate corrective actions [7], [9], but remain largely reactive and typically do not estimate urgency (e.g., time-to-failure). Critically, existing approaches also struggle with multi-intent ambiguity, where one fault yields cascading symptoms across multiple intents [12]. Positioning: Thus, existing work either emphasizes partial lifecycle automation (often translation) [14]–[18], [20] or provides assurance methods that are reactive or single-intent oriented [7], [9], [10], [24], [25] and can be challenging to scale. This thesis addresses these gaps by pursuing an end- to-end, controller-aware IBN pipeline that combines verifiable LLM-assisted realization (translation and conflict-aware acti- vation) with proactive multi-intent failure prediction and root- cause disambiguation, extending predictive outage modeling ideas [26], [27] to the specific challenges of IBN assurance. I. PROPOSED APPROACH Fig. 1 illustrates a holistic architecture of our proposed approach. It instantiates the classical IBN loop—translate, activate, assure—as a single pipeline that explicitly couples (i) verifiable intent realization, (i) controller-aware conflict- safe activation, and (i) proactive multi-intent assurance with actionable remediation. At a high level, natural-language intents are compiled into a schema-constrained policy IR, activated through domain adapters with enforcement feedback, and continuously assured using telemetry and observed state where assurance outputs (risk, likely root cause, attribution, lead time) drive ranked corrective actions that close the loop. We elaborate these stages in the following subsections, starting with verifiable LLM-based realization, then conflict- aware activation and enforcement checks, and finally, proactive multi-intent assurance and ranked remediation. A. LLM-Assisted Intent Realization with Verifiability Given a natural-language intent, the framework instantiates a translation prompt from a prompt template and context examples, then invokes an LLM to produce a structured policy IR (e.g., JSON/YANG-like). To bound failure modes, the output is validated against a required schema/tags where invalid outputs trigger a correction prompt and re-generation until a valid policy IR is produced. In parallel, metadata (e.g., scope, constraints, priority) is extracted from the validated policy IR to support downstream conflict checks and assurance context building. B. Conflict-Aware Activation and Enforcement Checks Before deployment, the framework performs conflict detec- tion by combining the validated policy IR, extracted metadata, and the set of existing policies/active intents (per domain). A ranked/selected LLM (router-style selection) can be used to specialize conflict analysis across domains and intent types (e.g., mixture-of-experts style selection [28]). If conflicts are detected, the framework applies a conflict-resolution policy and iterates until the conflict is resolved, and unresolved cases are escalated to the operator. Once cleared, the policy artifact is enforced through a domain adapter, followed by an explicit policy enforcement check. Importantly, enforcement failures (e.g., deployment/runtime errors) are directly fed into the as- surance context builder so corrective actions can be generated even when realization does not complete successfully. C. Proactive Multi-Intent Assurance and Remediation The assurance stage continuously aggregates operational state (telemetry and observed configuration/state) and feeds it to a proactive multi-intent assurance module, e.g., a fixed- horizon predictor with intent-level root-cause disambiguation under co-drift [29]. This module outputs early-warning signals, including per-intent risk and root-cause indications under multi-intent ambiguity, as well as KPI-level attribution and lead-time estimates. In addition, verification signals derived from telemetry provide near-real-time evidence of whether the current assurance objectives are satisfied. To drive remediation in a consistent way, the framework uses an assurance context builder / prompt composer that fuses: (i) verification signals, (i) proactive module’s outputs Natural Language Intent Correction Prompt Translation Prompt (instantiated) Context Example Set LLM for Translation Translation Prompt Template Validated Policy IR LLM for Conflict Detection Conflict Resolution Conflict Resolution Policy Conflict Exists? Valid Policy IR? Enforce Policy (Domain Adapter) Policy Enforced? LLM to Find Corrective Actions Conflict Detection Prompt Operational State (Telemetry, Config/State) Validation Feedback no no yes no yes Proactive Multi-Intent Assurance Module replace increase Set of Ranked LLMs Intent Store Validation JSON Schema, Required Tags Metadata Extraction Existing Policies + Active Intents (per domain) Conflict Resolved? Operator no yes yes Verification Signals (Telemetry) policy artifact metadata yes yes Assurance Fulfilled? yes no no Set of Ranked Corrective Actions Subroutine Execution Assurance Context Builder / Prompt Composer action info deployment failure updated state / new telemetry risk, root-cause distribution, KPI attribution, lead-time Fig. 1. Closed-loop thesis framework: LLM-assisted realization (translate+activate) coupled with proactive multi-intent assurance and ranked remediation. (risk/root-cause/attribution/lead-time), and (i) intent/policy context from the intent store. This composed assurance prompt is passed to an LLM that produces a ranked set of corrective actions. The selected actions are executed as subroutines, after which the updated state and new telemetry close the loop by feeding back into the operational state, proactive assurance module, and enforcement/assurance checks. D. Telemetry Signals for Multi-Intent Assurance We aim to leverage multiple representative application KPIs that can be used as inputs to the proactive assurance and verification stages such as CPU, RAM and storage utiliza- tion percentage, Service network throughput, Service reliabil- ity/availability index, End-to-end API request latency, Inges- tion/queue backlog length and Analytics/processing through- put. IV. CHALLENGES AND OPEN QUESTIONS While the proposed framework (Fig. 1) outlines an end- to-end pipeline for verifiable intent realization and proactive multi-intent assurance, several challenges must be addressed before reliable deployment at scale, especially in heteroge- neous and 5G/6G environments. Federation and 5G/6G multi-layer control: Moving be- yond single-domain SDN requires operating across federated domains and multi-layer control planes (core, transport, RAN), where controllers expose different abstractions, policies, and trust boundaries [2]. A practical direction is to maintain a controller-agnostic policy IR at the global layer, while using domain adapters to compile/validate domain-specific artifacts under explicit policy contracts that govern what telemetry and state can be shared [3]. Key open questions are: (i) what minimal shared schema (or capability description) is sufficient for cross-domain conflict detection; (i) how to provide safe activation guarantees when domains can reject, delay, or partially apply policies; and (i) how to validate end-to-end compliance for multi-layer intents (e.g., slice-like intents) when layers differ in observability and timescales. Data, labels, and generalization for proactive assurance: Proactive multi-intent assurance depends on learning subtle precursors of failure from KPI streams [9], yet labeled multi- intent co-drift incidents are scarce and telemetry is often noisy, missing, delayed, or biased by sampling. We therefore pursue hybrid evaluation using controlled benchmark generation for specific co-drift patterns, complemented with testbed traces and partially labeled operational logs when available. Open questions include: (i) which failure/co-drift patterns best ap- proximate realistic incidents, (i) how to quantify domain shift between synthetic and real telemetry, and (i) how to calibrate risk estimates so lead-time predictions remain trustworthy across environments. Safety controls for LLM-assisted realization: Natural- language intent expression introduces risks of incorrect or unsafe outputs (e.g., malformed artifacts or over-permissive security policies). Beyond schema validation and conflict- aware activation, deployment requires stronger controls such as constrained decoding to a typed IR, static checks (e.g., invariants and policy overlap), and staged activation (canary and rollback) [16], [23]. A central open question is the safety contract, namely which properties can be guaranteed pre-deployment (e.g., syntactic validity and non-contradiction with existing intents) versus those requiring runtime evidence (telemetry-based verification and targeted active tests). An- other practical concern is prompt grounding. Prompts should reflect the current network state without exposing sensitive details, so the assurance context builder should supply only minimal summaries (e.g., topology sketches, intent inventory, critical KPIs).. Repair and self-reconfiguration: When drift, faults, or intent violations are observed, the loop must trigger safe repair actions such as re-configuration, re-routing, scaling, or policy re-optimization without violating coexisting intents. Practi- cal directions include policy-aware remediation workflows, staged execution with post-change verification, and human- in-the-loop approval for high-impact changes. Open questions include how to rank actions by expected impact/risk under uncertainty and how to prevent control-loop instability in multi-intent settings. Latency, scalability, and actionable outputs: End-to-end automation must meet operational time budgets where LLM inference, conflict analysis, and predictive assurance can add latency under frequent churn or large intent volumes [4], [17]. A pragmatic approach is to separate tasks by criticality and timescale where lightweight validation/conflict filtering runs inline, while heavier reasoning (explanations and deep predictive models) executes asynchronously with rate limits and caching. Finally, predictions must be actionable. Beyond accuracy and lead time, evaluation should capture alert fatigue, root-cause disambiguation quality, and the safety/impact of recommended actions under multi-intent interactions. Open questions include how to partition intelligence across edge vs. central placement, and which explanation modalities (KPI at- tribution, causal graphs, counterfactuals) best support operator trust and remediation. V. CONCLUSION This doctoral research investigates how to make intent-based networking more practical and dependable by unifying two capabilities in a single closed loop: (i) verifiable, LLM-assisted intent realization that translates natural-language intents into controller-ready policy artifacts with conflict-aware activation; and (i) proactive, multi-intent assurance that anticipates fail- ures early and disambiguates the likely root cause from co- drifting symptoms. To date, we have implemented and eval- uated key realization components in SDN settings (structured policy generation/validation and controller-aware activation), and we have validated the proactive assurance direction on controlled multi-intent scenarios, showing promising lead time and improved root-cause separation. However, two open ques- tions remain in our research: Extending to 5G/6G management: What is a realis- tic, well-scoped path to extend the same pipeline beyond SDN into 5G/6G (e.g., slice-like/service intents spanning core/transport/RAN), and which initial intent types and en- forcement points provide the most defensible evaluation? Validation with real telemetry: What is the most practi- cal strategy to evaluate proactive multi-intent assurance on real data—adapting existing datasets via augmentation/transfer learning, instrumenting a controlled testbed to collect KPI traces with incident labels, or combining both—and what labeling/evaluation protocol best supports credible root-cause and lead-time claims? REFERENCES [1] C.-Y. Hong, S. Mandal, M. Al-Fares, M. Zhu, R. Alimi, K. N. B, C. Bhagat, S. Jain, J. Kaimal, S. Liang et al., “B4 and after: managing hierarchy, partitioning, and asymmetry for availability and scale in google’s software-defined wan,” in Proceedings of the ACM SIGCOMM Conference, 2018, p. 74–87. [2] S. Marinova and A. Leon-Garcia, “Intelligent o-ran beyond 5g: Archi- tecture, use cases, challenges, and opportunities,” IEEE Access, vol. 12, p. 27 088–27 114, 2024. [3] N. Feamster and J. Rexford, “Why (and how) networks should run themselves,” in Proceedings of the 2018 Applied Networking Research Workshop, ser. ANRW ’18.New York, NY, USA: Association for Computing Machinery, 2018, p. 20. [4] A. Leivadeas and M. Falkner, “A survey on intent-based networking,” IEEE Communications Surveys & Tutorials, vol. 25, no. 1, p. 625–655, 2023. [5] A. Clemm, L. Ciavaglia, L. Z. Granville, and J. Tantsura, “Intent-Based Networking - Concepts and Definitions,” RFC 9315, Oct. 2022. [Online]. Available: https://w.rfc-editor.org/info/rfc9315 [6] S. D’Oro, L. Bonati, M. Polese, and T. Melodia, “Orchestran: Orchestrat- ing network intelligence in the open ran,” IEEE Transactions on Mobile Computing, vol. 23, no. 7, p. 7952–7968, 2023. [7] K. Dzeparoska, A. Tizghadam, and A. Leon-Garcia, “Intent assurance using llms guided by intent drift,” in Proc. IEEE NOMS, 2024, p. 1–7. [8] A. Chouman, D. M. Manias, and A. Shami, “Towards supporting intelligence in 5g/6g core networks: Nwdaf implementation and initial analysis,” in 2022 International Wireless Communications and Mobile Computing (IWCMC), 2022, p. 324–329. [9] K. Dzeparoska and A. Leon-Garcia, “Kpi assurance and llms for intent- based management,” in Proc. IEEE/IFIP NOMS, 2025, p. 1–9. [10] X. Zheng and A. Leivadeas, “Network assurance in intent-based net- working data centers with machine learning techniques,” in Proc. IEEE CNSM, 2021, p. 14–20. [11] 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. [12] 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. [13] C. Liu, X. Xie, X. Zhang, and Y. Cui, “Large language models for networking: Workflow, advances and challenges,” IEEE Network, 2024. [14] A. Mekrache, A. Ksentini, and C. Verikoukis, “Intent-based management of next-generation networks: an llm-centric approach,” IEEE Network, vol. 38, no. 5, p. 29–36, 2024. [15] R. Han, J. Wang, H. Sun, Z. Jiang, Q. Qi, Z. Zhuang, Y. Zhang, and J. Liao, “Network copilot: Intent-driven network configuration updating for service guarantee,” in IEEE INFOCOM 2025-IEEE Conference on Computer Communications. IEEE, 2025, p. 1–10. [16] C. Wang, M. Scazzariello, A. Farshin, S. Ferlin, D. Kosti ́ c, and M. Chiesa, “Netconfeval: Can llms facilitate network configuration?” Proceedings of the ACM on Networking, vol. 2, no. CoNEXT2, p. 1– 25, 2024. [17] N. Tu, S. Nam, and J. W.-K. Hong, “Intent-based network configuration using large language models,” International Journal of Network Man- agement, vol. 35, no. 1, p. e2313, 2025. [18] F. Li, H. Lang, J. Zhang, J. Shen, and X. Wang, “Preconfig: A pretrained model for automating network configuration,” arXiv preprint arXiv:2403.09369, 2024. [19] A. S. Jacobs, R. J. Pfitscher, R. H. Ribeiro, R. A. Ferreira, L. Z. Granville, and S. G. Rao, “Deploying natural language intents with lumi,” in Proceedings of the ACM SIGCOMM Conference Posters and Demos, 2019, p. 82–84. [20] A. Mekrache and A. Ksentini, “Llm-enabled intent-driven service con- figuration for next generation networks,” in 2024 IEEE 10th Interna- tional Conference on Network Softwarization (NetSoft).IEEE, 2024, p. 253–257. [21] Y. Li, X. Yin, Z. Wang, J. Yao, X. Shi, J. Wu, H. Zhang, and Q. Wang, “A survey on network verification and testing with formal methods: Approaches and challenges,” IEEE Communications Surveys & Tutorials, vol. 21, no. 1, p. 940–969, 2019. [22] J. Zhang, J. Guo, C. Yang, X. Mi, L. Jiao, X. Zhu, L. Cao, and R. Li, “A conflict resolution scheme in intent-driven network,” in 2021 IEEE/CIC International Conference on Communications in China (ICCC). IEEE, 2021, p. 23–28. [23] 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, p. 10 512–10 541, 2025. [24] 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, p. 1–6. [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] 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, p. 434–446, 2023. [27] M. Z ̈ ufle, J. Agne, J. Grohmann, I. D ̈ ortoluk, and S. Kounev, “A predictive maintenance methodology: Predicting the time-to-failure of machines in industry 4.0,” in Proc. IEEE INDIN, 2021, p. 1–8. [28] 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, p. 23 049–23 062, 2022. [29] 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