# Service for Deploying Digital Twins of QKD Networks
## 5 Validation and Results
### Performance of Orchestration Actions  
In this experiment, the QKD network digital twin orchestrator builds digital twins of QKD networks with different numbers of nodes, making use of the open source network orchestration solution OSM, and collects the time spent in building the digital twins as a function of the number of nodes in the defined QKD network. A schematic of the scenario of this test can be seen in Figure 11.  
To better analyze the results, the deployment time is divided into three main processes: the time of the virtual machine's instantiation, which corresponds to Step 2 defined in Section 3.1, the configuration time of those machines as QKD network sites, which includes the download of the necessary software, and the execution time, i.e., starting SimulaQron in each node to make the QKD network operational. These two processes conform the Step 3 in Section 3.1.  
Figure 11: Scenario scheme of the experiment regarding the performance of orchestration actions.  
Figure 10: Performance evaluation results. (**a**) Time spent in the exchange of one key as a function of the key size. For each key size, the distribution of the 20 exchanged keys is shown. (**b**) Qubits discarded when exchanging a key as a function of the key size. For each key size, the distribution of the 20 exchanged keys is shown.  
The first process conducted is the instantiation, which corresponds to the bottom range shown in Figure 12a. A linear growth can be seen in this component (note that the separation in the horizontal axis does not scale linearly) since the OSM executes the deployment sequentially.  
The second process, the configuration, is represented in the middle range of Figure 12a, and as can be seen, it is the most time-consuming process. The behavior in the time spent performing this process can be explained because of the functioning of Ansible, discussed in Section 4.1. Since the default number of parallel processes that Ansible sends is 5 [49], the configuration time remains constant until this limit is exceeded, doubling in size once the number of nodes is greater than 5. As can be seen in Figure 12a, for networks of 1 to 5 nodes the configuration time is the same, while for the 8-node network under consideration, a growth of about twice as much is observed.  
The execution time, which is the initialization of the emulator SimulaQron in each module, corresponds to the upper range in Figure 12a. It is quite small compared to the other two considered times and remains virtually constant for every considered number of nodes since it corresponds to the execution of a command to start SimulaQron, which is a fast process.  
Therefore, after analyzing the results, we can say that the deployment time consists mainly of two processes: one that grows linearly and corresponds to node instantiation,  
Figure 12: Deployment evaluation results. (**a**) Deployment time as a function of the network node number. For each network, the distribution of the 20 deployments is shown. (**b**) Average percentage that each process represents in a deployment.  
and another that involves node configuration and increases for every group of five nodes due to the maximum number of parallelized tasks supported by Ansible [49].  
As can be seen in Figure 12a, the service allows, for example, having an operational QKD network of 2 nodes in about 3 min, or a larger QKD network with eight nodes in less than 7 min. Thanks to this test, it has been proven that digital twins of QKD networks can be built and made operational in a reduced time-frame.  
Figure 12b shows a diagram of the fractions each process represents of the total deployment time. As discussed, the configuration of the nodes represents more than half of the total time (60.1% of the total), followed by the instantiation process that takes 39.6% of the total time, and lastly, the execution, which corresponds roughly to the 3% of the total.