PaperlayerView exact revision on arXiv

Source-linked AI summary

Assured AI-Native Network Control Loops: State of the Art, Research Challenges and the Missing Runtime Assurance Layer

Bartosz Belter, Mariusz Głąbowski

arXiv:2609.11996v1cs.NI

TL;DR

Autonomous network control raises a system-level assurance problem because individually acceptable decisions may interact through shared, changing network state. This review analyzes AI-native control architectures and runtime assurance, identifying dependency-aware assurance as a research direction for composing loops and setting out open challenges.

  • Problem

    AI-native architectures lack a unified mechanism to assure heterogeneous control loops whose decisions depend on shared, dynamically changing network state.

    Source: B. Limitations of Existing… · p. 10

  • Method

    The paper reviews AI-native network control and identifies dependency-aware runtime assurance, which links decisions to assumptions and dependencies and monitors changes that may invalidate them.

    Source: §X · p. 22

  • Results

    The review identifies dependency-aware runtime assurance as a research direction for assured composition of AI-native control loops.

    Source: §X · p. 22

  • Takeaways & Limitations

    Further work is needed on formal dependency representation, runtime decision validation, conflict resolution, latency-aware assurance, and reproducible experimental evaluation.

    Source: §X · p. 22

    Current approaches do not provide a unified mechanism for continuously assuring heterogeneous control loops that depend on shared, dynamically changing network state.

    Source: B. Limitations of Existing… · p. 10

Abstract

from arXiv · show

The evolution towards autonomous and AI-native telecommunication networks is transforming network control from predefined automation towards distributed and intelligent decision-making. Advances in closed-loop automation, O-RAN, Network Digital Twins, AI-driven orchestration, and autonomous agents enable multiple specialized control functions to operate concurrently across network domains and timescales. This introduces a system-level assurance challenge: individually acceptable decisions may interact through shared resources and network state, while changes in their operational context may invalidate assumptions under which they were evaluated. This paper presents a state-of-the-art review of AI-native network control, focusing on the composition and runtime assurance of autonomous control loops. It examines closed-loop and zero-touch automation, intelligent controllers, Network Digital Twins, AI-driven orchestration, autonomous agents, trustworthy AI, and runtime assurance. The analysis shows that these directions provide important foundations for autonomous operation but lack a unified mechanism for assuring heterogeneous control loops whose decisions depend on shared and dynamically changing network state. To address this gap, the paper identifies dependency-aware runtime assurance as a research direction for assured composition of AI-native network control loops. The proposed perspective associates decisions with assumptions and dependencies on which their validity relies, monitors changes that may invalidate accepted decisions, and supports runtime resolution of concurrent control interactions. A telecom use case and an initial architecture and formal model illustrate the concept and identify open challenges in dependency representation, runtime validation, conflict resolution, latency-aware assurance, and experimental evaluation.

I. INTRODUCTION

The introduction traces network control from human-led management through closed-loop automation toward AI-native autonomy, then frames the assurance problem: multiple autonomous loops may interact despite locally reasonable decisions.

A. From Traditional Network Management to Autonomous Operation

  • Autonomic communications and closed-loop control replaced manual adaptation with continuous monitoring, analysis, decisions, and corrective actions.The MAPE-K model organizes this adaptive process around Monitor, Analyse, Plan, Execute, and a shared Knowledge base.Source: §I · p. 1, A. From Traditional Network Management… · p. 2

I. INTRODUCTION

  • Autonomous network control raises the question of how multiple loops can be composed so their joint operation remains predictable and trustworthy.Each loop may pursue its own objective while influencing shared infrastructure, so locally reasonable decisions can interact in undesirable ways.Source: §I · p. 2

B. The Rise of Closed-Loop Network Automation

  • Closed-loop automation, supported by SDN and NFV, made network control programmable, but early automation remained largely rules-based.SDN separates control from forwarding, while NFV deploys network functions as software on virtualized infrastructure.Source: B. The Rise of Closed-Loop Network… · pp. 2–3

