## 6 Evaluation and Analysis
### Performance Evaluation on the Success Probability and the Max Traffic Supported  
The results of success probability (\(SP\)) versus the number of requests per minute on different topologies are depicted in Figure 4a-d. We set the average keys for one request (\(\varpi\)) as 100 kbits. The \(SP\) on the topology with seven-plane constellation is higher than that on the topology with six-plane constellation, since there are more satellites for QKD on the topology with seven-plane constellation. Obviously, the proposed algorithms perform better than the benchmark algorithms in terms of the success probability. For example, the GF-TAR and LF-TAR algorithms increase the \(SP\) by 44.6% and 47.4%, respectively, compared to the Benchmark-LFU on the six-plane Star topology. This is because the topology abstraction-based routing scheme can fully save the secret keys in the QKP of the link on the abstracted topology. The quantum links are established for immediate requests in benchmark algorithms, and the free time resources are wasted due to the lack of key management. Meanwhile, the proposed algorithms establish the shortest quantum link to ensure the largest number of keys provided to QKPs, which contributes to the success of requests. In addition, on the abstracted topology, the links are increased compared to the  
Figure 3: An example of the 6-plane Star topology with 25 ground stations, 3 GEOs, and a Walker Star constellation containing 66 LEOs. physical topology. Hence, the number of relaying hops will decrease, and fewer keys are wasted due to the relaying operation. It can also create more possible paths for the request to increase the \(SP\). The Benchmark-GFU and Benchmark-LFU have a higher \(SP\) than the Benchmark-GFN and Benchmark-LFN, respectively. This is because the former two benchmark algorithms update the physical topology according to the rest time resources, which can initially prevent the QKD relaying path including some links lacking resources. The Benchmark-LFN and Benchmark-LFU perform better than the Benchmark-GFN and Benchmark-GFU, respectively, since the GEO-based QKD is utilized in the former two benchmark algorithms. Furthermore, the LF-TAR and MS-TAR algorithms perform better than the GF-TAR algorithm, since the GF-TAR does not utilize the GEO satellites for QKD, which decreases the number of secret keys produced. The LF-TAR has a better performance than the MS-TAR in terms of the \(SP\). This is because in the MS-TAR algorithm, the GEO is also included in the abstracted topology, which serves as the same role with the LEO. In this scheme, the GEO actually serves as an LEO with a low secret key rate, which cannot utilize the characteristic of the GEO that has a large coverage. Due to the large coverage of GEO, it can establish quantum links with many sites. However, owing to the limitation of quantum transmitters/receivers that can be carried by a GEO satellite, the number of quantum links established cannot exceed \(l_{\mathrm{h}}\). If we fix the GEO to link with the closest sites, it is not efficient to improve the \(SP\). Furthermore, since the number of secret keys produced by the GEO is relatively low, it does not urgently need the secret key management based on the topology abstraction scheme. In the LF-TAR algorithm, we make the GEO-based QKD as an alternative plan for the LEO-based QKD. It can accurately fulfill the requirements of the requests failed to be fulfilled by the LEO-based QKD. This can effectively utilize the characteristic of GEO that has a large coverage. We also evaluate the max traffic supported on different topologies. Figure 5a shows the results of the max average key volume supported (_MAX_) for different algorithms on the four topologies, where the number of requests per minute is fixed as 300 (i.e., \(\mid R(t_{j})\mid\) = 300) and  
Figure 4: Success probability versus number of requests per minute on the (**a**) 6-plane Star topology, (**b**) 6-plane Delta topology, (**c**) 7-plane Star topology and (**d**) 7-plane Delta topology.