Pith. sign in

REVIEW 4 major objections 5 minor 25 references

AI-Native Network Controller: A Modular Framework for Safe Agentic Control of Multi-Domain Network Infrastructure

T0 review · 4 major / 5 minor · reviewed 2026-07-05 · glm-5.2

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read AI agents get a safety gatekeeper for 6G networks

desk verdict Solid open-source framework for multi-domain network control; oversells safety guarantees from stateless per-command validators read the letter →

arxiv 2606.20565 v1 pith:4VTWTFRM submitted 2026-04-20 cs.NI cs.AI

Merim Dzaferagic This is my paper · ORCID
classification cs.NIcs.AI
keywords controlnetworkagenticframeworkacrossai-nativeapplicationscontroller
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper presents the AI-Native Network Controller (AI-NNC), an open-source software framework designed to let AI agents control heterogeneous network infrastructure (radio access, optical transport, core networks) without directly issuing commands to physical equipment. The core architectural claim is that safety can be enforced by interposing a layer of validated control applications between AI agents and network devices: every command, regardless of whether it originates from an AI agent, an automated control loop, or a human API call, passes through the same per-command validation pipeline before reaching any network node. The framework integrates any device through a single Python adapter that translates between the device's native protocol and a uniform ZeroMQ message bus, and exposes control logic to AI agents via the Model Context Protocol (MCP). The paper argues that this design yields three properties: uniform enforcement (no command source can bypass validation), compositional safety (adding new applications does not require rewriting safety rules), and conflict detection (the registration plane tracks which applications control which nodes, enabling detection of competing commands). The AI agent is positioned not as a direct device controller but as a meta-controller that orchestrates domain-specific applications, which the author argues is a fundamentally safer paradigm for autonomous network management.

What carries the argument

Three-plane architecture: data plane (ZeroMQ message broker with PUSH/PULL and PUB/SUB patterns), registration plane (REQ/REP service backed by Redis for capability discovery and conflict tracking), control plane (FastAPI server, MCP server, control applications). Node adapters (single Python script per device type implementing register, setup, poll_measurements, handle_command). Control applications defined via @aic_app decorator with @command_validator and @agent_controlled decorators. MCP server auto-generates tools from registered applications for LLM-based agents.

What would settle it

Deploy two or more validated control applications that individually pass all per-command validators but whose concurrent or sequential commands produce an unsafe network state (e.g., a gain adjustment that is safe in isolation but causes amplifier saturation when combined with a concurrent wavelength change from another application). If the framework cannot prevent this, the safety guarantee claim fails.

Watch

Extended reading notes

Core claim

The central mechanism is the command validation pipeline, implemented via Python decorators, that sits between all command sources and all network devices. The paper's claim is that by attaching validators to command types rather than command sources, and by routing all commands through a single message broker with a uniform JSON envelope, the framework guarantees that AI agents cannot bypass the safety checks that apply to classical automated control loops. This is coupled with a registration plane that tracks application-to-node control relationships, enabling conflict detection when multiple applications issue competing commands to the same node.

Load-bearing premise

The paper assumes that domain-specific safety constraints for critical network infrastructure can be fully captured by static, per-command threshold checks (e.g., rejecting a gain value above 25.0), without addressing race conditions between concurrent applications, state-dependent constraints where a command's safety depends on current network state, or compositional effects where individually safe commands from different applications combine to produce unsafe network states

Editorial extensions

If this is right

  • If the validation pipeline approach scales, network operators could deploy LLM-based agents on production telecom infrastructure with per-command safety guarantees, lowering the barrier to autonomous network optimization.
  • The single-adapter-per-device integration model could accelerate multi-domain testbed research by unifying measurement collection and control across radio, optical, and core equipment from different vendors.
  • The conflict detection mechanism, if extended with formal verification as the author suggests, could provide provable safety properties for multi-agent network control scenarios where several AI agents manage overlapping network domains.
  • The MCP-based tool generation pattern could become a standard interface for AI agents in critical infrastructure beyond telecommunications, wherever validated command execution is required.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents the AI-Native Network Controller (AI-NNC), an open-source, modular framework for safe agentic AI control across heterogeneous network domains (radio, optical, core). The architecture consists of three planes: a data plane using ZeroMQ for protocol-agnostic messaging, a registration plane using Redis for service discovery and state tracking, and a control plane hosting FastAPI and MCP (Model Context Protocol) servers for AI agent integration. The central design principle is that AI agents interact with network infrastructure only through validated control applications (defined via Python decorators) rather than issuing commands directly to equipment. A command validation layer enforces domain-specific safety constraints uniformly across all command sources. The paper also describes a conflict detection mechanism and outlines various use cases including dataset collection, agentic AI experimentation, and testbed orchestration.

