DANA: A Digital Agent for Network Data Acquisition in Network Digital Twin Context

1. Introduction

The Digital Twin paradigm has emerged in recent years as a key enabler for the monitoring, analysis, and continuous optimization of complex systems through the tight coupling between physical entities and their digital counterparts. By maintaining an up-to-date digital representation of a physical system, Digital Twins enable what-if analysis, predictive evaluation, and closed-loop control throughout the entire system lifecycle. Although the concept has been successfully applied in domains such as manufacturing, aerospace, and smart infrastructures, as well as in 5G and 6G networks [1,2,3,4,5], its application to communication networks introduces additional challenges stemming from their scale, heterogeneity, and dynamic behavior.

In the networking domain, these ideas have materialized in the concept of the Network Digital Twin (NDT), which aims to replicate the topology, configuration, and operational state of communication networks within a digital environment. Network Digital Twins have been proposed as a foundational technology for next-generation mobile networks [6], enabling advanced use cases such as proactive network management, performance optimization, fault diagnosis, and security analysis. This vision is particularly relevant in the context of 5G and beyond, where softwarization, virtualization, and service-based architectures significantly increase network flexibility, but also operational complexity [7,8].

Despite the growing number of architectural proposals and conceptual frameworks for Network Digital Twins, their practical deployment in real operational environments remains limited. A critical and often overlooked challenge lies in the acquisition and management of the network data required to create, maintain, and synchronize the digital twin with its physical counterpart. Most existing approaches implicitly assume the availability of accurate, structured, and continuously accessible network information, without addressing how such data can be systematically obtained from heterogeneous devices, diverse protocols, and management interfaces deployed in real networks [9].

In practice, operational networks are composed of a diverse set of technologies, including vendor-specific devices, virtualized network functions, general-purpose servers, and container-based platforms. These elements expose configuration, topology, and state information through a variety of mechanisms, ranging from standardized management protocols to ad-hoc tools and proprietary interfaces. As a result, the processes of collecting, normalizing, and correlating network data become complex tasks that directly impact the feasibility and fidelity of Network Digital Twin implementations.

This article addresses this gap by focusing on network data acquisition as a first-class operational problem in Network Digital Twin environments. Rather than proposing a new Network Digital Twin architecture, the main contribution of this work lies in the design and validation of DANA, a system dedicated to the automated acquisition, normalization, dissemination, and transformation of network data throughout the lifecycle of the Digital Twin. DANA provides a reproducible end-to-end workflow that connects heterogeneous operational infrastructures with deployment-ready Network Digital Twin instances. The contribution is not a new acquisition, communication, or virtualization primitive. It is the integration and experimental evaluation of a bounded acquisition-to-deployment workflow across the two infrastructure categories and deployment backends studied here. The comparison with prior work is qualitative and representative rather than exhaustive. It is conceived as an enabling component that supports both the initial creation of a Network Digital Twin and its continuous operation through runtime monitoring and synchronization.

The proposed system follows a modular, device-category-aware design: it uses different acquisition mechanisms for network devices and general-purpose systems rather than assuming a single management interface. Moreover, it explicitly distinguishes between data acquisition processes oriented toward topological modeling and those required for operational monitoring, thereby covering the lifecycle perspective of Network Digital Twins. The applicability of the proposed approach is experimentally evaluated using controlled network-emulation and container-orchestration scenarios, demonstrating how the acquired information can support deployment and operation of Network Digital Twin environments.

The contributions of this work are as follows. First, the article presents an acquisition component that separates centralized collection from distributed host-level collection through a common normalization layer. Second, it introduces a two-state operational model that distinguishes information used for initial NDT construction from information used for runtime monitoring. Third, it describes an MQTT-based control and dissemination interface together with backend-specific adapters for KNE/Kubernetes and OSM/OpenStack. Fourth, it experimentally evaluates the resulting acquisition-to-deployment workflow in two complementary laboratory scenarios, including quantitative structural and reachability checks for the centralized case and functional evidence for the distributed case. The contribution is therefore an integration and validation result rather than a claim of a new SNMP, MQTT, Kubernetes, or NFV primitive.

Finally, the applicability of the proposed solution is demonstrated through an end-to-end experimental validation in which acquired network information is transformed into deployment-ready descriptors and used to instantiate digital-twin environments over Kubernetes/KNE and OpenStack/OSM. The validation is intentionally bounded to controlled laboratory scenarios.

The remainder of this article is organized as follows. Section 2 reviews related work and comparatively analyzes existing academic and state-of-practice approaches with respect to the problem addressed in this paper. Section 3 presents the design and operation of the proposed DANA system. Section 4 describes the experimental validation and evaluation results. Finally, Section 5 concludes the article and outlines future research directions.

2. Related Work and Comparative Analysis

Network Digital Twins (NDTs) have been proposed as digital representations of communication networks that remain synchronized with their physical counterparts to support analysis, validation, optimization, and closed-loop operation [1,3,10]. Existing reference architectures typically distinguish between the physical network, the digital twin environment, and the synchronization mechanisms that exchange information between both domains [3,6]. Within this architecture, data acquisition is not a secondary function: the fidelity and usefulness of the twin depend directly on the availability of accurate topology, configuration, state, and behavioral information.

A significant part of the NDT literature addresses this requirement from an architectural or conceptual perspective. Wu et al. [1] and Sai et al. [10] identify data management, telemetry, and synchronization as fundamental capabilities for operational NDTs. These works provide a broad view of the research landscape and highlight challenges such as data heterogeneity, scalability, and latency. However, they mainly characterize the problem rather than providing an operational mechanism able to acquire, normalize, and disseminate network data across heterogeneous infrastructures and across different phases of the NDT lifecycle.

Controller-led and model-driven approaches address part of this problem by relying on standardized management models and programmable control planes. González-Sánchez et al. [11] propose an NDT architecture for network operations and management that translates YANG-modeled management information into an interoperable NGSI-LD representation. Their architecture integrates NETCONF and gNMI collectors, model translation mechanisms, and a context broker to expose network configuration and operational state. Similarly, Vilalta et al. [12] apply digital twins to optical networks using cloud-native SDN controllers, while related SDN-assisted approaches have been explored for transport and optical infrastructures [13]. These proposals are valuable when the network exposes programmable interfaces or when a controller acts as the authoritative source of information. Nevertheless, their applicability is more limited in brownfield or heterogeneous environments where legacy devices, general-purpose systems, virtualized functions, and containerized services coexist without a unified control plane.

Another research line focuses on semantic and graph-based representations of network knowledge. Zhu et al. [14] propose a knowledge-graph-based construction method for Digital Twin Networks, enabling structured representation of network entities and their relationships. Raj et al. [15] present a Digital Twin Network for SDN environments using knowledge graphs to represent topology, OpenFlow rules, link statistics, device attributes, and controller information. These approaches improve reasoning, contextualization, and query capabilities over network state. However, they usually depend on predefined models, curated input sources, or controller-provided information. As a result, they are stronger in representation and reasoning than in the complete operational path from raw data acquisition to the deployment of an executable twin.

Data-driven modeling approaches provide complementary capabilities. For instance, RouteNet-Fermi [16] uses graph neural networks to model relationships among topology, traffic matrices, and performance metrics. Such approaches are highly relevant for prediction, optimization, and what-if analysis once suitable datasets are available. However, they generally assume that clean, structured, and consistent data have already been collected. They do not address how those data are obtained from operational infrastructures, normalized across heterogeneous sources, or maintained over time as the physical network evolves.

Beyond academic NDT proposals, commercial network assurance and digital twin platforms have demonstrated strong capabilities in brownfield discovery, snapshot generation, historical comparison, and operational validation. IP Fabric [17] discovers existing networks through read-only mechanisms such as CLI access, ICMP probing, routing information, ARP, CDP/LLDP, NDP, and traceroute, generating snapshots that represent the network state at a given point in time. Forward Enterprise [18] also builds a vendor-agnostic software replica of the network from collected configurations and state tables, supporting path analysis and comparison across snapshots. These platforms are mature and effective for network assurance, change tracking, and operational visibility. However, they are primarily snapshot-based and read-only: their goal is to analyze, validate, and compare the network, rather than to transform acquired information into a deployable network digital twin instance.

Intent-based platforms represent a different category. Juniper Apstra [19] uses a blueprint- and intent-driven model to design, deploy, validate, and operate data center fabrics. In this case, bidirectionality is stronger than in snapshot-based assurance platforms because the system can generate, validate, and deploy vendor-specific configurations according to the intended state. However, this model is not a general-purpose bottom-up discovery mechanism. It is mainly oriented to supported data center fabric scenarios where the network is incorporated into an intent-based operational framework. Therefore, although Apstra provides strong closed-loop capabilities, its starting point and scope differ from the lifecycle-aware acquisition problem addressed in this paper.

