# Towards Digital-Twin Assisted Software-Defined Quantum Satellite Networks
## 4 Proposed Architecture
### Quantum Path Setup Protocol  
In the following part, we describe the protocol that has been designed for the architecture shown in Figure 3, along with its packet format.  
Specifically, the packet design is based on the TCP/IP stack and uses the format defined in RFC 5444 [61], which is related to the Mobile Ad Hoc Network (MANET) Packet/Message Format, but it can be easily extended. The packet is composed of the following fields:  
* Type: this is a field used for defining the type of the message. Specifically, the four message types are defined as follows:
* Type 0: sent by a GS to the MCS indicates a request to initiate a quantum communication with a specific destination.
* Type 1: sent by the MCS to a destination GS to verify whether it is willing to establish a quantum communication.
* Type 2: sent by the MCS to the source GS to confirm that the destination GS is available to initiate a quantum communication.
* Type 3: sent by the MCS to the QSRs to perform the communication setup according to the specifications provided by the DT.
* Type 4: sent by the DT to the MCS to communicate the list of satellites to be involved in quantum communication. The list is obtained from the optimization performed by the DT.
* Type 5: sent by the satellites to the DT to communicate the status of their quantum memories.
* T\({}_{\text{start}}\) + Duration: specifies the initial time and duration of the path that has to be initialized. It allows programming of the establishment and termination of the connections at specific times.
* Flow descriptor: variable length field, dependent on the protocol stack being used. The above field description the \"Flow descriptor\" field depends on the protocol stack being used. The time and duration fields need to be further specified, since that they use a standardized time representation. This point is subject to further investigation, and it shall be considered in the implementation and standardization phases. In our work we did use the standard UNIX time representation. The DT processes the connection requests originated by one of the GSs. Specifically, the DT receives a message with Type equal to 0 and the flow identifier, e.g., the IP address of the GS that requests the connection, the IP address of the destination GS, etc. Moreover, the DT sends a Type 1 message to the other GS to verify if it can accept the connection. If the destination GS acknowledges the request, the DT forward the Type 2 response message to the GS that had requested to communicate to confirm that the receiving GS is available. The DT establishes a connection with the involved satellites in order to obtain information regarding the quantum memory status. The satellites transmit Type 5 messages to the DT, enabling it to update the state of its digital network. Therefore, the DT starts to compute the best E2E paths for all the time intervals wherein the GSs are simultaneously in contact with the favorable satellites using the proposed optimization procedure, which minimize the RTT between the DT and the involved satellites and derives a list of available paths. The list is sent to the controller installed in the MCS with a Type 4 message. The derived time intervals will form the Duration field of the subsequent messages explained in the following part. Specifically, the Controller sends multiple packets to the QSRs, with Type set to 3. In this case, the Duration contains the time interval in which the path is valid, and it has to be considered by the node in order to operate during the specified time interval.
Furthermore, the source port and the destination port define the quantum flows, which are mapped in specific quantum memory locations on the QSRs that compose the chain.  
Therefore, quantum communication can begin and concludes when the path ceases to exist. At that point, the procedure restarts in order to establish a new E2E path for the following time interval. A sequence diagram of the protocol is represented in Figure 4.