C. From Automation Towards Intent-Based and Zero-Touch Management

  • Intent-based, zero-touch, and AI-enabled management advance autonomy, but interacting intents and cross-domain decisions raise a need for safe delegation.The ZSM framework emphasizes closed-loop automation and autonomy; ENI specifies context-aware, AI-enabled management.Source: C. From Automation Towards… · p. 3

D. AI as an Enabler of Adaptive Network Control

AI-native network architectures bring intelligence into network control through adaptive models and specialized platforms, but lack a unified way to assure interacting autonomous decisions over shared resources and changing state.

D. AI as an Enabler of Adaptive Network Control

  • AI and machine learning extend network operations from prediction and recommendation toward adaptive decision-making within control loops.Applications include traffic prediction, anomaly detection, resource allocation, wireless optimization, and operational processes such as failure detection and remediation.Source: D. AI as an Enabler of Adaptive… · p. 3

E. Towards AI-Native Network Control Loops

  • AI-native networking embeds AI in control, while distributed specialized controllers make safe coexistence—not merely individual intelligence—the open problem.AI can support faster adaptation, improved efficiency, and reduced operational complexity, but learned decisions introduce uncertainty.Source: E. Towards AI-Native Network Control… · p. 3

A. Architectural Foundations of AI-Native Networks

  • Architectural directions have evolved independently, leaving no unified perspective for safe interaction among autonomous components sharing an environment.O-RAN, Network Digital Twins, orchestration, and agents each address distinct parts of AI-native operation.Source: A. Architectural Foundations of… · p. 3

B. O-RAN and Intelligent Network Controllers

  • O-RAN deploys programmable radio-control applications, but independently developed xApps can conflict over shared parameters and degrade performance.The Non-Real-Time RIC supports longer-term optimization and AI/ML lifecycle functions; the Near-Real-Time RIC enables faster control through xApps.Source: B. O-RAN and Intelligent Network… · p. 4

C. Network Digital Twins as a Foundation for Predictive Control

  • Network Digital Twins represent physical networks dynamically and support monitoring, simulation, prediction, and optimization.Controllers can test configuration changes and predict performance impacts in a virtual representation, but prediction alone does not determine whether an action should be allowed under current conditions.Source: C. Network Digital Twins as a… · p. 4

D. AI-Driven Orchestration Across Network Domains

  • AI-driven orchestration extends management across network and computing domains, where individually reasonable cloud and network objectives can interact to degrade service behaviour.A cloud orchestrator may minimize computational cost while a network controller minimizes latency.Source: D. AI-Driven Orchestration Across… · p. 4

E. AI Agents and Autonomous Network Operations

  • AI agents add perception, reasoning, planning, and tool interaction, while reliability, hallucination, and inference latency remain deployment challenges.Their generated plans, context interpretations, and external-tool interactions complicate guarantees that decisions stay within operational boundaries.Source: E. AI Agents and Autonomous Network… · pp. 4–5

F. Limitations of Current AI-Native Architectures

  • Current AI-native building blocks enable autonomous decisions but provide little support for assuring that multiple decisions remain compatible when executed together.Open questions include detecting controller conflicts, checking whether decision assumptions remain valid, representing component dependencies, and preserving predictable behaviour as networks change.Source: F. Limitations of Current AI-Native… · p. 5

IV. RUNTIME ASSURANCE AND TRUSTWORTHY AI FOR AUTONOMOUS NETWORKS

The section argues that trustworthy operation must be assessed at the control-system level and continuously in context, because model-level properties do not assure interacting controllers in changing networks.

A. From AI Performance to AI Trustworthiness

  • Trustworthiness must cover the complete feedback control system, since individually robust controllers can still create undesirable effects for one another.AI actions modify the environment that shapes later decisions, linking models, network state, policies, and autonomous components.Source: A. From AI Performance to AI… · p. 5

B. Limitations of Model-Centric Trustworthy AI Approaches

  • Model-centric methods address uncertainty within individual models but do not capture uncertainty from operational environments or interactions among autonomous components.Improving individual model accuracy does not resolve incompatible assumptions between controllers; assurance must assess whether decision conditions remain valid.Source: B. Limitations of Model-Centric… · p. 6

