# Towards Digital-Twin Assisted Software-Defined Quantum Satellite Networks
## 4 Proposed Architecture  
As reported in RFC 9340 [3], there are significant differences between classical networks and QNs concerning data operation, network resource management, and the physical principles governing the quantum world. For instance, differently from classical networks that operate according to the \"store and forward\" mechanism, QNs operate following the \"store and swap\" logic that requires different state management techniques. Moreover, the control algorithms and QNs optimization procedures are different from those for classical networks, in the sense that entanglement swapping is stateful in contrast to stateless packet-by-packet forwarding. Therefore, it is necessary to define specific architectures and protocols for the proper management of QNs resources. As mentioned in the previous sections, a LEO satellite constellation where each satellite is a QSR is a promising solution for long-distance quantum communications. Therefore, we consider a LEO constellation where all elements that compose the network are QSRs. The QSRs and the GSs are part of the DP, and work in the FSO frequency range [60]. The performance of FSO is significantly conditioned by atmospheric factors that cause phenomena such as beam wandering, especially regarding G2S and S2G communications [35]; however, acceptable performance can be achieved in favorable meteorological conditions with the use of the 1550 nm technology. The main problems in managing such a system are related to calculation of the best path according to the satellite positions and available resources, which vary over time. Our proposed architecture, shown in Figure 3 is composed of the satellite LEO QSRs network, a DT, and an SDN Controller:  
* The DT performs the network optimization and the what-if analysis to find the optimal path in the QSRs network. * The SDN Controller is in charge of applying the configurations to the QSRs, which acts as SDN switches. Specifically, we have defined the modules composing the Quantum Satellite DT (QSDT) as follows:
* A first block containing the digital network and a global vision of the involved quantum processors, i.e., the virtual quantum processor. * A second block that performs an evaluation of the QN's performance, also accounting for potential faults. * A third block that includes the network view derived from the performed simulations. Furthermore, the modules that constitute the SDN Controller and have a direct interaction with the QSDT are outlined below:
* The Abstract Topologies Manager is tasked with the storage and management of information concerning the networking devices under its supervision. It observes notifications and updates the topology data, specifically the temporal graph, which includes all satellites forming the constellation along with their connections. * The Satellite Manager provides information on the satellites and their ports, allowing Northbound APIs to retrieve details about the constellation. * The Forwarding Rules Manager (FRM) handles basic forwarding rules, resolving conflicts and validating them. Specifically, given that the TN module offers a temporal perspective of the scenario, the FRM can adjust satellite forwarding rules based on the scenario's temporal progression. * The Statistics Manager collects statistics by sending requests to all active satellites and storing the responses within the operational statistics subtree. * The GS Tracker retains data on the GSs and offers APIs to access information about end nodes. The DT derives a virtual scenario extrapolating a TG from the TLE data. The TG includes the time intervals at which the satellites are in contact with each other, and the average inter distances as weights. Afterward, a specifically designed path selection algorithm used to calculate the best path considering the time intervals in which the path is viable is applied to the TG and performance is verified to meet the user's requirements.