## 6 Simulation Results
### Simulation Results Analysis
When the LBMSA algorithm is used, the number of SLs and SBs occupied in the three networks is increased as the traffic load increases, except for one special case. This special case was found when the simulation data of the NSF network topology was analyzed. Theoretically, the number of SLs and SBs assigned to the traffic request set of 350 Tb/s should be the maximum. However, when the total traffic rate is 350 Tb/s, the number of occupied SLs and SBs is 161 and 4489, respectively, which is less than the number of occupied SLs and SBs when the total traffic rate is 250 Tb/s and 300 Tb/s. The reason for the special case is that, in the same \(\overline{T}_{s,d}\), after the allocation of traffic requests that occupy more SBs, the remaining spectrum resources in each SL happen to carry the traffic requests that occupy fewer SBs. Therefore, the number of occupied SLs is reduced instead. To verify the specificity of this case, three other different 350 Tb/s traffic request sets were generated for simulation. The simulation results are consistent with the theoretical analysis, i.e., the number of SLs and SBs allocated to the 350 Tb/s traffic request set is the maximum. As shown in Figure 6, LBMSA clearly occupies fewer SLs and SBs than the other two algorithms and can save more network resources, which also means that using the LBMSA algorithm can make SCNs have greater throughput. Comparing the KSP algorithm with the KSP-CNs algorithm, the number of SLs and SBs occupied using the KSP-CNs algorithm is slightly smaller than the number in the KSP algorithm. This shows that even without MFC, segmenting the entire routing path and using a flexible MF is effective. Comparing the LBMSA algorithm with the KSP-CNs algorithm, there is a significant difference in the amount of network resources occupied by the two algorithms because LBMSA can perform MFC at the CNs. This illustrates the importance of introducing MFC into SCNs in this paper. Figure 6: (**a**) The number of occupied SLs and SBs for the different traffic loads in the simple mesh network; (**b**) The number of occupied SLs and SBs for different traffic loads in the Japan network; (**c**) The number of occupied SLs and SBs for different traffic loads in the NSF network. In Figures 7 and 8, the utilization of MFs and MFC in three network topologies is analyzed. We obtained the number of traffic requests that were not end-to-end requests under different traffic load scenarios and calculated the percentage of those traffic requests that performed MFC. It can be obtained that the adoption of different MFs and MFC is related to the average SDM link length of the network topology and the use of MFC is also related to the total traffic rate. In the simple mesh network topology, QPSK and DP-QPSK (with maximum achievable transmission distances of 1000 km and 2000 km, respectively) are used most frequently because of the average SDM link length of 1063 km and the small SDM link length variance. As a result, in Figure 8, multiple CNs are set up to perform MFC to carry traffic requests using more efficient MFs. When the total traffic rate is 200 Tb/s, the percentage of traffic requests performing MFC even reaches 85%. This also proves that when the traffic attempt rate in the network is small, the LBMSA algorithm takes maximizing network resource utilization as the primary goal. Since the average SDM link length of the Japan network topology is small, more efficient MFs, such as DP-8 QAM, DP-16 QAM, and DP-32 QAM are effectively utilized. Meanwhile, the SDM link length variance in the Japan network topology is large, so CNs and MFC are used more frequently than in the simple mesh network topology. This is why the number of SLs and SBs occupying the Japan network topology is always less than that of a simple mesh network when the traffic rates are the same. The average SDM link length in the NSF network topology is 1936.36 km, therefore, the inefficient BPSK and QPSK are used many times, which is consistent with the analysis above.