C. Runtime Assurance in Safety-Critical Autonomous Systems

  • Runtime assurance separates potentially uncertain advanced decision-making from an independent mechanism that preserves safe operation.The Simplex architecture pairs an advanced controller with a simpler safety controller that takes over when unsafe behaviour is detected.Source: C. Runtime Assurance in… · p. 6

D. Applying Runtime Assurance Concepts to Network Control

  • Telecom networks require assurance beyond single-system settings because distributed controllers operate across domains, objectives, data sources, and timescales.An action acceptable in isolation may become problematic after another controller changes the environment or invalidates its assumptions.Source: D. Applying Runtime Assurance Concepts… · p. 6
  • Runtime assurance for telecom should evaluate whether decisions remain acceptable as network state, dependencies, resources, policies, and other controllers’ actions change.The assurance layer should be integral to the control architecture, not applied only after decisions are generated.Source: D. Applying Runtime Assurance Concepts… · p. 7

E. Dependency-Aware Assurance for Composed AI Control Loops

Composed network control loops can interact through shared state and conflicting objectives, so the paper frames dependency-aware runtime assurance as a way to track decision assumptions and reassess actions as conditions change.

E. Dependency-Aware Assurance for Composed AI Control Loops

  • A decision’s runtime validity depends on the context and dependencies under which it was generated, not only on its individual action or objective.The proposed assurance layer would validate decision context and support safe adaptation when operational assumptions change.Source: E. Dependency-Aware Assurance for… · p. 7
  • Dependency-aware assurance associates autonomous decisions with assumptions, monitors relevant dependencies, and checks whether actions remain acceptable when those assumptions change.Assumptions can concern network state, resource availability, input data, conflicting actions, policies, service requirements, and dependency stability.Source: E. Dependency-Aware Assurance for… · p. 7

A. From Individual Control Loops to Composed Autonomous Systems

  • Composed controllers can produce unexpected system-level effects even when each loop is locally correct and individually optimized.Control functions may pursue different objectives over shared infrastructure, making the overall outcome a product of their interaction.Source: A. From Individual Control Loops to… · pp. 7–8

B. Challenges of Multi-Objective Autonomous Control

  • Different objectives and state interpretations can make one controller’s action alter the conditions that supported another controller’s decision.Trade-offs include performance versus energy efficiency and reliability versus resource utilization; O-RAN xApps can also conflict over overlapping resources.Source: B. Challenges of Multi-Objective… · p. 8

C. Interactions Between Control Loops and Emergent Behaviour

D. Limitations of Current Approaches

Existing network-control approaches provide important capabilities, but do not generally assure how heterogeneous loops interact over shared, changing state. The paper frames assured composition as a runtime layer that checks decision assumptions, dependencies, and interactions.

D. Limitations of Current Approaches

  • O-RAN, digital twins, intent-based management, and trustworthy AI address complementary needs, but lack a unified mechanism for assuring interacting loops as shared conditions evolve.Digital-twin effectiveness depends on fidelity and synchronization; concurrent xApps can conflict.Source: D. Limitations of Current Approaches · p. 8

E. Towards Assured Composition of AI-Native Control Loops

  • Assured composition must check whether decision assumptions remain valid, other components have changed context, and planned actions conflict or remain safe to execute.The proposed assurance layer complements autonomous decision-making with monitoring, dependency representation, constraint validation, and unsafe-interaction mitigation.Source: E. Towards Assured Composition of… · pp. 8–9

VI. RESEARCH GAP AND OPEN CHALLENGES

  • A general assurance perspective is needed because independently developed control functions can interact over shared resources and invalidate decisions as operating conditions change.The identified gap includes representing dependencies, detecting invalidated decisions, and coordinating actions under system-level constraints.Source: §VI · p. 9

A. Beyond AI-Enabled Optimization Towards Assured Autonomy

  • Assured autonomy addresses whether decisions remain valid and safe in context, beyond whether individual AI controllers optimize throughput, latency, energy, or prediction accuracy.The traffic-allocation and energy-optimization example shows how individually reasonable actions may combine to degrade service quality.Source: A. Beyond AI-Enabled Optimization… · p. 9