Significance. The paper addresses a timely and practically important problem: providing a unified, AI-native control plane that spans multiple network domains while maintaining safety guarantees for critical infrastructure. The open-source framework with its protocol-agnostic adapter pattern and automatic MCP tool generation represents a useful engineering contribution. The declarative validation mechanism via decorators is a clean design choice. However, the significance is substantially undermined by the absence of any quantitative evaluation and by safety claims that exceed what the described mechanisms can deliver.

major comments (4)
  1. §V.B, 'Compositional safety' claim: The paper states that 'safety guarantees compose automatically' because validators are attached to command types rather than sources. However, the validators shown (Listing 2, §V.A) are stateless per-command threshold checks (e.g., `if params['target_gain'] > 25.0: return False`). This cannot detect unsafe interactions between individually-safe commands issued by concurrent applications. Since applications run in independent threads (§III.C) with asynchronous ZMQ messaging, race conditions between validated commands are structurally possible. The claim of 'compositional safety' requires either a formal argument or an empirical demonstration that per-command checks compose to system-level safety, neither of which is provided.
  2. §V.C, Conflict detection: The ConflictMitigator application is described as one that 'observes the behavior of other applications' and arbitrates competing commands. This is a reactive, best-effort mechanism, not part of the validation pipeline. The paper does not explain how this prevents unsafe states before they occur, yet the conclusion claims the framework provides 'guarantees required for autonomous management of critical infrastructure.' The gap between reactive observation and safety guarantees is not addressed.
  3. §VIII, Conclusion: The paper states the framework 'has been validated using both simulated and physical optical network equipment,' but no experimental data, evaluation results, or quantitative validation appears anywhere in the manuscript. This claim is unsupported by the content of the paper. Either the evaluation should be included or the claim should be removed.
  4. §V.B, 'Safety guarantees' framing: The paper repeatedly uses the term 'safety guarantees' (contributions list, §V.B title, conclusion), but the mechanism described is a set of hard-coded threshold checks in Python functions. While useful as a defense-in-depth measure, framing this as providing 'guarantees' overstates what static, per-command validation can deliver, particularly in the absence of formal proof, concurrency control, or state-dependent constraint checking.
minor comments (5)
  1. Listing 2, line 30: `current = measurements[8][-1]['snr']` references a hardcoded node_id (8), but the read_measurements dictionary on lines 6-8 uses keys 3 and 8. This inconsistency should be clarified.
  2. §III.D: The adapter contract mentions an optional 'Setup' step for credential setup for external databases (e.g., influxDB, Prometheus), but §III mentions ModelarDB, MinIO, and S3-compatible storage. The database examples are inconsistent across sections.
  3. Table I: The comparison between AI-NNC and 'Traditional' approaches is qualitative and lacks citations or specific baselines. Consider grounding the comparison with references to specific existing controllers.
  4. §IV.C: The list of supported AI agents includes 'OpenClaw' — this appears to be a typo or a non-standard name. Please verify.
  5. The paper would benefit from a figure showing the command validation pipeline in more detail, including where conflict detection fits relative to the validation step (the relationship between Fig. 2 and the ConflictMitigator in §V.C is unclear).

Simulated Author's Rebuttal

4 responses · 0 unresolved

We thank the referee for a careful and constructive review. The referee raises four major comments, all of which concern the gap between the safety mechanisms we describe and the strength of the claims we make about them. We agree that the manuscript overstates what per-command validation can deliver, and we will revise accordingly. Below we address each comment in detail.