Communication and synchronization have also been studied from the broader perspective of interconnected Digital Twin systems. Liu et al. [20] introduce the concept of the Internet of Digital Twin (IoDT) and distinguish between intra-twin communication, i.e., the interaction between a physical entity and its digital representative, and inter-twin communication, i.e., the interaction among different digital representatives. Their survey discusses communication-oriented aspects such as synchronization, latency, reliability, edge/cloud deployment, 5G/6G support, blockchain, and machine learning. This perspective is relevant for contextualizing bidirectional data exchange in Digital Twin systems, but it mainly focuses on communication models and enabling technologies for already established twin ecosystems rather than on the acquisition, normalization, and deployment pipeline required to create an operational NDT from heterogeneous network data.

Publish/subscribe mechanisms have also been explored to support scalable synchronization between physical and digital domains. Alhazmi et al. [21] propose an MQTT-based data distribution framework for Digital Twin Networks, showing the suitability of lightweight brokers for decoupled information exchange. Message-oriented communication has also been adopted in broader Digital Twin platforms [22]. These works are relevant for dissemination and synchronization, but they usually assume that the information to be exchanged has already been collected, normalized, and semantically organized. In other words, they address the communication layer but not the full acquisition and preparation pipeline required to instantiate and operate an NDT.

The reviewed works can be organized into four representative families: model-driven/controller-led NDTs, semantic or knowledge-graph-based NDTs, brownfield discovery and assurance platforms, and intent-based operational platforms. Each family addresses an important part of the NDT problem. Within the representative works reviewed here, we did not find a single openly described workflow that combines heterogeneous acquisition, explicit lifecycle separation, normalization, publish/subscribe dissemination, and deployment-artifact generation. This is a bounded observation about the selected literature and publicly documented platforms, not a claim that no other system provides these capabilities.

This gap is particularly relevant in scenarios where the digital twin must be created from operational network data rather than from an already available model, controller, blueprint, or curated dataset. Model-driven approaches provide strong semantic integration, but they typically assume programmable devices and standardized management models. Knowledge-graph and data-driven approaches provide advanced representation or prediction capabilities, but usually rely on already structured input data. Brownfield discovery platforms provide mature network visibility and change tracking, but are mainly oriented to assurance and snapshot comparison rather than executable twin deployment. Intent-based platforms provide strong closed-loop operation, but within controlled fabric environments driven by predefined intent models.

The scope of this work is therefore deliberately focused on the acquisition-to-deployment path required to support operational NDT creation and synchronization. The proposed system is designed as a lifecycle-aware data acquisition layer that connects heterogeneous physical infrastructures with deployable NDT environments. It combines: (i) centralized SNMP-based acquisition for network devices; (ii) distributed agent-based acquisition for general-purpose systems and containerized environments; (iii) normalization of raw information into structured data models; (iv) explicit separation between the initial twin creation phase and the runtime monitoring phase; and (v) MQTT-based dissemination and control to support bidirectional synchronization between physical and digital domains. This combination enables acquired network information to be transformed into deployment-ready descriptors that can instantiate a functional digital twin over KNE/Kubernetes.

At the same time, the scope of this work should not be interpreted as a replacement for the complementary capabilities provided by other approaches. The proposed system does not aim to define a new NDT reference architecture, to provide a full semantic reasoning framework, to outperform commercial assurance platforms in large-scale brownfield discovery, or to deliver production-grade intent-based closed-loop automation. Its contribution is narrower but operationally relevant: it addresses the practical transition from heterogeneous network data acquisition to the instantiation and synchronization support of a deployable Network Digital Twin.

Therefore, the comparison focuses on the functional boundary of the present work rather than on a performance ranking. Table 1 summarizes this positioning across representative academic and state-of-practice alternatives, considering acquisition approach, heterogeneity support, lifecycle awareness, bidirectional communication or control, and deployable twin generation. The table is qualitative and representative; it is not a systematic review or a benchmark of the compared platforms.

This comparison clarifies both the contribution and the boundaries of the proposed approach. Compared with model-driven, semantic, and knowledge-graph-based NDT solutions, this work places more emphasis on acquisition from heterogeneous infrastructures and on the transformation of collected data into deployable artifacts. Compared with commercial assurance platforms, it is less mature in large-scale brownfield validation, but addresses a different objective: enabling the deployment of a functional digital twin rather than only representing or comparing network state. Compared with intent-based systems, the proposed approach does not assume a pre-existing blueprint or controlled data center fabric, although it does not yet provide the same level of production-grade closed-loop actuation.

Therefore, the main novelty of this work should be understood as the design of a practical acquisition and transformation layer for NDT environments. The system separates the data required to create the twin from the data required to operate and synchronize it, combines centralized and distributed acquisition modes, and disseminates normalized information through a decoupled publish/subscribe communication model. This positioning makes the proposal complementary to existing NDT architectures and platforms, while addressing the identified gap: the lack of an openly described mechanism that bridges heterogeneous operational network data and deployable, continuously updated Network Digital Twins.

The resulting boundary is operational rather than absolute. DANA does not claim to outperform mature observability, assurance, or orchestration platforms in their native domains. Its contribution lies in combining acquisition from two infrastructure categories, lifecycle-aware separation between initial modeling and runtime monitoring, a normalized intermediate representation, decoupled dissemination and control, and transformation into descriptors for two selected deployment backends. The experiments demonstrate these functions in controlled scenarios; they do not establish universal superiority or complete coverage of the NDT problem.

The current implementation also has limitations that delimit the claims made in this article. First, the experimental validation is based on controlled emulation and laboratory scenarios and therefore does not yet demonstrate operation over large-scale production brownfield networks. Second, the centralized acquisition mode relies on SNMP and an initial structural input, making it useful for the evaluated management-plane workflow but not equivalent to fully autonomous discovery in arbitrary networks. Third, although MQTT supports bidirectional control and synchronization messages, this article does not claim production-grade closed-loop actuation over the physical infrastructure. Finally, runtime monitoring is supported, but the present evaluation does not benchmark topological change detection latency and accuracy under large-scale dynamic conditions.

These limitations define the next steps of the research. Future work will focus on quantifying the detection latency and accuracy of node, link, adjacency, and configuration changes under both SNMP-based polling and agent-based push acquisition, extending validation to larger hybrid brownfield environments, and strengthening security and reliability mechanisms for closed-loop operation.

3. DANA: Digital Agent for Network Data Acquisition

As discussed in the previous sections, an operational NDT requires reliable mechanisms to acquire, structure, and synchronize data from heterogeneous physical networks. To address this challenge, this section presents DANA (Digital Agent for Network Data Acquisition), a dedicated system for acquisition across two infrastructure categories and two NDT lifecycle states.

DANA is designed as an integral component of the NDT ecosystem. Its primary function is to collect, normalize, and disseminate the network information required both for the initial instantiation of the digital twin and for its subsequent monitoring and synchronization during operation.

3.1. Design Principles and Assumptions

The design of DANA is driven by a set of principles derived from real-world network environments and from the limitations identified in existing NDT approaches.

Heterogeneity awareness. Modern communication networks comprise a wide variety of devices and technologies, ranging from legacy equipment with limited programmability to cloud-native infrastructures exposing advanced telemetry interfaces. DANA operates in such environments without assuming uniform management capabilities or standardized telemetry availability.

Heterogeneous-infrastructure operation. DANA uses different acquisition mechanisms for different categories of network elements. In particular, it distinguishes between specific-purpose devices (e.g., routers and switches) and general-purpose systems hosting virtualized or containerized network functions, adapting the data collection strategy accordingly. This should not be read as a claim of universal vendor or device independence.

Lifecycle-aware data acquisition. Data requirements vary across the NDT lifecycle. During the initial phase, structural and selected configuration-related data are required to model the network topology. During operation, monitoring data are needed to reflect network behavior and support synchronization. DANA explicitly incorporates this distinction into its operational model.

Decoupled communication. DANA adopts an event-driven publish/subscribe communication model, decoupling data producers from consumers. This architecture can support multiple consumers, but scalability is not quantitatively benchmarked in this paper.

Management-plane-oriented deployment. The system is designed to use available management and monitoring interfaces without requiring changes to the forwarding logic of the monitored devices. The operational overhead of deployment is not quantified in this paper.

These principles guide the architecture and operational behavior of DANA, ensuring its applicability in realistic NDT deployment scenarios.