B. Limitations of Existing Architectural Approaches

  • Existing research directions provide partial interaction support, but not unified assurance of heterogeneous loops dependent on dynamically changing shared state.The comparison identifies gaps in representing dependencies, tracking assurance validity as dependencies change, and coordinating concurrent actions under system-level constraints.Source: B. Limitations of Existing… · pp. 9–10

C. Open Research Challenge 1: Runtime Validation of AI Decisions

  • For heterogeneous loops operating at different timescales over shared state and resources, accepted decisions may need re-evaluation when their underlying dependencies change.A further challenge is acquiring assumptions from black-box models: their completeness and accuracy remain open questions, especially for nonlinear or context-dependent behavior.Source: C. Open Research Challenge 1: Runtime… · p. 10

D. Open Research Challenge 2: Dependency-Aware Control Loop Composition

Autonomous network control loops depend on shared resources, state, and conditions that other components can change. Assuring their composition therefore requires tracking dependencies over time and resolving conflicts within operational constraints.

D. Open Research Challenge 2: Dependency-Aware Control Loop Composition

  • Independently developed control loops may affect shared network parameters, resources, and objectives, creating direct or indirect conflicts.O-RAN xApps illustrate how overlapping controls can interact.Source: D. Open Research Challenge 2:… · p. 10
  • Dependency-aware representations should link decisions to operational conditions so the assurance mechanism can assess whether changes affect their continued validity.This also provides a basis for identifying interactions among concurrently operating control functions.Source: D. Open Research Challenge 2:… · pp. 10–11

E. Open Research Challenge 3: Safe Adaptation in Dynamic Environments

  • Assurance must be continuous rather than one-time as services, traffic, failures, and configurations evolve, incorporating new evidence to maintain confidence amid uncertain operational observations, intervention mechanisms, and fallback strategies.Source: E. Open Research Challenge 3: Safe… · p. 11
  • Runtime assurance must complete within each control loop’s timing constraints, creating a trade-off between assurance depth and computational latency.The O-RAN Near-RT RIC operates on control timescales between 10 ms and 1 s [17].Source: E. Open Research Challenge 3: Safe… · p. 11

F. Open Research Challenge 4: Conflict Resolution and Priority Arbitration

  • When actions are invalid or conflict, the assurance layer must choose whether to modify, delay, reject, or roll back them and determine which controller’s objective prevails.The initial framework considers service criticality, policy precedence, temporal urgency, reversibility, and impact severity.Source: F. Open Research Challenge 4: Conflict… · p. 11
  • Priority arbitration remains difficult when objectives are incomparable, controllers are equally critical, actions are hard to reverse, or negotiation may be preferable.Resolution must account for operational priority, impact, reversibility, and available intervention time.Source: F. Open Research Challenge 4: Conflict… · p. 11

G. Towards a Research Framework for Assured AI-Native Networks

The paper positions assurance as a complement to increasingly autonomous network control, not a restriction on it. It identifies dependency-aware runtime assurance as a research direction for keeping decisions valid and compatible as network conditions change.

G. Towards a Research Framework for Assured AI-Native Networks

  • A framework for assured composition should complement AI optimization by modelling loop dependencies, validating action context, tracking invalidating changes, and supporting safe execution, adaptation, or rejection.Assurance is an active part of the control architecture rather than a final verification step.Source: G. Towards a Research Framework for… · p. 11

VII. RESEARCH DIRECTIONS TOWARDS ASSURED AI-NATIVE NETWORK CONTROL

  • As control becomes more distributed across domains and timescales, decisions must remain valid, compatible, and operationally safe as shared network conditions change.The envisioned progression moves from task automation through closed-loop management and AI optimization to autonomous control under assurance constraints.Source: §VII · p. 12, A. From Intelligent Control Towards… · p. 12

