Network Digital Twin based Architecture for AI driven Network Operations

3.1. Generative AI and AI Agent

The integration of AI into network operations has marked a significant leap forward in the pursuit of network automation and intelligence, while generative AI further enhances the role of AI driven network operations and management. Generative AI is a subfield of AI that uses generative models such as Large Language Models (LLMs) to generate new and original content such as text, images, videos, or other forms of data with the capability to adapt and make decisions to achieve specific goals.¶

An AI agent refers to a system or program that Large Language Models (LLM)s to interact with humans (or other AI Agents) for purposes of performing tasks. In the context of network operations and management, Network AI agents are increasingly being designed to interact with physical world and act upon it based on tools [Google-Agents-Whitepaper] and perform network management tasks such as understanding user intent, generating network configurations, diagnosing and resolving network incidents [I-D.ietf-nmop-network-incident-yang]. Meanwhile, other SDOs also try to define terms related to Network AI agent in the context of network operations and management, e.g., TM Forum defines Autonomous Agent in [TMF-1251D] as one of AN (Autonomous Network) Terminologies.¶

3.2. Network Digital Twin

The Network Digital Twin is a digital representation that is used in the context of network. The concept and architecture of the Network Digital Twin are specified in [I-D.irtf-nmrg-network-digital-twin-arch]. Three core functional components which includes Data Repository component, a Service Mapping Models component, and an NDT Management component are introduced to characterize the Network Digital Twin and its reference architecture.¶

The Network Digital Twin is widely recognized to be useful as an advanced platform for network emulation, serving as a tool for scenario planning, impact analysis, and change management. By delivering applications requests to the Network Digital Twin through standardized interfaces (see Section 9.4 of [I-D.irtf-nmrg-network-digital-twin-arch]), the Network Digital Twin exposes the various capabilities to network applications.¶

5.1. Overall Architecture

Figure 2 provides the overall architecture for integrating Network Digital Twin and Network AI Agent System. The components and functional interfaces are discussed in Section 5.2 and Section 5.3, respectively. The use cases described in Section 7 show how different components are used selectively to provide different services. It is important to understand that the relationships and interfaces shown between components in this figure are illustrative of some of the common or likely interactions; however, this figure does not preclude other interfaces and relationships as necessary to realize specific functionality.¶

+------------------------------------------------------------------------+
|   +-------+   +-------+          +-------+           Network           |
|   | App 1 |   | App 2 |   ...    | App n |         Applications        |
|   +-------+   +-------+          +-------+                             |
+-------------------------------------^----------------------------------+
                                      | Intent
+-------------------------------------+----------------------------------+
|Autonomous Domain                    |                                  |
| +---------+   +---------------------+------------+  +----------------+ |
| |         |   |Multi-Agent System   |            |  |  Agent Gateway | |
| |         |   |             +-------v--------+   |  |+--------------+| |
| | Network |   |             |Network AI Agent|   |  || Registration || |
| |         |   |             +--------^-------+   |  |+--------------+| |
| | Digital |   |                      |           |  |+--------------+| |
| |         <--->           +----------+---------+ <-->|Authentication|| |
| | Twin    |   |           |          |         | |  |+--------------+| |
| |         |   | +---------v--+ +-----v------+  v |  |+--------------+| |
| |         |   | |Task Agent 1<->Task Agent 2| ...|  ||Knowledge Base|| |
| |         |   | +------------+ +------------+    |  |+--------------+| |
| +----^----+   +-----------------^----------------+  +--------^-------+ |
|      |                          |                            |         |
|      |                          |                            |         |
| +----v--------------------------v----------------------------|-------+ |
| |Physical Network                                            |       | |
| |      +---------+    +------------------+             +-----v---+   | |
| |      |         |    |                  |             |  +-----+|   | |
| |      |   NE    |    |NE(lightweight AI)|    ...      |NE|Agent||   | |
| |      |         |    |                  |             |  +-----+|   | |
| |      +---------+    +------------------+             +---------+   | |
| +---------------- ---------------------------------------------------+ |
|                                                                        |
+------------------------------------------------------------------------+

5.2. Functional Components

This section describes the functional components shown as boxes in Figure 2. The interactions between those components, the functional interfaces, are described in Section 5.3.¶

5.3. Functional Interfaces

This section describes the interfaces between functional components that might be externalized in an implementation allowing the components to be distributed across platforms. Where existing protocols might provide all or most of the necessary capabilities, they are noted.¶

As noted in Section 5.1, it is important to understand that the relationships and interfaces shown between components in Figure 2 are illustrative of some of the common or likely interactions; however, this figure and the descriptions in the subsections below do not preclude other interfaces and relationships as necessary to realize specific functionality. Thus, some of the interfaces described below might not be visible as specific relationships in Figure 2, but they can nevertheless exist.¶

