# Digital Twin-Driven Virtual Network Architecture for Enhanced Extended Reality Capabilities
## 3 Architecture's Proposed Approach
### DTM Traffic Flows
DTN re-configuration request: This process is performed with the objective to modify the DTN configuration as explained in Section 3.1. The process requires that the DTM Builder operates as a DTCD super users' interface. The Builder receives the request and then the previously described re-modeling and re-generation operations are initiated (Figure 12). 5. DTN synchronization Status Sharing: This process is designed to ensure that the ONM is aware of the DTN network model status. The DTM Modeler generates a \"Sync.Status\", which contains the DTM network model information, and is sent through the Classifier and Edge Routers (with the double ACK mechanism), finally reaching the ONM DTN Synchronization Status. Figure 13 illustrates the traffic flow. 6. DTN synchronization: The DTM model is able to detect any change in the ONM and the DTM model. The DTM model is able to detect any change in the ONM and the DTM model. The DTM model is able to detect any change in the ONM and the DTM model. The DTM model is able to detect any change in the ONM and the DTM model. The DTM model is able to detect any change in the ONM and the DTM model. The DTM model is able to detect any change in the ONM and the DTM model. The DTM model is able to detect any change in the ONM and DTM model. Figure 11: DTN monitoring flows. Figure 10: DTN synchronization flows. Figure 9: DTN creation flows. 2. Data Plane: The data plane traffic flows describe the data flow transmitted within the DTN among the DTCDs along with the data shared between DTCDs and ON devices. Three scenarios are introduced next: 1. Scenario 1: Two clients within the DTN exchange information: This is the simplest scenario. The DTN communication delay will be the typical delay from any terrestrial network. Then, the communication transport protocol can be approached with TCP or different streaming protocols. 2. Scenario 2: A client within the DTN requests content to the ON: In this scenario, the DT client is requesting contents that are originally located in the ON. This scenario introduces the high latency issue described in previous sections. Since a continuous content downloading involves the high latency problem, this paper proposes leveraging proxy servers placed in the space station; these proxy servers can monitor the channel utilization and request to the DTM to download ON content. Then, two sub-scenarios emerge: 1. The content is already stored in the proxy server: the DTM requests the content directly to the proxy server; data flow for this request can be approached with the TCP protocol. 2. The content must be downloaded to the proxy server: the DTM must request to the ONM to transmit the content and then store it in the proxy server. Inevitably, the content transmission will suffer from the space communication delay. In both previous cases, the DTM Content Delivery Agent is responsible for determining whether or not to request content download to the ONM. Furthermore, the DTM Status Control may have the ability to asses the DTN's  
Figure 12: DTN re-configuration flows. Figure 13: DTN synchronization status sharing. utilization and requests for content downloading in instances where the DTN operates at low utilization. The decision-making process can be leveraged with AI techniques. Scenario 3: A client within the DTN is communicating with a client within the ON: In this third scenario, the communication between the two nodes will suffer high latency from space communication conditions. The DTM Edge Router must determine that the TCP protocol is unsuitable to support the communication; consequently, the data flow from DTM to ON must be approached with a different transmission protocol; Delay-and Disrupting-Tolerant Networking can be considered as a potential solution. The traffic flows for this scenario are illustrated next in Figure 14.