A. From Intelligent Control Towards Assured Autonomous Control

  • Intelligence and assurance are complementary: AI adapts decisions, while assurance evaluates their acceptability as systems and operating environments evolve.The objective is to balance adaptability with predictable, acceptable system-level behavior rather than restrict autonomy.Source: A. From Intelligent Control Towards… · p. 12

B. Dependency-Aware Runtime Assurance as a Research Direction

  • Dependency-aware runtime assurance should make decision assumptions and dependencies explicit, preserve assurance validity as state evolves, and operate within control-loop timing constraints.The research direction connects runtime assurance, multi-agent coordination, and autonomous network management; open questions include detecting invalidation and identifying conflicts before execution.Source: B. Dependency-Aware Runtime Assurance… · p. 12

C. Towards Composable Autonomous Network Control

Safe composition requires more than communication among autonomous components: their decisions must be assessed in shared network context. The paper connects this need to experimental evaluation and illustrates it with concurrent control loops in an AI-native RAN.

C. Towards Composable Autonomous Network Control

  • Components with standardized interfaces may still make decisions that interact undesirably; O-RAN xApps can conflict over overlapping parameters and objectives.Composable control therefore requires representations of objectives, constraints, decision dependencies, uncertainty, and loop interactions.Source: C. Towards Composable Autonomous… · pp. 12–13

D. Experimental Evaluation and Benchmarking Challenges

  • Experimental methods should assess loop interactions, robustness under changing conditions, conflicting objectives, runtime-assurance effectiveness, and autonomy–assurance–performance trade-offs.Evaluation environments can combine programmable network infrastructure, autonomous controls, orchestration, and operational data; latency overhead is a specific measurement priority.Source: D. Experimental Evaluation and… · p. 13

E. Research Outlook

  • The survey calls for architectures, assurance mechanisms, and experiments that preserve operational objectives and system dependencies across multiple loops sharing network state and resources.The research question is how to maintain trustworthy behavior under changing network conditions.Source: E. Research Outlook · p. 13

VIII. TELECOM USE CASE: DEPENDENCY-AWARE RUNTIME ASSURANCE IN AI-NATIVE RAN

  • The RAN use case considers energy optimization, traffic prediction and capacity, and service assurance loops whose decisions may couple through shared resources, state, or constraints.The scenario illustrates how individually acceptable actions can become incompatible; it is not intended to reproduce a specific O-RAN deployment.Source: §VIII · pp. 13–14

A. Scenario Description

The scenario illustrates how energy, capacity, and service-assurance controllers can make individually reasonable decisions that interact over shared resources. Because operational context may change after evaluation, assurance must recheck dependencies and resolve concurrent actions.

A. Scenario Description

  • Energy, capacity, and service-assurance controllers pursue distinct objectives but can affect shared resources while observing only information relevant to their own goals.The scenario is illustrative, not a specific standardized O-RAN deployment.Source: A. Scenario Description · p. 14

B. Decision Generation and Assumption Validity

  • An energy decision depends on low traffic, sufficient remaining capacity, and no competing need for affected resources, so changed context can invalidate its prior evaluation.Assurance should reconsider the result before execution when network state or another action changes a supporting condition.Source: B. Decision Generation and Assumption… · p. 14

C. Runtime Assurance Intervention

  • Dependency-aware assurance evaluates actions together with their assumptions and dependencies, including changed traffic, shared-resource links, and conflicts between energy and capacity objectives.The scenario describes this as an additional validation step before execution.Source: C. Runtime Assurance Intervention · p. 14
  • Resolution compares control-loop priorities, conflict characteristics, action reversibility, and time budget; it can modify, delay, reject, or roll back an action.Here, service continuity and capacity availability outrank energy optimization, so the energy action is modified to keep the carrier available.Source: C. Runtime Assurance Intervention · p. 15

D. Research Implication

The research implication is that assurance for autonomous control loops must track changing network state, decision assumptions, and dependencies among loops. The proposed initial architecture and model make those relationships explicit for runtime validation and resolution.

