A Reference Functional Architecture for Network Digital Twins in 6G Systems

This document corresponds to a manuscript currently under review for publication in a peer-reviewed journal. The content may be subject to change following the peer-review process. 1 A Reference Functional Architecture for Network Digital Twins in 6G Systems Ayat Zaki-Hindi ∗ , Paola Soto † , German Castellanos ‡ , Touhid Hossain Pritom § , Gaetano Volpe ¶ , Iskander Zellagui ∥ , Burkhard Hensel § , Julian Jimenez † , Michele Marvulli ¶ , Luís Santos ∗∗ , Ayse Sayin †† , Jean-Sébastien Sottet ∗ , Wasim Ali¶, Ines EL-Korbi∥, Ion Turcanu∗, Andrey Belogaev†, André Duarte∗∗, Ultan Kelly‡‡, Sumit Kumar∗, Georgy Myagkov x , Stephen Parker ‡ , Mario Franke § , Shajjad Hossain ∥ , Rajarshi Sanyal xi , Nida Shafi x , Christoph Sommer § , Miguel Camelo†, Julien Baudouinxi , Régis Decormexii , Maria Pia Fanti¶, Ramin Fuladi††, Chris Murphyx, Ana Pereira∗∗, Sidi Mohammed Senouci∥, Simon Pryor‡, Sébastien Faye∗ ∗Luxembourg Institute of Science and Technology (LIST), Luxembourg †IDLab, University of Antwerp - imec, Belgium ‡Accelleran, Belgium §TU Dresden, Faculty of Computer Science, Germany ¶Politecnico di Bari, Italy ∥ Université de Bourgogne, France ∗∗ Ubiwhere, Portugal †† Ericsson Ara¸stırma Geli¸stirme ve Bili¸sim Hizmetleri A.¸S., Turkey ‡‡Viavi Solutions Ireland Ltd, Ireland xViavi Solutions UK Ltd, UK xi Proximus Luxembourg S.A., Luxembourg xii R2M Solution, France Corresponding author: [email protected] Abstract—AI-native, programmable, and disaggregated 6G networks will be highly dynamic and distributed, demanding tools that can explain, predict, and safely optimize behavior across the edge–cloud continuum. Network Digital Twins (NDTs) promise this capability, yet current efforts in research and industry are fragmented and lack widely accepted formal definitions and architectural guidelines. This paper proposes a structured framework for NDTs in 6G, addressing these gaps by refining the conceptual foundations of NDTs, introducing a functional architecture, inherited from the 6G-TWIN EU consortium, and clarifying key components such as AI-driven workflows, the place of simulation, data management, and orchestration. Concrete examples illustrate how these components enable network automation, optimization, and predictive analytics. The paper proceeds by reviewing related work and standardization efforts, specifying functional and non-functional requirements, presenting the architecture and its various domains, and detailing lifecycle management across cloud to edge. We then report early implementations and evaluation results, and discuss security, privacy, and governance considerations, concluding with directions for validation and uptake. The key objective is to offer a cohesive reference model that guides the community in shaping NDT development, ensuring interoperability, scalability, adaptability, and seamless integration into AI-native 6G networks for improved intelligence and efficiency. Index Terms—6G, AI-Native Network Orchestration, ClosedLoop Network Automation Edge–Cloud Continuum Management, Federated Co-Simulation, Network Digital Twin, I. INTRODUCTION F UTURE 6G networks will operate under unprecedented levels of complexity, driven by ultra-dense deployments, heterogeneous access technologies, stringent latency and reliability constraints, and pervasive intelligence at the network edge. The number of connected applications and services will far exceed those of previous generations, with traffic demand expected to be nearly ten times higher than when 5G was first introduced in 2018 [1]. These trends will also introduce new constraints from verticals such as connected mobility, digital health, and public protection and disaster relief. Each of these domains will impose distinct requirements on reliability, latency, and distributed intelligence across the edge-cloud continuum, while ensuring energy efficiency and seamless operation across diverse and dynamic network environments. To manage such systems, network operators will require continuous visibility, predictive control, and automated assurance across the entire service lifecycle, from design and planning to real-time operation and optimization. Conventional management frameworks, largely static and rule-based, can no longer cope with the dynamics, heterogeneity, and scale of next-generation networks. Instead, networks must evolve toward dataand model-driven operation, combining predictive intelligence (i.e., anticipating behaviors, trends, and anomalies beyond the limits of traditional simulation) with real-time adaptive control (i.e., ensuring continuous optimization and resilience under rapidly changing conditions). In this context, Network Digital Twins (NDTs) are emerging as a cornerstone of next-generation network management. An NDT is a virtual, continuously synchronized replica of the physical network that captures its topology, configuration, performance, and environment. Through bidirectional data exchange, the NDT mirrors the state of the live network, enabling real-time monitoring, predictive analytics, “what-if” experimentation, and closed-loop optimization. NDTs thus act as cognitive mirrors and safe sandboxes of the network to test policies, train Artificial Intelligence (AI) models, and anticipate failures before they affect live services. The integration of NDTs into 6G architectures is therefore essential. The 6G vision extends beyond connectivity to create intelligent, sustainable, and self-adaptive infrastructures spanning the edge-cloud continuum. Achieving this vision requires a management paradigm in which the network continuously reasons about its own behavior, learns from historical and contextual data, and refines its operation autonomously. NDTs provide the means to achieve this: they support closed-loop 2 learning and optimization at multiple timescales, facilitate the safe introduction of AI-based control, and underpin key functions such as network planning, slice assurance, and energy optimization. Incorporating NDTs into the operational lifecycle of 6G, including design, deployment, operation, and assurance, ensures that the network remains both agile and trustworthy as conditions evolve. However, orchestrating NDTs efficiently across distributed 6G infrastructures introduces significant challenges [2]. The heterogeneity of data sources, compute nodes, and administrative domains demands federated, context-aware orchestration and semantic interoperability [3]. From a literature perspective, existing efforts remain fragmented: while several standardization bodies (e.g., ITU-T SG13, 3GPP, ETSI) and research works have proposed concepts or domain-specific digital twins, proposals are either too abstract for implementation or too narrow to generalize beyond a particular segment (e.g., RAN, core, or transport). Critically, there is no widely accepted, formal scope and lifecycle for NDTss, limited integration between AI training and simulation pipelines, and insufficient coordination across the edge-cloud continuum. This fragmentation underscores the need for an architecture that explicitly governs orchestration and lifecycle management across the entire stack. This paper addresses these gaps by proposing a comprehensive functional architecture for NDTs in 6G systems, designed to enable scalable, interoperable, and AI-driven orchestration from cloud to edge. Building upon our previous work [4], which introduced the first conceptual framework from the Horizon Europe 6G-TWIN project [5–11], we extend and consolidate that vision through four key advancements: • We formalize a working definition, scope, and lifecycle for NDTss in 6G, consolidating fragmented literature/industry efforts and deriving functional and non-functional requirements to guide design and evaluation. • We present a reference functional architecture, decomposed into application, physical, digital, and management domains, with clear interfaces and a harmonized data pipeline. • We specify lifecycle-aware procedures for NDT instances (instantiation, synchronization, model selection/update, federation, and safe actuation) that operate coherently across the full cloud–edge continuum. • We integrate AI and simulation via coordinated MLOps and co-simulation workflows, distinguishing basic and functional models to support explainable “what-if” experimentation and closed-loop optimization. • We validate the approach through early implementations, showcasing different but complementary assets of the NDTs while discussing security, privacy, and data governance. Beyond the proposed functional architecture, the paper also introduces preliminary implementation results demonstrating early NDT deployments that focus on specific architectural aspects such as data harmonization, AI-based modeling, and simulation-driven optimization. Furthermore, we outline deployment considerations critical to ensuring secure, privacyNetwork application Physical network Network Digital Twin Visualization Optimization … UE Infrastructure Computing resources NDT management Unified data models Unified Data Repository Capability exposure Intent input Data collection Control Functional models Basic models Security mgmt Topology mgmt Model mgmt Figure 1. Baseline reference architecture from ITU-T preserving, and sustainable integration of NDTs into operational networks. The remainder of the paper is structured as follows. Section II reviews related work and existing architectural proposals. Section III presents the functional and non-functional requirements of the proposed NDT architecture. Section IV introduces our proposal for an AI-native functional architecture that integrates NDT as a central element. Sections V to VIII detail the application, physical, digital, and management domains. Section IX discusses NDT lifecycle management and mapping to representative 6G scenarios. Section X discusses implementation details and evaluation results. Section XI concludes the paper by addressing security, privacy, governance, and future research directions. II. RELATED WORK This section reviews the current landscape of NDT architectures, covering perspectives from standardization bodies, industry, and academia, highlighting their main contributions and conceptual differences. A. Standard Development Organizations (SDOs) The International Telecommunication Union - Telecommunication Standardization Sector (ITU-T) Recommendation Y.3090 [12] defines one of the foundational NDT architectures, structured into three layers: application, Digital Twin (DT), and physical network – as abstracted in Figure 1. The physical layer includes real and virtualized entities such as gNodeBs (gNBs), User Equipments (UEs), and core functions; the DT layer hosts the models, data, and management entities; and the application layer orchestrates NDT instances in response to external requests. The ITU-T identifies four core enablers, namely, data, mapping, models, and interfaces, ensuring realtime synchronization, fidelity, and interoperability across digital and physical domains. Complementary frameworks from the 3rd Generation Partnership Project (3GPP) [13], Open RAN Alliance (O-RAN) Alliance [14], European Telecommunications Standards Institute (ETSI) [15], and Internet Engineering Task Force (IETF) [16] extend this vision. 3GPP focuses on NDTs for network automation and closed-loop control, while O-RAN emphasizes their role in Radio Access Network (RAN) optimization. ETSI 3 integrates NDTs into the Zero-touch Service and network Management (ZSM) framework for automated orchestration, and the IETF outlines a functional architecture emphasizing real-time modeling, analytics, and decision feedback in live networks. B. Industry Industry leaders have embraced NDTs as tools for operational efficiency, predictive maintenance, and autonomous management. Spirent [17] conceptualizes NDTs as modular softwarehardware systems enabling validation and performance assurance. ZTE [18] extends this with a microservice-based architecture for scalability and maintainability. Ericsson integrates AI/Machine Learning (ML) with NDTs in collaboration with 3GPP to ensure interoperability and AI-native automation 1 , also demonstrating cloud-native 5G Core deployment with Deutsche Telekom and Google Cloud 2 . Nokia’s Dynamic Digital Twin 3 and AI-native 6G efforts enable real-time predictive operations and adaptive optimization. Huawei’s “Intelligent World 2030” [19] envisions fully autonomous, energy-efficient networks through deep AI integration4. C. Academia Academic efforts initially focused on AI-driven network management before the formalization of NDTs. Wang et al. [20] surveyed AI for network optimization, while Dong et al. [21] introduced early DT-based energy-efficient models. Zhou et al. [22] proposed a hierarchical satellite DT framework with edgeand central-level twins to support distributed optimization. Vilà et al. [23] presented a RAN-centric NDT architecture aligned with O-RAN and IETF principles, emphasizing modular models and data repositories. Kuruvatti et al. [24] synthesized NDT requirements from ITU-T and IETF, defining a threelayer, dual closed-loop structure consistent with Y.3090. D. Discussion Overall, SDO-driven works define core NDT principles: data, mapping, models, and interfaces, but lack clarity on data ingestion, AI model integration, and simulator roles. Industrial and academic efforts mainly target RAN-centric use cases [23, 25, 26], often remaining too narrow or conceptual. Some studies [27–29] propose AI-native architectures acknowledging NDTs but without concrete integration strategies. Our previous work [4, 30] addressed these gaps through an AI-native architecture integrating data collection, ZSM, federated management, and simulation. The present work further refines this by introducing an NDT MANagement and Orchestration (MANO) layer, a unifying vertical control framework harmonizing AI workflows, simulation, and federated orchestration across physical and digital domains. 1https://www.ericsson.com/en/6g 2 https://www.telekom.com/en/media/media-information/archive/ 5g-cloud-native-pilot-shows-efficiency-1026992 3 https://www.nokia.com/bell-labs/research/air-lab/modelling-optimization/ dynamic-digital-twin/ 4 https://www.huawei.com/en/news/2021/9/ huawei-releases-intelligent-world-report-2030 III. NDT FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS When creating a software tool, one of the first things to do is to list the Functional Requirements (FRs) and NonFunctional Requirements (NFRs). This is not different for an NDT since it lays the foundation for aligning the NDT with the needs of users, stakeholders, and the technical challenges posed by 6G environments, making this phase extremely important. To ensure effective implementation, an NDT must accurately model and represent the physical network in real time, relying on unified data models and a harmonized data repository. It must support full instance lifecycle management, seamless integration with AI/ML components, and operate either as an analytical or controlling twin within closed-loop systems. Federated cooperation between multiple NDT instances is also required. To do so, the NDT system should have a MANO layer, enhanced with ZSM, that orchestrates NDT lifecycle processes including creation, deployment, updates, and deletion, while supporting AI-based workflows and standardized Application Programming Interfaces (APIs). Similarly, to support whatif capabilities, the NDT should integrate and synchronize heterogeneous simulators, manage configurations, and maintain closed-loop interoperability with other system components. Representing the physical network with high-fidelity cannot occur without a robust data collection framework that ensures multi-domain data integration across the Cloud-toFar-Edge continuum, harmonization of heterogeneous data formats, and securing, protocol-agnostic communication with connected devices. Similarly, all the processes and interactions of the NDT with its physical counterpart should follow the automation principles outlined by a ZSM framework who discovers, monitors, and orchestrates network resources, while ensuring interoperability and secure communications via standardized APIs and Authorisation/Authentication/Accounting mechanisms. Regarding the non-functional requirements, they define the performance, scalability, and reliability constraints of the NDT architecture. The NDT architecture must guarantee scalability, low latency, reliability, and security, with mechanisms for redundancy, access control, and fault tolerance. Its modular, service-based design should ensure maintainability and compatibility across technologies. Moreover, it must integrate Developer Operations (DevOps), Machine Learning Model Operationalization Management (MLOps), and cloudnative principles to achieve efficient, secure, and flexible orchestration of distributed AI-enabled network functions and simulations in real time. IV. NDT ARCHITECTURE OVERVIEW Building upon the requirements outlined in Section III, Figure 2 represents the proposed functional architecture, designed as an integrated framework that unifies NDTs with AI-driven functionalities and simulation components under a unified management layer. This functional architecture is designed to operate as a closed-loop system, where data flows continuously between the real-world network, its digital representation, and the management functions that synchronize 4 NDT Instance Network applications Data collection: telemetry collector, databases, data buses, … Actuation and execution Physical Network Digital Network - aka NDT - Human world Functional models: Energy savings in dense deployments Teleoperated driving Real-world representation User equipment Environment Radio access network Core network Network MANO with ZSM capabilities Simulator 1 Simulation model 1 Simulation model 2 Simulator 2 Simulation model 3 Simulation model 4 Interface layer Use-case instantiation & results Unified data repository: structured and harmonised data … Results, inc. linked KPIs Push/request data to/from the real network Push/request data, metrics (i.e., predicted), and models Effect changes Open and secured NDT modelling and simulation framework RIC Tester Real CU/DU/RU:ACC, PX, … NDT Instance Link with the reality RIC Core: Free5GC, OAI, … Ideas and scenarios: Snapshot & requirements pushed to the framework „Scenario builder“ interface inc. NDT functionality „marketplace“ Real-time monitoring Complete, persistent view “What-if” representation for testing & data generation - simulation Incomplete, on-demand view (snapshot) AI training / optimizer (functional models) Unified data model repository Training data from simulation or real network Trained model Unified dashboard AI training methods Optimization methods Comparison of what-if simulation results Basic models: representations of network components and behaviour Functional models:Traffic analysis & generation Network planning Network management & control 6G-TWIN Management and Orchestration Layer Physical Network MANO Simulation Management NDT Management: mapping between scenario requests and NDT‘s data/models/simul ation; life-cycle management. Data Management NDT Model Management NDT Translation LayerResource ManagementNDT Orchestrator NDT Monitor AI Workflow Management Federated Management Management and Orchestration Instructions Figure 2. 6G NDT functional architecture them. To structure this interaction, the architecture is organized into four interconnected domains: application,physical,digital, and management. Each domain fulfills a distinct role while contributing to the end-to-end integration of the NDT. The application domain contains the dashboard equipped with the interfaces through which humans interact with the NDT. The dashboard serves as the human-in-the-loop entry point, enabling stakeholders to visualize network state, and to configure NDT and monitor NDT operations in real time. The physical domain comprises the operational infrastructure, including the RAN, Core Network (CN), Transport Network (TN), and edge/cloud computing resources. It plays a dual sense–act role in the NDT ecosystem by providing telemetry and contextual data to the digital domain, and then by enforcing optimization decisions, configuration updates, and control actions generated by the NDT. The digital domain contains the digital representation of the physical network and the mechanisms needed to analyze and predict its behavior. It integrates the data-driven digital representation of the physical network, simulation engines, and AI training pipelines. This domain ensures that the NDT continuously reflects the state of the physical network while enabling predictive modeling, what-if analysis, and the creation of deployable functional models that are validated in the NDT before being instantiated in the physical domain through the NDT MANO. The management domain oversees the instantiation, synchronization, and lifecycle of NDT components. It orchestrates interactions between domains, ensuring that data flows are harmonized, models remain consistent, and simulations or AI workflows are executed efficiently. By coordinating telemetry ingestion, model updates, and decision deployment, this domain is what makes the NDT “alive,” transforming static models into an adaptive, self-evolving system. An important aspect of the proposed architecture is the distinction between the NDT and an NDT instance, a differentiation that is rarely emphasized in the existing literature. The NDT architecture covers the full set of components, representations, and functionalities that, in principle, could replicate the physical network in all its detail. However, maintaining such a global and continuously accurate digital replica is both costly and unnecessary for most applications. In practice, the NDT is instantiated to create an NDT instance, designed to perform a specific task for a given time duration. For example, an application may require an NDT instance dedicated to planning new gNB deployments within a certain geographic area under specific Quality of Service (QoS) constraints. In such cases, only a subset of models and functionalities is activated to serve the task. This distinction is essential: treating the NDT as a single, monolithic instance reduces its value as a flexible, general-purpose architecture, whereas recognizing instances allows the architecture to support multiple, concurrent objectives efficiently. The following sections detail the building blocks within each domain and their role in enabling scalable, adaptive, and AI-driven NDTs. 5 V. APPLICATION DOMAIN The unified dashboard serves as the primary interface between NDT stakeholders and the system. It provides users with the means to interact with both the NDT and, indirectly, the physical network. The range of functionalities exposed through the dashboard depends on the autonomy level of the NDT [31]. In low-autonomy settings, the NDT operates only in the digital domain, and the dashboard is limited to monitoring and analysis tasks. At higher levels of autonomy, the NDT can issue control actions to the physical network, making the dashboard a critical channel for decision-making and oversight. At its core, the dashboard supports the visualization of the current network state, enabling users to query specific parameters or network elements. More advanced features extend this role by offering predefined models and commands that can be configured or personalized. A further step is the integration of natural-language interfaces, for example, through Large Language Model (LLM)-based chatbots pre-trained on domainspecific tasks. In this case, users can describe their goals in natural language, and the chatbot translates these objectives into actionable tasks within the NDT. This direction aligns with emerging research trends in network management, as illustrated in [32], which demonstrates the potential of conversational AI to simplify network operations. Interfaces between the dashboard and the NDT are realized through APIs, which are defined and managed within the NDT MANO. To ensure reliability, such interfaces can incorporate a verification step, where the chatbot presents its interpretation and planned actions for user confirmation before execution. The dashboard also acts as the NDT output channel. For tasks requiring control over the physical network, different levels of automation are possible. In a conservative mode, the NDT provides recommended solutions, and users retain responsibility for applying them, thus ensuring compliance with organizational policies or regulatory constraints. In fully autonomous settings, the NDT may apply changes directly, while still presenting a summary of actions to the user. In hybrid approaches, changes are executed only after explicit user approval, although this may limit applicability in real-time scenarios. VI. PHYSICAL DOMAIN The physical domain constitutes the tangible environment on which the NDT operates and provides feedback and control. As illustrated in Figure 3, this domain is composed of three main components. The first is the physical network, representing the real-world infrastructure, including its relevant entities, interfaces, and resources that the NDT is designed to replicate, monitor, optimize, and when required, control. The second component is the data collection framework, which enables the NDT to monitor the state of the physical network by continuously acquiring, processing, and harmonizing operational data to maintain synchronization between the physical and digital worlds. The third component is the actuation and execution framework, responsible for translating the insights, recommendations, or control policies generated by the NDT Telemetry Data Layer Telemetry Data Storage Telemetry data ingestion Telemetry Data Stream Processor Network planning, management and control User equipment Environment Radio access network Core network Telemetry Data Stream Output Act Sense Figure 3. Structure of the physical domain illustrating its components: physical network, data collection, and actuation User Equipment (UE) Radio Access Network (RAN) Core Network (CN) Data Network (DN) Transport Network (TN) Edge and Cloud Computing Figure 4. 5G and 6G physical network domains into deployable configurations or algorithms within the live network. Together, these components establish the basis for closedloop operation, where the NDT continuously performs a cycle of sensing (observing the physical network), thinking (analyzing and deciding within the NDT), and acting (executing optimized actions in the physical domain), followed by renewed sensing to assess outcomes and refine subsequent decisions. These components are further detailed in the following subsections. A. Physical network To construct the NDT, it is first necessary to define the network domains that the twin must represent. Since the focus of this work is on next-generation systems, where 6G is considered a natural evolution of 5G, the NDT must capture the components that remain fundamental to these networks while accommodating emerging architectural extensions. As illustrated in Figure 4, the network can be divided into several main domains that collectively form the foundation of end-toend communication systems. The RAN and the CN constitute the structural backbone of contemporary 5G deployments and are expected to retain this central role in 6G [33]. These domains are typically managed by Mobile Network Operators (MNOs), who oversee most of the optimization and orchestration activities. Network planning, mobility management, traffic steering, and resource allocation are primarily performed within these domains. Complementing them, the TN interconnects the RAN and CN, ensuring reliable data forwarding and synchronization. Although the TN is not always the primary target of optimization, it plays a vital role in supporting end-to-end capabilities such as network slicing and latency-sensitive service delivery [34]. The edge and cloud computing domains are also essential components of next-generation architectures. As in 5G, these domains enable 6 the processing of large volumes of data closer to where it is generated, reducing latency and improving service efficiency. Their integration is tightly coupled with QoS and Quality of Experience (QoE) guarantees, which are key drivers of future intelligent communication systems. Consequently, they must be represented within the NDT to ensure accurate modeling of distributed computation and data offloading behaviors. At the final stage of the communication chain lies the Data Network (DN), which provides connectivity to external application servers and the broader Internet. Since the DN generally falls outside the administrative control of MNOs, a full-scale digital replication may not be feasible. Nonetheless, aggregated application-level statistics exposed by the CN can serve as proxies to capture the DN’s impact on end-to-end performance metrics. Finally, the UE is an essential part of the physical network representation, as many NDT applications target usercentric performance optimization through adaptive and contextaware resource management. Including the UE ensures accurate reproduction and prediction of network behavior from both infrastructure and user perspectives. Driven by the principles of network programmability [35] and ZSM [36], the physical network adopts an AI-native architecture that enables data-driven automation and dynamic, closed-loop optimization. It exposes the telemetry data, programmability hooks, and orchestration interfaces needed for the NDT to operate as an analytical and decision-support service or to evolve into a fully controlling component in highly autonomous networks [37]. In this role, the NDT serves as a safe, isolated sandbox where decisions, configurations, and experiments can be evaluated before deployment on the live network, ensuring no impact on its real-time operation or performance. This capability supports the training and validation of AI and nonAI algorithms, while enabling the continuous refinement of decision-making mechanisms. Ultimately, it allows network controllers to dynamically adapt to changing conditions through programmatic, feedback-driven loops. B. Data collection Data collection is considered one of the essential requirements to build and maintain an accurate digital replica, as specified by several standardization bodies [12, 38]. Data collection must be driven by specific operational objectives rather than performed indiscriminately, as excessive data acquisition increases resource consumption and reduces system efficiency. To address this, operators can define adaptive data collection parameters that respond to network conditions or predefined events, ensuring that only relevant and actionable data is gathered, an essential feature in large-scale networks where bandwidth and storage are limited. Our approach adopts a multi-layer design comprising a Telemetry Data Layer (TDL) in the physical domain and a Harmonization Data Layer (HDL) in the digital domain. The TDL captures and pre-processes raw telemetry streams from network interfaces. The HDL, on the other hand, aggregates, harmonizes, and structures these pre-processed datasets into standardized smart-data models 5 for use in modeling, simula5https://smartdatamodels.org/ tion, and decision-making. This separation enables telemetry data to be leveraged independently for network performance monitoring, without invoking the full NDT processing chain. Details of the HDL and its integration into the Unified Data Repository (UDR) are further discussed in Section VII-A 1. The two layers are interconnected via Data Communication Buses (DCBs), which ensure reliable and adaptive data flow between domains through dynamic routing, prioritization, and integrity checking mechanisms. Focusing on the physical domain, the TDL, as shown in Figure 3, is subdivided into four key functional elements. The telemetry data ingestion collects raw telemetry data from various sources in real-time, forming the initial entry point into the system. This raw data is then passed to the telemetry data stream processor, which processes and analyzes the ingested data streams, performing tasks such as filtering, aggregation, and enrichment to generate actionable insights. The processed telemetry data is then stored on the telemetry data storage, enabling historical analysis, reporting, and use in future decision-making processes. Finally, the telemetry data stream output facilitates the delivery of processed telemetry data to the next stage, which includes preparation for network planning, management, and control. The data collected by the TDL undergoes an initial phase of pre-processing, filtering, aggregation, and storage to prepare it for further analysis. This process ensures the data is consistent and usable by external applications or different layers within the NDT architecture. A benefit of this pre-processing is that it can reduce communication overhead by eliminating the need to transmit raw data. The software component responsible for data extraction, normalization, and exposure in the NDTs context is a Digital Twin Connector. This connector is a composition of protocols, communication buses, and specific instances of the TDL’s ingestion, processing, and output functions. This layer collects real-time data using various protocols, depending on the network domain. For instance, in the management plane, the collected data is used for performance metrics, logs, warnings, and state data, interfacing with network management systems and using protocols such as Simple Network Management Protocol [39], Network Configuration Protocol (NETCONF) [40], among others. In the control plane, the collected data is used to monitor the health of network control protocols, e.g., routing protocols, to aid in real-time issue detection and optimization using protocols such as sFlow 6 [41] and Border Gateway Protocol-Monitoring Protocol [42]. Finally, the data plane telemetry involves extracting and analyzing data from user packets to ensure efficient network operations, balancing collection overhead with traffic processing using protocols such as Alternate Marking Technology [43], In Situ OAM [44], or Packet Sampling [45]. In this sense, the TDL enables the “sense” phase of the Sense–Act cycle by providing continuous telemetry to the upper digital and management layers, which transform this information into actionable insights and decisions. The complementary “act” phase, where these decisions are applied back to the physical network, is described in Section VI-C. 6https://sflow.org/sFlowOverview.pdf 7 C. Actuation and execution Once the NDT has been instantiated and validated within the digital domain, its outputs such as optimized configurations, predictive models, or control strategies can be deployed back into the physical network through the NDT MANO. These outputs represent the actionable intelligence derived from the NDT and are used to enhance network operation and management across domains. The process of translating NDT insights into deployable actions, however, differs depending on the characteristics of each network domain defined in Section VI-A . 6G systems are expected to integrate multi-vendor infrastructure through O-RAN and rely heavily on AI/ML-based automation. Achieving seamless interoperability and coordinated operation requires advanced Service Management and Orchestration (SMO) capabilities. The following subsections describe how NDT-derived actions and models are applied within each domain, including the RAN, CN, TN, and multi-domain SMO, through their respective control and management mechanisms. It is important to note that while UEs are key elements of network performance optimization, they are not direct targets of actuation. Instead, the NDT actions focus on optimizing the network itself to improve the overall UE experience. 1) RAN actuation: The O-RAN architecture introduces the RAN Intelligent Controller (RIC), a software-based controller that enables intelligent, flexible, and vendor-agnostic management of the RAN [46]. The RIC monitors, controls, and optimizes key radio functions such as resource allocation, interference coordination, power control, and mobility management, and exposes standardized APIs for deploying control applications. The RIC is composed of two hierarchical components that operate over distinct timescales: • Non-real-time RIC: Located in the SMO layer, it operates above one second to perform long-term optimization, policy management, and model training. Its applications, or rApps, handle non time-critical tasks such as configuration, radio resource policy generation, and performance forecasting. • Near-real-time RIC: Deployed at the network edge, it operates between 10 ms and 1 s to execute time-sensitive control tasks, including handover, scheduling, and interference mitigation. Its xApps interact directly with RAN nodes through standardized interfaces. Within the proposed NDT architecture, the RIC serves as the RAN actuation interface. Control policies or parameter adjustments derived from functional models in the digital domain are dispatched to either the nonor near-real-time RIC, which applies them through the appropriate rApps or xApps. This establishes a closed-loop cycle in which the RIC enforces NDT-generated decisions while telemetry continuously updates and aligns the digital replica. 2) CN actuation: In the CN, the orchestration and management of Virtual Network Functions (VNFs) are essential for achieving flexibility and scalability in cloud-native network infrastructures. The Network Function Virtualization (NFV)- MANO framework, standardized by ETSI [47], defines how VNFs are deployed, scaled, and maintained across distributed environments. It consists of three key entities: the NFV Orchestrator, which coordinates network service lifecycles; the VNF Manager, which controls configuration and scaling of individual VNFs; and the Virtualized Infrastructure Manager, which manages compute, storage, and networking resources. Modern orchestration mechanisms increasingly rely on policydriven automation and AI-assisted optimization [48, 49], enabling dynamic adaptation to traffic conditions and service requirements. Open platforms such as Open Source MANO 7 , the Open Network Automation Platform 8 , and Cloudify 9 , further support closed-loop automation. Within the proposed NDT architecture, functional models continuously analyze CN telemetry to forecast load, detect anomalies, or optimize routing. Their outputs are translated into actionable configurations through the MANO layer which triggers orchestrator-driven adjustments through standardized APIs, establishing a closedloop control cycle in which NDT-generated insights directly steer policies and service chaining in the live network. 3) TN actuation: In the transport domain, Software-Defined Network (SDN) separates the control and data planes, enabling programmable and dynamic management of connectivity, bandwidth, and QoS. This flexibility supports network slicing, where multiple logically isolated networks run over the same physical infrastructure, each tailored to service categories such as Enhanced Mobile Broadband (eMBB), Ultra-Reliable LowLatency Communications (URLLC), or massive Machine-Type Communications (mMTC). To coordinate this process, the ETSI slicing management framework [50] defines four key functions. The Communication Service Management Function (CSMF) translates high-level service requirements into slice specifications. The Network Slice Management Function (NSMF) orchestrates slices end-to-end across domains, while the Network Slice Subnet Management Function (NSSMF) manages the instantiation and optimization of slice subnets within each domain. The Network Function Management Function (NFMF) handles lifecycle management of individual network functions. Within the NDT architecture, functional models continuously analyze telemetry from the TN to predict congestion, optimize routing, and anticipate resource bottlenecks. The resulting decisions are translated into reconfiguration actions and enforced through the SDN controller and the NSMF/NSSMF control interfaces. Through this closed-loop integration, the TN evolves from a statically configured backbone into a self-optimizing transport substrate that adapts proactively to service demands. 4) Multi-domain Orchestration: In large-scale 6G environments, services often traverse multiple network domains with distinct control mechanisms and administrative boundaries. The multi-domain SMO framework coordinates orchestration across the RAN, TN, and CN, ensuring coherent control, synchronized operation, and global optimization of network resources. This approach supports end-to-end service provisioning by federating domain-specific functions, monitoring crossdomain performance, and adapting configurations dynamically. It enables unified policy enforcement, service assurance, and optimization across heterogeneous domains, representing a key 7https://osm.etsi.org/ 8https://www.onap.org/ 9https://docs.cloudify.co/ 8 enabler for autonomous and collaborative network management. VII. DIGITAL DOMAIN The digital domain represents the central analytical and decision-making environment of the NDT. It comprises modular components that can be instantiated and orchestrated on demand to construct a specific NDT instance. This domain integrates three principal functional dimensions. First, it maintains an accurate digital representation of the physical network through the UDR, basic models, and functional models, ensuring coherence between the physical and virtual entities. Second, it provides an AI training and optimization pipeline, essential for developing and refining data-driven models. Finally, it incorporates a simulation environment that enables predictive analytics, network planning, and validation of trained or calibrated models under diverse operational conditions. Together, these components form the “thinking” layer of the NDT, transforming collected telemetry into actionable knowledge that supports control, optimization, and autonomous decisionmaking across network domains. The following subsections describe these dimensions in detail. A. Real-world representation The foundation of the digital domain is data, which fuels every process from representation to simulation. Within this domain, representation operates along two dimensions. The first concerns the physical domain, which is mirrored through basic models populated with telemetry data collected from the operational network. This representation captures the topology, configuration, and dynamic state of the physical infrastructure. The second dimension concerns the application domain, represented by functional models and application-level data, including service intents, operational goals, and target Key Performance Indicators (KPIs). Together, these representations ensure that the NDT captures both the operational behavior of the network and the performance requirements that drive its optimization. The following sections detail the components that enable this dual representation. 1) Unified data repository: The UDR constitutes the main interface between the physical and digital domains and contains the HDL, which consolidates data streams from the TDL into smart-data models, as described in Section VI-B . The repository is considered unified because it combines network-generated data with contextual datasets from external sources (e.g., geographical information, mobility statistics, environmental conditions), which enhance the relevance and accuracy of digital-domain models for applications such as coverage optimization, mobility prediction, and energy efficiency planning. The UDR is thus responsible for data sharing, harmonization, and storage, as follows. a) Data sharing Given the heterogeneous and multi-stakeholder nature of 6G networks, data sharing is a core challenge for developing and operating NDTs. Data exchange must ensure privacy, security, interoperability, and regulatory compliance. To support this, we propose a dedicated data space to be integrated within the UDR to enable secure and governed data sharing among operators, service providers, and third-party stakeholders. A data space provides both the organizational framework and technical infrastructure for structured data exchange [51]. Unlike open repositories, it enforces data ownership, access control, and governance policies. Technically, it acts as middleware that enables trusted interactions between participants while enforcing usage policies aligned with the European Data Strategy 10 . Within the NDT architecture, it federates data from multiple domains, allowing NDTs to operate as both data consumers (telemetry and operational data) and data producers (simulation outputs or synthetic datasets). Interoperability is achieved through data connectors and standardized metadata catalogs [52], while identity providers ensure authentication and access control. This guarantees traceable and compliant exchanges. Governance and security aspects are discussed in Section XI, and data harmonization is detailed in Section VII-A1b. b) Data harmonization Harmonization is essential to ensure interoperability and consistency across heterogeneous network data sources. Although it introduces processing overhead, particularly in multi-vendor environments, it enables uniform semantics and reusability. In our approach, the harmonized data stored in the UDR is encoded using smart-data models expressed in NGSI-LD, ensuring semantic interoperability, machine readability, and long-term maintainability. Telemetry data forms the primary input for constructing and updating the network representation, which includes performance indicators, configuration parameters, and fault or event notifications collected from Network Elements (NEs) through standardized interfaces [53–55]. Our methodology [3] organizes harmonized data into two categories: attributes, representing static or configurable parameters [56], and measurements, representing dynamic operational metrics [53, 57]. Each NE is mapped to its corresponding set of attributes and measurements, defining its operational profile and enabling consistent interpretation across systems. The classification and representation of NEs follow 3GPP management standards, which define NEs through Information Object Classes (IOCs) [58]. Each IOC specifies the attributes and measurements describing the configuration and behavior of the resource it represents. For example, in the RAN, the gNB is decomposed into the Radio Unit (RU), Distributed Unit (DU), and Centralized Unit (CU), along with finergrained components such as antenna beams and bandwidth parts. In the CN, VNFs such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF) are modeled similarly, each with its own IOC and associated data schema. This modular representation supports scalability, interoperability, and automated management. Contextual and external data, which complement but do not form part of the main network representation, are incorporated 10http://dataeconomy.eu/eu-data-strategy-2020/ 9 through the data space framework, which ensures harmonized semantic representations across domains. c) Data storage The UDR must support efficient data management, retrieval, and persistence strategies. This involves three main storage types: data indexing,real-time storage, and historical storage. Data indexing organizes and tags incoming data to facilitate efficient querying and retrieval. Real-time storage captures and processes data as it is generated, enabling immediate analytics and operational responses. Historical storage archives past data for trend analysis, validation, and model retraining. Furthermore, data storage in the proposed architecture follows a distributed design, where each network component maintains its own local repository, collectively forming a data fabric that ensures scalability, resilience, and fault tolerance. These distributed repositories are federated into a cohesive framework that enables unified access to heterogeneous data sources. However, during the execution of an active NDT instance, a central and continuously updated data store is required to support efficient model training, inference, and control operations. This central repository, instantiated during the creation of the basic model as detailed in Section VII-A 2, consolidates relevant data at runtime and renders it “active” by capturing inter-component relationships and enabling functional models on top of it. 2) Basic models: Basic models build on the harmonized data from the UDR to provide a structured representation of the physical network, its constituent NEs, and their interrelations, reflecting both topology and operational state. These models can be instantiated using graph-based representations, which emphasize structural dependencies, or simulation-based representations, which capture system behavior under various conditions. Although NDT modeling is still emerging, useful insights can be drawn from DT practices in domains such as manufacturing, where standardized modeling approaches (e.g., ISO frameworks [59]) define structured representations of assets and their interdependencies. These frameworks commonly adopt hierarchical modeling [60], distinguishing unit-, system-, and system-of-systems levels. By analogy, in 6G networks, individual NEs correspond to unit-level entities, while the network as a whole can be treated as the system level. Given that the distinction between system and system-of-systems primarily reflects the degree of granularity, we treat the network as a cohesive system for the scope of basic model construction. Graph-based formalisms have long been recognized as effective means of representing interconnected and dynamic systems. The comprehensive survey presented in [61] explores methodologies for modeling complex networked systems, emphasizing representations that preserve both structural and behavioral heterogeneity. The authors categorize these approaches into three main paradigms: basic graph-based, probabilistic graph-based, and network embedding models, each offering progressively higher expressiveness and fidelity in capturing network complexity. A complementary perspective is offered in [62], which proposes a dynamic knowledge-graph framework for DTs grounded in semantic web principles. The framework NRFrequencyNRCellCU NRFreqRelation NRCellRelation AdjacentNRCell Beam BWP Beam Attributes: beamIndex; beamType; beamAzimuth; beamTilt; beamHorizWidth; beamVertWidth. Measurements: IntraNRCell SSB Beam switch Measurement; RSRP Measurement; SSB beam related measurement. BWP Attributes: bwpContext; isInitialBwp; subCarrierSpacing; cyclicPrefix; startRB; numberOfRBs; Measurements: - CommonBeamfor mingFunction Attributes: coverageShape; digitalTilt; digitalAzimuth; Measurements: - NRCellDU Attributes: cellLocalId; operationalState; administrativeState; cellState; pLMNInfoList; nRPCI; nRTAC; arfcnDL; arfcnUL; arfcnSUL; bSChannelBwDL; ssbFrequency; ssbPeriodicity; ssbSubCarrierSpacing; ssbOffset; ssbDuration; bSChannelBwUL; bSChannelBwSUL; Measurements: Packet Delay; Radio resource utilization; UE throughput; Number of Active UEs; CQI-related measurements; Transmit power utilization measurements; Received Random Access Preambles; PHR (power headroom) Measurement NRSectorCarrier Attributes: txDirection; configuredMaxTxPower; configuredMaxTxEIRP; arfcnDL; arfcnUL; bSChannelBwDL; bSChannelBwUL; Measurements: - Figure 5. Example of a graph basic model schema for RAN NEs distinguishes between a “base world”, synchronized with live data streams, and multiple “parallel worlds”, enabling the exploration of hypothetical configurations or design alternatives without impacting the operational model. This concept demonstrates how semantic and graph-based representations can enhance adaptability and reasoning in DTs. Other studies have extended such approaches to the networking domain. For instance, [63] defines an NDT reference architecture through a software engineering lens, mapping modeling concepts from ETSI standards and established network simulators such as ns-3 and OMNET++. This work underscores the importance of metamodels that formally capture NDT entities, their attributes, and relationships. Similarly, [64] presents a vendorneutral data model designed to simplify network management, representing logical and physical dependencies, such as shared sessions or resource linkages, through graph abstractions. These contributions collectively illustrate how graph-based representations provide a natural foundation for defining the structure and semantics of NDTs. a) Graph-based representation of NDT basic models The proposed methodology for constructing and utilizing basic models within the NDT views the network as an integrated system of interconnected NEs. Each NE is represented using the harmonized data structure introduced in Section VII-A 1b, consisting of its attributes (configuration and state) and measurements (dynamic performance indicators). The basic model is therefore defined as the set of these NE 16 3GPP/O-RAN). For RL-based functions, the AI block interacts directly with the simulation framework (e.g., OMNeT++, ns3) to generate synthetic environments that enable safe policy learning before deployment in live networks. Workflow automation and scalability are ensured through modern MLOps practices, such as orchestration tools like Perfect and Kubeflow in Kubernetes environments, that provide reproducibility, version control, and efficient resource usage. Model metadata, such as performance metrics, and versioning details are maintained in the UDM, enabling continuous monitoring and retraining triggered by performance degradation or data drift. Aligned with emerging AI-native management paradigms, this framework supports distributed and federated learning by decoupling data ingestion from training and inference. Its modular design ensures low-latency, high-throughput processing of massive 6G telemetry streams while preserving responsiveness for mission-critical applications such as industrial automation and teleoperated driving [102]. D. Data management The evolution of 6G networks introduces significant complexity and diversity, making efficient and secure data management crucial. In the NDT-enabled 6G architectures, effective data management supports real-time decision-making, optimization, and orchestration, addressing scalability, reliability, and security challenges within the NDT MANO layer. Data management ensures data integrity, availability, and usability across systems, especially in dispersed cloud-based environments. The data management provides the real-time network data feeds to the basic and functional models, enabling a continuous refinement of models, simulations, and AI-driven functionalities. Protecting sensitive data involves controlling access through role-based access control and multi-factor authentication, while preserving data integrity. Additionally, privacy regulations must be considered, which require data masking or anonymization operations. The vulnerabilities that cause malicious exploitation are increasing as the system expands. Therefore, it is crucial to have key requirements, including maintaining data consistency across nodes, preventing the sharing of sensitive data, and providing secure data management throughout the system. Our architecture proposes an integrated data management system that extends a data exposure and collection architecture, where data is moved from the physical world to the digital and human world via diverse interfaces, as explained in Section VI. Based on the IETF RFC9232 [103], our approach includes the generation,collection,processing, and consumption data modules, mapped in the architecture via the telemetry data layer. These modules support data MANO services, such as security, scalability, and federated distributed parallelization. Additionally, the HDL acts as a bridge between the telemetry layer and the NDT instance. It ensures that the raw telemetry data is transformed into standardized formats compatible with structured smart data models, which serve as the foundation for defining and operating the entire architecture. E. Federated management Modern communication networks increasingly span multiple autonomous administrative domains, each enforcing independent policies and operating under distinct technological and governance constraints [104]. This decentralization enhances flexibility but complicates end-to-end coordination, especially when automation and cross-domain optimization are required. From a physical-network perspective, federation enables multi-domain service delivery by decomposing services across administrative boundaries. Recent 3GPP releases (e.g., Release 16 [54]) define hierarchical management entities to support such cross-domain orchestration, consistent with frameworks like ITU-T Y.3061 and ETSI ZSM [37, 105]. However, integrating AI-based network functions introduces dynamics (e.g., adaptivity, continuous learning, and dependency on real-time data) that challenge the determinism of traditional hierarchical models and require more flexible coordination mechanisms. Federation at the digital level, enabled by interconnected NDTs, offers a complementary approach by supporting privacypreserving cross-domain collaboration. NDTs may operate at node-, domain-, or service-level granularity [15], and can be hierarchically composed so that lower-level twins feed insights to higher-level abstractions. This allows administrative domains to retain control over their data and models while exchanging standardized, anonymized information for joint optimization and pre-deployment validation of controllers or AI policies. In large-scale deployments, multiple distributed NDT instances must remain synchronized. The federated management component ensures state consistency, regulates inter-twin communication, and provides policy-driven orchestration to avoid conflicting decisions across the federation. Moreover, federated setups may integrate external simulators or digital platforms [106]; in these cases, the simulation framework described in Section VIII-B maintains semantic and temporal alignment across heterogeneous components. F. Physical network management The proposed architecture introduces a physical network management block that serves as the orchestration and automation interface between the physical infrastructure and its NDT. This component integrates traditional LCM with AI/ML-driven decision-making and closed-loop control, enhancing network programmability and enabling efficient telemetry pipelines to preserve alignment between physical and digital layers. The physical domain also supports self-monitoring, analysis, and adaptation mechanisms, contributing to zero-touch operation in future 6G systems. Two complementary closed-loop processes govern physical network behavior. The internal loop manages the creation and configuration of NDT instances through the NDT management system, coordinating interactions with simulation frameworks and AI training modules. The external loop uses NDT as a service, leveraging continuous telemetry to aid the physical network management to diagnose performance deviations, optimize configurations, and reapply decisions to the physical network in real time. Together, these loops shift network 17 control from static rule-based methods toward an AI-native, self-optimizing paradigm. The MANO/ZSM layer further enables automated device onboarding, intent translation, and secure exposure of network capabilities. Through these mechanisms, the physical network becomes a programmable and adaptive substrate that supports intelligent, closed-loop management across the 6G ecosystem. IX. LIFECYCLE MANAGEMENT OF NDT INSTANCES The lifecycle of an NDT involves coordinated interactions among the various building blocks and layers of the architecture depicted in Figure 2. In this section, these interactions are captured through Unified Modeling Language (UML) sequence diagrams that describe how the system behaves over time. While the following workflows remain generic, they can be tailored for specific deployment scenarios. A. Creation As shown in Figure 10, NDT creation is triggered on demand due to the computational cost of running high-fidelity simulations and performing “what-if” analyses. Upon receiving a request, the NDT Management component interprets user and system requirements and generates an NDT descriptor [105]. The descriptor defines the initial scenario deployment, required basic and functional models, data sources, performance bounds, simulation settings, software dependencies, and expected outputs. The NDT Manager initializes a generic instance template, which is refined in co-creation with the end user turning high-level requests into executable specifications. Then, the orchestrator analyzes the descriptor and coordinates with the resource manager, validating infrastructure availability. If sufficient resources are available, the model manager retrieves or generates missing models via the UDM. Additionally, the system may need to pull relevant input data, either historical or real-time, from the UDR to feed into the basic models. The simulation manager instantiates any simulation tools in case they are required for the NDT operation. After all components are prepared and configured, the orchestrator deploys the NDT instance and acknowledges readiness to the requester. B. Update NDT instances evolve as models are refreshed with new physical network data. Basic models follow the data-collection update cycle, while functional models are updated either reactively, upon quality-metric degradation, or through periodic scheduling. We consider the reactive case, where the NDT continues operating under the previous configuration until an updated version is installed. Depending on the type of functional model(s) the NDT is based on, several scenarios may occur when updating it. 1) Analytical functional models: As illustrated in Figure 11, the monitoring system triggers a quality alert that prompts the orchestrator to request a model update. The model manager checks the UDM; if no newer version exists, a new one is generated. The orchestrator then installs the updated model, amends the NDT descriptor, and clears the alert. Notice that such updates often respond to changes in physical-layer characteristics or system parameters. 2) AI-based functional models: As mentioned in Section VII-C , if the functional model is based on AI/ML techniques, different pipelines are followed depending on the type of technique. For DL-based models (Figure 12), the update process also begins with a quality alert. If no updated version exists, the orchestrator triggers a new AI training pipeline via the NDT manager. The AI workflow block trains the model using data from the UDR, updates the UDM repository, and notifies the orchestrator to deploy the new version. For RL-based models (Figure 13), training additionally requires simulation–AI interaction. The NDT manager coordinates with the simulation framework to support time-step interactions until the RL policy converges. The new model is then stored in the UDM and deployed as above. C. Deletion Figure 14 shows the deletion workflow. A deletion request may originate from an external entity or result from the expiration of the NDT descriptor. The NDT Manager issues the delete command, and the orchestrator retrieves resource usage information, terminates basic and functional models, releases all resources, and confirms deletion to the requester. X. IMPLEMENTATION AND RESULTS Building on the theoretical foundations outlined in earlier sections, where the architectural components enabling and creating NDT as a service were introduced, this section shifts focus to the practical realization of some of these concepts. It presents a series of implementations and examples that demonstrate the feasibility and effectiveness of the proposed NDT architecture. A. Telemetry framework for location prediction The TDL was conceived as a foundational component of the data collection framework described in Section VI-B , enabling AI-native network management and NDT synchronization across heterogeneous domains. It provides a unified architecture for the collection, harmonization, and exposure of multidomain data streams, supporting both O-RAN-compliant and non-compliant systems. As discussed previously, the data collection framework is organized in three principal layers: (i) the TDL, which ingests and preprocesses real-time network measurements from RUs, DUs, and Core components; (ii) the HDL, responsible for normalizing heterogeneous inputs into standardized data models (e.g., Yet Another Next Generation (YANG), JSON, or Protobuf formats); and (iii) the DCB, providing scalable publish/subscribe interfaces through Kafka, NATS, or Zenoh for northbound data exposure toward AI/ML functions and NDT engines. The functional realization of the TDL was implemented through the Telemetry Gateway (TGW), a modular software entity integrated within the Accelleran dRAX Near-Real-Time 18 NDT Instance Real World Representation List of available resources Simulation Manager Unified Data Model Model Manager Resource Manager Orchestrator NDT ID Get available resources Deploy NDT RequestBasic and Functional Model(s) Basic and Functional Model(s) IDs Simulations NDT Descriptor Basic and Functional Models IDs 6G-TWIN MANO Request NDT Creation Request Models Send simulation data Request simulation data NDT Creation acknowledgment Simulation Framework Simulation Running Instance Simulator Simulation Finished NDT Manager Unified Data Repository Simulation finished Start Simulationfor NDT Creation Human World Human Operator/ Network Applications Figure 10. NDT creation sequence diagram NDT Instance Real World Representation Unified Data Model Model Manager Resource Manager Orchestrator NDT Deployed Deploy NDT Monitor Loop Request quality Metrics Get quality Metrics Sent Quality Alert Request Functional model update Request latest version functional model Send latest version Stop Quality Alert Service not available due to update Dashboard NDT descriptor updated NDT Descriptor Models ready for update Figure 11. Update analytical functional models NDT Instance Real World Representation Unified Data Model Model Manager Resource Manager Orchestrator AI 6G-TWIN MANO NDT Manager AI Training Monitor Latest version = current version Service not available due to update Dashboard NDT Descriptor Latest version = current version Request functionalmodel creation Functionalmodel updated notification Loop Request quality Metrics Get quality Metrics Sent Quality Alert Request Functional model update Request latest version functional model NDT Deployed Deploy NDT Stop Quality Alert NDT descriptor updated Request model train Model trained Push functional model Functional model ID Unified Data Repository Loop Request data Data for training Figure 12. Update DL-based functional models. RIC environment. The TGW acts as an interoperability layer across E2, O1, and A1 interfaces, bridging O-RAN and NonO-RAN compliant data, as well as legacy components. Internally, the TGW comprises three main modules: a) the Input Interface Manager, supporting NETCONF, RESTCONF, User Datagram Protocol (UDP), and InfluxDB line protocols for ingesting RAN metrics and device telemetry. This input interface is mapped within the data ingestion and data stream process mechanisms described in the data collection framework. NDT Real World Representation Simulation Manager Unified Data Model Model Manager Resource Manager Orchestrator AI 6G-TWIN MANO NDT Manager AI Training Loop Monitor Latest version = current version Simulations Simulation Framework Service not available due to update Dashboard NDT Descriptor Latest version = current version Request Functionalmodel creationRequest Simulation results Functionalmodel updated notification Loop Request quality Metrics Get quality Metrics Sent Quality Alert Request Functional model update Request latest version functional model NDT Deployed Deploy NDT Stop Quality Alert NDT descriptor updated Instance Simulation Model trained,Stop simulation Push functional model Functional model ID results Figure 13. Update RL-based functional models Human World Human Operator/ Network Applications NDT Instance Model Manager Resource Manager Orchestrator 6G-TWIN MANO NDT Manager Monitor Request NDT Deletion Resources released NDTDelete instruction Get running resources List of running resources Simulation Manager Stop simulation(s) NDT deleted Undeploy Models Simulations Simulation Framework Stop Simulator NDT deleted NDT deleted Simulator stoped Simulator stoped Modes undeployed Release resources Figure 14. NDT deletion b) Translator Core, including Transformers and Mappers to convert raw messages into normalized telemetry structures compliant with O-RAN and 3GPP specifications; and c) the Output Publisher, which timestamps and streams processed metrics to Kafka and HTTP/Virtual Event Streaming (VES) collectors for consumption by xApps, rApps, and external AI pipelines, based on the 3GPP data structures and the data stream output. This output is then fed into the dRAX DCB for data storage or external VES collectors as described in Figure 15. For the implementation, telemetry streams were collected from a 5G O-RAN testbed provided by VIAVI’s AI RAN Scenario Generator (RSG) tool. This tool emulates a real- 19 Figure 15. Telemetry Gateway implementation istic campus outdoor scenario with six cells and 20 users moving across the campus. The TGW continuously exported performance indicators such as Signal-To-Interference-PlusNoise Ratio (SINR), Physical Resource Block utilization, and power consumption toward the dRAX DCB. These data were consumed by an energy-saving and traffic steering xApp to control the network’s performance. Additionally, a location modeling rApp was created to model the radio environment, based on the telemetry ingested. Inside this rApp, a set of algorithms calculates the location of the UEs in relation to the cells and the error of its predictions. The entire pipeline is visualized in Grafana dashboards, showing near-instantaneous reflection of physical-network events in the NDT environment as in Figure 16. The TDL implementation was showcased live at EuCNC 2025. The latency between physical measurement and AI model update averaged below 250 ms, while the harmonization overhead remained below 3 % of total processing time. The system sustained a throughput of over 15 000 telemetry messages per second without data loss across Kafka topics, confirming the scalability of the implementation. Finally, the calculated error is around 50 m, which highlights the necessity to involve further sensing information to increase accuracy, which is foreseen for future implementation of this demonstrator. These results validate the TGW as a robust and scalable mechanism for unified telemetry in AI-driven network management. Its modular architecture ensures adaptability to diverse network technologies and provides an operational foundation for zero-touch automation and federated AI training. From a research perspective, the experiment demonstrates that telemetry-assisted NDT synchronization can be achieved with sub-second latency, enabling dynamic retraining of AI models and real-time policy enforcement in 6G-oriented RIC environments. (a) Internal demo architecture (b) TGW dashboard Figure 16. EUCNC TGW demonstrator B. NDT instantiation of basic and functional models After data collection and harmonization, the resulting datasets are stored in the UDR for future retrieval and analysis within the NDT instance. As an initial demonstration, we focus here on radio coverage prediction, which serves as a representative use case for illustrating the instantiation and interaction between basic and functional models. A detailed analysis of this use case is reported in [107]; while here, we emphasize the architectural aspects of model instantiation and management within the NDT framework. The instantiation process is illustrated in Figure 17, where purple arrows indicate the NDT MANO workflow. While this process can ultimately be automated, the current implementation relies on expert input to guide model selection and configuration. During instantiation, the NDT MANO populates the basic models with data retrieved from the UDR and associates them with functional models relevant to the specific use case. These functional models are trained or calibrated using the basic model to produce parameterized versions which are subsequently stored in a dedicated repository for traceability, benchmarking, and offline validation. 1) Basic model and functional models: The basic model represents the infrastructure of the network. For this experiment, we selected a real-world environment in an indoor laboratory setting and a 5G gNB using the OAIBOX platform. The measurements were collected across a single floor, where a UE was connected to the gNB, and logs containing Reference Signal Received Power (RSRP), as an indicator of signal strength, were collected at multiple static positions for approximately two minutes per location. The logs were processed and ingested into 20 RAN • RU • BWP • … • CU • DU • … Core • AMF • SMF • … UE •Location •SS RSRP •SS SINR • … … Application App1: Teleoperated driving • QoS requirements: Latency < 1 ms, Throughput > 10 Mbps • Network domains: RAN, Core • Functionalities: Coverage prediction, Resource allocation, … App3: … • … App2: Network energy saving • QoS requirements: 20% less energy, … Basic Models Coverage prediction • GPR • CNN • Random forest •… Resource allocation optimization • Q-learning • … … Traffic analysis • Congestion detection • … Functional Models Unified Data Repository Real-time and historical data Contextual data Real Network Network topology Configurations Measurements Sensors, maps, … NDT Management Functional models selection Basic models selection Data collection & harmonization Basic models population UE 1 •Location (37.2, 7.5) •SS RSRP -101 dBm UE •Location s (37.2, 7.5) •SS RSRP -102 dBm UE •Coordinate s (37.2, 7.5) •SS RSRP -101 dBm 𝑡1𝑡2𝑡3 GPR for coverage prediction NDT Instance 1 Data Model Repository GPR (label) UE 1 •Location (37.2, 7.5) •SS RSRP -101 dBm UE 1 •Location (37.2, 7.5) •SS RSRP -102 dBm UE 1 •Location (37.2, 7.5) •SS RSRP -102 dBm 𝑡1𝑡2𝑡3 CNN for coverage prediction NDT Instance 2 CNN (label) … Recommendation (if applicable) Trained or calibrated models Training Figure 17. Example of NDT instantiation for radio coverage prediction. Figure 18. Visualization of the basic model within GreyCat. GreyCat, following the internal schema defined for basic models (see Section VII-A 2). Each measurement was timestamped and spatially linked, creating a dynamic data structure capable of supporting time-aware queries and predictions. Figure 18 shows an example of the GreyCat visualization for the UE measurements over the laboratory floor plan. To demonstrate the integration of functional models in the NDT, we implemented two complementary approaches for radio coverage estimation: a probabilistic method, a kernelbased method using Gaussian Process Regression (GPR) and a data-driven Convolutional Neural Network (CNN). These models learn the mapping between spatial coordinates and RSRP from partial measurements, offering different trade-offs between interpretability, generalization, and sensitivity to data sparsity.The GPR model used location coordinates (x, y) as inputs and the averaged RSRP as the target variable, employing a Radial Basis Function kernel. Hyperparameters were optimized through likelihood maximization, and predictions were obtained through grid-based interpolation. The CNN model took a 2D grid of RSRP values, with missing data masked, as input. It consisted of two convolutional layers trained directly Figure 19. GPR and CNN prediction errors of RSRP for validation points. Figure 20. NDT Update general workflow. on known values using mean-squared error loss, allowing the inference of the full coverage map in a single pass. 2) Evaluation and comparative analysis: The evaluation aimed to assess the predictive accuracy of both models using a shared dataset, enabling the NDT to identify the most suitable functional model for future deployment under similar conditions. The dataset was partitioned into training and validation subsets to ensure fair comparison. Each model, GPR and CNN, was trained on the same training samples, and predictions were compared against the withheld validation points. Prediction errors were computed per location, distinguishing between Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS) conditions. The results, summarized in Figure 19, show that the CNN achieved higher robustness in NLOS scenarios, while the GPR exhibited better accuracy in LOS. These findings underscore the importance of the NDT as an evaluation platform for comparing functional models under identical conditions and selecting the most appropriate one for deployment. C. NDT update of functional model based on deep learning Once the NDT is instantiated, maintaining its fidelity and alignment with the physical network becomes critical. This responsibility is jointly managed by the NDT MANO layer and the monitoring system. To illustrate this, consider a scenario where a functional model within the NDT begins to deviate from its expected performance bounds. In such cases, corrective action must be taken to preserve the NDT’s integrity and utility. As shown in Figure 20, the system follows an automated workflow to update or replace the underperforming model. This process is triggered when the model no longer satisfies the QoS constraints or performance thresholds set for the NDT instance. This update is orchestrated by retrieving new models or retraining existing ones, ensuring that the NDT delivers accurate, real-time insights and decisions aligned with network conditions. 21 For this implementation, we consider an NDT instance that receives packets from the UE (1) and classifies each packet within the network (1.1) for posterior analysis, e.g., for anomaly detection. Meanwhile, the NDT monitor checks the response times, system load, and algorithm accuracy (2). Then, the procedure explained in Section IX-B 2 occurs. An alert is raised once a quality degradation is detected (3). Next, the Orchestrator requests the Model Manager to update the functional model to its latest version (5). The UDM reviews the last available update (5). If the newest version in the UDM is the same as the one already implemented in the NDT instance, the Model Manager requests training in a new version (6). If training is required, the AI Training module uses the data from the UDR to train a new model; this data is collected from network telemetry (7). When the new model is ready, it is stored in the UDM (8), which sends a message to the Model Manager (5) to notify that the new version is available. The Model Manager notifies the Orchestrator about the new model’s version (4), then the Orchestrator deploys the new model into the NDT instance (9). From then on, the NDT continues making decisions based on the new model version. 1) Implementation details: To illustrate this case, an NDT instance was created using DynamicSim [49], Python, Prefect, and Kubernetes. We used a Kaggle dataset [108] in pcap format containing 1,803,059 packet samples across three traffic classes: Transmission Control Protocol (TCP) (999765 samples), UDP (803087 samples), and Multipath TCP (MPTCP) (207 samples). The validation setup involved a desktop machine with an AMD Ryzen 9 5900 12-core processor, an Nvidia RTX 3080 graphics card, 64 GB of RAM, and Windows 11, with Docker Desktop and Kubernetes v1.29.1 used for container management. Figure 21 shows two screenshots of the implementation of this procedure. On Figure 21a, our Grafana monitor shows the client as a container sending a packet stream to the NDT (classifier on Figure 21a), which classifies the packets using a functional model based on DL. When the NDT monitoring system detects that the accuracy and reliability, measured in the amount of processed packets per second, are not met, it notifies the NDT orchestrator to trigger the pipeline that trains and deploys a new model to replace the current one. Additionally, the image shows the time required for preprocessing and training, based on the data collected up to that point. Prefect manages the pipeline, an open-source orchestration engine that turns Python functions into production-grade data workflows. Figure 21b shows a screenshot of the model training process, where the name “blazing-wildcat” is a random token created by Prefect to identify this pipeline. The timeline shows when the pod to perform data preprocessing is started. In Kubernetes jargon, a pod is the smallest deployable computing unit, similar to a container. When these pods finish their work, they are undeployed. Several functional models were used in this process, specifically a Linear Regressor, a Decision Tree Regression (DTR), and a DNN. These models were selected because they balance interpretability, performance, and scalability for different traffic classification scenarios. The models are evaluated in [109]. The NDT Orchestrator selects one model or another depending on the distinct trade-offs between accuracy and efficiency. The DNN achieves the highest (a) Grafana Monitor acting as dashboard. (b) Prefect AI training pipeline. Figure 21. Implementation of the NDT functional model update. accuracy, especially for less frequent classes like MPTCP, but at the cost of significantly higher computational time (up to 19 × slower). On the other hand, the DTR provides a strong balance between performance and speed, making it ideal for realtime applications with unencrypted data. In contrast, the DNN becomes the preferred option in more complex or encrypted traffic scenarios, where its superior feature extraction justifies the added computational cost, particularly when hardware acceleration is available. D. Multi-objective route optimization for remote driving In complex use cases, real-time representation of the physical network is not enough to perform network optimization. Such is the case in teleoperated driving, where, besides networklevel representations, vehicular traffic representations are also needed [110]. For this application, the NDT should be able to integrate information from other domain-specific DTs or simulators through the Federated MANO (F-MANO) and the simulation framework. Two complementary implementations demonstrate this capability. The first one represents a comprehensive validation use case of the proposed framework, combining traffic and networklevel representations through the joint use of OMNeT++ [111], Simu5G [112], and SUMO [113], enabling a realistic cosimulation of vehicular mobility and network dynamics [114]. These simulators are coupled through APIs and TraCI interfaces, allowing real-time interaction between vehicle control, 22 network conditions, and AI models. The second approach constructs the environment through systematic data integration, extracting real-world road networks from OpenStreetMap [115] and incorporating 5G base station deployments from the OpenCelliD dataset [116]. This data is processed to generate stochastic network parameters that reflect temporal and spatial variations in connectivity. Both architectures replicate the endto-end behavior of a 6G-enabled teleoperated driving system, providing realistic and reproducible testbeds for validating intelligent routing algorithms under variable connectivity and latency conditions. This implementation aims to train and evaluate a multi-objective route optimization based on DRL. This algorithm jointly minimizes travel distance and network latency, while maximizing available bandwidth. The system is designed to satisfy the stringent requirements of latency below 30 ms and bandwidth above 20 Mb/s, thereby ensuring reliable, real-time communication essential for teleoperation [117]. The implementation operates across multiple layers of the architecture in Figure 2, demonstrating how the proposed NDT can integrate mobility, network, and AI-based functional models within a single, coherent workflow. In the digital domain, a functional model processes real-time network metrics and generates optimized routing decisions using a DRL. This model is trained using the joint simulation environment to replicate the complex interactions between physical road infrastructure and telecommunications network performance. Although all the interactions within the joint simulation environment are handled manually or using custom implementations, ideally, the simulation framework should be able to synchronize and manage them effectively. The simulation environment emulates a real-world urban environment as a graph with stochastic network parameters based on a city map, capturing the dynamic nature of the network conditions as they vary temporally and spatially. The functional model trained within the AI workflow management, then stored and managed within the UDM, demonstrates how RL creates intelligent, adaptive networking solutions that respond to the dynamic requirements of next-generation connected vehicle applications. 1) Basic and functional Models: The proposed framework includes Basic models and Functional models and is organized into two key components: • Basic models: representing the 6G mobile network infrastructure, including gNB entities for radio resource management, handover, connection establishment, and the vehicular infrastructure, including cars, roads and topography information. Normally, these basic models are provided by the different simulators for the first work. Additionally, constructing a clustered graph representation of another city based on [115] for road networks, and [116] for stochastic latency and bandwidth parameters modeled using normal distributions to capture temporal network variability in [117]. • Functional models: encompassing AI-based modules for both coverage prediction and optimal vehicle routing, while [117] focuses specifically on optimal vehicle routing through DRL. Figure 22. Dueling DQN algorithm flowchart showing dual-stream architecture and action selection process with exploration-exploitation balance. The optimal vehicle routing functional model formulates the route optimization problem as a MDP, where States encode vehicle position, destination coordinates, associated network performance metrics (SINR, or alternatively bandwidth and latency), and accumulated path metrics. The Action space consists of basic navigation maneuvers (turn left,turn right,go straight) [118], or selecting adjacent intersections, with action masking applied to enforce graph connectivity constraints and prevent invalid moves. The routing policy minimizes path length while maintaining strong network coverage, ensuring safe teleoperation under dynamic conditions. 2) DRL-based functional models: We propose two approaches for the route optimization problem. The first approach employs a Dueling Deep Q-Network (DDQN) architecture where its Reward function balances competing objectives through a weighted linear combination: R(s, a) = wd·Rd(s, a) + wb·Rb(s, a) + wl·Rl(s, a)(1) where the normalized components are defined as Rd= −d(e)/dmax for the distance penalty, Rb= (b(e, τ)− bmin)/(bmax −bmin) for the bandwidth reward, and Rl= −l(e, τ)/lmax for the latency penalty. Through systematic experimentation, we determined the optimal weights wd= 0.5 , and wb=wl= 0.25 . The workflow of the DDQN algorithm is illustrated in Figure 22. The second approach uses the Proximal Policy Optimization (PPO) [119], selected for its stability and efficiency in continuous control problems. The multi-objective reward function integrates several components: rtot(t) = αrshortest(t)+βrcoverage(t)+γrpenalty(t)+robjective+rillegal where rshortest incentivizes progress toward the destination, rcoverage encourages higher network coverage, rpenalty penalizes 23 Figure 23. Heatmap of SINR values over the city of Bari generated by the Random Forest coverage prediction model. insufficient coverage, robjective rewards successful task completion, and rillegal penalizes unlawful actions. The weights α , β , and γ allow tuning the balance between efficiency, connectivity, and safety. This formulation balances progress toward the destination, network coverage quality, and penalties for unsafe or disconnected states. The algorithm supports three operational scenarios: Coverage Maximization, which prioritizes maintaining high SINR values; Shortest Path Maximization, which minimizes travel distance while keeping coverage above the threshold; and Balanced Optimization, which achieves a trade-off between path length and connectivity, ensuring stable communication and efficient routing. 3) Case study and results: To demonstrate the effectiveness of the proposed approach, a comprehensive case study was conducted, using a realistic city map where a teleoperated vehicle navigates between multiple gNBs. In the first implementation, the Coverage Prediction model is needed to map the vehicle positioning with network-related metrics such as SINR, delay, or bandwidth. Specifically, the coverage prediction model was developed using a Random Forest (RF) regression algorithm [120] trained on SINR data collected along simulated vehicle trajectories in the city center of Bari, Italy. This experiment provides a concrete validation of the proposed NDT-based AI workflow under realistic conditions. The trained RF model achieves R2= 0.9993 and RMSE = 0.3274, demonstrating outstanding predictive performance. The resulting SINR heatmaps (see Figure 23) provide a spatially continuous estimation of coverage quality, which informs the routing agent with accurate connectivity information. Regarding the optimal vehicle routing model, Figure 24 depicts the learning outcomes of the PPO model, demonstrating convergence within a few hundred steps and an average cumulative reward exceeding 1400, indicating fast and stable convergence of the PPO agent in all configurations, validating its robustness for multi-objective optimization in stochastic urban network environments. More details of the evaluation and usage of this functional model can be found in Paparella et al. [118]. In addition to the PPO, we evaluated the DDQN model [117] implemented on the city center of Nevers, France. The urban environment was extracted from OpenStreetMap [115] and Figure 24. Learning performance of the PPO agent in the balanced optimization scenario, showing convergence and stable reward accumulation. Figure 25. Combined performance metric demonstrating overall routing effectiveness across multiple objectives. transformed into a directed graph through clustering. The network metrics used were latency and bandwidth assigned to each edge based on proximity to 5G base stations from the OpenCelliD dataset [116], with stochastic temporal variations modeled using normal distributions. The DDQN model was evaluated by comparing it against classical routing algorithms: Shortest Path,Lowest Latency, and Highest Bandwidth. To enable a holistic assessment of multi-objective performance, we designed a combined evaluation metric that normalizes and aggregates both the operational requirement compliance rate and the route efficiency. Under this unified metric, our method achieved the highest overall score, as illustrated in Figure 25. These results, obtained through the NDT framework, confirm that the proposed reinforcement learning approach effectively balances competing objectives, achieving a level of performance unattainable by any single-objective optimization strategy. This demonstrates the NDT’s capability to serve as a comprehensive testbed for validating functional models before deployment in physical networks. E. Co-simulation framework As mentioned in the previous section, several simulators can be coupled to enhance the capabilities of the NDT in predictive modeling. The co-simulation framework of the architecture (cf. 24 Figure 2) is responsible for the coordination and sequential execution of separate simulators and supports data exchange among the simulators, as mentioned in Section VII-B and Section VIII-B . For this purpose, protocol translators are used to map the generic protocol-2 services to specific simulators. This has already been implemented for some of the most well-known simulators in the field of mobile communication. This section presents a reference implementation of the cosimulation framework, with some of the first features already tested successfully. 1) Implemented components: One of these simulators is OMNeT++, a widely used network simulator in communication studies. Our protocol translator implementation for OMNeT++ supports starting and stopping OMNeT++ as well as telling OMNeT++ the current position of UEs in the simulation. Additionally, the protocol translator is able to make OMNeT++ continue its simulation until a given point in (simulated) time. Inserting and deleting UEs to and from the simulation are also supported at runtime. OMNeT++ is started with simulation configuration files that contain further information about the simulated tasks, e.g., the simulation time and transmission power. A second supported simulator is SUMO, the most wellknown mobility simulator for vehicles. Our protocol translator prototype allows starting and stopping SUMO based on given configuration files, processing until a given time, as well as calling the position of all vehicles at runtime. Also, added and removed vehicles are communicated to the co-simulation framework via the protocol translator of SUMO. Third, a protocol translator prototype for AirMobiSim has been implemented. AirMobiSim computes the position of UAVs based on path information that is given to the simulator at the start of the simulation. The protocol translator allows starting and stopping AirMobiSim and retrieval of the current position of UAVs. Information about newly added and deleted UAVs is sent to the co-simulation framework as well. In order to make a fully coupled simulation system, also a prototype of the co-simulation framework itself has been implemented. This coordinates the creation and deletion of all necessary simulator instances based on a configuration file. It tells the simulators which configuration files they shall use and starts their execution. Then, it coordinates the execution of each simulator by telling them to simulate to a certain time instance. When the simulators reach this synchronization point, data from the simulators is collected and sent to the relevant other simulators. For example, the number and position of all vehicles is collected from SUMO via its protocol translator and sent to OMNeT++ via its protocol translator. Similarly, the UAV position data from AirMobiSim is collected by the co-simulation framework at each synchronization point and sent to OMNeT++. Furthermore, during run-time the cosimulation framework also provides a mechanism such that one simulator may influence the behavior of another simulator by sending commands like changing the route of a vehicle or changing its speed at certain points in time. This is done at the synchronization phase by pro-actively asking each simulation to submit any requests it wishes to perform before moving to the next step of the simulation. At the end of the simulation, Figure 26. Screenshot of the running co-simulation framework. all simulators are stopped and their instances are disposed. 2) Simulation results: The implemented components have been tested in several configurations. It has been shown that running the co-simulation framework with OMNeT++ and SUMO is working, as well as an extended simulation containing OMNeT++, SUMO, and AirMobiSim. This can simply be realized by activating AirMobiSim in the co-simulations’ configuration file, provided that each simulator has a fitting configuration file that is loaded when starting each simulator. The performance of the co-simulation framework has been measured in order to make sure that the overhead due to the introduction of co-simulation middleware is reasonable in comparison to the execution time of the tightly coupled simulation framework. More information on the performance results can be found in [84]. A screenshot of the running simulation is presented in Figure 26, where on the left, OMNeT++ is shown, and on the right SUMO. The positions of the vehicles in OMNeT++ are taken from SUMO via the cosimulation framework. The position of the UAV is taken from AirMobiSim via the co-simulation framework. AirMobiSim has no own GUI. The blue dotted lines represent packet transmissions, showing that OMNeT++ correctly uses the vehicle data it gets from SUMO and AirMobiSim, respectively. There is no direct communication between OMNeT++ and the other simulators; all interactions are realized via protocol-2. XI. NDT CONSIDERATIONS Beyond its architectural and functional design, the deployment of an NDT must address several cross-cutting considerations that ensure its reliability, trustworthiness, and interoperability. These include the security and privacy mechanisms necessary to protect sensitive network data, the interfacing and data collection processes that enable seamless integration with real and virtualized network components, and the governance principles that regulate data sharing and model management. Finally, comprehensive evaluation methodologies are required to assess the NDT’s performance, accuracy, and operational impact across different lifecycle stages. A. Security and privacy considerations for NDTs An NDT is not only a visualization or analytical tool for network management but a digital copy of the real networks 25 Table I THREAT CATEGORIES IN NDT SYSTEMS Threat category Brief description Data storage and NDT repository Unauthorized access to the NDT and associated network functions. Critical or confidential data, basic/functional models may be stolen or copied. Sensors or software in the data collection process An adversary may spoof or manipulate data traffic between the NDT and the physical network, leading to corrupted model states or false decisions. Physical network component An adversary can damage or interfere with physical assets Data flow between physical assets and NDT An attacker can disrupt synchronization, listen to or alter data flow. They can also launch a denial-of-service (DoS) attack Network management models and functions An insider attacker or an attacker with unauthorized access can change configurations, security policies, or steal confidential data Application layer interfaces Application layer data can be altered and intercepted; NDT can be affected by DoS attacks interacting with it bidirectionally. For this reason, NDT is planned to be positioned at the center of the real network’s decision-making cycle. Consequently, a breach in the security of an NDT or its data sources/synchronization mechanisms can directly impact the decision-making mechanisms and systemic risks. An NDT requires collection, consolidation, and processing of large-scale data from heterogeneous network environments including different devices and components. This might create new, use case-specific attack surfaces and privacy threats. The operation of an NDT relies on sensitive information such as real-time telemetry data, performance indicators, and control feedback; therefore, the confidentiality, integrity, and availability of this data must be protected throughout all stages of its life cycle. In addition to that, the integration of data governance, privacy, and compliance mechanisms into the NDT architecture should be considered from the initial design phase. Within this framework, NDTs generate predictive and prescriptive decisions for live networks, so security-bydesign must be a guiding principle for NDTs. Security and privacy analysis to be performed on NDT-based network management should identify threat vectors, attack surfaces, assess vulnerabilities and risks to define countermeasures and mitigation scenarios. The overall architecture of NDT includes physical and digital components and assets. These assets might be vulnerable to various threats. A summary of the threats for these assets is provided in Table I [121]. All identified threats must be addressed and mitigated according to the specific use case. While there are established mitigation techniques, solutions, and security controls available to protect each asset, the most appropriate measures should be selected based on the asset’s risk profile and operational context. Additionally, the applicability and effectiveness of any chosen controls must be evaluated against real-world operational constraints to ensure they provide the intended protection with the required complexity and cost [122]. Figure 27. NDT governance through the data space B. NDT governance NDT Governance plays a critical role in ensuring the secure, fair, and transparent management of data, models, and interactions among multiple stakeholders. Effective governance establishes the principles, policies, and technical mechanisms required to maintain trust, accountability, and regulatory compliance across a distributed NDT ecosystem. It defines how data is accessed, shared, and monetized while safeguarding privacy and sovereignty, key aspects for the operational viability of large-scale NDT deployments. Unlike other sectors such as the European Network of Transmission System Operators for Electricity in the energy domain, or even certain wired communication infrastructures, the radio access network lacks a centralized information hub. Consequently, the governance of NDTs for 6G networks must adopt a decentralized approach. In such a framework, each MNO manages its own NDT instance while selectively sharing data with other MNOs’ NDTs when cooperation or federation is required. Additionally, MNOs are responsible for providing relevant information to regulatory authorities, Virtual MNOs, and application providers. These exchanges take place within the framework of a regulated data space [123], as introduced in Section VII-A 1, which specifies the technical and legal rules governing interactions between MNOs and external stakeholders (see Figure 27). Nevertheless, providing the national network regulator with a partial but relevant view of operations is essential for ensuring compliance with regulations and legal requirements. They should take into account the different governance: • Transparency & accountability. Clear policies must define who can access, modify, or share data within the NDT, ensuring traceability and accountability for all actions. • Interoperability & standards. Adopting common data models, interfaces, and protocols enables seamless interaction between different NDTs and stakeholders, fostering collaboration and reducing fragmentation. • Data sovereignty & privacy. Governance should respect data ownership rights and enforce privacy protections, especially when sharing sensitive information across MNOs, regulators, and third parties. • Role-based access control. Access to NDT data and functionalities should be granted based on predefined roles, ensuring that each actor, whether MNO, Virtual