7.1. Multi-Agent Collaboration on Network Configuration Change

Network configuration changes are needed in scenarios such as optimizing network or service performance, provisioning new network services, or resolving network incidents/faults.¶

                 +------------+
     Human       |   OSS      |
   Operator ----->  AI Agent  |
                 |            |
                 +-----+------+
                       |Intent                      +---------+
                       |                            |         |
      Network  +-------V---------+                  |         |
      AI Agent |     Goal        |                  |         |
       +-------| Task-1,Task-2   +------------------>         |
       |       |   ... Task-n    +-------+          | Network |
       |       +-------+---------+       |          | Digital |
       |               |                 |          |  Twin   |
       |               |                 |          |  Task   |
 +-----V------+  +-----V-------+  +------V----+     |  Agent  |
 |   Config   |  |  Config     |  |  Config   <----->         |
 | Generation |  | Distribution|  |Validation |     |         |
 | Task Agent |  |  Task Agent |  | Task Agent|     |         |
 +------------+  +-------------+  +-----^-----+     +---------+
                                        |
                                 +------V------+
                                 |  Resource   |
                                 | Allocation  |
                                 | Task Agent  |
                                 +-------------+

Network configuration change leveraging Network AI Agent and Network Digital Twin may experience the following typical steps:¶

Step 1:

The network operator inputs the intent of network configuration change into the Network AI Agent using natural language. The network operator may simply explain the objectives and requirements of the changes.¶

Step 2:

Network AI Agent first verifies the identity of the user requesting the change and checks the user's permissions to make certain types of network changes against predefined rules or policies. It then understands and parses the initial intent of the request, by leveraging the powerful knowledge and reasoning capabilities of LLM and decompose the tasks into configuration generation task, configuration distribution task, configuration validation task and assign to corresponding task agents. Configuration generation Task Agent first generates initial suggestions for specific network configuration update, which may include multiple possible network configuration change plans if possible.¶

Step 3:

Network AI Agent further communicates with the Configuration Validation task agent and Network Digital Twin task agent to validate the suggested configuration change, including the syntax and semantics of the configuration, verification of effected application and resources. The network digital Twin task agent may generate a report indicating the validation result, and suggested configuration fix when the validation fails after network simulation leveraging the current physical network operational state.¶

Step 4:

Network AI Agent may generate a configuration change plan and submit to the network operator for approval. Based on the feedback from the operator, Network AI Agent then further decides whether to optimize the change plan or deliver the plan to the Configuration Distribution task agent to conduct the physical network configuration change. The configuration distribution task agent may further communicate with resource allocation task agent to obtain network resource (e.g.,vlan, IP subnet) allocated by resource allocation task agent.¶

7.2. Network Troubleshooting

Network AI Agent could assist in network troubleshooting in the following significant aspects:¶

• Fault Identification:

  Network AI Agent continuously monitors and aggregates data from various sources, the comprehensive data collection provides a holistic view of the network operational state. By analyzing the real-time data, Network AI Agent could detect network anomalies swiftly, which enables the prompt identification of potential issues before they escalate into major faults, minimizing downtime or service disruptions. In some cases, the Leightweight AI located in the Network Element may handle some simple fault identification tasks (e.g., optical module fault automatic identification) to enhance the awareness, while the Network AI Agent and LLM could leverage their powerful processing capabilities to analyze the time-domain data collected from the optical module.¶

• Fault Diagnosis:

  Once a fault is identified, Network AI Agent delves into diagnosing the exact cause, it may also invoke some existing operations such as "incident-diagnose" RPC defined in [I-D.ietf-nmop-network-incident-yang]. By correlating symptoms and/or applying AI models trained on historical data, it can narrow down the potential causes and pinpoint the exact cause, which accelerates the diagnosis process and reduces the time needed to address the issue.¶

• Fault Repair:

  After diagnosing the fault, Network AI Agent can generate targeted repair solutions. These solutions range from specific configuration adjustments to more complex fixes (e.g., hardware replacement). Network AI Agent would also communicate with the Network Digital Twin to simulate the proposed repair solutions and get feedback from the Network Digital Twin. In advanced setups, Network AI Agent may automatically execute these repairs, ensuring quick restoration of normal operations and enhancing the overall reliability and efficiency of network management. But it may also first present the fault details and repair advice to the network operator for review, and proceed to carry out the repair task once it is confirmed.¶