3.2. Architecture Overview

Figure 1 illustrates the high-level architecture of DANA and its position within the NDT ecosystem. The system consists of a central agent and a set of specialized data acquisition modules, which can be deployed in either centralized or distributed modes depending on the characteristics of the target network.

DANA interacts with the physical network through suitable data acquisition mechanisms and exposes normalized data streams to the NDT platform through a publish/subscribe communication layer.

The architecture is organized around three main functional blocks:

Data collection layer. This layer comprises a set of collectors responsible for obtaining information from the physical network. Depending on the device type and deployment model, data collection can be performed in a centralized manner by polling multiple network devices from a single DANA instance, or in a distributed manner, where lightweight satellite agents collect data locally on general-purpose systems and report it to the central agent.

Data normalization and structuring. Raw data obtained from the network are processed to extract relevant information and transform it into a structured representation aligned with the NDT data model. This step ensures that heterogeneous data sources can be uniformly consumed by subsequent components of the NDT ecosystem.

Communication and control interface. DANA communicates with the NDT platform through a publish/subscribe interface, enabling both the dissemination of acquired data and the reception of control commands. This interface supports unidirectional data flows from the physical network to the digital twin, as well as bidirectional interactions required for synchronization and control.

3.3. Centralized and Distributed Acquisition Modes

DANA supports both centralized and distributed deployment models, enabling operation over heterogeneous infrastructures. These modes differ in their acquisition mechanisms, input sources, and interaction paradigms with the physical network.

In the centralized model, DANA directly interacts with specific-purpose network hardware (e.g., routers and switches) using SNMP. As shown in Figure 2, the system relies on an ALTO (Application-Layer Traffic Optimization) network map as a bootstrap input; the role of this input in the experiment is scenario-specific and should not be confused with a complete physical-topology ground truth [24]. Based on this seed, DANA performs active polling of devices to retrieve topology and routing information. This acquisition mechanism follows a PULL-based approach.

The ALTO map is used as a bootstrap seed rather than as an authoritative ground truth. It provides the initial structural hints required by the prototype, while the SNMP observations provide the device-level information used by the collector. If the seed is incomplete, DANA can only discover and model the portion of the network that remains reachable and observable from it. If the seed is inconsistent with the observations, the affected elements must be resolved before descriptor generation. Therefore, the centralized mode is not zero-touch discovery from an empty prior; it is a controlled acquisition mechanism initialized from partial structural knowledge.

The collected information is normalized into the snmp_topology_data structure. Table 2 summarizes the schema, which includes device identity, interface-level attributes (IP address, MAC address, identifiers, operational status), and routing knowledge (directly and indirectly reachable networks with associated hop metrics). This structured representation is used to reconstruct the evaluated topology within the NDT; it is not presented as a complete vendor-independent configuration model.

In the distributed model, DANA extends its functionality through lightweight satellite agents deployed on general-purpose systems. As illustrated in Figure 3, these agents locally collect behavioral and resource-level information and transmit structured XML reports to the central DANA component. This acquisition model follows a PUSH-based paradigm; the reports are normalized into the common JSON representation after reception.

The received information is normalized into the agent_behaviour_data schema. Table 3 summarizes the structure, which captures network adapter status, operating system context, Docker environment data, container identifiers, runtime status, and allocated resources (CPU and RAM). The prototype also records a connected-user count when that host-level field is available. This model complements topology acquisition with visibility at the host and execution-layer levels.

Data Model Validation and Extensibility

Table 2 and Table 3 summarize the acquisition-specific blocks of the DANA data model. These blocks are not treated as isolated field lists, but as part of a common JSON-based logical structure that includes both lifecycle metadata and acquisition-specific payloads. Each normalized DANA message includes a common metadata envelope containing, at least, the scenario identifier, the network-element identifier, the acquisition timestamp, the DANA lifecycle state, the acquisition source, and the communication flow. This common envelope allows downstream components to identify the origin, context, and intended use of each data block before applying any transformation or update.

Table 4 makes this common envelope explicit. The schema_id and schema_version fields identify the logical DANA schema and support backward-compatible evolution of the normalization format. The remaining metadata bind each payload to a scenario, element, acquisition state, source, timestamp, and communication flow, allowing consumers to validate whether the record is usable for initial modeling, runtime monitoring, or historical inspection.

The fields shown in Table 2 and Table 3 define the current schema version used by the prototype. The type column specifies the expected representation of each field, while nested JSON fields are used for structured sub-objects such as interfaces, reachable networks, Docker containers, or resource allocations. Basic validation is performed before publishing or consuming the data through a five-step workflow: (i) syntactic validation of the JSON document; (ii) verification of the common metadata envelope; (iii) type and cardinality checks for acquisition-specific fields; (iv) validation of state/topic coherence; and (v) rejection, quarantine, or persistence of records depending on whether inconsistencies affect mandatory or optional fields. For example, topology-oriented fields are expected in State 0 messages, whereas runtime behavioral fields are associated with State 1 monitoring records.

The model is designed to be extensible through additive evolution. New collectors or device families can introduce additional optional JSON blocks without modifying the semantics of existing fields. Consumers that do not understand a new block can ignore it while still processing the common metadata and the known acquisition-specific structures. This strategy provides backward compatibility for the current prototype and allows the data model to evolve as new acquisition technologies are incorporated. DANA does not define a native YANG module; instead, it uses a lightweight JSON representation as an intermediate normalization format. When required, this intermediate model can be mapped by the adaptation layer to deployment-specific or standard-aligned representations, such as NFV descriptors or YANG-based models, depending on the target NDT backend.

Taken together, the SNMP-based centralized mechanism (PULL) and the agent-based distributed model (PUSH) provide complementary acquisition capabilities over a common normalized data representation. The use of shared metadata, typed acquisition-specific blocks, and additive extensions enables consistent topology reconstruction and enriched behavioral monitoring while preserving interoperability with backend-specific adaptation modules in heterogeneous NDT environments.

3.4. Operational Model: State 0 and State 1

DANA operates according to a two-state model aligned with the Network Digital Twin (NDT) lifecycle, explicitly distinguishing between initial model construction and runtime operation, as illustrated in Figure 4. This distinction is essential because the information required to create the digital twin is not equivalent to the information required to monitor it once it is already operational.

State 0 represents the NDT creation phase. In this state, DANA focuses on acquiring the static and structural information required to instantiate the digital twin, including network topology, device characteristics, interface information, addressing, routing data, and configuration-related information. The output of this state is a topology-oriented structured representation that can be consumed by the corresponding adaptation module to generate deployment artifacts, such as KNE descriptors or NFV descriptors. Therefore, data collection in State 0 prioritizes completeness, consistency, and coverage over acquisition frequency.

State 1 represents the NDT operational phase. This state is reached only after the digital twin has been instantiated by the external NDT orchestration workflow. In this state, DANA changes its acquisition objective from structural modeling to runtime monitoring. The collected data include behavioral information such as resource usage, status indicators, traffic-related measurements, and event notifications. These data are used to support synchronization between the physical and digital domains, but they are not treated as a replacement for the structural model generated in State 0.

The transition between states is controlled by an external NDT management and orchestration layer. This layer is outside the functional scope of DANA and has been described in our previous work on NDT modeling and deployment methodology [8]. In the present work, DANA exposes the mechanisms required by such a layer: it subscribes to MQTT control topics, receives explicit state-transition commands, and adapts its acquisition behavior accordingly. Thus, DANA does not autonomously infer lifecycle transitions from monitoring samples; instead, it executes the acquisition mode requested by the NDT orchestration workflow.

A transition from State 0 to State 1 is triggered when the external orchestration workflow has completed the creation of the digital twin, including data acquisition, modeling, descriptor generation, deployment, and provisioning. Conversely, a transition from State 1 back to State 0 is only triggered when a structural change is detected or requested by the orchestration layer, for instance a topology modification, a device inventory change, or an interface-level change that invalidates the previously generated structural model. In that case, DANA performs a controlled re-acquisition of the affected structural information instead of allowing monitoring data to directly overwrite the original model.

Formally, the DANA operational model can be represented as a state machine $M=(S,E,G,A,s_0)$, where $S=\{S_0,S_1\}$, $S_0$ denotes structural acquisition for NDT creation, $S_1$ denotes runtime monitoring, E is the set of externally issued lifecycle commands, G is the set of transition guards, A is the set of acquisition actions executed after a valid transition, and $s_0=S_0$ is the initial state. Table 5 summarizes the semantics, consistency rules, and failure handling associated with each transition. DANA provides state-scoped consistency of acquisition records: State 1 monitoring messages cannot overwrite the State 0 structural baseline, and structural changes require an explicit transition back to State 0. It does not provide distributed transactional consistency or autonomous fault recovery across the entire NDT platform, which remain responsibilities of the external orchestration and management layer.