D. Research Implication

  • O-RAN conflicts and evolving operational conditions motivate assurance that tracks network state, decision assumptions, and dependencies between interacting control loops through execution.The scenario provides a basis for studying composition while maintaining system-level operational constraints as shared conditions evolve.Source: D. Research Implication · p. 15

IX. INITIAL ARCHITECTURE AND FORMAL MODEL FOR ASSURED COMPOSITION OF AI-NATIVE CONTROL LOOPS

  • The initial architecture and formal model establish a common representation for controllers, decisions, assumptions, dependencies, and changes in shared state, rather than a complete implementation framework.It extends runtime assurance principles to interactions among heterogeneous autonomous control loops.Source: §IX · p. 15

A. Architecture Overview

  • A dependency-aware Runtime Assurance Layer sits between autonomous controllers and infrastructure, monitoring state and dependencies, validating decisions, analyzing conflicts, and enforcing accept, modify, delay, or reject outcomes.The layer evaluates decisions independently of controllers’ internal optimization logic and re-evaluates them as conditions evolve.Source: A. Architecture Overview · p. 16

B. Decision Representation

  • Each control loop is represented by its objective, observed state, available actions, and dependencies related to resources, constraints, and other control functions.A generated decision then comprises the selected action and its associated dependencies.Source: B. Decision Representation · p. 16
  • A decision’s action alone does not establish its acceptability; its assumptions and dependencies capture conditions such as traffic, capacity, service requirements, and other control-loop interactions.These conditions determine whether the action remains acceptable for execution.Source: B. Decision Representation · p. 16

1) Acquisition of Decision Assumptions:

Decision assumptions may be difficult to extract from black-box controllers, so the assurance layer builds them from complementary sources rather than requiring a complete controller-provided specification. These sources range from operator constraints and captured context to model-derived signals and observed runtime behavior.

Acquisition of Decision Assumptions

  • Assumptions αi describe conditions required for a decision’s valid execution, but extracting them from black-box models is difficult,.The assurance layer can use available assumption information without requiring a complete specification from the controller.Source: 1) Acquisition of Decision Assumptions · pp. 16–17
  • Operator-defined policies, service-level agreements, resource limits, and safety boundaries provide baseline assumptions independent of model interpretability,.A radio-resource decision, for example, may inherit traffic-demand and resource-availability conditions.Source: 1) Acquisition of Decision Assumptions · p. 16
  • Captured system state, input data, and operating conditions let the layer check whether the context in which a decision was generated still holds.This approach evaluates decision premises at runtime without inspecting the controller’s internal logic.Source: 1) Acquisition of Decision Assumptions · p. 16
  • Explainable-AI attributions and uncertainty estimates can approximate influential inputs and validity ranges, but do not fully specify αi,.These signals augment externally specified and context-based assumptions.Source: 1) Acquisition of Decision Assumptions · pp. 16–17
  • Runtime profiles use past acceptable and degraded outcomes to estimate decision conditions, but their evidence is uncertain rather than proof of validity.Profiles complement explicit specifications, policies, and controller-provided metadata.Source: 1) Acquisition of Decision Assumptions · p. 17

C. Runtime Validation of Autonomous Decisions

The framework treats decision validity as time-dependent and examines how shared dependencies can connect otherwise separate control loops. When validity or compatibility is in question, it proposes resolution choices guided by priorities, conflict characteristics, and available time.

C. Runtime Validation of Autonomous Decisions

  • A decision remains valid only while current network state satisfies its assumptions and relevant dependencies stay unchanged or within acceptable limits.A decision accepted at one moment may later become invalid without an AI-model failure [48].Source: C. Runtime Validation of Autonomous… · p. 18

D. Composition of Multiple Control Loops

  • Shared dependencies can expose decisions to interaction through common network state, resources, or constraints, but do not automatically imply conflict.Assurance must assess whether changes affect validity and whether concurrent execution remains compatible with system objectives.Source: D. Composition of Multiple Control Loops · p. 19