• Fault Prediction

  As an advanced enhancement of fault management capabilities, fault prediction aims to reduce network risks through proactive management that prevents problems before they occur. Before a fault actually occurs, the NDT constructs a dynamic simulation model by collecting real-time multi-dimensional operational state data, including network topology, traffic load, and device performance indicators. Based on the network data, AI Agent uses large models and machine learning algorithms (such as time-series prediction models and anomaly detection models) to reason and analyze potential faults—for example, predicting the risk of physical link interruption based on optical cable signal attenuation data. Furthermore, the AI Agent generates recommended operations to avoid faults and validates them through simulation in the NDT, thereby achieving predictive maintenance of the network.¶

7.3. Network Optimization

Network optimization is often introduced due to the Network AI Agent's awareness of some potential network faults or anomalies through continuously monitoring of network operational state, e.g., AI models may predicts network congestion by analyzing historical and real-time network traffic data. It may also be triggered by the network operator actively inputting the network optimization intent.¶

Based on the analysis of network data and user's intent (if any), AI Agent proposes network optimization strategies. For instance, once the network congestion sometime in the future is predicted, it may proactively optimize the network configuration, or suggest scaling up to meet specific demands.¶

Before the network optimization is conducted, Network AI Agent implements and evaluates the optimization solution using the Network Digital Twin. This may need repeated trials and validations based on specific evaluation criteria, before the optimal strategy could be selected. Network AI Agent may also first present the suggested network optimization solution to the network operator for review, and apply it to the physical network after obtaining approval from the network operator.¶

7.4. Network level Energy Efficiency Management

Network level Energy Efficiency refer to a set of processes used to discover a inventory of capabilities, use specific metrics to monitor and assess energy consumption of the network , operate, and control the use of available energy in an optimized manner while achieving the network’s functional and performance requirements by improving overall network utilization.¶

Network level Energy Efficiency allows network operators not only see real time energy consumption in the network devices of large scale network through interaction with the GREEN Network AI Agent, but also allow them see¶

o which network devices enable energy saving, which devices not,which are legacy ones,¶

o The total energy consumption changing trend over the time of the day, for all network devices,¶

o Energy efficiency changing trend over the time of the day for the whole network.¶

On the other hand, With the better observability to energy consumption statistics data and energy efficiency statistics data, the Network AI Agent can know which part of the network need to be adjusted or optimized based on network status change.¶

7.5. Network Security Drills

The AI Agent can help construct a dynamic attack-defense verification system in network security drills through NDT and AI reasoning capabilities. It uses generative AI to automatically generate diversified attack paths, models network topologies with graph neural networks, covers attack stages such as reconnaissance and penetration, and dynamically adjusts strategies via reinforcement learning to simulate the adaptive characteristics of network attacks. The virtual range built based on the NDT can 1:1 map the production environment, supporting simulations of composite scenarios like ransomware chain attacks and supply chain attacks—such as simulating the entire process of Conti virus laterally penetrating to domain controllers through weak passwords.¶

During drills, the AI Agent automatically deploys virtual environments with vulnerabilities, collects defense response data in real time through NDT, and generates attack path heatmaps and repair suggestions. This capability can further verify emergency response processes, inject real-time threat intelligence to dynamically update drill scenarios, and simulate end-to-end automated deployment, vulnerability injection, and real-time analysis of security drills, enhancing the proactive verification ability of defense systems against real-world threats.¶

8.1. Hallucination

Hallucination refers to the generation of AI responses that are incorrect, irrelevant, or even nonsensical in relation to the input or context provided. Although Gen-AI can produce seemingly impressive results at first glance, there's a risk of them being completely wrong at times. These hallucinations can lead to incorrect decisions and actions in network management. For example, if the AI generates inaccurate network configurations or diagnoses faults incorrectly, it may cause network disruptions or security vulnerabilities. The challenge lies in identifying and correcting these hallucinations to ensure the reliability of AI-driven network management actions.¶

8.2. Security

Integrating AI into network management introduces new security challenges. Large volumes of network data needs to be accessed to learn network behaviors and make accurate decisions. Protecting sensitive network data and ensuring the integrity of AI-generated decisions are crucial. Besides, AI systems can become targets for attacks aimed at compromising network security. For instance, malicious actors could attempt to manipulate AI models to make them generate harmful network configurations or to disclose confidential network information. Additionally, the integration of AI Agents from different vendors may create new vulnerabilities that need to be addressed, e.g., lack of effective authentication and authorization among different Agents. In summary, ensuring robust security measures throughout the entire AI-based network management architecture is essential to prevent unauthorized access and maintain the security of the network infrastructure.¶

8.3. Data Quality and Consistency

The performance of AI models heavily relies on the quality and consistency of the data they're trained on. In network management area, data sources can be diverse and heterogeneous, leading to potential issues such as data inconsistencies, missing, or outdated data. Poor-quality data may result in inaccurate AI predictions and decisions. For example, if incorrect or outdated network configuration data is provided, the model may provide incorrect repair advice when diagnosing network incidents or faults, it may suggest checking an non-existing interface. Ensuring that data is properly cleaned, validated, and maintained is a significant challenge in providing reliable inputs for AI-driven network management.¶