read point-by-point responses

  1. Referee: §V.B, 'Compositional safety' claim: The paper states that 'safety guarantees compose automatically' because validators are attached to command types rather than sources. However, the validators shown are stateless per-command threshold checks. This cannot detect unsafe interactions between individually-safe commands issued by concurrent applications. Since applications run in independent threads with asynchronous ZMQ messaging, race conditions between validated commands are structurally possible. The claim requires either a formal argument or an empirical demonstration that per-command checks compose to system-level safety.

    Authors: The referee is correct. Our use of the term 'compositional safety' is misleading. What we can honestly claim is that validators are attached to command types rather than command sources, so adding new applications does not require duplicating or re-specifying safety rules for those command types. This is a property of the validation architecture's modularity, not a guarantee that per-command checks compose to system-level safety. The referee is right that stateless per-command validators cannot detect unsafe interactions between concurrent commands, and that the threaded, asynchronous execution model creates a structural possibility of race conditions between individually-valid commands. We do not have a formal proof or empirical demonstration that per-command checks compose to system-level safety, and we should not claim they do. We will revise §V.B as follows: (1) rename the property from 'Compositional safety' to 'Validator reuse across command sources' or similar; (2) explicitly state that per-command validation does not guarantee system-level safety under concurrent execution; (3) note that detecting unsafe command interactions requires stateful or transactional validation, which is identified as future work alongside the formal verification mentioned in the conclusion. revision: yes

  2. Referee: §V.C, Conflict detection: The ConflictMitigator is reactive and best-effort, not part of the validation pipeline. The paper does not explain how this prevents unsafe states before they occur, yet the conclusion claims the framework provides 'guarantees required for autonomous management of critical infrastructure.' The gap between reactive observation and safety guarantees is not addressed.

    Authors: We agree with this assessment. The ConflictMitigator is a best-effort, reactive mechanism that observes competing commands and arbitrates after the fact. It is not part of the synchronous validation pipeline and does not provide pre-emptive prevention of unsafe states. The conclusion's claim that the framework provides 'guarantees required for autonomous management of critical infrastructure' overstates what the conflict detection mechanism delivers. We will revise the manuscript to: (1) clearly characterize conflict detection as a best-effort, reactive capability rather than a safety guarantee; (2) remove or substantially soften the claim in the conclusion that the framework provides 'guarantees required for autonomous management of critical infrastructure,' replacing it with an accurate description of what the framework does provide (uniform per-command validation, auditability, and best-effort conflict detection); (3) add a discussion of the limitation that conflict detection operates post-hoc and that pre-emptive conflict prevention would require integrating conflict checks into the synchronous validation pipeline, which is future work. revision: yes

  3. Referee: §VIII, Conclusion: The paper states the framework 'has been validated using both simulated and physical optical network equipment,' but no experimental data, evaluation results, or quantitative validation appears anywhere in the manuscript. This claim is unsupported.

    Authors: The referee is correct. The manuscript contains no experimental data, evaluation results, or quantitative validation. The claim in the conclusion that the framework 'has been validated using both simulated and physical optical network equipment' is unsupported by the content of the paper as submitted. We have two options, and we will pursue the one the referee considers most appropriate: (a) remove the claim from the conclusion and replace it with an accurate statement that the framework has been implemented and tested in a development setting but has not yet undergone formal quantitative evaluation, which is planned as future work; or (b) add an evaluation section with quantitative results from experiments on both simulated and physical optical equipment. We are prepared to include an evaluation section with latency measurements, command validation overhead, and conflict detection case studies if the referee and editor consider this necessary for acceptance. In either case, the unsupported claim will be addressed. revision: yes

  4. Referee: §V.B, 'Safety guarantees' framing: The paper repeatedly uses the term 'safety guarantees' but the mechanism is hard-coded threshold checks in Python functions. While useful as defense-in-depth, framing this as providing 'guarantees' overstates what static, per-command validation can deliver, particularly without formal proof, concurrency control, or state-dependent constraint checking.

    Authors: We agree that 'safety guarantees' is too strong a term for what the mechanism provides. The validation layer enforces per-command, stateless threshold checks that prevent individually unsafe commands from reaching equipment. This is a useful defense-in-depth measure, but it does not constitute a formal safety guarantee in the sense used in formal methods or control theory, because: (1) it lacks formal proof of completeness or soundness; (2) it does not account for state-dependent constraints (e.g., a gain value that is safe in one configuration but unsafe in another); (3) it does not provide concurrency control or transactional semantics across commands. We will revise the manuscript to replace 'safety guarantees' with more precise language throughout — e.g., 'per-command safety validation,' 'defense-in-depth validation,' or 'command-level safety constraints' — and will add an explicit limitations paragraph in §V.B or §VI acknowledging that the current validation mechanism is stateless, per-command, and does not provide formal guarantees, state-dependent checking, or concurrency control. We believe this framing accurately represents the contribution while not overstating it. revision: yes

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the paper is a framework description, not a derivation chain, and its self-citations are framing rather than load-bearing logical steps.