E. Resolution Strategies and Priority Mechanisms

  • When validity fails or actions conflict, the enforcement mechanism can accept, modify, delay, reject, or roll back an action.Rollback addresses an already executed action whose assumptions were subsequently invalidated.Source: E. Resolution Strategies and Priority… · p. 19
  • Resolution weighs loop priority alongside reversibility, impact severity, and the available time budget.For example, reversible actions may be modified or delayed, while conflicts threatening service availability may warrant rejection or rollback.Source: E. Resolution Strategies and Priority… · p. 19
  • Unilateral resolution suits short deadlines, whereas negotiated resolution requires time for bounded controller coordination.The choice depends on conflict severity, priority, operational context, and time available.Source: E. Resolution Strategies and Priority… · p. 20
  • The resolution framework is initial; precise priority policies, efficient reversal procedures, and realistic comparisons of negotiated and unilateral resolution remain research directions.The framework’s outcomes are selected according to loop priorities and conflict characteristics.Source: E. Resolution Strategies and Priority… · pp. 19–20

F. Latency Budget and Scalability Considerations

Runtime assurance must fit within the end-to-end time available to a control loop, while its depth and computational scope vary with timing needs. The paper proposes bounded and dependency-focused analysis but states that latency and scalability require experimental validation.

F. Latency Budget and Scalability Considerations

  • Tdecision + Tassurance + Tenforcement ≤ Tcontrol defines the timing condition for assurance within a control loop’s end-to-end constraint.Decision generation and enforcement consume part of the available time, so assurance receives only the remaining budget.Source: F. Latency Budget and Scalability… · p. 21
  • Fast control loops require lightweight assurance, while slower loops may permit deeper dependency and conflict analysis.Near-RT RIC loops typically span approximately 10 ms to 1 s; Non-RT RIC loops operate at 1 s or longer, and assurance receives only a fraction of that time.Source: F. Latency Budget and Scalability… · p. 21
  • A synchronous path performs checks required before execution, while deeper analysis can run asynchronously and inform later assurance cycles.This separates time-critical checks from additional analysis that updates assurance information.Source: F. Latency Budget and Scalability… · p. 21
  • Dependency graphs focus analysis on loops and resources related to a decision, while domain or resource partitioning may further reduce interactions examined.This targets the cost of exhaustive pairwise analysis as the number of control loops grows.Source: F. Latency Budget and Scalability… · p. 21
  • The architecture’s actual latency and scalability characteristics must be established experimentally across control-loop timescales.Evaluation should measure assurance-operation overhead and identify which mechanisms fit each timescale.Source: F. Latency Budget and Scalability… · p. 21

G. Research Perspective

The research perspective shifts assurance from individual AI decisions to how autonomous loops coexist in shared infrastructure. The conclusions identify dependency-aware runtime assurance as a research direction and outline work needed to assure such compositions.

G. Research Perspective

  • The proposed abstraction comprises autonomous decision-generating entities, assumptions of decision validity, dependencies among loops and resources, and runtime compatibility mechanisms.It shifts the focus from improving individual AI decisions to understanding how autonomous decisions coexist in shared infrastructure.Source: G. Research Perspective · pp. 21–22

X. CONCLUSIONS

  • Concurrent control applications may conflict through shared network parameters and performance objectives, while changes to state, resources, policies, or other loops can invalidate decision assumptions.Assurance must consider whether supporting conditions remain valid until execution and while other loops modify the shared environment.Source: §X · p. 22
  • Existing foundations span digital twins,, AIOps,, trustworthy AI,, and runtime assurance for learning-enabled and distributed multi-agent controllers,.The review presents these capabilities as substantial foundations for autonomous operation.Source: §X · p. 22
  • Dependency-aware runtime assurance would represent decision assumptions and dependencies, monitor operational changes, trigger re-evaluation, and resolve interactions between concurrent control actions.Its objective is to compose heterogeneous AI-native control loops while maintaining acceptable system-level behaviour under changing network conditions.Source: §X · p. 22
  • The research agenda calls for formal dependency representations, runtime decision validation, conflict resolution, latency-aware assurance, and reproducible experimental evaluation.It frames these as further work toward assured composition of AI-native network control loops.Source: §X · p. 22
Loading 2609.11996v1…