This state separation also defines how partial updates are handled. In State 1, runtime updates are published as monitoring records associated with a specific network element and timestamp. These updates are applied to the behavioral view of the digital twin and do not modify the State 0 topology-oriented model. Structural information is updated only through an explicit transition back to State 0, followed by a new modeling/adaptation cycle for the affected elements. This design prevents monitoring samples from inadvertently overwriting the initial modeling information used to instantiate the NDT.

Dynamic events such as node failures, interface flapping, and route convergence changes are therefore handled according to their effect on the NDT model. Events that only affect operational status are represented as State 1 monitoring updates. Events that invalidate the structural baseline, such as the addition or removal of a node, link, or interface, require an externally controlled transition back to State 0. For structural changes in the centralized mode, the synchronization time after a confirmed transition back to State 0 is bounded by the reacquisition and redeployment pipeline, i.e., $T_{sync}=T_{disc}+T_{coll}+T_{trans}+T_{dep}$ for full reconstruction, or by the corresponding subset of stages for partial reconstruction. The event-detection delay itself depends on the monitoring policy: under polling, it is bounded by the polling period plus the time required to collect the affected objects; under PUSH-based reporting, it depends on the agent reporting interval and broker delivery latency. The present experiments measure the State 0 acquisition-to-deployment pipeline but do not benchmark event-driven detection delay or synchronization accuracy under dynamic failures.

3.5. Communication Layer and MQTT Topic Hierarchy

DANA adopts a publish/subscribe communication model based on MQTT [25] to enable decoupled interaction within the Network Digital Twin (NDT) ecosystem. MQTT is used both for control signaling and for the dissemination of acquired network data between the physical and digital domains. Within the scope of this paper, DANA provides the acquisition and communication mechanisms required to support such interaction, while the global NDT management and orchestration workflow is considered an external layer, as described in our previous work on NDT modeling and deployment methodology [8].

From a security perspective, the MQTT-based communication channel can be protected using standard broker-level mechanisms, including TLS-based encryption, client authentication, and topic-level access control. Table 6 summarizes the security controls that are directly compatible with the DANA communication model. Authentication can be based on mutual TLS or broker-supported client credentials. Authorization can be enforced through broker access-control lists that restrict publication and subscription rights according to topic family, lifecycle state, scenario identifier, and agent identity. Replay protection can be implemented at the consumer side by combining timestamps, bounded acceptance windows, and monotonically increasing sequence numbers or nonces in the message metadata. Trust establishment between DANA, satellite agents, and management components is a deployment responsibility and can be implemented through a local PKI, pre-provisioned credentials, or the credential-management mechanisms of the target NDT platform. These mechanisms strengthen architectural robustness, but a complete security evaluation, intrusion-detection strategy, and operational hardening policy remain outside the scope of this acquisition-to-deployment article.

Control messages, such as state-transition commands and operational signals, are exchanged through dedicated MQTT topics to which the DANA core is subscribed. These messages allow an external NDT orchestration layer to activate the corresponding DANA acquisition mode without making DANA responsible for the complete NDT lifecycle management. In particular, DANA reacts to the received lifecycle state by selecting either the State 0 acquisition pipeline, devoted to structural modeling, or the State 1 acquisition pipeline, devoted to runtime monitoring.

Acquired network data are published under structured topic hierarchies that encode the data type, device identity, and operational phase of the NDT lifecycle. This organization supports decoupled dissemination and maintains a clear separation between modeling information and monitoring information. Table 7 summarizes the relationship between DANA states and MQTT topic families.

Broker-level performance depends on the selected MQTT broker, QoS policy, persistence configuration, payload size, deployment resources, and number of concurrent twin instances. Therefore, it is not treated as an intrinsic property of DANA. Nevertheless, the offered load can be characterized by the number of publishers and their reporting frequencies. If A denotes the number of publishers and $f_a$ the publication frequency of publisher a, the aggregate ingress rate is ${\lambda }_{in}={\sum }_{a=1}^A{f}_a$. If $s_a$ denotes the average payload size, the corresponding ingress bandwidth is $B_{in}={\sum }_{a=1}^A{f}_a{s}_a$. Topic partitioning reduces unnecessary consumer processing through selective subscriptions and supports multi-twin coexistence through scenario- and element-specific topic suffixes, but it does not remove the need to size the broker for aggregate ingress load, bursts, retained messages, and QoS-related persistence.

The hierarchical organization of topics enables selective subscriptions, allowing different NDT components, management functions, and digital twin instances to consume only the information relevant to their specific role. In particular, topics can be structured following patterns such as <domain>/<data_type>/<device_id> or <domain>/<state>/<data_type>/<device_id>, enabling fine-grained subscription and efficient data dissemination. This design facilitates interoperability, scalability, and the coexistence of multiple digital twins within the same communication infrastructure.

The topic hierarchy also contributes to consistency across lifecycle states. Data published under State 0 topic families are consumed by the modeling and adaptation pipeline and represent the structural baseline used to instantiate the NDT. By contrast, data published under State 1 topic families are treated as behavioral updates associated with an already deployed digital twin. Therefore, runtime monitoring messages do not overwrite the initial modeling information by default. Any structural modification, such as the addition or removal of a node, link, or interface, requires an explicit control message from the external orchestration workflow to move DANA back to State 0 and trigger a controlled re-acquisition of the affected structural information.

Each DANA message includes lifecycle metadata, such as the acquisition state, timestamp, data type, scenario identifier, and network-element identifier. This metadata allows consumers to validate whether a received message corresponds to structural modeling information or to runtime monitoring information before applying any update. As a result, partial updates can be handled incrementally: monitoring samples update only the behavioral view of the NDT, whereas structural updates are processed through a new State 0 modeling cycle.

In the experimental implementation, this separation is reflected by topology-oriented publications through the TOPOLOGY topic and by the use of communication-flow identifiers such as PT2MANO. The same principle can be extended to State 1 monitoring topics by assigning each network element a dedicated topic suffix, enabling the external management layer to subscribe only to the elements and data streams required for synchronization or observability. Overall, MQTT is used not only as a transport mechanism, but also as a logical separation mechanism that preserves modularity and prevents monitoring data from inadvertently replacing the structural information used to create the NDT.

In summary, this section has presented the communication model of DANA and its relationship with the two-state lifecycle model. By combining lifecycle-aware data publication, MQTT-based control signaling, and explicit separation between topology-oriented and monitoring-oriented topic families, DANA provides the communication substrate required to bridge physical network data and digital twin operation while remaining compatible with external NDT management and orchestration workflows. The next section experimentally validates the proposed system in realistic network scenarios, demonstrating its applicability and effectiveness in supporting NDT deployment and operation.

4. Experimental Evaluation

This section presents the experimental evaluation of DANA, focusing on its role as a data acquisition and transformation component for the initial construction of Network Digital Twins (NDTs). The main objective is to validate the end-to-end workflow that connects data collection from a reference network environment, data normalization, descriptor generation, and deployment of a functional NDT instance. KNE and Kubernetes are used as the first deployment backend [26,27], while Open Source MANO (OSM) and OpenStack are used in the second scenario [28,29].

The evaluation is specifically designed to address the two acquisition models introduced in Section 3.3. First, the centralized model is evaluated through an SNMP-based PULL workflow, where DANA collects topology, interface, configuration, and operational information from network devices and uses the resulting data to generate a KNE-compatible NDT deployed over Kubernetes. Second, the distributed model is evaluated through an agent-based PUSH workflow in a 5G/NFV laboratory scenario, where satellite agents collect host-, virtualization-, and container-level information from general-purpose systems and report it to the central DANA component.

The purpose of the evaluation is not to claim a production-ready NDT platform, but to experimentally validate the feasibility of the proposed acquisition-to-deployment pipeline. In particular, the evaluation focuses on the gap between heterogeneous data acquisition and the automatic creation of a deployable NDT from scratch. This includes the collection of physical-side information, its normalization into the DANA data model, its dissemination through the MQTT-based communication layer, and its transformation into deployment descriptors suitable for the selected virtualization backend.

Accordingly, the evaluation is organized into two complementary case studies:

• Case Study I – Centralized topology discovery and KNE-based NDT deployment: this case study evaluates the centralized SNMP-based acquisition mode. DANA retrieves topology and operational information from an EVE-NG reference network composed of Arista cEOS routers and end-hosts. The collected data are transformed into a KNE-compatible descriptor and used to deploy the corresponding NDT over a Kubernetes cluster. This case study focuses on topology fidelity, functional reachability parity, and the performance of the acquisition, transformation, and deployment pipeline.
• Case Study II – Distributed behavioral monitoring in a 5G network: this case study evaluates the distributed agent-based acquisition mode. The scenario corresponds to a 5G/NFV laboratory environment deployed over virtualized infrastructure, following the same technological principles used in private 5G deployments based on NFV. In this case, satellite agents running on general-purpose systems collect local host and container information and push it to DANA. The resulting data are normalized, published through MQTT, transformed into OSM-compatible VNFD/NSD descriptors, and used to deploy the NDT over OpenStack through Open Source MANO (OSM).

It is important to note that DANA natively uses SNMP in its centralized acquisition mode. Therefore, the flexibility evaluated in this section does not refer to replacing SNMP within that specific mode, but to the separation between data acquisition and deployment-specific descriptor generation. The normalized information produced by DANA can be consumed by different adaptation modules. In Case Study I, the adaptation module targets KNE and Kubernetes, whereas in Case Study II it targets OSM and OpenStack. Both deployment backends act as virtualization and orchestration environments over the underlying hardware infrastructure.

4.1. Case Study I: Centralized Topology Discovery and KNE-Based NDT Deployment

The first case study evaluates the centralized acquisition model of DANA. This model is intended for specific-purpose network devices, such as routers and switches, that expose standard management interfaces. In this case, DANA operates as an external acquisition agent that actively polls the network devices through SNMP, following a PULL-based approach.

The goal of this case study is to validate the complete workflow from centralized data acquisition to the deployment of a topology-equivalent NDT. The workflow includes: (i) the deployment of a reference network environment, (ii) SNMP-based acquisition of topology and operational data, (iii) normalization of the collected information into the snmp_topology_data model, (iv) transformation of the resulting topology-oriented JSON dataset into a KNE-compatible descriptor, and (v) deployment of the resulting NDT over Kubernetes.

4.1.1. Physical-Side Reference Environment Using EVE-NG

Due to the limited accessibility of large-scale hardware, this study employs a network topology emulated via EVE-NG [30] as the reference physical-side environment. The validity of this setup as a physical-side reference environment is limited to the management and control-plane behaviors exercised in the experiment. By executing vendor-specific binary images, the emulated infrastructure exposes the management interfaces and routing behavior required by DANA to acquire and normalize the evaluated topology information. This provides a reproducible laboratory substrate for constructing a deployable NDT, while avoiding any claim that the setup reproduces all hardware-specific effects of production networks.

The reference topology is composed of multiple Arista cEOS routers interconnected through point-to-point links, along with several end-hosts acting as traffic sources and sinks. The routers expose management interfaces including CLI and SNMP, enabling DANA to interact with them through the interfaces exercised in the experiment. SNMP is standardized for network management, but the available information depends on the device MIBs and configuration [31]. This approach preserves reproducibility while maintaining a controlled environment for topology discovery and NDT instantiation; it does not constitute a vendor-neutral configuration-extraction benchmark.

Figure 5 depicts the network topology deployed in EVE-NG and used as the reference environment during the evaluation. The scenario consists of a meshed core of interconnected routers and multiple edge nodes, enabling the assessment of DANA under realistic connectivity and routing conditions.

4.1.2. SNMP-Based PULL Acquisition

Within the EVE-NG reference environment, DANA is deployed as an external agent with management connectivity to all network devices forming the topology. In this case study, DANA uses its centralized acquisition mode, in which the agent actively polls the network devices through SNMP. This corresponds to the PULL-based mechanism described in Section 3.3.

During the acquisition process, DANA collects the information required to characterize the network structure and operational state, including:

• Network topology and interface connectivity.
• Device characteristics, including hardware- and software-related attributes.
• Interface-level parameters and operational state.
• Configuration and protocol-related information.

The collected data are normalized according to the snmp_topology_data model defined in Section 3.3. This model includes device identity, interface-level attributes, operational status, and routing information, enabling the consistent reconstruction of the reference topology within the NDT. The normalized representation is serialized as a topology-oriented JSON dataset, which is later consumed by the descriptor-generation module.

The resulting dataset represents a structured snapshot of the reference environment at a given time instant and serves as input for the NDT instantiation process. This step validates the ability of DANA to transform heterogeneous SNMP responses into a coherent data model suitable for automated descriptor generation.

4.1.3. Transformation to KNE-Compatible Descriptors

Once the centralized data collection phase is completed, DANA automatically transforms the acquired information into a Kubernetes Network Emulator (KNE)-compatible descriptor. This transformation adapts the internal DANA data model into the YAML-based schema required by KNE.

The generated descriptor declaratively encodes node definitions, device attributes, configuration artifacts, and explicit interface-to-interface connectivity, enabling the automated deployment of a container-based replica of the original EVE-NG scenario. In this case study, the descriptor-generation stage is implemented as a KNE-specific adaptation module. Therefore, KNE is the selected deployment backend for this experiment, rather than a constraint of the general DANA workflow.

A representative abstracted view of the KNE descriptor automatically generated by DANA is shown below.

• name: large_scenario
• nodes:
  • r1

    *

    vendor: ARISTA

    *

    model: cEOS

    *

    os: EOS

    *

    config:

    • image: ceos_tc:4.33.2F
    • config_file: startup-config

  • server1

    *

    vendor: HOST

    *

    config:

    • image: rstiupm/server:v6

• links:

  -

  r1:eth3→server1:eth1

  -

  r1:eth5→r2:eth3

This excerpt illustrates how DANA maps the topology discovered in the reference environment into a declarative representation directly consumable by KNE. The complete descriptor is generated without manual intervention and used as input for the deployment of the corresponding NDT.

4.1.4. Kubernetes-Based NDT Deployment

Using the generated KNE descriptor, a digital replica of the reference network is instantiated within a Kubernetes cluster. Each network device from the reference environment is deployed as a containerized instance, preserving the logical topology and connectivity represented in EVE-NG. In this case study, the Kubernetes-based deployment represents the evaluated NDT environment.

In addition to the replicated topology, the NDT incorporates auxiliary components for observability and monitoring, such as probe containers and a message broker. These elements are deployed exclusively in the digital environment to enable metric collection and system introspection, and therefore do not require direct counterparts in the reference network.

To enable continuous validation, DANA is also deployed within the NDT environment, mirroring its role in the reference environment. This dual deployment enables direct comparison between the reference network and its digital counterpart, facilitating the assessment of structural and functional fidelity across both environments.

4.1.5. Metrics and Results

The evaluation of Case Study I focuses on three aspects: topology fidelity, functional fidelity, and pipeline execution time. These metrics quantify the ability of DANA to reconstruct the reference network, instantiate a structurally equivalent NDT, and preserve its basic forwarding behavior.

The ground truth for topology fidelity is obtained from the reference EVE-NG scenario and the device state exposed by the emulated network elements. The deployed NDT topology is obtained from the generated KNE descriptor and the resulting Kubernetes/KNE deployment state. Before comparison, node names, interface identifiers, and link endpoints are canonicalized to remove backend-specific naming differences. A mismatch is counted when an element is missing or when an additional element appears in the deployed NDT. Measurements are taken after both environments reach steady state and routing information remains stable during the validation interval, avoiding transient effects due to deployment and protocol initialization.

Topology fidelity evaluates the degree to which the deployed NDT preserves the structural properties of the reference environment. Three metrics are considered: node fidelity, link fidelity, and interface fidelity. They are defined as follows:

$$F_X={\displaystyle \frac{|X_{DT}\cap X_{PT}|}{|X_{DT}\cup X_{PT}|}},X\in \{N,L,I\}.$$

(1)

where $PT$ denotes the reference physical-side environment and $DT$ denotes the deployed digital twin. N, L, and I represent the sets of nodes, links, and interfaces, respectively. This Jaccard-style definition penalizes both missing and additional elements; exact set equality therefore yields $F_X=1$.

Functional fidelity evaluates whether both environments exhibit equivalent network behavior after deployment and convergence. This aspect is assessed using reachability parity, defined as the percentage of node pairs for which ICMP reachability results are identical in the reference environment and in the NDT.

Reachability parity is computed as the percentage of evaluated node pairs for which the ICMP result is identical in the reference environment and in the NDT. The calculation is exhaustive over the selected validation matrix after steady-state convergence, rather than a random sample from a larger population. Therefore, the reported values should be interpreted as deterministic agreement ratios for the evaluated scenarios, not as inferential estimates with confidence intervals. Repeated-trial variance under different initialization orders, routing convergence transients, or failure conditions is not evaluated in this work and is identified as part of future performance-oriented validation.