8.4. Interpretability and Explainability

AI-generated decisions can sometimes be difficult to interpret and explain, as the AI model structure and the parameter settings make it hard to track its internal decision-making logic. Network operators need to understand the reasoning behind AI-driven decisions to trust and effectively utilize them. For example, if an AI system recommends a particular configuration change to optimize the network performance, operators may wonder why that specific change is being suggested. The lack of interpretability can hinder the adoption of AI Driven Network Management and make it challenging to identify potential issues with AI-generated recommendations.¶

8.5. Fast Decision-making

In network operation and maintenance scenarios with high real-time requirements, such as scheduling strategy optimization and critical fault repair, the rapid generation of network optimization decisions is crucial. However, AI Agents based on large models adopt a "Token-based" generation and reasoning approach, which is limited by computing power and algorithms, resulting in generally slow reasoning speeds. In addition, the simulation and verification process of Network Digital Twin (NDT) further increases decision latency, which leads to long end-to-end decision-making time in complex scenarios and is difficult to meet the real-time requirements of services. To improve decision efficiency, continuous efforts are needed in lightweight NDT modeling algorithms, optimizing large model reasoning frameworks (such as quantization technology and parallel computing), and deploying high-performance AI acceleration hardware.¶

11.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2. Informative References

[A2A]

"Agent2Agent (A2A) protocol", April 2025, <https://google-a2a.github.io/A2A/#/documentation?id=agent2agent-protocol-a2a>.

[A2A-T]

"Agent to Agent Protocol for Telecoms (A2A-T)", 2025, <https://www.tmforum.org/resources/introductory-guide/ig1453-agent-to-agent-protocol-for-telecoms-a2a-t-v1-0-0/>.

[Google-Agents-Whitepaper]

"Agents", 2024, <https://www.kaggle.com/whitepaper-agents>.

[I-D.hong-nmrg-agenticai-ps]

Hong, Y., Youn, J., Wu, Q., and B. Claise, "Motivations and Problem Statement of Agentic AI for network management", Work in Progress, Internet-Draft, draft-hong-nmrg-agenticai-ps-00, 20 October 2025, <https://datatracker.ietf.org/doc/html/draft-hong-nmrg-agenticai-ps-00>.

[I-D.ietf-nmop-network-incident-yang]

Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network-incident-yang-07, 3 January 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang-07>.

[I-D.ietf-nmop-terminology]

Davis, N., Farrel, A., Graf, T., Wu, Q., and C. Yu, "Some Key Terms for Network Fault and Problem Management", Work in Progress, Internet-Draft, draft-ietf-nmop-terminology-23, 18 August 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-nmop-terminology-23>.

[I-D.irtf-nmrg-ai-challenges]

François, J., Clemm, A., Papadimitriou, D., Fernandes, S., and S. Schneider, "Research Challenges in Coupling Artificial Intelligence and Network Management", Work in Progress, Internet-Draft, draft-irtf-nmrg-ai-challenges-05, 18 March 2025, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ai-challenges-05>.

[I-D.irtf-nmrg-network-digital-twin-arch]

Zhou, C., Yang, H., Duan, X., Lopez, D., Pastor, A., Wu, Q., Boucadair, M., and C. Jacquenet, "Network Digital Twin: Concepts and Reference Architecture", Work in Progress, Internet-Draft, draft-irtf-nmrg-network-digital-twin-arch-11, 6 July 2025, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-network-digital-twin-arch-11>.

[MCP]

"Model Context Protocol", November 2024, <https://modelcontextprotocol.io/>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/rfc/rfc6241>.

[RFC7011]

Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/rfc/rfc7011>.

[RFC7854]

Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/rfc/rfc7854>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/rfc/rfc8040>.

[RFC8639]

Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, <https://www.rfc-editor.org/rfc/rfc8639>.

[RFC8641]

Clemm, A. and E. Voit, "Subscription to YANG Notifications for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641, September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.

[RFC9232]

Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, <https://www.rfc-editor.org/rfc/rfc9232>.

[RFC9315]

Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, <https://www.rfc-editor.org/rfc/rfc9315>.

[TMF-1251D]

"AN Agent Architecture v1.0.0", May 2025, <https://www.tmforum.org/resources/introductory-guide/ig1251d-an-agent-architecture-v1-0-0/>.

[TMF-1258]

"Autonomous Networks Glossary v1.2.0", May 2025, <https://projects.tmforum.org/wiki/display/PUB/IG1258+Autonomous+Networks+Glossary+v1.2.0>.