full rationale

This is an implementation/architecture paper, not a derivation paper. There is no mathematical or logical chain where an output is defined in terms of an input. The paper describes a software framework (AI-NNC) and its components. The two self-citations ([4], [22]) are used to attribute the architectural concept ('Inspired by the architectural principles identified in our prior work... [4]') and to suggest future integration with O-RAN RIC interfaces ([22]). Neither citation is used to prove a claim or forbid alternatives via a 'uniqueness theorem.' The central claims about the framework's properties (uniform enforcement, auditability) are structural properties of the described code architecture, not derived results that could be circular. The claim of 'compositional safety' (§V.B) is arguably overstated given the stateless per-command validators shown in Listing 2, but that is a correctness/overclaiming issue, not circularity: the paper is not defining a term in terms of itself or renaming a fit as a prediction. The 'validated using both simulated and physical optical network equipment' claim in the conclusion lacks supporting data in the paper, but this is an unsupported empirical claim, not a circular derivation. No step in the paper reduces to its inputs by construction. Score 1 reflects the minor, non-load-bearing self-citations for framing context, which is normal academic practice and does not constitute circularity.

Assumptions & free parameters 3 free parameters · 3 assumptions · 3 invented entities

The framework introduces a few design-level parameters (intervals, thresholds) and relies on domain assumptions about the sufficiency of static validation and ZMQ messaging for safe control. The invented entities are software artifacts with code listings, but one (ConflictMitigator) is referenced without detail.

free parameters (3)
  • measurement_interval = 1.0 (in Listing 1 example)
    Polling interval for node measurements, set per node.
  • control_loop_update_time = 2 (in Listing 2 example)
    Update interval for control applications, set per application.
  • Safety thresholds (e.g., max gain) = 25.0 (in Listing 2 example)
    Domain-specific limits hard-coded in validator functions.
assumptions (3)
  • domain assumption Safety constraints can be encoded as static per-command threshold checks.
    The command validation mechanism (§V) relies on validators that check individual command parameters against limits, assuming this is sufficient for infrastructure safety.
  • domain assumption ZeroMQ PUB/SUB and PUSH/PULL patterns provide sufficient reliability for network control messaging.
    The data plane architecture (§III.A) is built on ZMQ without discussing message loss, ordering guarantees, or latency bounds in critical control loops.
  • ad hoc to paper MCP (Model Context Protocol) is a suitable interface for agentic AI to interact with network infrastructure.
    The paper adopts MCP for AI agent integration (§IV.C) as a design choice; its suitability for real-time or safety-critical network control is assumed, not demonstrated.
invented entities (3)
  • AI-NNC (AI-Native Network Controller) independent evidence
    purpose: Software framework for multi-domain network control
    The framework is described as open-source with code listings provided, making it falsifiable and testable by others.
  • @aic_app / @command_validator decorators independent evidence
    purpose: Declarative Python interfaces for defining control applications and safety validators
    Concrete code patterns shown in Listings 1 and 2; reproducible.
  • ConflictMitigator application
    purpose: Arbitrates competing commands from different control applications
    Mentioned in §V.C as part of the reference implementation but not detailed or evaluated in the paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AI-Native Network Controller: A Modular Framework for Safe Agentic Control of Multi-Domain Network Infrastructure." pith.science (2026). https://pith.science/paper/4VTWTFRM

@misc{pith2026260620565,
  author       = {Pith},
  title        = {Pith review of: AI-Native Network Controller: A Modular Framework for Safe Agentic Control of Multi-Domain Network Infrastructure},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4VTWTFRM}},
  note         = {Machine review of arXiv:2606.20565}
}
read the original abstract

The convergence of multiple network domains, including radio access, optical transport, and core networks, under unified intelligent control is a fundamental requirement for future 6G systems. This is important because existing network controllers remain largely domain-specific, such as the O-RAN RIC for radio, or they lack native support for AI-driven automation across heterogeneous infrastructure. As a result, safe and coordinated agentic control of multi-domain networks is still an open challenge. In this paper, we present the AI-Native Network Controller (AI-NNC), an open-source and modular framework that enables agentic AI control across diverse network domains. The framework is designed around a protocol-agnostic architecture in which each physical device is integrated through a lightweight Python adapter, while control logic is implemented through domain-specific control applications. Beyond closed-loop control, the framework also supports dataset collection, agentic AI experimentation, and coordinated testbed operation using the same validated control and measurement interfaces. This design enables a safer paradigm for autonomous network management, where AI agents operate through validated applications rather than issuing commands directly to network equipment.