The execution time of the acquisition-to-deployment pipeline is evaluated using the following metrics:

• $T_{disc}$: topology and device discovery time.
• $T_{coll}$: data acquisition time.
• $T_{trans}$: descriptor generation time.
• $T_{dep}$: NDT deployment time.
• $T_{e2e}$: measured end-to-end wall-clock time, including any uninstrumented orchestration overhead.

The present evaluation does not include a fine-grained profiling study of CPU utilization, memory footprint, I/O overhead, or concurrent acquisition stress. The reported timing metrics characterize the end-to-end acquisition-to-deployment workflow and identify the dominant pipeline stages, while detailed system profiling is left for a scalability-oriented evaluation.

Table 8 summarizes the topology and functional fidelity results obtained for the evaluated scenarios. The scenarios include 4, 7, and 10 routers, corresponding to the small, medium, and extended topologies, respectively.

The results show that the number of nodes, interfaces, and links obtained through SNMP-based acquisition is fully preserved in the deployed NDT. Consequently, maximum topology fidelity is achieved in all scenarios. This confirms that the information collected by DANA and normalized into the snmp_topology_data model is sufficient to reconstruct the structural properties of the reference network in the KNE/Kubernetes environment.

Functional fidelity is also consistently preserved. Reachability parity remains above 99% in all evaluated scenarios, showing that end-to-end connectivity in the NDT closely matches the behavior observed in the reference environment. Minor discrepancies in larger topologies are attributed to differences in protocol convergence, initialization order, and timing effects between the EVE-NG environment and the Kubernetes-based deployment, rather than to errors in topology reconstruction.

All measurements were taken under steady-state conditions, after allowing both the reference environment and the NDT to converge. This isolates the fidelity assessment from transient effects associated with deployment and routing protocol initialization.

Table 9 reports the pipeline performance results. The total execution time increases with the number of routers and links, as expected, since larger scenarios require additional SNMP interactions, more extensive descriptor generation, and the deployment of a larger number of containerized network functions.

Here, $T_{e2e}$ is the measured end-to-end wall-clock time. It includes the four displayed stages and any uninstrumented orchestration or initialization overhead; consequently, it is not expected to equal their arithmetic sum. The displayed stage times sum to 117.8, 263.9, and 479.7 s for the three scenarios, whereas the measured end-to-end times are 120, 268, and 488 s.

The discovery phase, represented by $T_{disc}$, corresponds to the identification of network devices and their connectivity relationships starting from the available structural input. In this setup, DANA progressively obtains interface and adjacency-related information through SNMP queries, which explains the non-negligible discovery time even in the small scenario.

The collection phase, represented by $T_{coll}$, corresponds to the retrieval of topology, interface, configuration, and operational information from all discovered devices. This stage involves multiple SNMP GET and WALK operations per node, including the retrieval and parsing of interface, routing, and device-level parameters. As a result, $T_{coll}$ becomes one of the dominant contributors to the total execution time.

From a scalability perspective, the cost of the centralized acquisition stage is mainly determined by the number of monitored devices and by the amount of management information retrieved per device. If N denotes the number of network devices, $I={\sum }_{d=1}^N{I}_d$ the total number of interfaces, $R={\sum }_{d=1}^N{R}_d$ the total number of routing entries, and L the number of discovered links, the sequential SNMP acquisition effort grows with the number of device-level, interface-level, and routing-level objects queried from the network. More explicitly, the number of processed management objects can be approximated as ${\sum }_{d=1}^N(\alpha +\beta I_d+\gamma R_d)$, where $\alpha$, $\beta$, and $\gamma$ depend on the selected MIB objects and collector configuration. Thus, collection complexity is $O(N+I+R)$, while the normalized topology representation requires $O(N+I+R+L)$ memory. Increasing node density mainly affects adjacency reconstruction and descriptor generation through L, whereas routing-table growth affects collection and parsing through R. The descriptor-generation stage is comparatively lightweight because it serializes the normalized representation into the selected backend format, with a cost $O(N+I+L)$. By contrast, the deployment stage is dominated by the selected virtualization backend, since container creation, image loading, and virtual interface attachment are performed by Kubernetes/KNE rather than by DANA itself. Therefore, the main scalability bottleneck of the current centralized mode is the SNMP discovery and collection process, whereas descriptor generation introduces negligible overhead in the evaluated scenarios.

The transformation phase, represented by $T_{trans}$, introduces limited overhead. This phase mainly consists of organizing the normalized DANA data model and serializing it into the KNE-compatible descriptor format. The results show that descriptor generation remains below three seconds even in the extended scenario.

The deployment phase, represented by $T_{dep}$, becomes dominant in the medium and extended scenarios. This is expected because the Kubernetes-based deployment includes container instantiation, image loading, virtual interface creation, and orchestration of the emulated network topology. Since each network function is deployed as an independent container, deployment time increases with the size and connectivity complexity of the scenario.

Overall, the results confirm that the centralized acquisition and deployment pipeline behaves predictably with respect to network size and data volume. Although SNMP-based discovery and collection introduce overhead, this cost is acceptable for the initial creation of the NDT, which is the main focus of State 0. Once the NDT has been instantiated, subsequent monitoring and synchronization can operate incrementally.

In addition to topology reconstruction and NDT deployment, Case Study I also validates the data management workflow through MQTT and Elasticsearch. The DANA agent deployed in the reference environment generates structured topology-oriented JSON data, which are published through the MQTT topic TOPOLOGY. The management component receives these data and stores them in Elasticsearch, creating a time-indexed repository of the network state that supports synchronization, inspection, and historical analysis.

Figure 6 shows a qualitative snapshot of stored topology data visualized through Kibana for case_I, composed of SNMP-monitored network devices. The field flag_status = 0 is the legacy prototype encoding for the initial acquisition phase, corresponding to State 0 in the terminology used in this paper. The dashboard timestamps reflect the captured laboratory records and are not used in the quantitative timing or fidelity analysis.

Kibana enables filtering based on specific fields and time ranges. Figure 7 illustrates filtered data corresponding to the communication flow identified by net_element.comm_channel = PT2MANO. The visualization includes network elements associated with net_element.id_scenario = case_I.

These results demonstrate that the centralized SNMP-based acquisition path can feed the complete DANA workflow, from topology discovery and data normalization to MQTT-based dissemination, persistence, descriptor generation, and deployment of a functional KNE/Kubernetes-based NDT.

4.2. Case Study II: Distributed Acquisition in a 5G/NFV Laboratory Scenario

The second case study evaluates the distributed acquisition model of DANA. In contrast to Case Study I, where DANA actively polls network devices through SNMP, this case study focuses on general-purpose systems used to support a softwarized 5G/NFV scenario. In this environment, data acquisition is performed through lightweight satellite agents that locally collect information from each host and report it to the central DANA component following a PUSH-based approach.

The purpose of this case study is not to introduce an additional network monitoring use case, but to experimentally validate the second acquisition mechanism described in the architecture. Therefore, the evaluation focuses on the acquisition-to-deployment path: satellite-agent reporting, JSON normalization, MQTT dissemination, descriptor generation, and deployment of the resulting NDT through an NFV/MANO backend.

4.2.1. 5G/NFV Scenario and General-Purpose Hosts

The evaluated scenario corresponds to a 5G/NFV laboratory environment deployed over virtualized infrastructure. This choice is aligned with the technological nature of private 5G deployments, where network functions are commonly implemented as software components running on virtual machines, containers, or cloud infrastructure. Therefore, the scenario is not intended to reproduce radio-layer behavior, but to provide a realistic and controllable 5G/NFV environment for validating the distributed acquisition and NDT creation workflow.

The physical-side reference scenario comprises four service virtual machines connected through different network segments, together with the separate agent virtual machine shown at the bottom of Figure 8. The service VMs host the components required to represent a simplified 5G environment: a 5G core, a UE component, a Data Network, and the STG-UTG connector, which is used together with the UE to emulate interaction with the 5G core. Satellite-agent placement is therefore reported explicitly rather than being conflated with the number of service VMs.

Figure 8 shows the 5G/NFV laboratory scenario used as the physical-side reference environment in this case study.

4.2.2. Satellite-Agent PUSH Acquisition

In this case study, DANA operates according to its distributed acquisition model. Instead of polling each element from a central location, DANA relies on satellite agents deployed on the general-purpose systems that compose the 5G/NFV scenario. Each satellite agent collects local information about the host and its execution environment and sends the resulting report to the central DANA component.

The collected information includes operating system information, compute and storage resources, network interfaces, virtualization-related information, Docker status, and container-level information. This information corresponds to the agent-based data model introduced in Section 3.3. Compared with the snmp_topology_data model used in Case Study I, this model provides visibility at the host and execution layers, which are essential in softwarized 5G/NFV environments.

The acquisition mechanism follows a PUSH-based paradigm. Each satellite agent generates a local report and transmits it to the central DANA component, which acts as a concentrator. This validates the distributed acquisition path described in the architecture, showing that DANA can receive information from multiple general-purpose systems without relying on centralized SNMP polling.

4.2.3. JSON Normalization, MQTT Publication, and Data Persistence

After receiving the reports from the satellite agents, DANA normalizes the collected information into an agent-based JSON representation. This JSON dataset captures the information required to characterize the 5G/NFV laboratory scenario from the perspective of host resources, network interfaces, virtualization support, Docker status, and containerized components.

Once the collection process is completed, DANA publishes the resulting JSON file through the MQTT broker using the TOPOLOGY topic and the PT2MANO communication flow. The management component subscribes to this topic and receives the JSON representation of the physical-side scenario. This validates the PUSH-based communication path from the distributed agents to the management layer.

As in Case Study I, the management component stores the received JSON data in Elasticsearch, enabling inspection and validation through Kibana. Figure 9 shows the topology-related information reported by the distributed acquisition process for Case Study II. Unlike the SNMP-based data shown in Case Study I, this information corresponds to general-purpose systems and includes host- and virtualization-related attributes. The dashboard timestamps are retained as provenance from the captured laboratory records and are not used as experimental timing measurements.

This workflow complements the topology-oriented JSON generated from SNMP in Case Study I. In the first case study, the JSON representation is derived from centralized SNMP polling of network devices. In the second case study, the JSON representation is derived from distributed reports produced by satellite agents running on general-purpose systems.

4.2.4. Transformation to OSM Descriptors: VNFD/NSD

Once the agent-based JSON data are received by the management layer, the descriptor-generation stage transforms the normalized information into deployment artifacts suitable for the selected NFV backend. In this case study, the target backend is Open Source MANO (OSM), and the generated artifacts are Virtual Network Function Descriptors (VNFDs) and a Network Service Descriptor (NSD).

This stage validates the adaptation capability of the DANA workflow beyond the KNE/Kubernetes backend used in Case Study I. The same acquisition-to-deployment principle is applied, but the output descriptor format changes according to the selected orchestration environment. In Case Study I, the topology-oriented JSON is transformed into a KNE-compatible descriptor. In Case Study II, the agent-based JSON is transformed into OSM-compatible VNFD/NSD packages, which can be onboarded into the OSM catalog and instantiated over an OpenStack VIM.

Figure 10 shows the graphical representation of the generated NSD in OSM. This figure provides evidence of the descriptor-generation stage for the NFV/MANO backend used in this case study.

4.2.5. OpenStack-Based NDT Deployment

After the descriptors are generated and onboarded into OSM, the 5G/NFV NDT is instantiated as a network service over OpenStack. In this case study, OpenStack acts as the Virtualized Infrastructure Manager (VIM), providing the compute, storage, and networking resources required to deploy the virtual machines and virtual links associated with the generated descriptors.

During the instantiation process, OSM deploys the Ubuntu-based instances and creates the virtual networks specified in the NSD. As a result, the digital environment reproduces the structure of the 5G/NFV laboratory scenario over the OpenStack infrastructure.

Figure 11 shows the resulting 5G/NFV NDT deployed over the OpenStack VIM connected to OSM.

4.2.6. Functional Validation Results

The results of Case Study II validate the distributed acquisition and deployment path of DANA in a 5G/NFV environment. Unlike Case Study I, this experiment is not intended to provide a quantitative scalability benchmark based on execution time, topology fidelity, high numbers of distributed agents, or high-frequency telemetry streams. Instead, it provides a functional validation of the agent-based PUSH workflow and its integration with an NFV/MANO deployment backend.

Consequently, this case study does not report satellite-agent CPU utilization, memory footprint, telemetry generation rates, or broker stress under message bursts. These metrics depend on the number of deployed agents, reporting frequency, payload size, local host configuration, broker implementation, and QoS/persistence settings. They are therefore outside the scope of the present functional validation and are identified as part of the scalability evaluation required for production-grade deployments.

Table 10 summarizes the main validation points of the case study, while Table 11 makes explicit the operational evidence obtained from the execution of the distributed acquisition-to-deployment workflow.

The experiment confirms that DANA can operate in distributed mode by receiving information from satellite agents deployed on general-purpose systems. This directly addresses the validation gap associated with the distributed acquisition model. The agent-based workflow complements the SNMP-based workflow of Case Study I by targeting a different type of infrastructure: virtualized hosts and containerized network functions instead of router-centric network devices.

Table 11 is intended to make explicit the evidence supporting the functional validation of the distributed workflow. The table does not report scalability-oriented timing metrics, because the purpose of this case study is not to benchmark DANA under high agent density, high reporting frequency, or dynamic host churn. Instead, it documents that all stages of the distributed acquisition-to-deployment chain were exercised: satellite-agent reporting, central normalization, MQTT dissemination, data persistence, descriptor generation, MANO onboarding, and OpenStack-based NDT instantiation.

The case study also confirms that the DANA workflow can feed different descriptor-generation backends. The KNE adapter used in Case Study I generates descriptors for Kubernetes-based network emulation, whereas the OSM adapter used in this case study generates VNFD/NSD packages for NFV deployment over OpenStack. This separation between acquisition, normalization, and backend-specific descriptor generation is essential for applying DANA to heterogeneous NDT environments.

Overall, Case Study II demonstrates the feasibility of the distributed agent-based acquisition path and its integration with an NFV-based NDT deployment workflow. The validation is functional rather than a large-scale performance benchmark, but it directly exercises the PUSH-based mechanism, the agent-based data model, MQTT dissemination, Elasticsearch persistence, OSM descriptor generation, MANO onboarding, and OpenStack deployment in a realistic 5G/NFV laboratory environment.

4.3. Cross-Case Discussion

The two case studies evaluate complementary aspects of DANA and jointly validate the acquisition-to-deployment workflow proposed in this article. Case Study I focuses on centralized acquisition from specific-purpose network devices, whereas Case Study II focuses on distributed acquisition from general-purpose systems supporting a softwarized 5G/NFV scenario.

Table 12 summarizes the main differences between both case studies.

The comparison shows that the two acquisition modes of DANA address different types of network environments. The centralized SNMP-based mode is suitable for network devices that expose standard management interfaces and can be queried from a central acquisition point. This makes it appropriate for reconstructing router-centric topologies and generating a topology-equivalent NDT, as demonstrated in Case Study I.

The distributed agent-based mode addresses a different class of environments, where relevant information is located inside general-purpose systems, virtualization platforms, Docker runtimes, or containerized services. In this case, centralized SNMP polling is not sufficient to characterize the execution environment. The use of satellite agents allows DANA to collect local information from each host and integrate it into the same acquisition-to-deployment workflow, as demonstrated in Case Study II.

The results also show that the descriptor-generation stage is independent from a single deployment backend. In Case Study I, the normalized data are transformed into a KNE-compatible descriptor and deployed over Kubernetes. In Case Study II, the normalized agent-based data are transformed into OSM-compatible VNFD/NSD packages and deployed over OpenStack through OSM. Therefore, the adaptation stage acts as a backend-specific translation layer between the DANA data model and the selected virtualization or orchestration environment.

This translation stage follows an adapter pattern. DANA does not require the normalized acquisition data to match the native schema of a specific backend. Instead, each backend adapter implements four functions: (i) selection of the target node or function abstraction; (ii) mapping of interfaces and links into backend-specific connectivity primitives; (iii) mapping of resource, image, and configuration attributes into deployment descriptors; and (iv) validation and packaging according to the target orchestrator. The KNE adapter maps topology-oriented JSON into YAML descriptors for Kubernetes-based network emulation, whereas the OSM adapter maps agent-based information into VNFD/NSD artifacts. Additional adapters could target Containerlab topologies, Helm charts, TOSCA-based NFV descriptors, or alternative MANO platforms. Therefore, backend portability is achieved at the normalized-data and adapter-interface levels, while each descriptor generator remains specific to its target orchestration framework.

This distinction is relevant for the scope of the proposed contribution. DANA is not presented as a complete production-ready NDT platform, but as a data acquisition, normalization, communication, and transformation component that supports the creation of deployable NDT instances from collected network information. The two case studies demonstrate that this workflow can operate with both centralized and distributed acquisition models and with different deployment backends.