Figures

Figures reproduced from arXiv: 2606.20565 by the authors.

Figure 1
Figure 1. AI-NNC three-plane architecture. AI agents interact through the [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Unified command validation pipeline. All command sources, including [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 25 canonical work pages

  1. [1]

    Network slicing in 5G: Survey and challenges,

    X. Foukas, G. Patounas, A. Elmokashfi, and M. K. Marina, “Network slicing in 5G: Survey and challenges,”IEEE Communications Magazine, vol. 55, no. 5, pp. 94–100, 2017

    work page 2017

  2. [2]

    Network slicing and softwarization: A survey on principles, enabling technolo- gies, and solutions,

    I. Afolabi, T. Taleb, K. Samdanis, A. Ksentini, and H. Flinck, “Network slicing and softwarization: A survey on principles, enabling technolo- gies, and solutions,”IEEE Communications Surveys & Tutorials, vol. 20, no. 3, pp. 2429–2453, 2018

    work page 2018

  3. [3]

    Resource management from single-domain 5g to end-to-end 6g network slicing: A survey,

    S. Ebrahimi, F. Bouali, and O. C. Haas, “Resource management from single-domain 5g to end-to-end 6g network slicing: A survey,”IEEE Communications Surveys & Tutorials, vol. 26, no. 4, pp. 2836–2866, 2024

    work page 2024

  4. [4]

    Decentralized AI-control framework for multi-party multi-network 6G deployments,

    M. Dzaferagic, M. Ruffini, N. Slamnik-Krijestorac, J. F. Santos, J. Marquez-Barja, C. Tranoris, S. Denazis, G. C. Tziavas, T. Kyriakakis, P. Karafotis, L. A. DaSilva, S. R. Pandey, J. Shiraishi, P. Popovski, S. K. Jensen, C. Thomsen, T. B. Pedersen, H. Claussen, J. Du, G. Zussman, T. Chen, Y . Chen, S. Tirupathi, I. Seskar, and D. Kilper, “Decentralized A...

    work page 2025

  5. [5]

    Agentic ai: a com- prehensive survey of architectures, applications, and future directions,

    M. Abou Ali, F. Dornaika, and J. Charafeddine, “Agentic ai: a com- prehensive survey of architectures, applications, and future directions,” Artificial Intelligence Review, vol. 59, no. 1, p. 11, 2025

    work page 2025

  6. [6]

    The agentic- AI core: An AI-empowered, mission-oriented core network for next- generation mobile telecommunications,

    X. Li, W. Shi, H. Zhang, C. Peng, S. Wu, and W. Tong, “The agentic- AI core: An AI-empowered, mission-oriented core network for next- generation mobile telecommunications,”Engineering, 2025

    work page 2025

  7. [7]

    A comprehensive survey on safe reinforce- ment learning,

    J. Garcia and F. Fernandez, “A comprehensive survey on safe reinforce- ment learning,”Journal of Machine Learning Research, vol. 16, pp. 1437–1480, 2015

    work page 2015

  8. [8]

    Safe reinforcement learning via shielding,

    A. Alshiekh, R. Bloem, R. Ehlers, B. K ¨onighofer, S. Niekum, and U. Topcu, “Safe reinforcement learning via shielding,” inProc. AAAI Conference on Artificial Intelligence, vol. 32, 2018

    work page 2018

Show all 25 references
  1. [9]

    OpenFlow: Enabling innova- tion in campus networks,

    N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: Enabling innova- tion in campus networks,”ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008

    2008

  2. [10]

    Software-defined networking: A com- prehensive survey,

    D. Kreutz, F. M. V . Ramos, P. E. Verissimo, C. E. Rothenberg, S. Azodolmolky, and S. Uhlig, “Software-defined networking: A com- prehensive survey,”Proceedings of the IEEE, vol. 103, no. 1, pp. 14–76, 2014

    2014

  3. [11]

    OpenDaylight: Towards a model-driven SDN controller architecture,

    J. Medved, R. Varga, A. Tkacik, and K. Gray, “OpenDaylight: Towards a model-driven SDN controller architecture,” inProc. IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2014

    2014

  4. [12]

    ONOS: Towards an open, distributed SDN OS,

    P. Berde, M. Gerola, J. Hart, Y . Higuchi, M. Kobayashi, T. Koide, B. Lantz, B. O’Connor, P. Radoslavov, W. Snow, and G. M. Parulkar, “ONOS: Towards an open, distributed SDN OS,” inProc. 3rd ACM Workshop on Hot Topics in Software Defined Networking (HotSDN), 2014

    2014

  5. [13]

    Under- standing O-RAN: Architecture, interfaces, algorithms, security, and re- search challenges,

    M. Polese, L. Bonati, S. D’Oro, S. Basagni, and T. Melodia, “Under- standing O-RAN: Architecture, interfaces, algorithms, security, and re- search challenges,”IEEE Communications Surveys & Tutorials, vol. 25, no. 2, pp. 1376–1411, 2023

    2023

  6. [14]

    Intelli- gence and learning in O-RAN for data-driven NextG cellular networks,

    L. Bonati, S. D’Oro, M. Polese, S. Basagni, and T. Melodia, “Intelli- gence and learning in O-RAN for data-driven NextG cellular networks,” IEEE Communications Magazine, vol. 59, no. 10, pp. 21–27, 2021

    2021

  7. [15]

    Managing o-ran networks: xapp development from zero to hero,

    J. F. Santos, A. Huff, D. Campos, K. V . Cardoso, C. B. Both, and L. A. DaSilva, “Managing o-ran networks: xapp development from zero to hero,”IEEE Communications Surveys & Tutorials, 2025

    2025

  8. [16]

    Resource manage- ment with deep reinforcement learning,

    H. Mao, M. Alizadeh, I. Menache, and S. Kandula, “Resource manage- ment with deep reinforcement learning,” inProc. 15th ACM Workshop on Hot Topics in Networks (HotNets), 2016, pp. 50–56

    2016

  9. [17]

    Large language model (LLM) for telecommunications: A comprehensive survey on principles, key techniques, and opportunities,

    Z. Zhouet al., “Large language model (LLM) for telecommunications: A comprehensive survey on principles, key techniques, and opportunities,” IEEE Communications Surveys & Tutorials, 2024

    2024

  10. [18]

    A comprehensive survey on LLM-based network management and operations,

    S. Honget al., “A comprehensive survey on LLM-based network management and operations,”International Journal of Network Man- agement, vol. 35, 2025

    2025

  11. [19]

    TS 23.288: Architecture enhancements for 5G system (5GS) to support network data analytics services,

    3GPP, “TS 23.288: Architecture enhancements for 5G system (5GS) to support network data analytics services,” 2023

    2023

  12. [20]

    GS ZSM 002: Zero-touch network and service management (ZSM); reference architecture,

    ETSI, “GS ZSM 002: Zero-touch network and service management (ZSM); reference architecture,” 2019

    2019

  13. [21]

    From intents to actions: Agentic ai in autonomous networks,

    B. Demirel, P. Soldati, and Y . Wang, “From intents to actions: Agentic ai in autonomous networks,”arXiv preprint arXiv:2602.01271, 2026

    2026

  14. [22]

    Modular and integrated AI control framework across fiber and wireless networks for 6G,

    M. Dzaferagic, M. Ruffini, and D. Kilper, “Modular and integrated AI control framework across fiber and wireless networks for 6G,”arXiv preprint arXiv:2502.15731, 2025

    2025 arXiv

  15. [23]

    ZeroMQ: Distributed messaging,

    iMatix Corporation, “ZeroMQ: Distributed messaging,” https://zeromq. org, 2024

    2024

  16. [24]

    Safety and security guidelines for critical infrastructure owners and operators: AI in critical infrastruc- ture,

    U.S. Department of Homeland Security, “Safety and security guidelines for critical infrastructure owners and operators: AI in critical infrastruc- ture,” 2024

    2024

  17. [25]

    Artificial intelligence risk management framework (AI RMF 1.0),

    NIST, “Artificial intelligence risk management framework (AI RMF 1.0),” 2023, nIST AI 100-1

    2023

Pith tools

Reviewed July 5, 2026 · model on record in the stance chip above.