At the same time, the two case studies have different validation scopes. Case Study I provides a quantitative assessment of topology fidelity, functional reachability parity, and execution time. Case Study II provides a functional validation of the distributed acquisition path and its integration with an NFV/MANO-based deployment workflow. This distinction avoids overgeneralizing the results while directly addressing the need to experimentally validate the agent-based PUSH mechanism.

4.4. Limitations and Threats to Validity

The experimental evaluation demonstrates the feasibility of the proposed acquisition-to-deployment workflow under two complementary acquisition models. Nevertheless, several limitations and threats to validity must be considered when interpreting the results.

First, the evaluation is performed in controlled laboratory environments. Case Study I relies on an EVE-NG reference environment, while Case Study II relies on a virtualized 5G/NFV laboratory scenario. These environments provide reproducibility and allow the evaluation of realistic management interfaces, virtualized network functions, containerized components, and orchestration workflows. However, they do not fully capture all the operational variability, hardware-specific behavior, failure conditions, or administrative constraints that may appear in large-scale production networks.

External validity toward production brownfield networks is therefore limited by factors not reproduced in the laboratory setup, including credential-management constraints, maintenance windows, access-control policies, vendor-specific MIB coverage, rate limits on management interfaces, partially documented topologies, and operational change processes. Consequently, the experiments validate the management-plane acquisition-to-deployment workflow under controlled conditions, but they do not constitute a production brownfield benchmark.

Second, the quantitative evaluation is mainly associated with the centralized SNMP-based workflow. In Case Study I, topology fidelity, reachability parity, and pipeline execution time are measured across several topology sizes. In contrast, Case Study II is used as a functional validation of the distributed agent-based workflow. It demonstrates satellite-agent reporting, agent-based JSON generation, MQTT dissemination, descriptor generation, data persistence, and OpenStack-based NDT instantiation, but it does not provide a large-scale performance benchmark with a high number of agents or highly dynamic host churn.

The reachability-parity values reported for Case Study I are deterministic agreement ratios over the evaluated validation matrix, not statistical estimates obtained from repeated randomized trials. Accordingly, the manuscript does not report confidence intervals or repeated-trial variance. Such analysis would require repeated executions under controlled variations in initialization order, convergence timing, topology scale, and failure conditions.

Third, the centralized acquisition mode depends on the availability and correctness of SNMP information exposed by the monitored devices. This makes the approach suitable for many legacy and brownfield network environments, but it also inherits the limitations of SNMP-based visibility, including polling overhead, incomplete management information bases, vendor-specific differences, and potential delays in reflecting fast operational changes.

Fourth, the descriptor-generation stage is evaluated using two specific deployment backends: KNE/Kubernetes and OSM/OpenStack. These backends demonstrate that the normalized DANA data can be transformed into different deployment artifacts, but they do not exhaust the possible target environments. Additional adapters would be required to support other deployment technologies, such as Containerlab topologies, Helm charts, alternative MANO platforms, or other NFV descriptor formats.

Fifth, the present evaluation focuses on the initial creation of the NDT, corresponding mainly to State 0 of the DANA operational model. Although the architecture supports runtime monitoring and synchronization through MQTT-based communication, this article does not claim a complete production-grade closed-loop operation system. Dynamic topology-change experiments involving node failures, interface flapping, route convergence events, false-positive detection, and recovery policies are not executed in the current evaluation. Large-scale measurements of change-detection latency, synchronization accuracy, fault recovery, and actuation safety are left for future work.

Finally, the distributed acquisition model is validated in a realistic 5G/NFV laboratory scenario, but not yet in a large production deployment. The results show that the PUSH-based mechanism is technically feasible and integrated with the rest of the DANA workflow. However, further experimentation is required to quantify its scalability, robustness, and performance under larger numbers of satellite agents, higher reporting frequencies, heterogeneous host configurations, message bursts, multi-twin coexistence, and failure conditions. Broker-level performance, satellite-agent CPU utilization, memory footprint, and telemetry generation rates are therefore treated as future performance-engineering tasks rather than as claims made by the current article.

These limitations do not invalidate the experimental contribution, but delimit its scope. The results support the main claim of this article: DANA can bridge the gap between heterogeneous network data acquisition and the automatic creation of deployable NDT instances. The two case studies show that this workflow can operate with centralized SNMP-based acquisition and distributed agent-based acquisition, and that the resulting normalized data can be adapted to different deployment backends.

5. Conclusion and Future Work

This paper presented DANA, a digital agent for automated network data acquisition in Network Digital Twin (NDT) environments. The proposed system addresses the gap between heterogeneous network data acquisition and the automatic creation of deployable NDT instances. DANA supports the collection, normalization, dissemination, and transformation of network information required to instantiate a digital counterpart from a physical-side reference environment. Consistent with the applied-research scope of this journal, the contribution is the design, integration, and experimental validation of a bounded acquisition-to-deployment workflow; it is not presented as a new isolated protocol or a new NDT reference architecture.

The proposed architecture combines a lifecycle-aware operational model, a heterogeneous-infrastructure acquisition design, and an MQTT-based publish/subscribe communication layer. DANA distinguishes between centralized SNMP-based acquisition for specific-purpose network devices and distributed agent-based acquisition for general-purpose systems, virtualized hosts, and containerized environments. This separation enables the evaluated prototype to operate across the two infrastructure categories studied and to support different phases of the NDT lifecycle.

The experimental evaluation was structured around two complementary case studies. The first case study validated the centralized SNMP-based PULL workflow using an EVE-NG reference topology composed of Arista cEOS routers and end-hosts. The acquired data were normalized into a topology-oriented representation, transformed into a KNE-compatible descriptor, and used to deploy the corresponding NDT over Kubernetes. The results showed full topology fidelity in all evaluated scenarios and reachability parity above 99%, confirming that the generated NDT preserves both the structural properties and the basic forwarding behavior of the reference environment. The measured pipeline times also showed predictable growth with network size, with SNMP-based collection and Kubernetes deployment being the dominant contributors.

The second case study validated the distributed agent-based PUSH workflow in a 5G/NFV laboratory scenario. In this case, satellite agents deployed on general-purpose virtual machines collected host-, virtualization-, Docker-, and container-level information and reported it to the central DANA component. The resulting agent-based JSON data were disseminated through MQTT, stored and inspected through the management layer, transformed into OSM-compatible VNFD/NSD descriptors, and used to instantiate the corresponding NDT over OpenStack through OSM. This validation demonstrates that the distributed acquisition path is operational and integrated with the same acquisition-to-deployment workflow used by the centralized mode.

The two case studies also show that the descriptor-generation stage is not restricted to a single deployment backend. While the first case study targets KNE and Kubernetes, the second targets OSM and OpenStack. This confirms that the normalized DANA data model can feed different adaptation modules, allowing the NDT deployment process to be tailored to the selected virtualization or orchestration environment.

Several limitations remain. The evaluation was conducted in controlled laboratory environments, which provide reproducibility but do not fully capture the variability and constraints of large-scale production networks. The centralized workflow was quantitatively evaluated across several topology sizes, whereas the distributed workflow was validated functionally in a 5G/NFV scenario but not benchmarked with a large number of agents or highly dynamic host conditions. In addition, the centralized acquisition mode inherits the limitations of SNMP, including polling overhead, dependency on available management information, and limited responsiveness to fast operational changes.

Future work will focus on extending the evaluation to larger hybrid environments combining network devices, virtual machines, containers, and cloud-native functions. Additional work will also address scalability measurements for the distributed agent-based mode, including higher numbers of satellite agents, different reporting frequencies, and failure conditions. From an acquisition-efficiency perspective, future extensions will explore parallel SNMP polling, adaptive sampling policies, and the integration of streaming telemetry sources as alternative collectors within the same DANA normalization and publication pipeline. Further extensions will explore additional descriptor-generation backends, such as Containerlab, Helm-based deployments, or alternative MANO/NFV formats. Finally, future research will strengthen runtime synchronization, change-detection latency analysis, and safe closed-loop interaction between the physical and digital domains.

Overall, DANA is positioned as a practical enabling component for Network Digital Twin construction and operation. Its contribution is the integration of centralized and distributed acquisition, lifecycle separation, normalization, MQTT-based communication, and backend-specific descriptor generation in one experimentally evaluated workflow. Rather than proposing a complete production-ready NDT platform, it provides a bounded acquisition-to-deployment pipeline that connects the two evaluated physical-side environments with deployable digital counterparts.